Name resolution for kickstart

[CLOSE Dave]

We have a number of internal machines which run a local nameserver. It's 
primarily a relay for the wider net but does a few other things as well. 
So DHCP is configured to specify 127.0.0.1 as the nameserver address for 
these machines.

Of course, that is also what kickstart is told when it connects and 
begins operation. But, of course, kickstart is not running a local 
nameserver. This means that name resolution for the "repo" lines in the 
kickstart file doesn't work and installations fail.

The only workaround I've found is to use IP addresses in the "repo" 
lines, not the associated names. But this isn't ideal: addresses can 
change and sites using multiple addresses can't be properly matched.

Is there a way I can tell kickstart not to use the resolver specified by 
DHCP but instead use one that I specify in the kickstart file?
-- 
Dave Close

[Tim]

Allegedly, on or about 03 October 2014, CLOSE Dave sent:
>  We have a number of internal machines which run a local nameserver.
> It's 
>  primarily a relay for the wider net but does a few other things as well. 
>  So DHCP is configured to specify 127.0.0.1 as the nameserver address for 
>  these machines.
>  
>  Of course, that is also what kickstart is told when it connects and 
>  begins operation. But, of course, kickstart is not running a local 
>  nameserver. This means that name resolution for the "repo" lines in the 
>  kickstart file doesn't work and installations fail.
>  
>  The only workaround I've found is to use IP addresses in the "repo" 
>  lines, not the associated names. But this isn't ideal: addresses can 
>  change and sites using multiple addresses can't be properly matched.
>  
>  Is there a way I can tell kickstart not to use the resolver specified by 
>  DHCP but instead use one that I specify in the kickstart file? 
Specify the details on your DHCP server.  Actually sending 127.0.0.1 is
an odd thing, because it means "yourself," and I'd only send such data
to those specific machines.  For everything else, give a specific DNS
server address for one of those machines.  Do all of that on the DHCP
server.  Have some specific machine entries (your servers), and separate
configuration for a range of dynamic client machines.

This is an modified example configuration from my own DHCP server,
below.  It used a range of different options, while trying things out.
There's some entries that are fixed by MAC (best option), others that
give out a specific IP to machines by their hostnames (too easily
screwed up by clients).  The stuff at the head of the file is sent to
everyone.  The stuff within the sub-clauses {bracketed}, only goes to
those particular items.

authoritative;
allow                   client-updates;
include			"/etc/rndc.key";  # (same key used by BIND, needed to update DNS
records)

default-lease-time	604800;  # 7 days (was 2 hours)
max-lease-time		1209600; # 14 days (was 24 hours)
min-lease-time		30;	 # 30 seconds (might help renewing experiments)

server-name		"gigs";

#local-address	192.168.1.2;

ddns-domainname		"lan.example.com.";
ddns-rev-domainname	"in-addr.arpa.";
ddns-update-style	interim;
ddns-updates		on;

option domain-name	"lan.example.com.";

option nntp-server	news.lan.example.com;
option pop-server	pop3.lan.example.com;
option smtp-server	smtp.lan.example.com;
option wpad-curl	code 252 = text;
#option wpad-curl	"http://proxy.lan.example.com/wpad.dat";
option www-server	www.lan.example.com;

option ntp-servers	time.lan.example.com;
# option time-offset	34200;	# Australian Central Standard Time
option time-offset	37800;	# Central Australia Daylight Time
# Seem to be stupidly stuck with manually setting this!
# Daylight savings:  2am last Sun of Oct - 3am first Sun of Apr
# 2009+ changed to:  first Sunday of Oct to first Sun of Apr

option ip-forwarding	off;	# tell clients not to act as gateways (?)

shared-network lan.example.com {

	option wpad-curl        "http://proxy.lan.example.com/wpad.dat";

	subnet 192.168.1.0 netmask 255.255.255.0 {

		range 192.168.1.100 192.168.1.200;  # dynamic IP assignment range

		option routers			192.168.1.254;  # default gateway
		option subnet-mask		255.255.255.0;
		option broadcast-address	192.168.1.255;
		option domain-name-servers	192.168.1.2;

		option netbios-dd-server	192.168.1.2;  # old windows networking
		option netbios-name-servers	192.168.1.2;  # WINS
		option netbios-node-type 8;                   # old windows networking
		option netbios-scope "";                      # old windows networking

		zone lan.example.com. { 
			primary 192.168.1.2;
			key rndckey;
		} # details for remote controlling the DNS server

		zone  1.168.192.in-addr.arpa. {
			primary 192.168.1.2;
			key rndckey;
		} # details for remote controlling the DNS server

		# we want the nameserver to appear at a fixed address
		# (Any terminal saying it's "ns" or ns.lan.example.com will
		# be assigned this IP.  It'd be better to match using MAC
		# data, like the subsequent items.)

		host ns {
			fixed-address 192.168.1.2;
		}


                host fluffy {
                        hardware ethernet 00:24:21:9A:6F:6C;
                        fixed-address 192.168.1.12;
                        option host-name "fluffy";
			option domain-name-servers 192.168.1.254; # a different DNS server
                }

                host smallblack {
                        hardware ethernet 00:11:2f:f4:57:8f;
                        fixed-address 192.168.1.113;
                        option host-name "smallblack";
			option domain-name-servers 127.0.0.1; # a different DNS server
                }

		host flakey {
			hardware ethernet 00:00:21:25:92:fb; 
			fixed-address 192.168.1.180;
			option host-name "deadmeat";
			update-static-leases on;
		}

		host rover {
			hardware ethernet 00:48:54:8e:8c:0c;
			fixed-address 192.168.1.9;
			set ddns-rev-name = "9.1.168.192.in-addr.arpa.";
			option host-name "rover";
		}

	}

}

# ------------------ end of it all ---------------------------------------
# see http://www.arda.homeunix.net/dnssetup.shtml for some additional help

# removed while tidying:
#
# option nis-domain		"localdomain.";
# probably not needed, as don't use NIS
#
# range dynamic-bootp 192.168.0.20 192.168.0.30;
# not using bootp
#
# next-server ns.lan.example.com;
# server where boot files are fetched from (network clients)



-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.

ZNQR LBH YBBX

[CLOSE Dave]

I wrote:

>  We have a number of internal machines which run a local nameserver.
>  It's primarily a relay for the wider net but does a few other things
>  as well. So DHCP is configured to specify 127.0.0.1 as the nameserver
>  address for these machines.
>
>  Of course, that is also what kickstart is told when it connects and
>  begins operation. But, of course, kickstart is not running a local
>  nameserver. This means that name resolution for the "repo" lines in
>  the kickstart file doesn't work and installations fail.
>
>  The only workaround I've found is to use IP addresses in the "repo"
>  lines, not the associated names. But this isn't ideal: addresses can
>  change and sites using multiple addresses can't be properly matched.
>
>  Is there a way I can tell kickstart not to use the resolver specified
>  by DHCP but instead use one that I specify in the kickstart file?
>  
On 10/03/2014 08:40 PM, Tim wrote:

>  Specify the details on your DHCP server.  Actually sending
> 127.0.0.1
>  is an odd thing, because it means "yourself," and I'd only send such
>  data to those specific machines.  For everything else, give a
>  specific DNS server address for one of those machines.  Do all of
>  that on the DHCP server.  Have some specific machine entries (your
>  servers), and separate configuration for a range of dynamic client
>  machines.
>  
Thanks for the reply. But I understand how to configure DHCP. As I wrote
above, "DHCP is configured to specify 127.0.0.1 as the nameserver
address for these machines". Only for those machines.

The difficulty is that, during kickstart the DHCP configuration is
wrong. I'd much rather not have to use a different configuration for
kickstart than for normal operation. While I can do that for an initial
installation, it is far trickier if the machine needs to be re-installed
later. A re-installation ought to be as simple and selecting PXE during
boot. There shouldn't be a need to change the DHCP configuration before
and after.
-- 
Dave Close

[Tim]

Allegedly, on or about 06 October 2014, CLOSE Dave sent:
>  The difficulty is that, during kickstart the DHCP configuration is
>  wrong. I'd much rather not have to use a different configuration for
>  kickstart than for normal operation. While I can do that for an
>  initial installation, it is far trickier if the machine needs to be
>  re-installed later. A re-installation ought to be as simple and
>  selecting PXE during boot. There shouldn't be a need to change the
>  DHCP configuration before and after.  
Realising you don't really want two configurations to have to do, but if
it's your intention that *some* things should use 127.0.0.1, and other
things should not, then I think you're stuck having to *manage* that.

But just a thought...  When I've set up systems, the network
configuration details applied during the installation period only
pertain to the installer (so it can get things from the network, as it
installs, etc.).  Post installation, my networks have always required
reconfiguration, as that install-time configuration is not put into the
installed system, just used by the installer, itself.  And this
post-install network configuration could be either manual, or simply
what my DHCP server does, as the machine boots up and connects.  So, the
situation exists for having two configuration stages.

I do not know if the kickstart system can be preset with separate
network configuration parameters for install time, and post install
(e.g. avoid having to intervene and reconfig, yourself).  It may be
possible for the DHCP server to detect the difference, and supply
different parameters.  e.g. A specific hostname being used during
install, for the install, then other individual hostnames applied to
machines, afterward.  And the hostname being the matchpoint for what
other details to provide to the DHCP client.

Is the PXE boot just for the installation, or do things always PXE boot?
If it's just for the installation, perhaps there's the place to set up
the alternative details.

I'm still inclined to think - avoid using 127.0.0.1, and when you're
preparing to install a system (new, or re-doing), making sure that
there's a DHCP server configuration for that new machine that not only
doles a specific IP to the machine, but also doles the same IP out as
its first DNS server.

Another thought might be to not get machines to self serve, but cross
serve between your local serves (they ask their peers, rather than
themselves).

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.

ZNQR LBH YBBX

[Junk]

On 6 October 2014 22:29:56 GMT+01:00, CLOSE Dave <Dave.Close(a)us.thalesgroup.com&gt;
wrote:
> I wrote:
>
> > We have a number of internal machines which run a local nameserver.
> > It's primarily a relay for the wider net but does a few other things
> > as well. So DHCP is configured to specify 127.0.0.1 as the nameserver
> > address for these machines.
> >
> > Of course, that is also what kickstart is told when it connects and
> > begins operation. But, of course, kickstart is not running a local
> > nameserver. This means that name resolution for the "repo" lines in
> > the kickstart file doesn't work and installations fail.
> >
> > The only workaround I've found is to use IP addresses in the "repo"
> > lines, not the associated names. But this isn't ideal: addresses can
> > change and sites using multiple addresses can't be properly matched.
> >
> > Is there a way I can tell kickstart not to use the resolver specified
> > by DHCP but instead use one that I specify in the kickstart file?
>
> On 10/03/2014 08:40 PM, Tim wrote:
>
> > Specify the details on your DHCP server.  Actually sending 127.0.0.1
> > is an odd thing, because it means "yourself," and I'd only send such
> > data to those specific machines.  For everything else, give a
> > specific DNS server address for one of those machines.  Do all of
> > that on the DHCP server.  Have some specific machine entries (your
> > servers), and separate configuration for a range of dynamic client
> > machines.
>
> Thanks for the reply. But I understand how to configure DHCP. As I
> wrote
> above, "DHCP is configured to specify 127.0.0.1 as the nameserver
> address for these machines". Only for those machines.
>
> The difficulty is that, during kickstart the DHCP configuration is
> wrong. I'd much rather not have to use a different configuration for
> kickstart than for normal operation. While I can do that for an initial
> installation, it is far trickier if the machine needs to be
> re-installed
> later. A re-installation ought to be as simple and selecting PXE during
> boot. There shouldn't be a need to change the DHCP configuration before
> and after. 
I think you might be better setting it up a slightly different way. Get the DHCP server to
send a normal DNS server for machines installing and get the kickstart file to configure
the machines to ignore the DNS server from the dhcp server (PEERDNS=no) and use
DNS1=127.0.0.1 instead. 
--
Junk

[CLOSE Dave]

Tim wrote:

>  Realising you don't really want two configurations to have to do,
> but
>  if it's your intention that *some* things should use 127.0.0.1, and
>  other things should not, then I think you're stuck having to *manage*
>  that.
>  
I'm on the trail of a possible solution. Further ideas welcome.

In the dhcpd.conf file, I can test the client information from 
Anaconda's DHCP requests. For example,

   if substring ( option vendor-class-identifier, 0, 8 )  = "anaconda" {
     option domain-name-servers { normal addresses };
   } else {
     option domain-name-servers 127.0.0.1;
   }

Indeed, this works -- up to a point. The first request that Anaconda 
sends includes this string and my DHCP server provides the proper 
response. But then Anaconda issues a couple of lease renewal requests 
(why? it has a full-day lease already). Those don't include the string 
so the server sends the 127 address. Then Anaconda fails. The sequence is,

   DHCP DISCOVER - with identifier "anaconda"
   DHCP OFFER - with normal name servers
   DHCP REQUEST- with identifier "anaconda"
   DHCP ACK - with normal name servers
   DHCP REQUEST- without identifier "anaconda"
   DHCP ACK - with 127 name server
   DHCP REQUEST- without identifier "anaconda"
   DHCP ACK - with 127 name server

There doesn't appear to be anything unique in the later requests on 
which I can key. I'm searching for a way to make the DHCP server 
remember the proper response.
-- 
Dave Close