Trouble with RHN Provisioning/Kickstart
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?
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.
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
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 ...
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
