Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
7Activity
0 of .
Results for:
No results containing your search query
P. 1
Pxe

Pxe

Ratings: (0)|Views: 235 |Likes:
Published by api-3722008

More info:

Published by: api-3722008 on Oct 14, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as TXT, PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

2. introduction
this howto attempts to explain how to get pxe execute kickstart in order to
install a lot
of linux machines at the same time fully automatic and unattended. the main idea
behind
this installation infrastructure is simplicity, robustness, and performance.
i assume a certain familiarity of the reader with linux in general and how to
install
and configure software on linux in particular.everything i am describing here is
for red hat
6.2 and newer clients. pick the files for the version you are planning to install
on your
clients. the servers can be red hat 6.2 or newer.
the mechanisms i am describing are designed to work with relatively strict
security: i am
using static ip addresses on all clients and no client has write access on a
server.
things may be simpler for you if your environment has not so tight restrictions.
according to http://www.suse.de/~nashif/autoyast1/html/index.html, the same
installation
infrastructure can be used to install suse linux over the network.

3. pxe
to install a client via pre-boot execution environment (pxe) you don't need a pxe
server!
pxe uses a bootp request to get an ip address and other network information and a
bootloader
program to the client. you can either use a bootp server for doing this or a dhcp
and tftp
server.
in the following sections, i will describe how to set up a dhcp and tftp server.

4. dhcp
install the dhcp server from isc ( http://www.isc.org/) by using red hat's rpm
ftp://ftp.redhat.com
/pub/redhat/redhat-7.2-en/os/i386/redhat/rpms/dhcp-2.0pl5-8.i386.rpm
before you can start the daemon, you need to create an empty leases file: bash#
touch /etc/dhcpd.leases.
secondly, you need a configuration file /etc/dhcpd.conf which looks similar to
this example:

deny unknown-clients;
not authoritative;
option domain-name
"slac.stanford.edu";
option domain-name-servers
192.168.0.9, 192.168.0.10;
option subnet-mask
255.255.255.0;
allow bootp;
allow booting;
option ip-forwarding
false; # no ip forwarding
option mask-supplier
false; # don't respond to icmp mask req
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers
192.168.0.1;
}group {
next-server tftpsrv;
# name of your tftp server
filename "pxelinux.0";
# name of the bootloader program

host node1 {
hardware ethernet 00:02:b3:1d:16:e1;
fixed-address 192.168.0.11;

}host node2 {
hardware ethernet 00:02:b3:1d:9f:87;
fixed-address 192.168.0.12;
}
}because pxe does really use bootp, you need to have a tftp server running on the

same machine
where your dhcp server runs.
in the above example, all clients are directed towards "next-server" tftpsrv. you
can use a
simple round-robin method to distribute the load evenly over several tftp server
by putting
the server name into each host section instead of having only one for all hosts in
a group.

group {
filename "pxelinux.0";
# name of the bootloader program

host node1 {
hardware ethernet 00:02:b3:1d:16:e1;
fixed-address 192.168.0.11;
next-server tftpsrv1;

# name of first tftp server
}host node2 {

hardware ethernet 00:02:b3:1d:9f:87;
fixed-address 192.168.0.12;
next-server tftpsrv2;

# name of second tftp server
}
}talk to your networking department about the dhcp protocol! ours had switched off

forwarding
the dhcp broadcasts over the routers. i needed to have an extra ip helper address
configured
in some routers because my dhcp server is not in the same subnet as the clients.
while you are at it: ask them to disable "auto-negotiation" on all your machine
ports. also ask
them to enable "portfast" on all ports where your machines are connected.
this disables the spanning tree protocol network gear uses. if you don't have
both of these
settings you can run into trouble with pxe during the early stages of your
install.
perhaps you need some sort of load balancing for your dhcp server or you are
concerned about

the stability of your dhcp server and want some backup. in this case you might
try to use two
(or more) dhcp servers sharing the same configuration file over a shared file
system
(nfs or afs for example). the common configuration file makes maintaining more
than one dhcp
server simple and the clients will talk to the one that is available and least
loaded.

5. automatic mac address detection
we, at slac, are using static ip addresses for all our computers. when getting a
whole bunch
of new machines you need to get their mac addresses into the dhcpd.conf file.
if you can use dynamic ip addresses, just designate an interval of ip addresses in
your
dhcpd.conf file to be handed out to your clients.

however, i have written a script to detect mac address for new machines
automatically and fully
unattended. it works by exploiting the topological knowledge about which node is
connected to
which port on the switch. it uses snmp to query the bridging table of the switch
the machines
have to be connected to. it writes a new dhcpd.conf file which now additionally
contains the
newly detected mac addresses. the script currently works for cisco catalyst 6509
and 3750
switches and is available upon request from the author.
here is the usage message of the script:

script to query a switch for mac addresses.
-- version 4.2,
author: alf wachsmann <alfw@slac.stanford.edu> --

usage: mac_print.pl
optional flags:
-c(onfig) <file>: configuration file. the default config file is

expected to be in the same directory as this script.
-p(xeprepare):
link pxelinux config file in tftpboot directory for
each ip address to do netboot.
-r(reset):
remove all links to pxelinux config file in tftpboot
directory for each ip address to do localboot.
-v(erbose):
be a bit more chatty.
-t(est):
test the configuration file.
-d(ebug):
lots of debug output;
especially usefull with -test option.
-h(elp):
print this help.
see text at end of this script for a description of how it works.
a configuration file for the script looks like this:

# system type can be 'linux' or 'solaris'.
# the scripts outputs either a dhcpd.conf addition for linux or
# just mac and ip address for solaris
$sys_type = 'linux';

Activity (7)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
shekar_bandi liked this
abbasahamed liked this
abbasahamed liked this
neostrikes liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->