Kickstart Fedora workstations and servers

Reduce the time and effort spent on server reconstruction with a Fedora kickstart. This bootable media will help you rebuild your system when your servers are damaged, destroyed or down for the count.

System and network administrators frequently encounter situations in which individual systems or servers get damaged, destroyed or otherwise bollixed enough that they need to be wiped clean and rebuilt. Nobody likes to do this kind of job, but a well-crafted unattended installation can make reconstruction much faster, more painless, and less labor intensive.

In this article, we walk you through the process of constructing a special set of bootable media called a kickstart, designed to help you rebuild systems when and as needed with minimal time and effort. Of course, it does require some planning, preparation and work to build a kickstart, but we'll cover that here.

With Fedora Core, the unattended installation process is a simple matter of creating a kickstart file complete with all required install-time settings. Obtaining the Fedora Kickstart Configurator is a simple command line affair:

  # yum -y install system-config-kickstart

The Kickstart Configurator can be invoked on the command line like this:

  # /usr/sbin/system-config-kickstart

Several configuration dialogs loaded with install-time settings are neatly categorized into a single interface. The following information summarizes those properties.

Basic configuration
Specify everything from default language support and time zone to root password and target architecture. This dialog contains fundamental settings for the installation process including checkbox options for post-installation reboot and text or interactive-mode setup.
Installation method
Two categories summarize this dialog: installation type and method. The default type of install (new or upgrade) can be specified along with installation source (CD-ROM, hard drive, or network drive).
Boot loader options
Three boot loader options are present, but only two are enabled by default. The first two options control whether or not a boot loader is installed, while the third (grayed-out by default) is for upgrading an existing boot loader. You can (and probably should) hard-code GRUB boot loader settings into your kickstart file. These settings might include the password and password encryption option and the boot loader's location (Master Boot Record or first sector in the boot partition).
Partition information
For organizations that use a predetermined disk layout for any given workstation or server, the Kickstart Configurator offers plenty of set-and-forget options for pre-installation drive partitioning. Choose whether the installer should clear the master boot record, erase any existing partitions or initialize any disk labels.
Network configuration
The Kickstart Configurator trivializes network interface configuration through a no-nonsense two-step dialog. The first three options add, edit and delete existing network profiles. A second dialog is available through the Add Network Device button, and it reveals three additional properties: Network Device (eth0), Network Type (DHCP, Static IP, BOOTP), and network interface addresses (IP, netmask, gateway, DNS).
Authentication
Where larger network authentication schemes are in force, such as LDAP, Kerberos 5 or SMB, the Authentication dialog provides pre-installation settings. Beyond the aforementioned services, you'll also find two checkboxes for shadow passwords and MD5 hashes.
Firewall configuration
Specify the firewall security level (enabled/disabled) and SELinux disposition (Active, Warn, or Disabled) along with trusted devices in the Firewall Configuration dialog. By default, the Trusted Devices listbox is empty, and there is no option to manually specify one.

The same five trusted services that appear during the normal installation routine (WWW, FTP, SSH, Telnet and SMTP) are available along with an input box to declare and define port-based access for other services.
Display configuration
For single-user installations and networked environments operating on identical hardware, these settings won't change much. Default values represent a best-effort attempt to make graphical installation as easy as possible, but the default values don't always produce ideal results.

Fixed display properties may be specified in this dialog by first enabling the Configure the X Window System checkbox item, then proceeding through each of the top-level tabbed categories (General, Video Card, Monitor).

More on servers:

Updating SuSE Linux clients from a local update server

Xen in action: Deploying multiple servers

General options include color depth, resolution, default desktop (GNOME, KDE) and boot-time X Windows options. Video Card settings offer two options: automatically probe a video card or manually select from a drop-down list of entries. Monitor settings offer the same functionality: a checkbox and drop-down list of selectable items (by type and resolution).
Package Selection
Perhaps the most time spent during attended installation is in the package selection process. For many environments, default settings leave much to be desired, and equates to more hands-on configuration time for system integrators. Although no options for detailed package selection appear, there are several checkbox items for the most common top-level categories. This dialog should be at least marginally helpful in reducing wasted setup time for most installations.
Pre-installation script
System integrators and enterprise administrators will find this dialog useful for any pre-installation customization tasks that must be performed.
Post-installation script
This dialog is similar to the above, but this one is for post-installation tasks. There is also an option for running the post-installation script outside of the installation chroot environment.

Once all settings are properly configured, click on File, select Preview to examine the kickstart script created by the configurator, then save the file (default name: ks.cfg) and quit. This kickstart file may then be used to kick off a completely custom unattended install process using only one simple boot-time directive. For example, linux ks=<KICKSTART_PATH>/ks.cfg will begin the Fedora installation process according to the kickstart configuration file contained at <KICKSTART_PATH> (which must be replaced with an actual disk or network location to work). That's all there is to it!

Ed Tittel is a full-time freelance writer and trainer based in Austin, Tex., who specializes in markup languages, information security and IT certifications. Justin Korelc is a longtime Linux hacker who works with Ed and concentrates on hardware and software security topics. Both contributed to a recent book on Home Theater PCs; right now, both are busy at work on a book about the Linux-based MythTV environment.


This was first published in May 2006

Dig deeper on Open source Web and application servers

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close