User:Gnyers/UnattendedDeploymentWithoutPXE

Jump to: navigation, search

Quite surprisingly, there are large data center environments, where the Linux team doesn't have the ability to use PXE for unattended deployment of new systems. Reasons are usually related to network security concerns or administrative restrictions on the DHCP infrastructure. As a result, at best, new deployments will require uploading a bootable ISO image to an out-of-band management facility, booting the server from the virtual DVD drive and finally manually typing a long string of boot parameters before the installation can get started.

This brief HOWTO aims to provide a more convenient, reproducible and controlled approach. The described method assumes the availability of an out-of-band management facility in the system, with support for bootable virtual media. The method combines features of the gPXE network boot loader and AutoYaST, in order to achieve a generic, scriptable deployment process and the ability to monitor the deployment progress on a central log host. Though this HOWTO focuses on SUSE Linux Enterprise and openSUSE, the concepts should also work with other distros as well.

Summary

To keep this HOWTO compact, the description does not elaborate on every aspect in extensive details. Instead it provides a few links to additional information, but mostly it relies on the reader's experience and insight to fill in the gaps.

Requirements:

  • out-of-band management card with support for bootable virtual media, preferably with CLI tools, e.g.: HP's iLO, IBM's RSA, Dell's DRAC or similar
  • install (through HTTP, FTP or NFS) and log server
  • firewall and routing support to initiate sessions from the deployment environment (eg. DMZ) to the install and log server

What is not required:

  • DHCP facility
  • PXE capable BIOS
  • TFTP protocol

The components and concepts used in this HOWTO:

  • uploading a virtual media image (gPXE) to the out-of-band management facility and booting the system with CLI tools is scriptable
  • the built-in scripting support of the gPXE bootloader makes a parametrized URL for retrieving a kernel and initrd possible
  • the "loghost" boot parameter, which makes AutoYaST to forward its log messages to the specified remote log server

Preparations

Create install server

The install server's function is to serve the content of the installation media through the network, often using the HTTP or FTP protocol for this purpose.

One of the simplest solution is to loop mount the installation ISO images and serve the content through a web server like Apache: 

mount -o loop,uid=wwwrun /path/to/SLES-11-SP1-DVD-x86_64-GM-DVD1.iso /srv/www/htdocs/install/sles11sp1-x86_64/

Which will result in something similar on the filesystem: 

/srv/www/htdocs/install/
  sles11sp1-x86_64/
    boot/x86_64/loader/linux
    boot/x86_64/loader/initrd
    ...
    suse/
    ...
Prepare the central log server

Simply uncomment below line in /etc/syslog-ng/syslog-ng.conf 

   source src {
       #...

       #
       # uncomment to process log messages from network:
       #
       udp(ip("0.0.0.0") port(514));
   };
Prepare a gPXE image

gPXE is an open source network bootloader. It provides the same functionality as proprietary PXE ROMs, but with numerous additional features, e.g.: HTTP and FTP support, several image formats (ISO, disk, ROM etc.), serial console and even wireless NIC support. gPXE also has a basic scripting capability.

A gPXE image can be obtained by either building gPXE locally or downloading an image from the project's ROM-o-Matic site.

The recommended options when creating an image using the ROM-o-Matic site are:

  1. Output format: Floppy bootable image (.dsk)
  2. NIC type: all drivers
  3. copy and paste below script in the "Embedded Script" field.
  4. click on "Get Image"
Scripting with gPXE

Example embedded gPXE script: 

   set hostip      192.168.1.101
   set hostnetmask 255.255.255.0                                          
   set gatewayip   192.168.1.1                                            
   set dnsip       192.168.1.1                                            
   set installip   192.168.1.1                                            
   set loghostip   192.168.1.1                                            
                                                                          
   ifopen net0                                                            
   set net0/ip       ${hostip}                                            
   set net0/netmask  ${hostnetmask}                                       
   set net0/gateway  ${gatewayip}                                         
   set net0/dns      ${dnsip}                                             
                                                                          
   kernel http://${installip}/systems/${net0/mac}/linux autoyast=http://${installip}/systems/${net0/mac}/autoyast.xml loghost=${loghostip} testmode=1 install=http://${installip}/systems/${net0/mac}/install/ hostname=ayhost101 netdevice=eth0 hostip=${hostip} netmask=${hostnetmask} nameserver=${dnsip}
   initrd http://192.168.110.1/systems/${net0/mac}/initrd
   
   boot

See also the gPXE scripting page.

Since DHCP is assumed not to be available for use, the script needs to set the usual network parameters both for gPXE and the Linux kernel as well. Fortunately these parameters are quite static and creating a new gPXE image to accommodate changes is quick.

An obvious weak point of this approach arises, when there is a need for more than 1 deployment process at the same time. As a consequence of this requirement there are two additional points one must address:

  • additional host IP addresses
  • keeping track of what IP address is used by the already running deployment process(es)

The additional host IP address problem can easily be solved by creating as many gPXE images, each containing a single host IP from the available range, as the desired number of deployment processes.

Regarding the problem of keeping track of host IP addresses used by the running deployment processes, the easiest solution is to devise a planning and locking scheme kept updated manually. Easy, though not foolproof implementation of this idea would be a spreadsheet.

Preparing the boot infrastructure

By parametrization of the gPXE script it is possible to use system specific deployment configuration. This means, that one can control what get's deployed to a system by setting a few symbolic links on the install server.

In this example the <MAC_ADDR> of the NIC is used to identify a system, but besides this, gPXE also allows the usage of several other parameters as well, e.g.: SMBIOS UUID or Asset Tag.

The filesystem schema of the web server's root on the installation server is as follows: 

/systems/
   <MAC_ADDR1>/
     linux -> ../../install/sles11sp1-x86_64/boot/x86_64/loader/linux
     initrd -> ../../install/sles11sp1-x86_64/boot/x86_64/loader/initrd
     autoyast.xml -> ../../autoyast/base-sles11sp1-x86_64/autoyast.xml
   <MAC_ADDR2>/
     linux -> ...
     initrd -> ...
     autoyast.xml -> ...
   <MAC_ADDR3> -> <MAC_ADDR1>/

/install/
   sles11sp1-x86_64/
     boot/x86_64/loader/linux
     boot/x86_64/loader/initrd
     ...
     suse/
     ...
   sles11sp1-i386/
     boot/i386/loader/linux
     boot/i386/loader/initrd
     ...

/autoyast/
   base-sles11sp1-x86_64/
     autoyast.xml
     ...
   base-webserver/
     autoyast.xml
     ...
Preparing a particular system's boot settings

The steps:

  1. Create the directory <MAC_ADDR1>
  2. Create symbolic links to the appropriate kernel, initrd and AutoYaST profile
  3. In case of multiple NICs in a system, and not certain of their enumeration, create a symbolic link <MAC_ADDR3> -> <MAC_ADDR1>

For example: 

/systems/
   <MAC_ADDR1>/
     linux -> ../../install/sles11sp1-x86_64/boot/x86_64/loader/linux
     initrd -> ../../install/sles11sp1-x86_64/boot/x86_64/loader/initrd
     autoyast.xml -> ../../autoyast/base-sles11sp1-x86_64/autoyast.xml

Deployment

Unattended deployment

Using the tools provided by the out-of-band management facility, upload the prepared gPXE image to the module's virtual floppy and boot the system from it. Depending on the out-of-band management facility this could be scripted as well. In case of GUI or Browser based tools, this step will probably needs to be performed manually.

Links:

After booting the system from the uploaded gPXE image, the embedded scripting in the bootloader will automatically kick-off the unattended installation. The progress can be monitored on the log host: 

   tail -f /var/log/messages | grep ayhost101
Interactive Installation

When omitting the "autoyast" parameter, YaST will perform an interactive installation, which will require a console. Besides the hardware options of a KVM switch or the console function of the out-of-band management facility (if available at all), YaST also provides two possibilities to interact with a user through SSH and VNC. To use either, please modify the above gPXE script to reflect one of the following:

for SSH: 

   ssh=1 sshpassword=MySecretPasswd

for VNC: 

   vnc=1 vncpassword=MySecretVNCPassword
Retrieved from "https://en.opensuse.org/index.php?title=User:Gnyers/UnattendedDeploymentWithoutPXE&oldid=47292"