There is a problem with /dev/random and mod_auth_digest that makes apache hanging on manual restart. If you restart apache2 by hand doing /etc/init.d/apache2 restart or /usr/sbin/apache2 -k restart then it starts just one process an in the error logfile the line: [Mon Nov 24 10:59:06 2003] [notice] Digest: generating secret for digest authentication ... appears and nothing else happens. It can be solved by disabling mod_auth_digest, but the reason for this is an empty /dev/random-device, so the apache2-startprocess is just waiting for randomness. Solution for me (without disabling mod_auth_digest): MY_BUILTINS="--with-devrandom=/dev/urandom" emerge apache This makes /dev/urandom the source for randomness on startup and all is fine.. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I saw this problem myself today. I disabled that module, but obviously this is unreasonable for people who need it.
du -h /usr and your machine's disk will spin, and apache will start much quicker.
This isn't a bug for us, and using /dev/urandom is insecure. you need to make more entropy for your machine. lots of other things will exhibit the same problem for lack of real random data (appearing to hang).
The bug is imho that there is no way for the not so experienced user for knowing what is happen.. Look at the forum, there are many questions about this. The startup-script returns as usual with [ok], but this isn't true. There shoul'd be a check, if apache has spawned the workers. If this doesn't happened, then maybe an action like 'du -s /path/to/apache' for gathering randomness and a retry.
impairing everybody to do a 'du -h /path/to/apache' is not a reasonable answer. look at alternate routes for more entropy data. possible routes include hardware RNG (see recent kernels), net-dev-randomness patches (in gentoo kernels i believe), or any other routes, look in up in the linux kernel mailing list archive. audio-entropyd is one possible route if you have an idle soundcard.
I'm not sure for this, but is net-dev-randomness secure? Or at least more secure as /dev/urandom? The possible solutions are ok, but I think there should be a check in the startup script if apache comes up with the workers or is just waiting.. Is there a way for doing a check of /dev/random?
Look in /proc/sys/kernel/random/ The way I see it with netdev-random, is since it uses the timing between network IRQs (not the data itself), the only way it can be seriously subverted is if an attacker has total control over your ethernet cable, in which case you have more serious problems anyway. /dev/urandom uses an SHA hash to cycle itself. I've added an interesting rng package to the tree, clrngd. see bug 26071 for the netdev-random waiting for gentoo-sources.
*** Bug 37981 has been marked as a duplicate of this bug. ***
note to self: mod_auth_digest needs 20 bytes of raw entropy to start. need to write some stuff for init.d that checks if enough entropy is available, and display warning otherwise.
Hi, I agree something has to happen with the ebuild. I went to reinstall openssl, but that didn't help. Using strace on openssl I see it uses /dev/urandom. Why isn't egd and prngd available on gentoo. They are both used to generate said to be fairly good random data. Actually, the egd guy said that prngd is crap. That would affect openssl has to rebuilt to use the socket file. Please stick to teh default location and don't invent new place for it. I think it's /var/tmp/egd-pool or something similar.
It seems the folks at Redhat faced this problem previously and have solved it by changing /dev/random to /dev/urandom: http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=103049
security: while i don't like the idea of using psuedo-random bits (/dev/urandom instead of /dev/random) for this, you're better qualified to tell me if it's safe to do this in this case.
Re #5 The hardened-dev-sources support netdev-random. Our patches are broken out so any other kernel could include them rather trivially. Note: netdev-random does not work with pcmcia devices. Another kernel patch we are about to start reviewing. http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm4/broken-out/urandom-scalability-fix.patch --- Re: not secuirty@ just my own thoughts. I would not want to use the /dev/random device for apache.. random is a blocking device where urandom is not. Your free do do what you want.. But I/me would also prefer urandom over random in this case. Note: You can raise the entropy pool size by simply doing (this helps) sysctl -w kernel.random.poolsize=8192 And to see the current amount of random data. sysctl kernel.random.entropy_avail
*** Bug 45527 has been marked as a duplicate of this bug. ***
This should be fixed in 2.0.49-r1. Please test.
I, for one, am still seeing this happen on my boxes. Is there a regression?
This should be fixed, though the fix is still in ~arch and not arch. Please see bug 102587 for details of the fix and how to activate it on your system
