This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 183531 - "booting disallowed" for hosts to which booting is not denied
"booting disallowed" for hosts to which booting is not denied
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-01 15:01 EST by Jason Tibbitts
Modified: 2008-09-19 18:15 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-22 19:27:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jason Tibbitts 2006-03-01 15:01:03 EST
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
Comment 1 Jason Vas Dias 2006-03-01 16:13:34 EST
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@redhat.com) .

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!
Comment 2 Jason Tibbitts 2006-03-01 16:34:53 EST
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.
Comment 3 Christian Iseli 2007-01-22 05:26:59 EST
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.
Comment 4 Jason Tibbitts 2007-01-22 19:27:45 EST
I no longer have the configuration needed to reproduce this issue, so I suppose
it's best to close this.
Comment 5 Jason Tibbitts 2008-09-19 18:15:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.