Trouble with RHN Provisioning/Kickstart

Latest response

Is there a correct way to handle multiple NICs in the RHN kickstart/provisioning?

 

Under Kickstart > Profiles > Kickstart Details > Advanced Options

I have my network stuff for setting a static IP on eth0, but when I tried to provision the system, during the kickstart it asked for the network details.  I think this is because the system has two NICs, eth0 and eth1.

 

Kickstart network line that it was provisioned with:

network --onboot yes --device eth0 --bootproto static --ip 192.168.1.2 --netmask 255.255.255.0 --gateway 192.168.1.1 --nameserver 192.168.1.1 --hostname hostname.domainname

 

After having to specify the network settings during boot, the resulting anaconda-ks.cfg file has two lines:

network --onboot yes --device eth0 --bootproto static --ip 192.168.1.2 --netmask 255.255.255.0 --gateway 192.168.1.1 --nameserver 192.168.1.1 --hostname hostname.domainname

network --onboot no --device eth1 --noipv4 --noipv6 --hostname hostname.domainname

 

How do I resolve this so it doesn't prompt for the network info and works with the line it is given?

 

network --onboot yes --device eth0 --bootproto static --ip 160.129.39.199 --netmask 255.255.255.224 --gateway 160.129.39.193 --nameserver 160.129.6.22 --hostname queso.mc.vanderbilt.edu
network --onboot no --device eth1 --noipv4 --noipv6 --hostname queso.mc.vanderbilt.edu

 

network --onboot yes --device eth0 --bootproto static --ip 160.129.39.199 --netmask 255.255.255.224 --gateway 160.129.39.193 --nameserver 160.129.6.22 --hostname queso.mc.vanderbilt.edu
network --onboot no --device eth1 --noipv4 --noipv6 --hostname queso.mc.vanderbilt.edu

Responses

I found this info from the CentOS wiki:
http://wiki.centos.org/TipsAndTricks/KickStart

Use a specific network interface for kickstart

When your system has more than one network interface anaconda asks you which one you'd like to use for the kickstart process. This decision can be made at boot time by adding the ksdevice paramter and setting it accordingly. To run kickstart via eth0 simply add ksdevice=eth0 to the kernel command line.

A second method is using ksdevice=link. In this case anaconda will use the first interface it finds that has a active link.

A third method works if you are doing PXE based installations. Then you add IPAPPEND 2 to the PXE configuration file and use ksdevice=bootif. In this case anaconda will use the interface that did the PXE boot (this does not necessarily needs to be the first one with a active link).

Within the kickstart config itself you need to define the network interfaces using the network statement. If you are using method 2 or 3 then you don't know which device actually will be used. If you don't specify a device for the network statement anaconda will configure the device used for the kickstart process and set it up according to your network statement.

Yeah, I know how to do that for doing a general kickstart and stuff.  I want to use the provisioning though.  It worked fine on my desktop that I was testing with because it only had one NIC.  I'm thinking about trying to turn off the second onboard NIC in the BIOS to try and see if that works next time.

Use DHCP?  I'd echo what was said above about ksdevice=(eth0|link).  Have struggled a bit with that in the past.  ksdevice=link seemed to be to solution to it.

 

Would always fight the corner of using DHCP to provide network config though.  Static reservations for each MAC address that a server uses.  This way you get an unchanging IP address, but will never be asked to type in any details during an install.

 

Also makes large changes to IP addresses easier (i.e. being instructed to move all servers from 10.0.2.X to 10.0.38.X because an aquisition brought in a company using 10.0.2.X for their IP telephony system - even though that's a monumental task with all your servers being static IP).  No - I'm not bitter.  I was on holiday the weekend the work had to be done!

 

D

Ah!  I didn't even see the ksdevice=link the first guy posted.  I will have to try that out.  I just disabled the second NIC in the case of this server.  Waiting on kickstart now to see if it works or not.  Although, I reinstalled the server hosting the install files, so we'll see if that is messed up or not too.  :)

Sigh, no suck luck.  Even when I had the second interface disabled, it still prompts to enter the network configuration when using the provisioning on RHN to kickstart the system.

I have a similar setup and provision servers with multiple interfaces via an automated kickstart installation.

 

My kickstart files are "handmade" and have entries like:

 

network --device eth0 --bootproto=static --onboot=yes --hostname=rhel6-be2 --gateway=192.168.1.1 --ip=192.168.1.61 --netmask=255.255.255.128 --nameserver=192.168.1.1

 

network --device eth1 --bootproto=dhcp --onboot=no

 

network --device eth2 --bootproto=dhcp --onboot=no

...

 

You see: I configure only one interface (eth0) via which I connect later to finalise/check the setup. The remaining eth1-eth... are configured by the kickstart "%post" phase with a simple shell script and here-text. For example:

 

 

----snipsnip--------

MYFILE="/etc/sysconfig/network-scripts/ifcfg-eth3"

cat << EOF > ${MYFILE}

DEVICE=eth3

BOOTPROTO=static

NETMASK=${IPMASK[$X]}

ONBOOT=yes

EOF

case $server in
    "server1")
         echo "IPADDR=${HBIPADDR[$X]}" >> $MYFILE;
    ;;
    "server2")
         echo "IPADDR=${HBIPADDR[$X]}" >> $MYFILE;
    ;;

# ... and so on ...

esac
#

------snipsnip-------

 

It requires that you set up an environment in which the variables like ${HBIPADDR[$X]} are defined. I do this beforehand and run the env from the kickstart %post-phase. For example, on a machine called "server1" and that would (above) receive the IP-address of server1, the %post section in the kickstart has something like:

 

%post
. ../configure.sh           
sleep 1
. ./config_net.sh server1           

 

... where "configure.sh" is a script I created before and that sets environment variables such as ${HBIPADDR[$X]} for use inside the actual config_net.sh (which e.g. sets up the network interfaces)

 

This might sound a bit complicated, but it is far more flexible than clicking around in a GUI and you can reuse the kickstart files much easier! In our particular case, I wrote a small perl script that extracts server parameters from an excel file and generates a kickstart file out of it! The planning department hands in an excel file, and you directly turn it into a kickstart for deployment ...