On 2012-04-12 at 07:52 -0700, Yan Seiner wrote:
> Seems to be a TLS entropy issue? (I'm guessing here but from reading what
> I've been able to it looks similar.)
>
> Yesterday the messages were persisting for hours, and there was upwards of
> 100 stalled at a time.
>
> Not sure what I can do to help the entropy issue. It may just be that
> I've had a huge rsync job running for days and if it's using the same pool
> it could be draining all the entropy faster than the system can generate
> it. I don't know enough about how entropy works to make more than guesses
> from googling....
Options:
* don't use TLS for talking to so many hosts;
* send less email;
* use a different TLS provider; eg, see if building Exim against
OpenSSL fixes issues encountered by GnuTLS, or vice versa;
* generate more entropy on the system.
To generate more entropy on the system, and have it be real entropy, you
need to inject something used to feed the system entropy pool. Almost
anything you do here from outside will be unreliable.
Your best option for entropy increase (besides checking OS release notes
to see if an upgrade will help) is a hardware change. You can add an
entropy-generation source (PCI card, typically as part of an encryption
off-load system; Soekris have some decent affordable cards here) and
there are some more listed at:
http://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators
Soekris:
http://soekris.com/products/vpn14x1.html
(although I'm not sure of the Linux support there).
Alternatively, some modern CPUs provide hardware entropy sources; for
Intel, that's still coming:
http://en.wikipedia.org/wiki/RdRand
while VIA x86 CPUs have had it for a long time:
http://www.via.com.tw/en/initiatives/padlock/hardware.jsp
and TPM chips also often have hardware entropy generators.
These might help:
https://lwn.net/Articles/283103/ "Appropriate sources of entropy"
http://en.wikipedia.org/wiki/Entropy_%28computing%29
-Phil
