Automated Linux Cloud Installation

One of the features of cloud computing is the ability to move applications from one processor environment to another. This feature requires a target operating system to receive it before moving the application. Wouldn't it be nice if you could automate the installation of a new operating system?

A well-known feature of the intel™ architecture system is the ability to install Linux automatically. However, installing Linux automatically is a tricky issue for System P or IBM power BAE using the hardware management console. One of the advantages of the solution discussed in this article is that it is a pure Linux solution and does not ask you to master any specific AIX technologies.

Automation Solutions Overview

The goal of this solution is to automate the installation of the operating system by using a set of configuration that is easy to maintain and modify. It has the following characteristics:

the LPAR you just created and installed uses a static IP address. This is only relevant to the final configuration of the LPAR, and you can use Dynamic Host Configuration Protocol (DHCP) during the installation process. Automatic Linux installation and revisit with YaST2 (autoyast) configuration XML files are common and can be used on many server types, including HTTP, MySQL, and so on. Autoyast files do not contain system-specific information, such as IP addresses, host names, and so on. Automate everything in this way so that a new LPAR can be installed using a single command on the HMC.

Steps to build and use an automated solution include:

configuration autoyast file configuration BOOTP and TFTP server use the HMC lpar_netboot command to automate Lpar_netboot reuse automation solutions with the-G parameter

Step 1. Configuring Autoyast Files

SUSE Linux uses an XML configuration file called Autoyast.xml to control the installation of the operating system. By default, each time you use Autoyast, it installs the system with the same configuration. This allows you to obtain autoyast files that are specific to different configurations. For example, you might have a autoyast file for the Web server, and another autoyast file for the MySQL server. However, it is difficult and time-consuming to configure and maintain multiple Autoyast files for servers that differ only by IP addresses and host names.

To create a custom autoyast file that obtains an IP address and host name from a DHCP server, you must copy the Autoyast file from the SUSE installation CD and modify it as follows:

standard autoyast files are configured to use DHCP. Modify the network section to use DHCP only when the operating system is first installed. Check to make sure that no host names are assigned to these network segments. If a section has a host name, the section must be completely removed. If your XML file contains static IP information, DNS information, or other network information, remove the content from the file. Copy the code in Listing 1 to the location before the last XML tag in the Autoyast file. This new section contains a script that converts the current boot DHCP configuration to a static network configuration (which is used the next time the LPAR is booted).

With this script, there is no need to prepare autoyast files for each LPAR separately for hard-coded IP addresses. Therefore, you only need to maintain the DHCP server.

Listing 1. Autoyast DHCP Transformation Script


<scripts> <init-scripts config:type= "list" > <listentry> <filename>network_setup</ Filename> <interpreter>shell</interpreter> <source><! [cdata[#!/bin/bash### Disable ipv6echo ' Install ipv6/bin/true ' >>/etc/modprobe.conf.local### to Calculate receptacle revisit Settings for a static revisit # # #ACTIVE_INTERFACE = '/sbin/ifconfig | grep ETH | awk ' {print} ' ip_address= '/sbin/ifconfig $ACTIVE _interface | grep ' inet addr ' | awk ' {print $} ' | Sed ' s/addr://' netmask= '/sbin/ifconfig $ACTIVE _interface | grep ' inet addr ' | awk ' {print $} ' | Sed ' s/mask://' broadcast= '/sbin/ifconfig $ACTIVE _interface | grep bcast: | awk ' {print $} ' | Sed ' s/bcast://' network= '/sbin/ip route list | grep $IP _address | awk ' {print '} ' | Sed ' s/\/[1-9][1-9]//' gateway= '/sbin/route | grep Default | awk ' {print $} ' hostname= '/usr/bin/host $IP _address | awk ' {print $} ' | Sed ' $s/.$//' ### Setup hostnameecho "$HOSTNAME" >/etc/hostname### Setup Gateway Addressecho "default $GATEWAY-" >/etc/sysconfig/network/routes### setup/etc/hosts with Correct host informationhost= '/usr/bin/host $IP _address | awk ' {print $} ' | Sed ' $s/.$//' | Cut-d "."-F 1 ' echo "$IP _address $HOSTNAME $HOST" >>/etc/hosts### receptacle revisit file rewrite for static configurationint_conf_file=/etc/sysconfig/network/ifcfg-eth-id-' Ifconfig eth0 | grep hwaddr | awk ' {print $} ' | Perl-ne ' $var =$_; Print LC ($VAR) ' echo ' Device=eth0 ' > $INT _conf_fileecho ' bootproto=static ' >> $INT _conf_fileecho ' ipaddr= $IP _ Address ">> $INT _conf_fileecho" netmask= $NETMASK >> $INT _conf_fileecho "broadcast= $BROADCAST" >> $ Int_conf_fileecho "network= $NETWORK" >> $INT _conf_fileecho ' startmode=onboot ' >> $INT _conf_fileecho ' TYPE =ethernet ' >> $INT _conf_file### restart network/etc/init.d/network restart]]></source> </listentry > </init-scripts></scripts>

Step 2. Configuring BOOTP and TFTP servers

This solution uses a standard Linux DHCP server, which is part of all major Linux distributions. In this step, you need to configure the DHCP server to provide network boot information for the new LPAR. The initial code is loaded to the LPAR via the Trivial File transmits Kyoto (TFTP) server. To set up a network boot, you must mount the DHCP server and the TFTP server to a server on your network.

This solution uses a DHCP server that is not configured to dynamically provide TCP/IP addresses to systems on the network, but it can coexist on the same network as the DHCP server that is the traditional role. This type of configuration can be used even if the network on which the DHCP server resides differs from the boot system network. For example, it can dynamically boot a system in New York through a Texas server.

For the Lpar_netboot command to work as Step 3 in this solution, you need to configure the DHCP server for each installed Lpar. The advantage of this approach is that all the configuration information required to install the LPAR automatically is contained in the dhcpd.conf file. Therefore, the Autoyast file that was changed in the previous step does not need to contain any hard-coded information that defines the LPAR network configuration.

Listing 2 contains an example dhcp.conf file. Use this example as a model and add additional host definitions for each LPAR that needs to be configured. The compressed file in the download section of this article contains a script named Addsystem that you can use to automate the editing of dhcpd.conf files.

Each time you change the dhcpd.conf file, you must restart the DHCP server for the changes to take effect.

Listing 2. Sample dhcpd.conf file


Ddns-update-style ad-hoc;allow bootp;subnet 0.0.0.0 netmask 0.0.0.0 {host rcc-hny-poc-003 {option Host-name " Myserver.cloud9.ibm.com "; Fixed-address 192.168.0.203; Hardware Ethernet 16:e9:10:94:87:03; FileName "Inst64"; Next-server 192.168.0.201; Option routers 192.168.0.201;}

The following is a detailed description of the options in the sample dhcp.conf file:

Subnet configures the server to respond to requests from other servers, regardless of the location of those servers on the network. Because this DHCP server is not configured for dynamic addressing, it responds to boot requests from the LPAR and does not affect normal DHCP operations on the network. The host section defines each LPAR that needs to be configured. A configuration file can have more than one host part. The host section of this example contains only the minimum options required to install the LPAR (and this option is also available when booting the Lpar as a DHCP client later). Host-name is the name of the IP address that DNS assigns to clients. If the client does not have a DNS entry, this option should specify the name to be included in the local host file for the LPAR. Fixed-address is the IP address assigned to the LPAR. This specified address is used in place of the default address pool for the DHCP server. The advantage of this is that the IP address is reserved for the LPAR each time the operating system is booted. Hardware Ethernet Specifies the MAC address of the LPAR. Use this option to associate the LPAR with the host entry in the BOOTP phase of the installation. filename Specifies the Linux kernel that needs to be mounted in response to a BOOTP request. You must be able to access this file through TFTP on the server specified by the Next-server option. Alternatively, if you omit Next-server, you must be able to access the file through TFTP on the DHCP server. NEXT-SERVER Specifies the address of the server. On this server, TFTP allows access to the Linux kernel defined in the filename option. If the TFTP server is on the same server as the DHCP server, you can skip this option. Option routers specifies the address of the TFTP server, provided that the router is configured to not forward a TFTP server request to a TFTP server on the network. If the TFTP server and the DHCP server are on the same machine, you can skip this option.

You can configure the TFTP server using the ATFTPD package in the SLES release. The TFTP configuration provides a directory where you can use TFTP to download files. The download directory is usually/tftpboot. The file specified on the filename parameter of each host part in the dhcpd.conf file must be in the download directory.

For example, for network installation SUSE, this file is a Inst64 file and can be obtained from the/suseboot directory of the SUSE installation CD. You need to put the file in the/tftpboot directory and make sure everyone has permission to read it.

Step 3. Using the HMC lpar_netboot command

Just as the HMC can be used to activate an existing lpar, it can also be used to install the operating system on a new lpar. Although the HMC provides a graphical user interface, all the HMC features can also be used from the command line. This step can be further automated through the command line.

The HMC command to start the network installation is lpar_netboot. The Resources section of this article contains links to detailed instructions on how to use the Lpar_netboot command. This solution uses Lpar_netboot to boot the Lpar over the network.

Listing 3 is an example Lpar_netboot command. Modify the example as needed, then use it on an LPAR and try to boot it from a server on the network.

The example command assumes that:

as described in the previous step of this article, configure the BOOTP server with the MAC address of the new LPAR and have an entry for the SUSE installer. The new LPAR is typically booted as DHCP and contains the static IP address defined for it in the dhcpd.conf file.


Listing 3. Example Lpar_netboot command


lpar_netboot-f t ent-m 16e910948703-s auto-d auto-s 192.168.0.201-g \192.168.0.201-c 192.168.0.203 lpar1 lpar1 Systema

Note: Listing 3 uses a backslash character to indicate a contiguous line; Do not use backslashes when entering commands.

The following is a detailed description of the parameters used in the example:

-M The MAC address of the client that needs to be booted. You can obtain a MAC address by using another form of lpar_netboot command. -S is the IP address of the BOOTP server. -G is the IP address of the gateway required to reach the BOOTP server. If the BOOTP server is on a local network, use the IP address of the BOOTP server instead. -C is the IP address assigned to the client being booted. At the end of the command there are 3 names: Lpar (LPAR1), the HMC name Lpar configuration name, by default the name of the server with the Lpar itself (LPAR1) on the HMC (Systema)

The compressed file in the download section of this article contains a sample script named AutoInstall. You can install the script to the HMC server to automatically install the new LPAR using the techniques described in this article. The script automatically obtains the MAC address of the LPAR, then invokes the DHCP Addsystem script to configure and restart the DHCP server, and then invokes the Lpar_netboot command to install the LPAR. Finally, it invokes a mkvterm command that allows you to see the installation process.

Step 4. Using the-G parameter to automate Lpar_netboot

The new LPAR uses the steps mentioned earlier in this article to load the Linux installer. If you open a console connection to the LPAR from the HMC, you can see the splash screen of the installer.

To further automate the installation, you can use the-g parameter of the Lpar_netboot command to pass additional parameters to the installer of the newly booted system. Linux distributions, such as SUSE and Red Hat, allow full automation of the installation over the network, provided that the correct information is passed to the installer to start the installation.

The information passed on the-G parameter is a string that contains the information the installer needs to find the SUSE autoyast XML file and the SUSE operating system to install RPM. The format of this information is archived by each release and is the same for all schemas (i386 and power, etc.).

Listing 4 is an example of the-G parameter, which initiates an automated installation from the server. Modify the example as needed, and then use it with the Lpar_netboot command to start an automated installation of the operating system.

This example assumes that:

has a WEB server running on the installation server. This WEB server can contain both a DHCP server and a TFTP server, but this is not required. The SUSE installation CD image has been copied to a directory in the root directory of the WEB server document. A copy of the Autoyast.xml file that you configured in step 1 of this article is placed in the WEB server directory where the SUSE installation image resides.


Listing 4. Example Lpar_netboot Server-G parameter


-G "hostip=192.168.0.203 netmask=255.255.255.0 \gateway=192.168.0.1 nameserver=192.168.0.1 insmod=ibmveth \ Install=http://192.168.0.201/suse Autoyast=http://192.168.0.201/autoyast.xml "

Note: Listing 4 uses a backslash character to indicate a contiguous line; Do not use backslashes when entering commands.

The Insmod parameter in Listing 4 loads a virtual Ethernet adapter. This parameter is not required if the currently booted LPAR has a physical Ethernet adapter.

Step 5. Reusing automated Solutions

You now have a configuration that is easy to manage LPAR in a cloud environment. Add the new LPAR by following these steps:

creates an LPAR on the HMC. Log on to the HMC SSH interface and run Lpar_netboot to determine the MAC address of the Lpar. Reconfigure the dhcpd.conf file with the new LPAR information. Restart the DHCP server so that changes to dhcpd.conf take effect. Log on to the HMC again and run Lpar_netboot to install the operating system on the Lpar.

Now all you have to do is wait for the OS installation to complete. After the installation is complete, your cloud environment has a new LPAR that is ready to accept the processes you need to load.

Download

Description Name Size Download method The code in this article autoinstall.zip2kbhttp information about the download method

Resources

Learning


You can refer to the English version of this article on the DeveloperWorks Global website.





more about Lpar_netboot commands through an online reference entry for IBM BAE information Center.





article "DHCP (Dynamic Host revisit Kyoto)" describes how to configure a DHCP server.





to learn more about cloud computing platforms and applications, read "cloud Computing on Linux" (developerworks,2008 year September).





to learn more about cloud computing background, read "Cloud computing with Amazon Web Services, part 1:introduction" (developerworks,2008 year July).





in the cute python: combining XML and Python to introduce Python's XML tools, you can find more references for Linux developers (including beginners of Linux for Linux novices), and check out the most popular articles and tutorials.





all Linux tips and Linux tutorials on DeveloperWorks.





is always focused on developerWorks technical activities and webcasts.








access to products and technology


Order SEK for Linux, which includes two DVDs, with the latest IBM trial software for Linux, including db2®, Lotus®, rational®, tivoli®, and websphere®.





builds your next Linux development project with IBM trial software that can be downloaded directly from DeveloperWorks.








discussion


joins the DeveloperWorks community through blogs, forums, podcast and space.

Author Introduction

David Ashley has over 25 years of IT experience in embedded devices and IBM mainframe installations. He is an IT instructor, development team leader, System architect, System Management advisor, and database integrator. He is currently advisor to IBM Lab Services's System p project and participates in the open source open Object Rexx project in his spare time.

David Boutcher, formerly a senior technician at IBM Linux Marvell Center, has been working in the IBM Development Lab since 1986 and has recently turned to various operating system studies. His field of work is mainly communication and distributed computing.