Prepare Automated Reinstallation


When it is necessary to rapidly install multiple systems and prepare them for production use, an automated reinstallation facility will make it easier to do so. More important, it will significantly improve the chances of commissioning a replacement server without mistakes being made. A breakdown that requires installation of a new server usually creates much stress and anxiety, thus creating a situation during which logic and a systematic approach to recovery of business operations may fail.

A secondary benefit that may be obtained from the process of creating an automated recovery facility is that it can also be used to roll out multiple identical servers. This is of considerable value in a large organization. In other words, sound administration practices can result in processes that support rapid recovery. Likewise, spending the time to prepare for recovery can improve normal operations.

It is easy to install Linux by inserting a DVD install disk and responding to a few installation process prompts. However, this type of installation is human resource intensive and requires product expertise, and the results of installation can be highly varied when performed by more than one person.

The purpose of automated installation is to reduce human resource overhead, to improve efficiencies, and to deliver a totally predictable and consistent installation result. The process begins by installing a server manually, then preparing automated installation processes.

Some sites prefer to install a temporary installation server that will be used to generate automated installation tools, after which this server is overwritten with an automatic installation. Most sites find it more practical to have a dedicated installation server.

A dedicated installation server can be used to perform local network updates as well as to assist in the deployment of new systems.

Automated installations can be performed from

  • CD-ROM or DVD-ROM

  • A local disk partition that contains the installation and recovery files

  • A network resource (via either NFS or SMB)

It is possible to generate custom installation CDs or DVDs from which a completely customized and fully configured server can be created. Considerable effort may be required to complete this, but the results are most often justified entirely by the speed of recovery in the event of a massive hardware failure.

Sites that have a large number of servers can appreciate the value of a permanently available network installation server. The same server can be used to install MS Windows servers as well as Linux servers. A low-cost dedicated installation server can be built for less than $1,000 using a relatively low- powered desktop PC with a 200GB IDE hard drive. As a precaution, do not install the installation server on the production network, and install server systems offline from the production network. This will help protect the installation software from any infection or malware circulating on the production network, and prevent a new server from being compromised during installation.

Prepare Red Hat Kickstart Install Facility

Use of Red Hat Kickstart is simple, but proficiency in the flexibility of its use will take some practice. The use of Kickstart ceases to be a simple process if the ultimate solution of a single custom installation CD is the only acceptable objective.

The Red Hat installation CD-ROM uses a floppy disk that has been specially encoded to use the El Torito boot process. The disk image that has been embedded into the CD-ROM boot catalog has a standard MS-DOS FAT file system. The boot disk is specific to each particular Red Hat Linux release and must be prepared from the boot disk that is provided on the installation CD-ROM.

Create the Kickstart CD-ROM

The following steps will permit modification of the first installation CD-ROM to include a Kickstart facility. In this instance, the multiple installation CD-ROM process will be preserved. This will permit the implementation of Kickstart with minimum change to the original CD-ROM.

  1. First install Red Hat Enterprise Linux AS 3.0 on a PC. Be sure to install the packages called cdrecord and mkisofs .

  2. Create a directory into which can be copied the first boot CD-ROM for your distribution. Insert the first installation CD-ROM into the drive.

  3. Follow these steps:

     [root@localhost /]# mkdir -p /export/RHEL3 [root@localhost /]# cd /export/RHEL3 [root@localhost RHEL3]# mount /dev/cdrom /mnt [root@localhost RHEL3]# cp -a /mnt/. . [root@localhost RHEL3]# cd isolinux [root@localhost isolinux]# vi isolinux.cfg 
  4. Now edit the contents of the file isolinux.cfg so it has the following information:

     default ks prompt 1 timeout 120 display kickstart.msg F1 boot.msg F2 options.msg F3 general.msg F4 param.msg F5 rescue.msg F7 kickstart.msg label linux   kernel vmlinuz   append initrd=initrd.img ramdisk_size=8192 label text   kernel vmlinuz   append initrd=initrd.img test ramdisk_size=8192 label expert   kernel vmlinuz   append expert initrd=initrd.img ramdisk_size=8192 label ks   kernel vmlinuz   append ks=cdrom:/ks.cfg initrd=initrd.img ramdisk_size=8192 label lowres   kernel vmlinuz   append initrd=initrd.img lowres ramdisk_size=8192 label memtest86   kernel memtest   append - 
  5. In this example file, the following modifications have been made:

    • The default installation type has been changed from an interactive installation to one controlled by the Kickstart control file.

    • The timeout has been reduced from ten minutes to two minutes.

    • The default boot message has been changed to our own message.

    • The entry under function key F7 has been changed from snake.msg to kickstart.msg.

    • The Kickstart boot parameter has been changed from ks to ks=cdrom:/ks.cfg. This specifies the default Kickstart control file.

      Heads Up  

      It is possible to place more than one Kickstart control file on the CD-ROM. There must be one in the root directory of the CD-ROM called ks.cfg. Assuming there is also a file called samba-ks.cfg, it can be specified by entering the following at the command line:

  6. Now create the kickstart.msg message file that will be displayed onscreen when the system is booted from the CD-ROM that will soon be created. The following contents can be used as an example:

     append ks=cdrom:/samba-ks.cfg initrd.img ramdisk_size=8192 ^L ^Xsplash.lss  - This is a kickstart CDROM. Press the ^O0f<ENTER>^O07 key (default).  - To effect a standard graphical installation, type:                ^O0flinux <ENTER>^O07.  - Use the function keys listed below for more information. ^)02[F1-Main] [F2-Options] [F3-General] [F4-Kernel] [F5-Rescue]^O07 
  7. The ks.cfg file can be created using any Unix text editor. A more convenient method is to use the GUI tool provided by Red Hat. To use the GUI tool, click the Red Hat icon, then select System Tools Kickstart. Carefully edit the installation configuration control parameters. When the configuration is complete, save it to the directory that will become the root directory of the CD-ROM as a file named ks.cfg. In the example used above the fully qualified file location will be /export/RHEL3/ks.cfg. An example of this tool following configuration is shown in Figure 5-1.

    click to expand
    Figure 5-1: Red Hat Kickstart editor

    The following listing was created using vi, the Unix system text editor. The file you have created will of course be different. Hopefully you will have selected just the software that is needed for your server.

     #Kickstart control file manually created #System language lang en_US #Language modules to install langsupport --default=en_US #System keyboard keyboard us #System mouse mouse generic3ps/2 #System timezone timezone --utc America/Phoenix #Root password rootpw not24get #Reboot after installation reboot #Install or Upgrade Red Hat Linux install #Use CD-ROM media cdrom #System bootloader configuration bootloader --location=mbr #Clear master boot record zerombr yes #Partition and clear all disk information clearpart --all --initlabel #Partitions to be created part / --fstype ext3 --size 1 --grow --asprimary part /var --fstype ext3 --size 512 part swap --size 1024 #System authentication settings auth --useshadow --enablemd5 #Network configuration network --bootproto=static --ip=123.45.67.89 --netmask=255.255.255.192 \ --gateway=123.45.67.65 --nameserver=123.45.67.65 --device=eth0 network --bootproto=static --ip=192.168.1.1 --netmask=255.255.255.0 \ --gateway=192.168.1.1 --nameserver=192.168.1.1 --device=eth1 #Firewall settings firewall --enabled --trust=eth1 --http --ssh --smtp #XWindows configuration xconfig --depth=32 --resolution=1280x1024 --defaultdesktop=GNOME \ --startxonboot  #Execute the setup agent on first boot firstboot --enable #Package installation details %packages --resolvedeps @ X Window System @ GNOME Desktop Environment @ Editors @ Engineering and Scientific @ Graphical Internet @ Text-based Internet @ Office Productivity @ Authoring and Publishing @ Server Configuration Tools @ Web Server @ Mail Server @ Windows File Server @ DNS Name Server @ Network Servers @ Administration Tools @ System Tools @ Printing Support 
  8. Add the ks.cfg file plus any additional Kickstart control files needed for your site to the root directory of the new CD-ROM.

  9. Now that all the Kickstart configuration files are in place, place a blank CD-R into the drive. The final steps that will be used to create the CD-ROM disk are as follows :

     [root@localhost /]# cd /export/RHEL3 [root@localhost RHEL3]# mkisofs -r -T -J \ -V "XYZ Corporation Custom Kickstart CD" \ -b isolinux/isolinux.bin \ -c isolinux/boot.cat \ -boot-emul-boot \ -boot-load-size 4 \ -boot-info-table \ -o /export/kickstart-cdrom-20040515.iso /export/RHEL3 [root@localhost RHEL3]# cd /export [root@localhost /export]# cdrecord -v speed=4 dev=0,0,0 \ /export/kickstart-cdrom-20040515.iso 
  10. You may now boot from the newly created CD-ROM to test the new Kickstart facility.

When creating the Kickstart control file, you may have noticed the provision for executing pre-install and post-install scripts. These make it possible to automate the configuration of the server. The scripts can be stored on a network file system from which they may be executed. This combination permits considerable flexibility in the use of Kickstart once it has been mastered.

Kickstart was introduced by Red Hat before Red Hat Linux 5.0 was released. It is a mature facility that has stood the test of time. Kickstart GUI configuration tool was a welcome addition. It will be interesting to see the development path that Red Hat will follow with Kickstart. Just imagine how powerful this tool might be if the entire process of creating a Kickstart environment could be fully automated so that even a novice can use it.

Red Hat Linux lacks a facility like YaST2 that will back up all files, including those that are not part of the operating system or configuration files that have been altered since the system was installed, and then be able to restore them for recovery. The administrator should therefore do a complete backup using his own scripts or commercial software. Scripts or software can then be used to restage the system. A commercial solution should be considered as the most reliable solution for this approach since implementing backup scripts and performing a complete recovery of a server is a very delicate task.

Using a Network-Based Kickstart Installation

Red Hat Linux can be installed over the network. Various methods can be used. The simplest method boots from a CD-ROM and simply obtains the Kickstart control file via NFS or FTP. It is also possible to use a boot floppy disk that has a Kickstart ks.cfg file that specifies a network source location for all installation files. Kickstart is a very flexible tool that can be used with Intel PXE or alternative DHCP-enabled means to provide a boot floppy image, thus doing away with the need even for a physical boot floppy disk. This way, the entire installation process can be automated. This is of particular interest to sites that want to roll out Linux to many thousands of systems.

Please refer to the network installation methods available for your version of Red Hat Linux, as documented in the administration guide.

Using SUSE YaST Auto-installation Tools

SUSE has taken its time to develop its YaST toolset. (YaST is an acronym for Yet another Setup Tool.) YaST in SUSE SLES8 is in its second generation. Prior to YaST, SUSE had a tool called ALICE (Automated Linux Installation and Configuration Environment). ALICE was extensively used, but lacked some features demanded by administrators.

YaST is an entirely new, integrated system for Linux system management that has recently been released under the GPL license. YaST is an exceptionally ambitious project that is much too complicated to document in one short chapter. The SUSE Linux administrator really ought to spend time getting to know the capabilities of this incredibly powerful toolset. The instructions for creating a SUSE auto-installation image are provided in the following steps.

SUSE has substantially updated YaST2 in SLES9. Autoyast (the auto-installation configuration system) in SLES8 can be used to generate a full ISO (CD-ROM or DVD) image of the installed system, or may be used to generate auto-installation control files. In SLES9, these two very different requirements have been separated into two tools, both of which are much easier to use than the compound all-in-one tool present in SLES8.

In both SLES8 and SLES9 Autoyast versions, it is possible to import a configuration file that was generated using the SLES7 ALICE toolset. It is also possible to import a Red Hat Kickstart control file. This capability adds flexibility and the ability to migrate from earlier versions as well as from Red Hat Linux to SUSE SLES without loss of previous effort. A personal preference of some administrators is to begin each new installation with a clean slate, thus the capacity to migrate using these backward-compatible tools is not of interest to all.

This is a good place to refocus on the objective of this chapter: to make it possible to rapidly recover from a major system breakdown. It s nice to have the ability to automatically roll out new servers, but that is not the primary focus here.

It is most helpful to provide an installation server to facilitate network based installations. Two NFS file systems are required. One will be used to store the installation files from the SUSE SLES8 install CD-ROMs, the other share will be used to store system backups .

You will create an NFS share point on the installation server (assumed hostname is pomeroy, IP address 10.0.0.95). In this case, it will be the file system under /export. The following steps complete the process:

  • Create the SLES8 network installation shared directory tree.

  • Include SLES8 SP3 in the NFS installation server share.

  • Create an ISO image of the installed system.

  • Create a recovery backup archive.

Create the SLES8 Network Installation Shared Directory Tree

Log into the Linux system as the user root, and open a shell session by clicking the icon of the shell in front of a computer monitor.

  1. Create the shared directory and load its contents as follows:

     [root@localhost /]# mkdir -p /export/{SLES8/{UL/CD{1,2,3},SLES},Backups} [root@localhost /]# echo "/export *(rw,no_root_squash,sync)" >> /etc/exports [root@localhost /]# rcnfslock start [root@localhost /]# rcnfsserver restart [root@localhost /]# chkconfig nfslock on [root@localhost /]# chkconfig nfsserver on 
  2. Insert the SLES8 install CD into the CD-ROM drive.

    The following steps permit the CD-ROM to be mounted so that the files on it may be copied to the hard disk:

     [root@localhost /]# mount /dev/cdrom /mnt [root@localhost /]# cd /export/SLES8/SLES  [root@localhost CD1]# cp -a /mnt/. . [root@localhost CD1]# umount /mnt; eject cdrom 
  3. Insert the UnitedLinux CD1 into the CD-ROM drive.

    Now repeat the process of mounting the next CD-ROM so that its contents also may be copied to the hard drive as follows:

     [root@localhost /]# mount /dev/cdrom /mnt [root@localhost /]# cd /export/SLES8/UL/CD1 [root@localhost CD1]# cp -a /mnt/. . [root@localhost CD1]# umount /mnt; eject cdrom 
  4. Insert the UnitedLinux CD2 into the CD-ROM drive.

    Each CD-ROM must be copied to its respective directory, so just keep following the steps shown here:

     [root@localhost /]# mount /dev/cdrom /mnt [root@localhost /]# cd /export/SLES8/UL/CD2 [root@localhost CD2]# cp -a /mnt/. . [root@localhost CD2]# umount /mnt; eject cdrom 
  5. Insert the UnitedLinux CD3 into the CD-ROM drive.

    The following steps complete the process of copying the SLES8 product installation CD-ROMs to the hard drive:

     [root@localhost /]# mount /dev/cdrom /mnt [root@localhost /]# cd /export/SLES8/UL/CD3 [root@localhost CD3]# cp -a /mnt/. . [root@localhost CD3]# umount /mnt; eject cdrom 
  6. Create the multi-source resource links and files so that the installer will find all necessary installation source files.

    Just follow the next steps carefully. Pay close attention to ensure that the correct number of > characters are used in each command executed in the following steps:

     [root@localhost /]# cd /export/SLES8 [root@localhost /]# mkdir yast [root@localhost /]# echo -e "/SLES\t/SLES" > yast/order [root@localhost /]# echo -e "/UL/CD1\t/UL/CD1" >> yast/order [root@localhost /]# echo -e "/UL/CD1\t/UL/CD1" > yast/instorder [root@localhost /]# echo -e "/SLES\t/SLES" >> yast/instorder [root@localhost /]# ln -sf SLES/content [root@localhost /]# ln -sf SLES/media.1 [root@localhost /]# cp -a SLES/boot . 

    Set the file system permissions on these two resources as follows:

     [root@localhost /]# chmod ug+rwx,o-rwx /export/Backups 
  7. Click the gecko (KDE) icon, then click Run Command. Enter yast2 . Click the Run button.

  8. Select Software Change Source Of Installation.

  9. Delete the original entries that were created during installation from CD-ROM.

  10. Click the Add button, click Local Directory, enter the path to the SLES8 installation CD-ROM files (/export/SLES8), then click OK. Figure 5-2 shows the screen as it should appear after the new settings have been applied.

    click to expand
    Figure 5-2: SUSE change source of installation

  11. Click Finish.

Now log onto the server that is the subject of the backup and for which auto-installation facilities are being prepared.

Including SLES8 SP3 in the NFS Installation Server Share According to the SUSE FAQ for auto-installation (see http://www.suse.de/~nashif/autoinstall/faq.html), service pack 3 sources may be added into the installation server SLES8 share as shown in the following example:

 mkdir -p SLES mkdir -p UL/{CD1,CD2,CD3} mkdir -p SP3/{CD1,CD2} mkdir -p yast mount -o loop /iso/SLES-8-x86-64-CD1.iso SLES mount -o loop /iso/UnitedLinux-1.0-x86-64-CD1.iso UL/CD1 mount -o loop /iso/UnitedLinux-1.0-x86-64-CD2.iso UL/CD2 mount -o loop /iso/UnitedLinux-1.0-x86-64-CD3.iso UL/CD3 mount -o loop /iso/UnitedLinux-1.0-SP-3-x86-64-CD1.iso SP3/CD1 mount -o loop /iso/UnitedLinux-1.0-SP-3-x86-64-CD2.iso SP3/CD2 ln -sf SLES/boot ln -sf SLES/media.1 ln -sf SP3/CD1/driverupdate ln -sf SP3/CD1/linux ln -sf SLES/content  printf "/SP3/CD1\t/SP3/CD1\n" >  yast/order printf "/SLES\t/SLES\n" >>  yast/order printf "/UL/CD1\t/UL/CD1\n" >> yast/order printf "/UL/CD1\n" > yast/instorder printf "/SLES\n" >> yast/instorder printf "/SP3/CD1\n" >>  yast/instorder 

The ISO image files can be created from the official CDs by executing the following:

 mkdir /iso dd if=/dev/cdrom of=/iso/SLES8-CD-name.iso 

The use of CD-ROM ISO images is not recommended for large scale use because mounted resources cannot be exported via NFS. It is a better proposition to copy each CD-ROM to the file system as shown in steps 2 to 5 in the earlier example. The instructions shown here were taken directly from the FAQ and are included purely for completeness. In any case, this clearly demonstrates the principles of adding service packs to the installation server exported files share.

When adding SP3 you will need the boot information from the SP3 CD-ROM, and the pointers to media.1 and content from the base SLES CD-ROM.

Create an Auto-installation Control File

The first step toward production of a CD-ROM disk from which the system can be fully cloned (recovered) is to create the auto-installation control file. This file will contain a list of all packages that have been installed as well as disk partitioning instructions.

The following steps will create the master file needed for the ISO image creation step:

  1. Click the gecko (KDE) icon, then click Run Command. Enter yast2 . Click the Run button.

  2. Select Software Change Source Of Installation.

  3. Delete the original entries that were created during installation from CD-ROM.

  4. Click Add, click the NFS option, enter the IP address (10.0.0.95) into the Server Name box, then enter the path to the SLES8 installation CD-ROM files (/export/SLES8). Click OK.

  5. Click Finish.

  6. Open a shell GUI by clicking on the icon of the shell on top of a monitor.

  7. From a shell prompt, mount the installation server NFS file system (/export) as follows:

     [root@localhost /]# mkdir /nfs [root@localhost /]# mount -t nfs 10.0.0.95:/export/SLES8 /nfs [root@localhost /]# exit 
  8. Click Misc Autoinstallation.

  9. In the Profile Management section, click the radio button beside Clone This Machine, then click Next.

  10. Click the Preferences button. Enter the path /nfs , then click Next. Figure 5-3 shows the edited screen before clicking the Next button.

    click to expand
    Figure 5-3: SUSE Autoyast preference settings

  11. Click the option to Save Result Into Repository. Set the name of the resulting profile to clone.xml as shown in Figure 5-4, then click Next. Be patient, this step can take a few minutes.

    click to expand
    Figure 5-4: SUSE Autoyast showing entry of the filename clone.xml

  12. The File Management panel shows the current profile, clone.xml, as shown in Figure 5-5. Click Save, click OK, and then click Finish.

    click to expand
    Figure 5-5: SUSE AutoYaST utility ready to save the clone.xml profile file

The auto-installation control file that is needed for the ISO image production is ready for use. Now follow the steps outlined to create ISO image of installed system.

Heads Up  

You should edit the clone.xml file using the auto-installation tool, carefully making certain that all options you want to create on the target system are correctly shown.

Create an ISO Image of the Installed System

The following process will create an ISO (CD-ROM) image from which the system can be reinstalled at a future date. The resulting CD-ROM will create only a clone of the machine from which it is produced.

  1. Mount the installation server shared resource under a directory called /nfs:

     [root@localhost /]# mkdir /nfs [root@localhost /]# mount -t nfs 10.0.0.95:/export /nfs [root@localhost /]# mkdir /nfs/Backups/portofive 

    The hostname of the server being installed (and subject to backup) is portofive.

  2. Click the gecko (KDE) icon, then click Run Command. Enter yast2 . Click the Run button.

  3. In the left panel of the YaST Control Center, click the Misc icon, then click the Autoinstallation icon.

  4. Click the radio button in the Media Management section on the right panel to activate Create ISO Image, then click Next.

  5. Select the control file clone.xml and click Next. See the example screen in Figure 5-6. The control file called mysystem.xml was generated to configure a different server. This was included to highlight the fact that in a large deployment there will likely be many server configurations. You can name the file that contains the control information that results from cloning your system by any name you choose, but if you use another name it must be used consistently throughout the remaining process of generating the auto-installation ISO file.

    click to expand
    Figure 5-6: SUSE Autoyast selection of the clone.xml profile

  6. Enter the Destination as /export/clone.iso . Click Next. The action that results can take some time, so be patient even if nothing seems to happen for a few minutes. Figure 5-7 shows the screen we generated at the conclusion of this step and before the Next button was clicked.

    click to expand
    Figure 5-7: SUSE Autoyast Create Custom CD screen

  7. At this time, the files that must be copied to the ISO image will be copied to a temporary disk area under the /tmp directory. This step will fail if there is insufficient space in the /tmp directory for approximately the volume of data that will be copied to the ISO image plus a margin of about 10 percent to cover intermediate operations.

    Figure 5-8 shows the final state of this operation. Click Next to complete the building of the ISO file.

    click to expand
    Figure 5-8: SUSE Autoyast ready to create the ISO image

    Figure 5-9 shows the final screen after the ISO file has been created. Note that when this screen is displayed there may still be considerable disk activity while the ISO image is being written to disk.

    click to expand
    Figure 5-9: SUSE Autoyast ISO file has been created

    The ISO image must now be burned to CD-R or DVD-R media. The ISO image size will depend on the software that has been installed on the system. The image produced in this example was 968MB ”obviously too large for a CD-R. If the ISO is larger than a CD-R can hold, the only choice is to burn it to DVD media. SUSE Linux products ship with a utility called k3b that can be used to burn ISO images to either CD-R or DVD-R media.

  8. Click Close, then Back to exit autoyast.

Create Recovery Backup Archive

YaST2 has a very useful backup and restore facility that can be used to back up all files that do not belong to system packages (see Figures 5-10 and 5-11). It can also be used to back up system configuration files that do belong to packages and that may have been modified during system configuration. The tar archive file that is generated by this process can be stored on a network file system from which it can be used to restore the server to its ready-to-run condition.

click to expand
Figure 5-10: YaST2 backup showing selection of backup archive location and type
click to expand
Figure 5-11: YaST2 backup showing exclusion of the /nfs mounted resources

This process should be completed when all software has been installed at the conclusion of system configuration. The resulting backup archive can be tailored to fit across CD-ROM “ sized files that can be burned to CD-Rs for safekeeping.

The backup archive for this machine can be created as follows:

  1. Mount the installation server shared resource under a directory called /nfs:

     [root@localhost /]# mkdir /nfs [root@localhost /]# mount -t nfs pomeroy:/export /nfs 

    If the directory for the machine portofive does not yet exist, create it using the following command:

     [root@localhost /]# mkdir /nfs/Backups/portofive 
  2. Click the gecko (KDE) icon, then click on Run Command. Enter yast2 backup . Click the Run button.

  3. In the Archive File Name box, enter /nfs/portofive/Backup20040515.tar .

  4. Select archive type tar with bzip2 subarchives. bzip2 is a more efficient compression tool than gzip. Click Next.

  5. Select the options Search files that do not belong to any package and Check MD5 sum instead of time or size. Click Next.

  6. Click Add. Add the /nfs directory to the list of directories to be excluded from search. Click Next.

The backup archive will now be created. The resulting file can be used with the yast2 restore facility to reset all configuration settings to the original values at any time.

This backup file can also be integrated into an auto-installation process, but that is beyond the scope for this book. Consult the administration guide that was provided with your copy of SUSE SLES8 for details on how to effect further integration where this is required.




Hardening Linux
Hardening Linux
ISBN: 0072254971
EAN: 2147483647
Year: 2004
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net