I'm still seeing "booting disallowed" message (and resulting failures to get addresses) for hosts which should be getting addresses. This is identical to the issue in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131212 I'm currently running dhcp-3.0.3-22.FC4 but the stock version fails as well. I have the following group set up: group { deny booting; host a {hardware ethernet 00:11:11:53:61:b3; } host b {hardware ethernet 00:10:5a:29:62:f8; } host c {hardware ethernet 00:08:74:2a:6c:ea; } host d {hardware ethernet 00:0d:61:46:8f:24; } host e {hardware ethernet 00:30:bd:1f:18:05; } } But other hosts are being denied: > s grep -h 'booting disallowed' /var/log/messages*|egrep -v '00:10:5a:29:62:f8|00:0d:61:46:8f:24|00:11:11:53:61:b3|00:30:bd:1f:18:05|00:08:74:2a:6c:ea'|sed -e 's/.*util9 //'|sort|uniq -c 60 dhcpd: DHCPDISCOVER from 00:08:0d:6d:9b:0b via eth0: booting disallowed 25 dhcpd: DHCPDISCOVER from 00:0a:95:bb:f5:48 via eth0: booting disallowed 72 dhcpd: DHCPDISCOVER from 00:0a:e4:26:21:1b via eth0: booting disallowed 19 dhcpd: DHCPDISCOVER from 00:0f:b0:3e:d3:a6 via eth0: booting disallowed 36 dhcpd: DHCPDISCOVER from 00:0f:b0:83:a1:c5 via eth0: booting disallowed 6 dhcpd: DHCPDISCOVER from 00:11:25:2b:e0:ee via eth0: booting disallowed 12 dhcpd: DHCPDISCOVER from 00:11:43:78:c4:71 via eth0: booting disallowed 1 dhcpd: DHCPDISCOVER from 00:15:f2:03:ef:7f via eth0: booting disallowed 6 dhcpd: DHCPDISCOVER from 00:c0:9f:1c:05:c0 via eth0: booting disallowed 4 dhcpd: DHCPDISCOVER from 00:d0:b7:5a:f8:0f via eth0: booting disallowed
Very strange. I just tested this again with a dhcpd.conf very similar to yours - thanks alot for sending it - but again I could not reproduce the problem. Please try to reproduce this problem with the latest dhcp-3.0.2-34.FC4 RPMs, now released to FC-4/Updates - I used dhcp-3.0.2-34.FC4, and had no such problem. I only have two dhcp clients to play with for testing - so I set one up to be denied : /etc/dhcpd.conf: ... group { deny booting; host jvdias { hardware ethernet 00:0d:60:cf:98:e3; } } ... And had a subnet declaration with a range statement, based on your subnet declaration . But ONLY host 00:0d:60:cf:98:e3 gets denied - I tried both booting up the 'allowed host' first, and then booting up the 'denied' host first, but ONLY the 0:0d:60:cf:98:e3 host ever got denied: dhcpd: dhcpd startup succeeded dhcpd: DHCPDISCOVER from 00:0d:60:cf:98:e3 via eth0: booting disallowed dhcpd: DHCPDISCOVER from 00:0d:60:cf:98:e3 via eth0: booting disallowed dhcpd: DHCPDISCOVER from 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPOFFER on 64.32.16.14 to 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPREQUEST for 64.32.16.14 (64.32.16.9) from 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPACK on 64.32.16.14 to 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPDISCOVER from 00:0d:60:cf:98:e3 via eth0: booting disallowed dhcpd: DHCPRELEASE of 64.32.16.14 from 00:a0:cc:34:cd:26 via eth0 (found) dhcpd: DHCPDISCOVER from 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPOFFER on 64.32.16.14 to 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPREQUEST for 64.32.16.14 (64.32.16.9) from 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPACK on 64.32.16.14 to 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPREQUEST for 64.32.16.14 from 00:a0:cc:34:cd:26 via eth0 dhcpd: DHCPACK on 64.32.16.14 to 00:a0:cc:34:cd:26 via eth0 dhcpd: dhcpd shutdown succeeded So I'm not able to reproduce this problem. Please supply some further information : 1. What architecture is your machine - ie. i386 / x86_64 ? 2. Do you have SELinux in enforcing mode ? If so, does the problem persist after you do: # setenforce 0 # service dhcpd restart 3. If the answer to (2) is yes, then please gather a dhcpd trace file - this should tell us exactly why dhcpd is denying booting to those hosts: a. Edit /etc/sysconfig/dhcpd to contain: DHCPDARGS='-tf /tmp/dhcpd.trace.log' b. Put SELinux into Permissive mode: # setenforce 0 c. Restart the dhcpd: # service dhcpd restart d. Then, when the problem has been reproduced (a client NOT in the 'deny booting' group is denied booting) # service dhcpd stop remove the '-tf' argument from /etc/sysconfig/dhcpd # gzip /tmp/dhcpd.trace.log e. Email the /tmp/dhcpd.trace.log.gz file to me (jvdias) . 4. If the answer to (2) was no, then please append the output of this command to this bug report: # audit2allow </var/log/audit/audit.log Thank You!
Thanks for your response. I didn't see the update in my most recent mirror pull but I'm sure I'll get it tomorrow. The problem is that this issue pops up infrequently; when I moved to FC4 I thought it had been fixed but it took a couple of days before the denials started showing up. So it's not going to be simple to reproduce; you'll need to try it on a fairly active server to see problems. However, this bug has been around since FC2 at least. The dhcp mailing list has plenty of related discussion, although none for several months which gave me hope that it had been fixed. I will gather further information for you tomorrow.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
I no longer have the configuration needed to reproduce this issue, so I suppose it's best to close this.
I ended up needing to disallow booting to a particular host again, and it seems this is still a problem with current RHEL5. I have no RHEL support (academic site license) so I'm not sure how I should proceed, but I'll try to move DHCP service to an F9 machine and see if I can reproduce.