The new init.d script for dhcpd runs a "/usr/sbin/dhcpd -cf ${DHCPD_CHROOT}/${DHCPD_CONF} -t" and checks the result before allowing dhcpd to start. However, this fails when using chroot and include files. Example: DCHPD_CHROOT is set to /var/chroot/dhcp /var/chroot/dhcp/etc/dhcp/dhcpd.conf is valid, and contains: include "/var/nfs/master/dhcpd.master" This causes the init.d script to execute the following: /usr/sbin/dhcpd -cf /var/chroot/dhcp/etc/dhcpd.conf -t However, when not run from within the chroot jail, the include line is likely not valid, and an error is the result: Internet Systems Consortium DHCP Server V3.1.2p1-Gentoo Copyright 2004-2009 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Can't open /var/nfs/master/dhcpd.master: No such file or directory ... because it didn't look for /var/chroot/dhcp/var/nfs/master/dhcpd.master which is the correct include name when run in a chroot jail. It doesn't have to point to an nfs directory, of course, includes like these will fail as well: include "/etc/dhcp/dhcpd.master" include "../intranet1/dhcpd.include" To summarize, /etc/init.d/dhcpd has outsmarted itself. It should not call -t at all unless it can do so from within a chroot context. Else, the test will not be valid. What added value does inserting the -t test give? I mean, if there's an error in the config files, dhcpd won't start anyhow. If the init.d script ran a -t test IF AND ONLY IF dhcpd failed to start, I could understand, but to run it BEFORE starting adds no value.
Created attachment 201716 [details, diff] dhcpd-init2-fix.patch We encountered the same problem at the OSL when we upgraded dhcpd for the latest GLSA. It looks like the new init script incorrectly deals with chroot'd dhcp setups. I used the same logic from the start section of the script and applied it to the configtest section. I tested it on both chroot and non-chrooted dhcpd setups and it appears to work properly now. You should fix this ASAP before other people encounter this problem. Cheers-
While the patch deals with the chroot situation, it still won't work when the master file is on an NFS mount with root_squash (recommended), unless the file is world readable (not recommended). The test runs as root, unlike the dhcpd process which runs as a user, and thus the test fails when root is disallowed from reading the include file. Similar for selinux or file systems with ACLs, I should think. Yeah, you can patch that too by adding -user and -group as appropriate, but what's the point? It doesn't add any value whatsoever, because any errors -t catches are also caught by attempting to start the daemon. If the daemon doesn't start, THEN the script can run -t to (try) to find out why, but if it DOES start, -t only adds to the startup time without giving any benefit. Most distros try to reduce startup time, not increase it.
(In reply to comment #2) > While the patch deals with the chroot situation, it still won't work when the > master file is on an NFS mount with root_squash (recommended), unless the > file is world readable (not recommended). The test runs as root, unlike the > dhcpd process which runs as a user, and thus the test fails when root is > disallowed from reading the include file. Similar for selinux or file > systems with ACLs, I should think. > > Yeah, you can patch that too by adding -user and -group as appropriate, but > what's the point? It doesn't add any value whatsoever, because any errors -t > catches are also caught by attempting to start the daemon. If the daemon > doesn't start, THEN the script can run -t to (try) to find out why, but if it > DOES start, -t only adds to the startup time without giving any benefit. > Most distros try to reduce startup time, not increase it. The point is, you don't want to stop a critical service if there's a config syntax error. DHCPD will *not* start if there's a syntax error, so if you test it afterwards your service will be broken. Testing it afterwards is pointless since you would have stopped the process at that point. Doing the check before allows you to keep the service running while you fix the config error. We probably should add -user/-group to the check so that its the same, but I don't know many people who are running DHCP via NFS ;-)
ive included this in dhcp-4.2.1. i'll leave open in case someone wants to also add to dhcp-3.x.
dhcp-4.x is stable now. dhcp-3.x is dead.
