Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155143 - DHCP can not set hostname
Summary: DHCP can not set hostname
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
 
Reported: 2005-04-16 23:28 UTC by David Kuestler
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 1.25.4-10.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-15 15:56:44 UTC


Attachments (Terms of Use)
debugging dhclient-script (deleted)
2005-04-17 22:28 UTC, Jason Vas Dias
no flags Details

Description David Kuestler 2005-04-16 23:28:57 UTC
Description of problem:
DHCP client configured FC4T2 install will not set the hostname.

Version-Release number of selected component (if applicable):
dhcpclient-3.0.2-7

How reproducible:
Install using DHCP network.

Steps to Reproduce:
1. Configure DHCP server to provide hostname and other parameters through 'host'
clauses.
2. Install FC4T2 for DHCP network.
3. Boot client.
  
Actual results:
message during boot:
"hostname: you must be root to change the host name"
the host name is picked up from the DNS.

Expected results:
The host name to be set by the DHCP server.

Additional info:

Comment 1 Jason Vas Dias 2005-04-17 22:26:43 UTC
I cannot reproduce this problem.

This message indicates you are not running dhclient as root:

"hostname: you must be root to change the host name"

dhclient can ONLY be run as root; because it is not in your case,
it cannot set the hostname (or configure the interfaces, or restart
the servers...).

If you are running dhclient as part of normal boot up sequence, 
it will be run as root and the message above would not be generated.

To determine what is going on in your case, please download the 
attached file "dhclient-script-dbg" and then, as root, run the
following commands:

# mv /sbin/dhclient-script /sbin/dhclient-script-real
# mv dhclient-script-dbg /sbin/dhclient-script
# chmod +x /sbin/dhclient-script
# mkdir /tmp/dhcp
# cp /etc/sysconfig/network /tmp/dhcp
# cp /etc/sysconfig/network-scripts/ifcfg-* /tmp/dhcp
# hostname localhost
# service network restart
# hostname >> /tmp/dhcp/hostname-after
# tar -cpvf /tmp/dhcp-dbg.tar /tmp/dhcp
# mv /sbin/dhclient-script-real /sbin/dhclient-script




Comment 2 Jason Vas Dias 2005-04-17 22:28:34 UTC
Created attachment 113296 [details]
debugging dhclient-script

Comment 3 Jason Vas Dias 2005-04-17 22:29:40 UTC
Then please attach the resulting /tmp/dhcp-dbg.tar to this bug.
Thank you!

Comment 4 David Kuestler 2005-04-18 12:43:15 UTC
alas there was no attachment to your email :-( please attach.

meanwhile here is a cut down and modified version of my dhcp server's
dhcpd.comf with further notes after :

############################################
authoritative;
server-identifier my_server.localdomain;

option domain-name "localdomain";
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.198;
option domain-name-servers 192.168.0.199;

ddns-update-style ad-hoc;

# Known machines
group {

   use-host-decl-names on;
   option log-servers 192.168.0.197;

   default-lease-time 100000;
   max-lease-time 200000;

# the client's host name should be set to 'the_name'
   host the_name {
     hardware ethernet aa:bb:cc:dd:ee:ff;
     fixed-address 192.168.0.100;
   }
}

# Visitors
subnet 192.168.0.0 netmask 255.255.255.0 {

   range 192.168.0.160 192.168.0.170;

   default-lease-time 3600;
   max-lease-time 3600;

}
############################################

This has been working for years, it allows me to hand out the same
fixed IP address to the machine with the associated ethernet address.
Note the host name should be set to 'the_name' instead the name is
picked up from the a reverse DNS lookup.
I presume the dhcp client would somehow run '/bin/hostname the_name'
which, while booting, would be run as root.
The more precise ( though not exact ) line I see on booting is :
"Determining IP address .... hostname: you must be root to change the
host name"

Could SELinux be barring this action ?

Comment 5 Jason Vas Dias 2005-04-18 13:59:15 UTC
The 'dhclient-script-dbg' script is attached to this bug report,
not the emails - please access it through bugzilla. 
Do you have SELinux enabled in "Enforcing" mode ? 
  # getenforce 
  Enforcing
This could be part of the probelm. Does the problem persist with
SELinux in permissive mode / disabled ?
Please download the attachment recreate the problem as described
above. Then repeat with 
  # setenforce 0 
Does the problem persist?
Thanks!



Comment 6 Jason Vas Dias 2005-04-18 18:26:03 UTC
 I've now managed to reproduce this bug, and produce a fix in 
 dhcp-3.0.2-8 , which should be in rawhide-20050419 - meanwhile,
 you can download it from:
  http://people.redhat.com/~jvdias/dhcp/FC4 

 This problem was caused by selinux-policy-targeted for dhclient. 
 
 The problem was that when dhclient runs during boot in context
     'system_u:object_r:dhcpc_exec_t'
 it cannot:
    o modify ANY configuration files
      (/etc/resolv.conf, /etc/yp.conf, /etc/ntp.conf, 
       /etc/ntp/step-tickers)
    o run /sbin/restorecon
    o run /usr/sbin/hostname or /usr/sbin/domainname
 For some reason, when dhclient is run out of the boot sequence,
 eg. by root command "service network restart", then it is allowed
 to modify the configuration files and run restorecon and 
 {host,domain}name. This may have something to do with the context
 of /etc/sysconfig/network-scripts/ifup-eth, from which dhclient is
 run, being 'system_u:object_r:etc_t' and not /sbin/ifup's 
 system_u:object_r:sbin_t .

 The temporary workaround, until SELinux policy is fixed, is to
    # chcon system_u:object_r:sbin_t /sbin/dhclient*
 in the dhclient-3.0.2-8.*.rpm %post script.
 The "restorecon"s are also restored in this version and now work.


Comment 7 David Kuestler 2005-04-18 20:40:01 UTC
Yes when I run selinux in permissive mode it works as expected.
I look forward to the SELinux policy fix.
Thanks.

Comment 8 Jason Vas Dias 2005-04-18 20:51:04 UTC
You should update to dhcp-3.0.2-8, because the configuration files
updated by dhclient may end up with the wrong SELinux labels.


Comment 10 Jason Vas Dias 2005-04-28 15:27:02 UTC
This should now be fixed with the latest selinux-targeted-policy in rawhide 
/ FC4t3 + dhcp-3.0.2-10+ . 


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