Bug 59563

Given the dhcpcd-1.3.21-noNISfakery.patch that I added in 1.3.21-3, I find it
hard to believe that it is happening in -4. Would it be possible for you to do
some debugging with the source from -4 to verify that it is really using the DNS
domain setting incorrectly on the client side?

I can only tell you that 7.2 dhcpcd was using "nis-domain" to enter it in
"search" line of /etc/resolv.conf before "domain-name". That was also a
non-desired behaviour but with no catastrofic consequences. I have not yet
checked what is being put in /etc/resolv.conf in 7.2.90.
My "domain-name" and "nis-domain" are very different and NIS domain is in UPPER
CASE. Domainname is definitely been set to "nis-domain" and upper case is
preserved in output of "domainname" command.

Whoa, I'm a little confused here.

When you were talking about 'domainname' I assumed you meant NIS domain name,
since "DNS domain name" has no clear definition on UNIX... Are you talking about
the DNS domain searches in /etc/resolv.conf (in which case I will ask "what
exactly is the bug?") or the NIS domain name (in which case I will ask you to
find out why my patch isn't having any effect).

Sorry if my comments about resolv.conf confused you.

The original description is correct: NIS client stopped working after upgrade
7.2 to 7.2.90 because dhcpd broadcased "nis-domain" is ignored by dhcpcd and
instead dhcpd broadcasted "domain-name" is used. I have to manually set
domainname to the proper value and restart ypbind every time my system is rebooted.

Are you able to duplicate the problem?

Here, my NIS domain is supposed to be "redhat.com" and DNS search should be
"devel.redhat.com".

resolv.conf gets set up fine, but NIS domain does not get changed - it appears
that there is some mismatch between the ypbind initscripts (which check
/etc/sysconfig/network for the NISDOMAIN) and dhcpcd (which only writes out
/etc/yp.conf and doesn't touch anything else).

The correct solution is a puzzlement...

I have a patch already in 1.3.21pl2-5 that does the setdomainname() - should fix it.

Upgraded clean 7.2 to beta2. Same problem as beta1.

$ rpm -qa | grep dhcp
dhcpcd-1.3.21pl2-5

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
DHCPCDARGS="-D -H"


From RH 7.2 based dhcpd.conf
...
option domain-name "DNSDOMAIN.com";
option nis-domain-name "NISDOMAIN.com";
...

After beta2 boot:

# domainname
DNSDOMAIN.com

Should be NISDOMAIN.com as it is currently in RH 7.2

Am I correct in assuming that dhcpcd is actually setting the NIS domain when it
initializes the interface (and it's not just leaving the existing setting intact)?

you are correct. This is a fresh install and changes to config files are only
those specified above. dhcpcd is actually setting NIS domain, because I did not
modify any other files after fresh install. I am not aware of any other settings.

Ahahh, dhcpcd sucks. If you don't pass the -D flag, my previous hack patches
will make it do the proper setdomainname.

Since -D is not the default, it's half your fault :) The other half of the
problem is dhcpcd's implementation of the -D option, which needs fixing at a
later date if we still use dhcpcd.

Well, I *had* to do "-D" on RedHat 7.2 because I followed man page and it worked
(almost, 99%) the way I wanted. Man page still says that -D is needed.

You are right, beta4 sets nisdomain and domain search path properly out of the
box. I am very pleased. Seems like man page and/or install document needs to be
adjusted appropriately. Someone else might read it and apply -D with wrong results.

There is a mismatch between actual behavior of dhcpcd and its manual page. It
has always been a requirement to report problems like this.
What does WONTFIX mean in this case?