Advanced Linux Installations and Upgrades With Kickstart

7/30/2019 Advanced Linux Installations and Upgrades With Kickstart

1/6

Advanced Linux Installations and Upgrades with Kickstart

by Ethan McCallum11/04/2004

Editor's note: Ethan has collected this series and other information into Managing RPM-Based Systems with Kickstartand Yum. This series concludes in Pre-patched Kickstart Installs.

In Hands-Off Fedora Installs with Kickstart, I provided an overview of the Kickstart process. This article is a collectionof techniques that may interest people who want to do more with Kickstart. It covers Kickstart customization,scalability, and security, including:

dynamic ks.cfg

storing ks.cfg on removable media

default booting to kickstart

pre- and postinstall scripts

custom RPMs and package groups using Kickstart to upgrade

Dynamic ks.cfg

Most Kickstart experiments begin with a single ks.cfg file, though this approach is less suitable for large deployments.Even a farm of cloned hardware will require some settings unique to each host. That means you have either severalone-use ks.cfgs, or one file to tweak for each Kickstart target. These methods are brittle because they bind twoelements that may vary independently of one another: host-specific data (the IP address) and build-specific data(packages to install). When either one changes, the ad hoc edits to resync the two may introduce errors.

You can avoid this hassle if you're programmatically inclined: pre-generate a series ofks.cfg, or generate the data onthe fly. The latter requires that your Kickstart clients fetch ks.cfg via HTTP. Both approaches use the mail-mergeconcept: create a template ks.cfg with placeholders for the dynamic info, then merge that with a data source thatcontains one set of values for each host. A Perl or PHP template, for example, may include the following:

## ... other settings ...

network --device ${network_device} --bootproto static--ip ${network_address} --netmask ${network_mask}--gateway ${network_gateway}--nameserver ${nameserver_1}--nameserver ${nameserver_2}--hostname ${hostname}
http://www.linuxdevcenter.com/pub/au/1910http://www.oreilly.com/catalog/9780596513825/http://www.oreilly.com/catalog/9780596513825/http://www.linuxdevcenter.com/pub/a/linux/2005/02/17/kickstart_updates.htmlhttp://www.linuxdevcenter.com/pub/a/linux/2004/08/19/kickstart.htmlhttp://ad.doubleclick.net/click%3Bh=v8/358d/3/0/%2A/d%3B111357591%3B0-0%3B0%3B14651645%3B4252-336/280%3B21685063/21702953/1%3B%3B~sscs%3D%3Fhttp:/www.untangle.com/index.php?option=com_content&task=view&id=275&Itemid=747&gclid=CLyfi7Wc5owCFSEfYQodZGDg0whttp://www.linuxdevcenter.com/pub/au/1910http://www.oreilly.com/catalog/9780596513825/http://www.oreilly.com/catalog/9780596513825/http://www.linuxdevcenter.com/pub/a/linux/2005/02/17/kickstart_updates.htmlhttp://www.linuxdevcenter.com/pub/a/linux/2004/08/19/kickstart.html


2/6

(We've split the above for readability; it is really one line.)

Pre-generating files requires that you create one file per target host (the Kickstart client). Specify that host's file atthe CD's boot: prompt. For example:

boot: linux ks=http://server/ks_configs/host5.cfg

While this method certainly works, it requires you to remove the generated files later (or leave them around forever).

By comparison, the web-based method requires no such cleanup, since the data lasts only as long as the HTTPrequest. Clients specify a unique identifier in the URL:

boot: linux ks=http://server/config.pl?target=host5

This identifier is a key to the rest of that host's data, which the script uses to populate the template.

A completely automated solution would detect the target host's identity rather than rely on URL parameters. Forexample, it could mine DHCP data to match the incoming IP to a MAC address. This sort of solution would require ahardware inventory system that I suspect is quite rare, though.

Neither method relies on a particular implementation: use PHP, Java, Perl, or whatever you fancy. Perl fans have theTemplate Toolkit. A Java solution could use Apache's Velocity. These last two have the added bonus of being usable inboth web (on the fly) and command-line (pre-generated) scenarios. Most programming languages provide built-insupport for a variety of data formats, so you have your choice of storing the machine data in flat files, XML, an

RDBMS, or whatever else comes to mind.

Storing ks.cfg on Removable Media

ks.cfg contains the root password, and as such, sensitive shops may not want it to cross the wire via HTTP or FTP. Youcan trade the convenience of clients downloading ks.cfg for the added security of storing it on removable media, suchas a disk, a CD, or an external drive.

The disk route is the easiest: copy the file to the root directory of a formatted disk. When you boot the target hostfrom the CD, enter:

boot: linux ks=floppy:/ks.cfg

floppy here is a device alias for fd0. Specify another partition's name to load ks.cfg from that device:

boot: linux ks=hd:{partition}:/ks.cfg

{partition} is an identifier from the/devdirectory, such as sda1. (Remember: USB, FireWire, and other suchdevices appear as SCSI devices.)

The CD method requires slightly more work, because it creates a bootable CD. In the distribution, the isolinuxdirectory represents the root directory of a boot CD. Copy it to a scratch space, and then copy your custom ks.cfg to{scratch space}/isolinux. Change to the directory above isolinuxand call mkisofs to generate the ISO image:

$ mkisofs -o boot-ks.iso -r -b isolinux.bin \-c boot.cat -no-emul-boot -boot-load-size 4 \-boot-info-table -R -J -v -T isolinux/

(Note that the boot image file, isolinux/isolinux.bin, must be writable or mkisofs will fail.)

Follow your standard procedure for burning this ISO to media. If you use VMWare as a Kickstart test platform, you

can save a disc by specifying the ISO as the guest's CD-ROM device. Boot a test machine from the CD and fire offKickstart using the local ks.cfg:
http://www.template-toolkit.org/http://jakarta.apache.org/velocity/http://www.vmware.com/http://www.template-toolkit.org/http://jakarta.apache.org/velocity/http://www.vmware.com/


3/6

boot: linux ks=cdrom:/ks.cfg

There are, of course, trade-offs here. Disks tend to have shorter and less predictable life spans than CDs and requireyou to have a boot CD handy. Then again, CDs and CD-RWs are good for a limited number of writes. Furthermore,because of the strong ties between the boot media and the target OS revision, your boot CDs become coasters at thenext upgrade rollout. Using other removable media requires that your boot medium's kernel support your SCSI (orUSB, or FireWire) adapter.

Whatever the case, you needn't limit yourself to a single config file. You could copy a series of pre-generated configfiles to the disk or CD, then specify the target host's file at the boot: prompt:

linux ks=hd:sdb5:/ks-host5.cfg linux ks=floppy:/ks-host5.cfg

As ks.cfg is just a few K in size, space shouldn't be a problem.

There's no right answer here. Arguably, storing ks.cfg on removable media works best for small or medium shops orfor large one-offs such as clone farms. If your goal is to make sure sensitive Kickstart data doesn't cross the normalnetwork, set up a private build network using a portable switch and serve Kickstart data from a laptop.

Default Booting to Kickstart

Whether you're building a clone farm or repeatedly testing a Kickstart setup, you'll tire of entering linux ks=...

each time you start a build. (Maybe that's just me; people have accused me of selective laziness.) You can create aboot CD that automatically loads your ks.cfg, making Kickstart a true fire-and-forget process.

The key to this magic is isolinux/isolinux.cfg. To start, define a new boot selection by adding a new stanza:

label custom_kickstartkernel vmlinuzappend initrd=initrd.img ramdisk_size=8192 ks=cdrom:/ks.cfg

This lets you enter:

linux custom_kickstart

at the CD's boot: prompt to fire off a Kickstart. The operation will use the ks.cfg in the CD's root directory. Change

the default directive to make this the default:

default kickstart

To be fancy, associate an explanatory message with an F-key:

F8 our_site.msg

(There are other directives in isolinux.cfg worthy of experiment, but they're beyond the scope of this article.)

The specified ks.cfg needn't exist on the boot CD; you can specify other valid sources, such as a disk or a URL. If yourdynamically generated ks.cfg doesn't require parameters to identify the target host, you can have a single boot CD forthe entire shop, or at the least, one CD per OS version.

Pre- and Postinstall Scripts

Kickstart does a lot of host customization for you--setting the root password, the time zone, and so on--but it won'tdo certain other tweaks, such as disabling services via chkconfig or setting up site-specific directory structures. Youcan automate these tasks using the pre- and postinstall scripts. (There is one of each.) Per their names, these scriptsrun before and after the installation, respectively.


4/6

The preinstall script starts toward the end ofks.cfg under the %pre directive. The syntax is similar to that of an RPM

spec file. At this early stage there is a bare-bones assortment of tools at your disposal, just enough to shuffle filesaround or mount NFS shares.

The postinstall script (%post) has more potential. By this point, with the OS installed, the script defaults to running

chrooted in the newly installed OS under/mnt/sysimage. You can disable this by using %post's --nochroot flag,

by the way. Use this script to alter runtime services with chkconfig, install a rudimentary firewall rule set, or doanything else you'd rather take place before the machine reboots into full-service mode.

Both the %pre and %post directives accept the --interpreter flag, which specifies an interpreter other than the

default Bourne shell. You can choose only from the interpreters available at runtime, obviously; but likely thechrooted environment of the postinstall script will have a wider selection.

Pre- and postinstall scripts certainly have their place, but they're easy to misuse, difficult to test, and require updatesas your build environment evolves. Simplify your build by extracting %pre and %post script functionality into custom

RPMs or formal update processes (such as cfengine and rsyncwrappers). These have the added benefit of beingusable (and testable) outside of the install process.

Custom RPMs and Package Groups

It's not uncommon for a Linux-savvy shop to create custom RPMs, such as homegrown software or site-specificadjustments of third-party packages. Kickstart's ties to RPM (via Anaconda) permit you to transparently add theseRPMs to the installation process. This requires that you copy your RPMs to the tree, create a new group in the compsfile, and update package headers.

The first step is the easiest: copy your custom RPMs to {install tree}/Fedora/RPMS. Make sure the files have

appropriate read-access permissions.

The comps file is Fedora/base/comps.xmlin the install tree. It contains definitions of package groups, which arecollections of RPMs that you can select and install en masse. (A detailed tour of the comps file is beyond the scope ofthis article, but you need to know very little to add a group.)

It's cleaner and more future-proof to put your custom RPMs in a new, separate group. For example, create a tag in comps.xml:

local_packages

Local RPMs

home-built RPMs

false

package1

package2package3

I find it easiest to define new groups at the top ofcomps.xml, or better still to store them in a separate file and insertthem into comps.xmlas needed.

The tag is a unique identifier for the group. Specify this name in ks.cfg preceded by an @ symbol to install all ofthe group's packages:


5/6

%packages...@ local_packages...

The body of the tag will appear on the Package Group Selection screen during a manual install, provided

is true.

The aptly named tag provides a brief description of the package group.

A global shop could take advantage of localization. Add extra and tags, each with the

xml:lang attribute, to set that language's code:

Trucs... Les Trucs...

holds the list of this group's packages in tags. The type attribute reflects a

package's status within the group: optional (addable), default (included by default), or mandatory(unremovable).

Don't rely on the filename for . If you're unsure, query the RPM itself for its internal name:

$ rpm -q --qf '%{NAME}\n' -p some_file.rpm

Package headers contain information about each RPM in the install tree, such as checksums and dependencies. Thequery process is rather I/O-intensive, so pre-generating the data speeds up the install process. To (re-)generate thepackage headers, run genhdlist(from the package anaconda-runtime):

$ /usr/lib/anaconda-runtime/genhdlist \--productpath Fedora \{path}

{path} is the fully-qualified path to the parent of the Fedora directory. For the curious, the header data goes inFedora/base/hdlistand hdlist2.

Using Kickstart to Upgrade

Vendors release new versions more frequently these days, which means OS upgrades are fast becoming a regularoccurrence. Why click through the upgrades by hand when Kickstart can do them for you?

Upgrades are similar to installs, though ks.cfg requires fewer directives:

upgrade (as opposed to install)

installation method (for example, url or nfs)

installation language (lang)

installed language support (langsupport)

device spec, if you need the device for the install (device)

installation process keyboard setup (keyboard)

boot loader configuration (bootloader)

(Refer to the previous article in this series or the Kickstart documentation for detailed explanations of thesedirectives.) The upgrade process ignores most other options, because it shouldn't change settings such as the timezone, the root password, or the network setup.
http://www.linuxdevcenter.com/pub/a/linux/2004/08/19/kickstart.htmlhttp://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickstart2.htmlhttp://www.linuxdevcenter.com/pub/a/linux/2004/08/19/kickstart.htmlhttp://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickstart2.html


6/6

I've provided a sample upgrade, ks.cfg. It is very generic, and accordingly, you could have a single such file for anentire site.

The upgrade operation otherwise functions similarly to the installation: boot from your preferred media, directAnaconda to ks.cfg, and walk away. Please note that boot media has very strong ties to the OS revision; you mustboot from the newer CDs to upgrade. However, the machine hosting the installation media needn't run the same OSversion, nor even the same OS.

My experience is that Kickstart's upgrade is nondestructive: while it doesn't delete any files or alter disk layouts, itinstalls new packages (including new kernels, though, so watch out if you rely on a custom kernel). That said, test theprocess before turning it loose on your environment.

Conclusion

There are several ways to customize the Kickstart process. Applying these techniques to your Kickstart infrastructureshould take you closer to a completely hands-off process for installing and retasking machines.

Resources

Downloadthe sample ks.cfg used for upgrades.

Hands-Off Fedora Installs with Kickstart provides a general introduction to Kickstart.

Chapter 7 of the Red Hat 9 Customization Guide gives Kickstart documentation.

The Fedora team has information on tweaking comps.xml available on its web site. Based on my experience,

adding the tags to comps.xmlis unnecessary. It would appear Anaconda pulls this information

from the generated headers list. (Perhaps the documentation is out of date?)

"Software Packaging with RPM" explains how to create custom RPMs.

Ethan McCallum grew from curious child to curious adult, turning his passion for technology into a career
http://www.linuxdevcenter.com/linux/2004/11/04/examples/sample-ks.cfghttp://www.linuxdevcenter.com/linux/2004/11/04/examples/sample-ks.cfghttp://www.linuxdevcenter.com/linux/2004/11/04/examples/sample-ks.cfghttp://www.linuxdevcenter.com/linux/2004/11/04/examples/sample-ks.cfghttp://www.linuxdevcenter.com/linux/2004/11/04/examples/sample-ks.cfghttp://www.linuxdevcenter.com/pub/a/linux/2004/08/19/kickstart.htmlhttp://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickstart2.htmlhttp://fedora.redhat.com/projects/anaconda-installer/comps.htmlhttp://fedora.redhat.com/projects/anaconda-installer/comps.htmlhttp://fedora.redhat.com/projects/anaconda-installer/comps.htmlhttp://www.linux-mag.com/2004-02/compile_01.htmlhttp://www.linuxdevcenter.com/pub/au/1910http://www.linuxdevcenter.com/linux/2004/11/04/examples/sample-ks.cfghttp://www.linuxdevcenter.com/pub/a/linux/2004/08/19/kickstart.htmlhttp://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickstart2.htmlhttp://fedora.redhat.com/projects/anaconda-installer/comps.htmlhttp://www.linux-mag.com/2004-02/compile_01.htmlhttp://www.linuxdevcenter.com/pub/au/1910

Documents

Advanced Linux Installations and Upgrades With Kickstart