Bug 178395 - disklessrc sets a bogus NIS domain name
disklessrc sets a bogus NIS domain name
Product: Fedora
Classification: Fedora
Component: system-config-netboot (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fabio Olive Leite
Depends On:
  Show dependency treegraph
Reported: 2006-01-19 21:32 EST by Konstantin Olchanski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 0.1.38-2_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-23 09:28:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Konstantin Olchanski 2006-01-19 21:32:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.3.2

Description of problem:
Typically, the NIS domain name (`domainname`) is set somewhere in the rc scripts to the value of NISDOMAIN from /etc/sysconfig/network. However this does not work when using disklessrc, because it sets the domain name to a bogus value (in my case, "triumf.ca"). This undesired behaviour cannot be overriden, other than by editing the disklessrc file.

Suggested solution: comment out these lines in disklessrc:

	   #if [ -n "${dname}" ] && [ "${dname}" != "${dhdname}" ]; then
	   #    /sbin/domainname ${dname}
	   #    echo "Domain Name set to ${dname}"

or make it possible to override the domainname from the kernel command line (e.g . append initrd=... DOMAINNAME=foo).


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

How reproducible:

Steps to Reproduce:
1. blah...

Additional info:
Comment 1 Jason Vas Dias 2006-01-20 12:41:24 EST
The best way to "override" the domainname set by disklessrc is to either:

  o Set the DNS PTR record for the IP address allocated to the host to
    end with the correct domainname in the DNS - I think this is where the 
    'triumf.ca' domain is coming from in your case.
  o Set the dhcp 'nis-domain' option to contain the correct NIS domain name
    in the dhcp server
  o Set the dhcp 'host-name' option to contain the correct domainname
    in the dhcp server - this will override the DNS domainname .

The NISDOMAIN option will also be honoured by the 'ypbind' initscript
IF the domainname of the machine is set to '(none)' or '', so you could
also fix this by setting NISDOMAIN, setting the domainname to '' in an
initscript run before the ypbind service is started .

You should really make the domain name correct in the DNS, 
which is what is obtained by disklessrc if the dhclient-script did not
set the domainname from the DHCP nis-domain option.

As there are many workarounds for this issue, and I believe an extra DOMAINNAME
/ NISDOMAIN boot option would simply confuse the issue, and what disklessrc is
doing is basically correct, I think this is NOTABUG .
Comment 2 Konstantin Olchanski 2006-01-22 23:27:18 EST
For the record: I disagree with the "not-a-bug" assessment. Regardless of one's
definition of a bug, here we have "unexpected behaviour" that (imho) should be
corrected. The expected behaviour is that of normal booting from disk, where
grub, initrd, linuxrc & co do not try to second guess the NIS domain name. K.O.
Comment 3 Jason Vas Dias 2006-03-01 13:41:12 EST
OK, I've now added an 'Enable NISDOMAIN' checkbox and 'Set $NISDOMAIN' entry
in the GUI, with system-config-netboot-0.1.38+.

If only 'Enable NISDOMAIN' is checked, the 'NISDOMAIN=(none)' boot option is
added, and disklessrc will not set the domainname, allowing the ypbind init
script to respond to whatever NISDOMAIN is set to in /etc/sysconfig/network
in the client root.

If the 'Set NISDOMAIN' entry is filled out, then the GUI will also add the 
NISDOMAIN= setting to /etc/sysconfig/network.

Please try out the new version, available from:
and let me know of any issues - thanks.
Comment 4 Fedora Update System 2006-03-01 17:01:04 EST
From User-Agent: XML-RPC

system-config-netboot-0.1.38-2_FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

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