Bug 165735 - diskless clients cannot cope with no DNS PTR record for their IP address
Summary: diskless clients cannot cope with no DNS PTR record for their IP address
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: system-config-netboot
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jason Vas Dias
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 149000 156322 165785
TreeView+ depends on / blocked
 
Reported: 2005-08-11 17:34 UTC by Jason Vas Dias
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: RHBA-2005-484
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 13:49:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:484 0 qe-ready SHIPPED_LIVE Updated system-config-netboot package 2005-10-05 04:00:00 UTC

Description Jason Vas Dias 2005-08-11 17:34:50 UTC
Description of problem:

If no DNS PTR record exists for the IP address that is assigned to a 
diskless boot client, disklessrc will set the hostname to '3(NXDOMAIN' ,
which becomes the name of the snapshot directory that the client will
attempt to mount .

Any hostname that may have been set by the DHCP server is ignored.

This is a latent problem with all previous releases of 
{system,redhat}-config-netboot , and stems from this code in disklessrc:

--- disklessrc, @line 220:
#
#  Mount the snapshot directory from the server and then mount files
#  in the snapshot/files file over the the shared ones
#
IP=`/sbin/ifconfig $ETHERNET|grep inet|cut -f 2 -d ':'|cut -f 1 -d ' '`

#
# Setup the hostname for the diskless client.
#
hostname `host $IP |  sed 's/.* \(.*\)./\1/'` 2> /dev/null

if [ -z "${SNAPSHOT}" ]; then
SNAPSHOT=`hostname`
fi
---

To fix this, I propose :

1. Check if any host name was set by the dhclient session - if so, use that
   hostname.

2. If no hostname was set by the dhclient session, and the 'host $IP' lookup
   fails, and $SNAPSHOT is not null, set the hostname to $SNAPSHOT .

3. If no hostname was set by the dhclient session, and the 'host $IP' lookup
   fails, and $SNAPSHOT is null, then set the hostname to the IP address,
   because pxeboot will create a default snapshot directory named with whatever
   IP address was given as the host configuration file name, and there is a 
   chance that this will be a 32 bit IP address.  This is better than multiple
   clients using the '3(NXDOMAIN' snapshot directory.

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

How reproducible:
100%

Steps to Reproduce:
Set up a boot client with no 'SNAPSHOT=' setting, to obtain an IP address 
via DHCP for which there is no DNS PTR record
  
Actual results:
Client will boot with hostname '3(NXDOMAIN' and create the snapshot
directory ${NFSSERVER}:/${CLIENT_ROOT}/snapshot/3\(NXDOMAIN

Expected results:
Client should ensure it sets its hostname and snapshot directory name to a 
unique value regardless of whether its IP address is in the DNS.
It should be possible to set the hostname for the client in the DHCP server
configuration.


Additional info:

Comment 1 Jason Vas Dias 2005-08-12 01:40:22 UTC
This is now fixed with system-config-netboot-0.1.26, available from:
  http://people.redhat.com/~jvdias/system-config-netboot

If the host-name option is sent by the dhcp server, it is used, so you can
set up a boot configuration with a dhcpd.conf entry like:
--
ddns-update-style none;
subnet 192.168.2.1 netmask 255.255.255.0 {
        option routers 192.168.2.1;
        option domain-name-servers 192.168.2.1;
        option domain-name "my.net";
        option next-server 192.168.2.1;
        range 192.168.2.2 192.168.2.254;
        allow booting;
        allow bootp;
        filename "linux-install/pxelinux.0";
        group {
                use-host-decl-names on;
                host client1.my.net {
                        hardware ethernet 00:0d:60:cf:98:e3;
                }
        }
}
---
In this case, when host 00:0d:60:cf:98:e3 is granted a lease, it will set
its hostname to 'client1' and its domainname to 'my.net' .

If no host-name option is sent by the DHCP server, a DNS lookup is performed
for a PTR record associated with the IP address. If a name is found in the DNS,
the hostname is again set to the prefix of non-period ('.') characters in the
the DNS name ('client1'), and the domainname to the suffix ('my.net').
 
If no DNS name was found, then the host name is set to the last octet of the
IP address, and the domainname to the DNS reverse IPv4 domain name of the 
IP address suffix; ie. if the client was granted address '192.168.2.2', the
host name would be set to '2', and the domainname to '2.168.192.in-addr.arpa.'.

If no SNAPSHOT setting was specified , then the snapshot directory name is set 
to the full host name before splitting into host and domain names.
ie. if the name client1.my.net is used for the host/domain name, SNAPSHOT
is set to client1.my.net; if the IP address is used for the host/domain name,
SNAPSHOT is set to the full IP address string (eg. '192.168.2.1').


Comment 5 Jason Vas Dias 2005-08-19 00:25:45 UTC
This bug is properly fixed only in system-config-netboot-0.1.28 :
If no DNS servers are configured by the DHCP server, and the DHCP server
sends no host-name option, host emits the message 
 ';; connection timed out; no servers could be reached
 '
and such clients end up with the hostname 'reached' .

disklessrc now correctly greps for the string 'domain name pointer' in
the host output and only the last such line emitted by host will set the
host and domain names .

0.1.28 can be downloaded from:
  http://people.redhat.com/~jvdias/system-config-netboot/RHEL-4/




Comment 7 Red Hat Bugzilla 2005-10-05 13:49:22 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-484.html



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