I installed freeipa-server in a VM and ran the installer. But in the end it wouldn't start. Through the logs I found out it was timing out. The strange thing was that it appeared to start as soon as systemd tried to kill it for taking too long. Using strace I found the problem. rndc-confgen tries to read from /dev/random, but this doesn't work or at least takes too long. I ran rndc-confgen manually with the keyboard option then updated the permissions that the script does. Now bind starts with no problem. I'm not sure what the proper solution here should be. Maybe it could have a timeout on reading /dev/random and switch to /dev/urandom if it's taking too long?
(In reply to Samuel Sieb from comment #0) > I installed freeipa-server in a VM and ran the installer. But in the end it > wouldn't start. Through the logs I found out it was timing out. The > strange thing was that it appeared to start as soon as systemd tried to kill > it for taking too long. Using strace I found the problem. rndc-confgen > tries to read from /dev/random, but this doesn't work or at least takes too > long. I ran rndc-confgen manually with the keyboard option then updated the > permissions that the script does. Now bind starts with no problem. > > I'm not sure what the proper solution here should be. Maybe it could have a > timeout on reading /dev/random and switch to /dev/urandom if it's taking too > long? Hi. I don't think we want to trade the cryptographic strength of the generated key for the speed. You can always prolong the timeout in named.service or generate the key manually. What we could do here is to add some reasonable log message so it is simpler to find out what is happening.
Sure, I understand. Maybe if I had let the VM run a bit longer before installing FreeIPA it would have been ok, but it's quite likely that someone would be setting it up right after creating the VM like I did. And it provided a pretty bad experience. I expect that most people wouldn't have been able to figure out what happened.
Hi. After discussing with our Security Engineer I'll switch to using /dev/urandom when generating the rndc.key.
Please don't do that. FreeIPA already solved that problem in newer version of installer.
It is not FreeIPA-only issue. It happens also on VMs after installation, when there is not enough entropy. I discussed this with Florian Weimer...
Fixed in: bind-9.9.4-13.P2.fc20 bind-9.9.5-5.fc21
the proper solution in a virtual machine would be yum install haveged systemctl enable haveged systemctl start haveged using /dev/urandom only *burries* the real problem that you don't have cryptographic useable, unpredictable random numbers inside a VM frankly for fedora cloud-images "haveged" should be part of the default install
Harald, thanks for the info. I hadn't heard of that package before and may use it in the future. However, the issue here is not that the VM can't generate enough entropy, it's just that at initial bootup there isn't any to start with. I don't see how haveged would solve that issue since it would still require some time as well. Or does it have some way of generating it that much quicker?
haveged generates random numbers *very quickly* i would say constantly 2 MB per second is enough for nearly anything [root@south:/data]$ dd if=/dev/random of=random.bin ^C0+189499 records in 30334+0 records out 15531008 bytes (16 MB) copied, 7.282 s, 2.1 MB/s [root@south:/data]$ dd if=/dev/random of=random.bin ^C0+229088 records in 36673+0 records out 18776576 bytes (19 MB) copied, 8.72872 s, 2.2 MB/s
If that is good quality random data, then that would certainly solve the issue for me and would be better than /dev/urandom. Now I'm kind of curious how they are able to do that.
why not simply use Google? :-) http://www.issihosts.com/haveged/ http://www.irisa.fr/caps/projects/hipsor/
bind-9.9.4-15.P2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bind-9.9.4-15.P2.fc20
Package bind-9.9.4-15.P2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing bind-9.9.4-15.P2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8477/bind-9.9.4-15.P2.fc20 then log in and leave karma (feedback).
bind-9.9.4-15.P2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.