Hi.

When installing Debian Squeeze on amd64-based clients in a NIS
environment, where the NIS domain name is supplied as DHCP option
nis-domain "Some_NIS_Domain+01" (containing the special character '+')
setting the additional class NIS through

<code>
#!/bin/sh
# add NIS if YPDOMAIN is defined
if [ -n "$YPDOMAIN" ];then
   echo "NIS $YPDOMAIN" | tr '.a-z-' '_A-Z_'
fi
</code>

fails without further notification.

Changing the plus sign in the NIS domain name to minus or underscore
setting the NIS domain on the install client works just fine.

As a workaround, one can explicitly define the NIS class for each
client, but that's redundant as the information is already
supplied through dhcp and and also a little anoying.

Exactly the same scenario described above used to work for both, Etch
and Lenny installations, using something like 'Some_NIS_Domain+01' as
NIS domain name.

I tested this with 3.4.7 from the official Squeeze tree and with 3.4.8
from fai-project "koeln" repository for Squeeze, but the result was the
same.

Please contact me if you need any further information.

Best regards,
 Michael

Hi Michael,
[...]

May I ask you for the following further information?

- Is it correct that the above code is executed as part of some script in
  class/? What is the name of that script?
- What exactly do you refer to as "fails" - is it that the resulting classes do
  not contain "NIS" (and neither do they contain "$YPDOMAIN")?
- Did you try to add debugging information like echo'ing "my XXYPDOMAIN:
  XX$YPDOMAIN" (which might in your case result in XX only, if $YPDOMAIN turns
  out to be empty)?
- What is the contents of boot.log on your client?

Greeting to Darmstadt,
Thanks a lot,
Michael

Hi Michael,

thanks for looking into this!

Yes, that's right.  The script is $FAI_CONFIGDIR/class/60-nis with
permissions 755.

Exactly.
with "XX" in the resulting classes list.  So $YPDOMAIN obviously remains
unset (or empty?).

Here's the snippet from fai.log:
<...>
/usr/bin/fai-class: File 60-nis found.
Executing /var/lib/fai/config/class/60-nis.
60-nis               OK.
/usr/bin/fai-class: Adding class XX
<...>
The boot.log file on the client contains the following lines:

netdevices_all="eth0"
netdevices_up="eth0"
netdevices="eth0"
BROADCAST='192.168.0.255'
DOMAIN='my.network.domain'
DNSSRVS='192.168.0.11 192.168.0.12 192.168.0.13'
DNSSRVS_1='192.168.0.11'
DNSSRVS_2='192.168.0.12'
DNSSRVS_3='192.168.0.13'
HOSTNAME='demo0'
IPADDR='192.168.0.101'
NETWORK='192.168.0.0'
YPSRVR='192.168.0.2'
YPSRVR_1='192.168.0.2'
NTPSRVS='192.168.0.2'
NTPSRVS_1='192.168.0.2'
GATEWAYS='192.168.0.1'
GATEWAYS_1='192.168.0.1'
SERVER='192.168.0.10'
NETMASK='255.255.255.0'

All the above variables are correct, but the variable

YPDOMAIN='my-nis-domain+01'

is missing, although it's supllied by the DHCP server.

Here's the config line from dhcpd.conf:

option nis-domain "my-nis-domain+01";

When I replace the plus sign by a minus sign, so that the NIS domain
name is "my-nis-domain-01", and doing a faireboot on the install
client, then

1) the NIS domain gets properly set during the installation sequence and
2) the boot.log additionally contains the line

YPDOMAIN='my-nis-domain-01'

and the resulting classes do contain "NIS MY_NIS_DOMAIN_01".

Here's the relevant snippet from fai.log for this case:
<...>
/usr/bin/fai-class: File 60-nis found.
Executing /var/lib/fai/config/class/60-nis.
60-nis               OK.
/usr/bin/fai-class: Adding class NIS MY_NIS_DOMAIN_01
<...>

So the script generally works, if YPDOMAIN finds it's way into boot.log.

I'm not absolutely sure about if this bug should be filed against
fai-nfsroot package, but as far as I tried to debug this, I came across
/usr/share/fai/dhclient-fai-script which is provided as script file to
dhlclient (with -sf option) and simply executes 'perl
/usr/lib/fai/dhclient-perl'.  I filed this bug against fai-nfsroot,
because both those files are part of this package.

Regards,
 Michael

Hi again,

Sorry for taking another day to respond.

[...]

Please don't worry about the exact package, but your assessment about this perl
script being executed is fully correct. May I ask you to add additional debug
output in

<YOUR NFSROOT>/usr/lib/fai/dhclient-perl

via simple

print "# some output\n"

statements? All of this should end up as comments in boot.log. I believe that
the key point must be the test in line 65 ("if ($ENV{$dhcpname}) ..."), which
should evaluate to true in case your NIS domain doesn't contain a "+", but
evaluates to false otherwise. You might also want to print the entire contents
of the %ENV hash at this point.

Thanks a lot,
Michael

Hi,

On Fri Sep 02, 2011 at 13:42:57 +0100, Michael Tautschnig wrote:
[...]

ok, I added some print statements to dhclient-perl, just as you
suggested.  Unfortunately, it now prints most of the information
multiple times.

Anyway, I attached the boot.log for both cases
(nis-domain "my-NIS-Domain+01" -> nis_domain_with_plus_-_boot.log and
nis-domain "my-NIS-Domain-01" -> nis_domain_with_minus_-_boot.log).

I also attached my version of dhclient-perl as a reference on how the
boot.log files were created.
It indeed looks very much like the problem occurs during the evaluation
of $ENV{$dhcpname}.  I already tried to "escape" this part, like
"$ENV{$dhcpname}" and \Q$ENV{$dhcpname}\E, but neither worked.  It even
lead to a nearly empty boot.log file, which just contained the three
"netdevices" lines.

Any ideas?

Have a nice weekend!

Cheers,
 Michael

Hi,

[...]
[...]

Hmm, it seems that dhclient doesn't even export new_nis_domain in the "plus"
case! (Check the diff of your two log files, new_nis_domain doesn't occur as
"envkey" in the "plus" case.)

Now either dhclient refuses to export the variable in this case, or it isn't
even transferred to the client. Could you use wireshark to sniff the packets
transmitted to the client? IMHO this is a problem with the dhcp client (BTW:
which package exactly are you using to supply dhclient?).

Best,
Michael

Hi,

On Fri Sep 02, 2011 at 20:25:37 +0100, Michael Tautschnig wrote:
[...]

right, that's why I expect the cause to be in the dhclient-perl script.

Yeah, I already did that when I started investigating and before I filed
this bugreport and I just captured a tcpdump again.  The NIS domain name
gets transfered correctly, so I think it must be on the client-side.

Regards,
 Michael

[...]

Hmm, no, I don't think this script is to blame. As $new_nis_domain is unset in
the environment, there isn't much that dhclient-perl could do about it. I'm
afraid this is a problem in dhclient itself. Could you please let me know which
package ships your version of dhclient (do chroot into NFSROOT and dpkg -S
/sbin/dhclient) and which architecture you are using? I'd then provide a
modified binary that has debugging output; obviously you can also do so yourself
if you feel like C hacking.

Best,
Michael

Sorry for the delayed answer.

It's the latest 'isc-dhcp-client' version 4.1.1-P1-15+squeeze3 from
Squeeze (6.0.2) on AMD64.  I guess it's not sufficient to just install
isc-dhcp-client-dbg and gdb into the NFSROOT and modify the call of
dhclient somewhere.

Unfortunately, I'm not a great C hacker.  It's probably the best if
you'd provide the modified binary, so that we can focus on the problem,
not on implementation errors I probably would inject.

Thanks a lot!

Greetings,
 Michael

IMO this is not a bug of FAI.

The FAI scripts calls following command in get-boot-info
    dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf /usr/share/fai/dhclient-fai-script $netdevices >>$bootlog 2> $LOGDIR/dhclient.log


I changed the dhclient-fai-script to a simple shell (/tmp/x) script which does
#! /bin/bash
printenv


If I now call
    # dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf /tmp/x eth0
on a test machine, and set the nis domain name to something containing a
plus (+), no nis variable is defined.

Without a plus I get this:
# dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf /tmp/x eth0|grep nis
new_nis_domain=some_nis_domain01


This proves, that it's a bug of dhclient (or the dhcpd server), but
not a problem of the dhcp related FAI scripts.

Please reassign this bug if you agree with me.


P.S.: Did anyone checked if a plus sign is allowed in nis domain
names?

IMO this is not a bug of FAI.

The FAI scripts calls following command in get-boot-info
    dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf /usr/share/fai/dhclient-fai-script $netdevices >>$bootlog 2> $LOGDIR/dhclient.log


I changed the dhclient-fai-script to a simple shell (/tmp/x) script which does
#! /bin/bash
printenv


If I now call
    # dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf /tmp/x eth0
on a test machine, and set the nis domain name to something containing a
plus (+), no nis variable is defined.

Without a plus I get this:
# dhclient -lf /dev/null -cf /usr/share/fai/dhclient-fai.conf -sf /tmp/x eth0|grep nis
new_nis_domain=some_nis_domain01


This proves, that it's a bug of dhclient (or the dhcpd server), but
not a problem of the dhcp related FAI scripts.

Please reassign this bug if you agree with me.


P.S.: Did anyone checked if a plus sign is allowed in nis domain
names?

Yes, I agree, the bug must be somewhere in dhcp.  Probably in the client
part, as the client-pc always received the nis-domain option in my case.
Even if it cotained a plus sign.

I'll reassing the bug to isc-dhcp-client.
Yes, I did, AFAICT it's OK.  As a matter of fact, I used exactly the
same nis domain name for more than 8 years, even in a heterogenous
(Linux - SunOS environment).  OK, this doesn't really prove, that it's
a valid character, but at least it didn't cause any problems until now.

dhcp-options(5) says:

       option nis-domain text;

         This  option  specifies  the  name  of  the client's NIS (Sun Network
         Information Services) domain.  The domain is formatted as a character
         string consisting of characters from the NVT ASCII character set.


As I understood RFC 854 - Telnet Protocol Specification, it is standard
7-bit USASCII (within an 8-bit field = a byte).  So, I would expect the
plus sign to be a valid character within a nis domain name.  Please
correct me, if I'm wrong.

Thanks,
 Michael

Yes, I agree, the bug must be somewhere in dhcp.  Probably in the client
part, as the client-pc always received the nis-domain option in my case.
Even if it cotained a plus sign.

I'll reassing the bug to isc-dhcp-client.
Yes, I did, AFAICT it's OK.  As a matter of fact, I used exactly the
same nis domain name for more than 8 years, even in a heterogenous
(Linux - SunOS environment).  OK, this doesn't really prove, that it's
a valid character, but at least it didn't cause any problems until now.

dhcp-options(5) says:

       option nis-domain text;

         This  option  specifies  the  name  of  the client's NIS (Sun Network
         Information Services) domain.  The domain is formatted as a character
         string consisting of characters from the NVT ASCII character set.


As I understood RFC 854 - Telnet Protocol Specification, it is standard
7-bit USASCII (within an 8-bit field = a byte).  So, I would expect the
plus sign to be a valid character within a nis domain name.  Please
correct me, if I'm wrong.

Thanks,
 Michael

Yes, I agree, the bug must be somewhere in dhcp.  Probably in the client
part, as the client-pc always received the nis-domain option in my case.
Even if it cotained a plus sign.

I'll reassing the bug to isc-dhcp-client.
Yes, I did, AFAICT it's OK.  As a matter of fact, I used exactly the
same nis domain name for more than 8 years, even in a heterogenous
(Linux - SunOS environment).  OK, this doesn't really prove, that it's
a valid character, but at least it didn't cause any problems until now.

dhcp-options(5) says:

       option nis-domain text;

         This  option  specifies  the  name  of  the client's NIS (Sun Network
         Information Services) domain.  The domain is formatted as a character
         string consisting of characters from the NVT ASCII character set.


As I understood RFC 854 - Telnet Protocol Specification, it is standard
7-bit USASCII (within an 8-bit field = a byte).  So, I would expect the
plus sign to be a valid character within a nis domain name.  Please
correct me, if I'm wrong.

Thanks,
 Michael

Hi Michael,

[...]
[...]

Hmm, actually that might do. It would be all about break'ing on client_envadd to
inspect what dhclient tries to add to the script's environment.

Would you be comfortable with/able to provide me with remote access to one of
your install clients? If yes, feel free to contact me in private.

Best,
Michael

Hi Michael,

[...]
[...]

Hmm, actually that might do. It would be all about break'ing on client_envadd to
inspect what dhclient tries to add to the script's environment.

Would you be comfortable with/able to provide me with remote access to one of
your install clients? If yes, feel free to contact me in private.

Best,
Michael