In the real world SAs often need to configure many hosts the same way. Rather than install each host manually most Unix or Linux systems allow an automated install. The SA installs once host manually (interactively), then saves the answers to the questions asked, in a file. This file can then be used to automate the install on other hosts.
Different vendors use different names for this process. Sun uses JumpStart (for Solaris) while Red Hat uses KickStart for RHEL and Fedora. In this project you will use KickStart. Although we went over this in the Admin I course I expect most students will have forgotten about this by now. Use the information location techniques you have learned to find information about KickStart on the Internet.
For such an install, the new system needs a boot image it can use to run the installer (Anaconda for Red Hat like systems). This can be supplied using a PXE boot (the BIOS initializes a NIC using DHCP, which also downloads and then runs the boot image and installer). For computers without PXE support (or a classroom lacking an appropriate DHCP server), you will need to use some sort of boot media in the target host.
When booting you need to supply an argument telling the installer the location of the KickStart file. This file could be on a USB drive, a CD, or accessible on the network. For this project you can make your KickStart file available from a web server (Apache) on the first computer. Then you can boot the target computer using a bootable CD. You can't use a Red Hat / Fedora Live CD for this, since those use a modified installer (not Grub!) that has no network support. However Fedora network installer bootable CDs are available and will be provided. (Unlike the Live CDs, these do not contain any software to install.)
Part of a automatic install is to create a software repository (or “depot”) with the correct set of current packages, patches, and post-install scripts. You could put the KickStart file and the set of packages to install on a modified bootable CD or DVD. But it is easier to use a repository accessible on the network. (You can easily keep the repository up to date and won't have to burn any media. This is especially handy when using PXE to install.) You should create a different repository for each class (type) of host, and a different configuration (KickStart) file for each as well.
The KickStart file must list the URL (or pathname, if the packages are included on the boot media) of the repository to use, as well as a list of packages and/or package groups to install.
For our class we only need to do a minimal install from the official
Fedora repositories, then manually perform any post-install tasks
such as running yum update.
(Setting up such a repository and performing a network KickStart
install from a local host requires extra setup that you will learn
later in this course.
If you want, you can re-install your second (and other) host(s)
at the end of the term using a network install.)
Note! Installing from a “Live” CD or DVD will not create the same system (and hence, the same KickStart file) as installing from a normal “install” CD/DVD. Experience has shown the first system should be created using a normal “install” CD or DVD rather than a “live” one, or you may need additional changes to the resulting KickStart file. You are permitted to install the first system using a live disk, if you want to try.
/boot partition and a
/home partition at least.
Make sure the root partition
is large enough to hold all binaries and configuration files
that you will put in it, plus room for more later.
10-15GB is reasonable.
(Less if you create many partitions.)
Later in this course you will create large disk image files,
make sure you have space for them.
yum first.
Note that although this process can take a long time, you can
interrupt it and later resume the update.
I would suggest adding an extra Yum repository to include some extras that Red Hat doesn't include by default, due to licensing issues. Consider adding rpmfusion.org, and possibly LinuxDownload.adobe.com (for the Flash player and browser plug-in).
Create the KickStart file by following the steps below.
Fedora creates a sample KickStart file based on the options that
you selected during installation, and saves it in the file
/root/anaconda-ks.cfg.
You can use this KickStart file from your first host's install
as a starting point.
Fedora includes a GUI KickStart file
configuration tool (system-config-kickstart)
you can use.
However that tool only creates an incomplete KickStart file!
An incomplete file will work but the install won't be automated.
Anaconda will prompt you for the missing information.
If that happens to you, note the questions asked and update the
KickStart file.
Then retry the install.
Repeat until Anaconda doesn't ask any questions.
Over the years Red Hat has made incompatible changes to the KickStart file syntax. Be sure you find the documentation for the current version! A sample anaconda-ks.cfg file is provided as a guide, but don't use it as it is for an older version of Fedora.
In your KickStart file you must specify a URL
where to download packages from.
(In the KickStart guide, look in the “install”
section for this.)
One close repository you can use is
http://ftp.usf.edu/pub/fedora/linux/releases/16/Fedora/i386/os.
(Use the correct URL for the version you plan on installing;
here Fedora 16 is used, but USF supports most versions.)
Other repositories can be found on the
Fedora Project site.
For this project you can't use a Fedora Live
CD.
This is because (any type of) Fedora Live CDs
don't actually contain grub!
They use a replacement boot loader called “liveinst”
which doesn't support network booting as does grub.
As mentioned above, you can make a custom Live CD by
modifying the image and burning that to a new CD.
However it will probably be easier just to use a different
“network install” version on some media (such as a CD).
Go to fedoraproject.org/en/get-fedora-all and download and burn the “Network Install CD”. (You could also use the install DVD or CD.)
When the system starts to boot from the install media,
you may need to type something to get to the
“boot:” prompt.
With Anaconda (the installer used with Fedora),
hit the “escape” key when the
initial screen appears.
When you get to the “boot:” prompt,
you boot the CD with an argument that specifies
where URL of your KickStart configuration file.
What command will you type at the
“boot:” prompt to use a network install from
your first host?
What changes did you need to make to your first host
to allow other hosts to use it for KickStart?
Make a copy of your system journal pages that document in detail the Linux install done in class, including any post install steps done. The system journal is a vital document that is used frequently for documentation of changes and of work performed, for accountability, and for trouble-shooting.
For this class you can use a wiki to host your system journal. Create (if you haven't done so previously) an account on the class wiki: YborStudent.hccfl.edu/UnixWiki. Then edit and create pages as necessary. (Use the help link for page creation and editing help.) What is your account name on the wiki?
Start your journal with the system name, location, purpose, and date. The initial system install documentation should include a hardware inventory for each system component (make, model, and configuration for each) such as the NIC, the video card, the RAM, CPU, Hard Disk(s), removable media, etc. Then each configuration choice made during the install should be documented in enough detail so that someone else could duplicate your setup if necessary, even if using a slightly different distribution. (Thus, saying "selected all defaults" is not good enough!) Don't forget to include any post-install steps taken!
If things aren't working, try using a step-by-step approach to trouble-shooting the issue. Ask these questions: Is my first computer working correctly? Is Apache web service working? (Test by trying to view your KickStart file in a web browser, pointed at localhost.) Can the KickStart file be viewed in a web browser, from a different host? (If not, suspect a firewall issue, or maybe you don't have SE Linux set to permissive mode.) Are you using the correct boot disk on the second host? (Remember that live distro disks won't work.)
For this class you can use the class wiki to host your system journal. You can edit and create pages as necessary, under your “user” page. (Use the help link for page creation and editing help.)
Write down every step either before you try it, or as you do it.
You will never remember exactly what you did, later!
If you stick to command line tools, you can use the script
command to record every keystroke you type and all output.
(You can also use the history (or fc) command
to view the commands you entered, and copy them into your journal. )
However this command isn't available for the install step, so
you should either use paper and pencil, or use a second computer and
work on your wiki page for your journal.
You should record everything, even the steps you un-do later!
You can always clean up the journal before creating management reports,
or before you turn it in to your instructor for grading.
Keeping an accurate and complete journal is a common requirement for
all engineers, not just system administrators.
Before making any changes to configuration files (such as those
under /etc), make a copy of the current version of
the file.
Then when done playing with the file and all is working again, you
can copy the output of diff to your journal, to show
what changed.
A beginner administrator tends to document each command issued, for example:
2/30/01 WP useradd -m FooBarr
Which says what command was done, when it was done, and by whom
(WP are the initials of the administrator).
This is actually not a bad journal entry.
But with experience your journal entries change.
Instead of showing how something was done
(i.e., what command),
the journal shows what was done and why:
2/30/01 WP Added user account for new employee "Foo Barr",
a programmer on the "DSL" project.
(Having both types showing the exact command used and why would be the most useful of all, but in reality no one keeps that detailed a journal.) A sample system journal can be found from our class web page, in the resources section. Please note that a single journal entry can list several related commands. This is easier to read than adding a date (and initials) to every line in the journal:
2/30/01 WP Added user account "fbarr" for new employee "Foo Barr",
a programmer on the "DSL" project.
Updated /etc/group entry for DSL to include fbarr.
Additional Linux installation help can be found at the CTS-2301 Linux Install Project webpage and at the Disk Partitioning Guide webpage.
Details on creating and editing KickStart files can be found at: FedoraProject.org/wiki/Anaconda/Kickstart. (Note there is a GUI tool you can use.)
You could make your own boot media (floppy or flash disk)
to use with KickStart.
The easiest way to make a boot floppy is by installing the Red Hat
mkbootdisk utility via yum.
A better approach is to copy an appropriate image file
to a blank floppy or USB flash drive.
A set of boot images can be found on the Install CD
in the directory /images.
Mount that CD and guess which image file to use.
Then use the command
“dd if=bootdisk.img of=/dev/fd0 bs=1440k”.
(You need a slightly different command to make a bootable
USB flash disk; you need to look that up yourself.)
The KickStart file must be named “ks.cfg”
and must be located in the boot disk's top-level directory.
Since Linux boot disks (and USB flash disks)
are in MS-DOS format you can copy the KickStart file
under Linux using the mcopy command (part of the
mtools package).
If using a bootable CD instead, first create the
directory structure used for a bootable CD, then
copy the ks.cfg KickStart file to the
isolinux directory.
Then create the file.iso image file.
Finally burn that image file to a CD.
Now boot the system you wish to setup, using the modified boot
media.
Enter the command “linux ks=floppy”
at the boot: prompt.
If using a USB flash disk, use the command
“ks=hd:device:/ks.cfg” instead, where
device is the name of your USB drive
(e.g. sdb).
With a bootable CD, use the command
“linux ks=cdrom:/ks.cfg” instead.
If you were to use a network KickStart install you would still need a boot floppy/CD/flash disk. However it wouldn't need to be modified from a standard boot image (no KickStart file need be added).
A copy of your journal pages. You can send as email to (preferred). If email is a problem for some reason, you may turn in a hard-copy. In this case the pages should be readable, dated, and stapled together. Your name should appear on the first page. See the System Journal Hints section above for more details.
Don't turn in your whole journal, you will need to add to it every day in class! It is common in fact to keep the journal as a text file on the system (with a paper backup of course).
Please see your syllabus for more information about submitting projects.