ks] Re: anaconda network install
R P Herrold
herrold at owlriver.com
Sat Jan 8 03:25:58 UTC 2005
On Fri, 7 Jan 2005, Paul Ionescu wrote
>> Is there an option to send the default ftp/http/nfs server and the
>> directory via DHCP instead of entering manually ?
>> Maybe is not something standard, but we can use some vendor DHCP options
>> for this.
Well, no, not really that early -- The URL with the location
of the ks.cfg file can be passed out, but not as part of the
DHCP transaction -- dhcp happens too early for there to be a
Vendor Option context for it to be meaningful without some
major surgery on how pxelinux.0 works.
But dhcp identifies the TFTP 'next' server, and the TFTP
transfer moves the information of which you ask.
As the next server, and the dhcp server are often (although
not formally required to be) the same server, you can probably
automate pointing to a desired installation path. I have done
so since RHL 6.2 days <?> with variants of what is now my
'install-from-iso.sh' mentioned with a URL in the notes at a
writeup I did.
see: http://www.owlriver.com/tips/pxe-install/
This writeup dates from a couple years ago, detailling, in
cookbook fashion, the configuration for identifying in the
'dhcpd.conf' configuration file, (1) the 'next server', and
(2) the relevant part of the path from the tftp-server's
(which is the 'next server') root path 'filename'.
That 'filename' is the 'pxelinux.bin' to be retrieved and
executed. That code is smart enough in turn to request,
and retrieve the file containing that information (among other
things) from the 'next server' identified under DHCP and PXE
install practice.
Jan 5 23:25:35 ftp tftpd[2796]: Serving /rhl/pxe/pxelinux.bin
to 10.16.33.254:2070
By RH (and derived distribution's) PXElinux convention, there
is a file of last resort sought [others are probed for first
under a nameing convention derived from the hex represesention
of the IP address assigned]. In searching for that file
(which is called 'default'), it first asks for a series of
more genreally named files, each starting 'OA' in this
example, [as '0A' is a hex name for '10' decimal, from the A
class network 10.x.x.x in which this server and its clients
live]. The found file is transferred out to the requesting
client, through tftp, using information derived from DHCP.
Jan 5 23:25:35 ftp tftpd[2796]: Serving
/rhl/pxe/pxelinux.cfg/0A1021FE to 10.16.33.254:57217
Jan 5 23:25:35 ftp tftpd[2796]: File
/tftpboot///rhl/pxe/pxelinux.cfg/0A1021FE not found
<snip>
Jan 5 23:25:35 ftp tftpd[2796]: Serving
/rhl/pxe/pxelinux.cfg/0A1 to 10.16.33.254:56582
Jan 5 23:25:35 ftp tftpd[2796]: File
/tftpboot///rhl/pxe/pxelinux.cfg/0A1 not found
Jan 5 23:25:35 ftp tftpd[2796]: Serving
/rhl/pxe/pxelinux.cfg/0A to 10.16.33.254:56455
This is also the approach in Debian.
<snip>
Jan 3 02:29:29 ftp tftpd[31242]: File
/tftpboot//debian/pxelinux.cfg/0A1 not found
Jan 3 02:29:29 ftp tftpd[31242]: Serving
debian/pxelinux.cfg/0A to 10.16.33.221:57096
Jan 3 02:29:29 ftp tftpd[31242]: File
/tftpboot//debian/pxelinux.cfg/0A not found
Jan 3 02:29:29 ftp tftpd[31242]: Serving
debian/pxelinux.cfg/0 to 10.16.33.221:57097
Jan 3 02:29:29 ftp tftpd[31242]: File
/tftpboot//debian/pxelinux.cfg/0 not found
Jan 3 02:29:29 ftp tftpd[31242]: Serving
debian/pxelinux.cfg/default to 10.16.33.221:57098
-- and the '0A' file (in the Red Hat example), found before
the failsafe 'default' file (in the Debian example) in turn,
points to the ks.cfg, which contains and provides the
information you mention.
[root at ftp log]# cat /tftpboot/rhl/pxe/pxelinux.cfg/0A
default linux
# serial 0,38400n8
label linux
kernel vmlinuz
append ksdevice=eth0 local_ramdisk=1 initrd=initrd.img ks=http://10.16.33.105/pub/kickstart/ks.cfg
#
paragraph 11 of my outline specifically has what you wish to
do.
--------------
It is perfectly possible for a single dhcp and tftp server to
handle multiple platforms and architectures and distributions.
-- Here is a cleaned up snapshot from one of my development
servers:
[root at ftp etc]# cat /tmp/ks-dhcpd.conf.txt
ddns-update-style none ;
ping-check true ;
get-lease-hostnames true ;
max-lease-time 120000;
default-lease-time 12000;
option option-128 code 128 = string;
option option-129 code 129 = text;
shared-network development {
authoritative ;
subnet 10.16.33.0 netmask 255.255.255.0 {
option domain-name "development.lan";
option domain-name-servers 10.16.33.105,
65.43.29.92, 66.195.224.112 ;
option routers 10.16.33.1;
option root-path "10.16.33.105:/opt/ltsp/i386";
allow unknown-clients;
host blahblah {
hardware ethernet 11:22:33:44:55:66 ;
}
allow booting ;
allow bootp ;
next-server 10.16.33.105 ;
filename "/rhl/pxe/pxelinux.bin" ;
range 10.16.33.200 10.16.33.219 ;
range 10.16.33.230 10.16.33.254 ;
group {
host netwinder1 {
hardware ethernet 00:10:57:00:07:54 ;
fixed-address 10.16.33.90 ;
option host-name "netwinder1";
}
host p3-220 {
hardware ethernet 00:02:B3:1D:8F:76 ;
fixed-address 10.16.33.220 ;
option host-name "dhcp220";
}
}
group {
next-server 10.16.33.105 ;
host debian-tftpclient {
hardware ethernet 00:00:DE:AD:BE:EF ;
fixed-address 10.16.33.221 ;
filename "debian/pxelinux.0" ;
option host-name "debian-tftpclient" ;
}
}
}
}
[root at ftp etc]#
This file supports both Red Hat type hands off kickstart
installs, and Debian installs; for arches x86, Netwinder mips,
and Aurora sparc installs. And an LTSP client as well. ;)
-- Russ Herrold
More information about the Kickstart-list
mailing list