CAcert System Admins discussion list

[Wytze van der Raay <wytze AT cacert.org>]

On 12/30/2010 04:28 PM, Guillaume ROMAGNY wrote:
> ...
> ok good, so BIT only (once upon a time) managed the others non critical
> SSL  connexions.

That's right: all the other SSL connections were and are still going
through the (Tunix-managed) firewall (which runs a FreeBSD-type OS).

> ...
> Of course not we cannot tell about the quality of the entropy without
> doing a "dd" of /dev/random to a file of a minimum size of 12 MB to do a
> diehard, ent or dieharder test.
> 
> at least, there is some data in the pool and we can expect the kernel to
> provide good enough quality based on the randomness from network card
> interruptions. Afaik, the linux kernel is pretty conservative on what is
> put in /dev/random
> 
> So unless we have a top number of SSL connections, the entropy pool is fine.

Agreed :-)

> Newbie remark : do we have a collectd on the systems to monitor the
> system parameters ? I have recently discovered collectd and  the kde
> kcollectd to watch the data collected. I configured it when I was
> testing the hardware entropy key to compare the size of the pool when
> "dd"-ing from /dev/random or /dev/urandom.

We don't run any of that right now ... in fact we try to limit the number of
processes on the critical webdb server to an absolute minimum. But it might
not be such a bad idea to run something like this in the future, especially
after we've moved to better hardware. Thanks for suggesting it!

> ...
> I do agree the bottleneck is not the entropy pool unless we have 200+
> (?) SSL connections at the same time. So we are happy.

Thanks for the input!
Regards,
-- wytze

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature