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.
In a datacenter, cloud, or cluster (enterprise) setup with many hosts, a minimal install is done, often with a pre-created disk image file. Later, configuration management tools are used to install and configure any additional software and services.
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 DVD, 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 DVD. You can't use a Red Hat / Fedora Live DVD for this, since those use a modified installer (not Grub!) that has no network support. However, Fedora network installer bootable DVDs are available and will be provided. (Unlike the Live DVDs, these do not contain any software to install.)
Part of a automatic install is to use 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 your 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 could create a different repository for each class (type) of host, and a different configuration (KickStart) file for each as well. In our case, we will just use a standard Fedora repo mirror site on the Internet. (That means we need to access the Internet from an unsecured server, but in our case that is an acceptable risk.)
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 you need to do a minimal-ish (a workstation with GUI
install) from the official
Fedora repositories, then manually perform any post-install tasks
such as running dnf 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.)
For the projects in this course, we will refer to the first host as “Server A”, and the second host as “Server B”.
Note! Installing from a “Live” CD or DVD will not create the same system (and hence, not the same KickStart file) as installing from a normal “install” CD/DVD. Experience has shown Server A should be created using a normal “install” DVD rather than a “live” one, or you may need additional changes to the resulting KickStart file. So don't try that.
/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.
15 GiB is a reasonable minimum.
Later in this course you may need to create large disk image files,
make sure you have space for them.
systemctl stop firewalld”.
(Note this assume you have the default Fedora firewall running; if you're
running iptables or some other firewall instead, just
turn that off instead.
(Also check that TCP Wrappers is allowing your web server
through.
Remember that is controlled from the files /etc/host.allow and
/etc/host.deny.)
yum/dnf first.
Note that although this process can take a long time, you can
interrupt it and later resume the update.
(Note: if you did a network install, there was a checkbox to use
the latest package versions, not the ones from the install repo.
If you did that, your system should already be up to date!)
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 (both free and non-free repos).
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.
Note, however, it is incomplete.
You will also find the file
/root/initial-setup-ks.cfg.
Some parts of Anaconda are optional, and the parts you skipped won't
appear in anaconda-ks.cfg.
On first boot, a program “initial-setup”
is run.
This program checks the anaconda-ks.cfg for parts
you didn't configure, asks the right questions, and saves the complete
KickStart file as initial-setup-ks.cfg.
(If you did all your configuration via Anaconda during the install, the
two files should have the same content; the order of entries may be
different, however, and I've noticed some entries may be quoted in one but
not the other.)
Those links are supposedly to the latest KickStart documentation. However, the technical details are not in the Fedora guide at that link. Use the Fedora KickStart syntax Reference (or your Fedora version) appendix for the technical details.
You will have to edit the generated KickStart file (but make a copy first; see the Hints section below), by adding a URL to your repository (and other missing elements), and the list of packages to install, as shown in the following steps.
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; it is for
a particular version of Fedora and may not work with your version of
Anaconda.
In addition, the disk partitioning is wrong, the user account created is
“wpollock”, and you won't know the password or
the root password!
In your KickStart file, you must specify a URL from where to download packages. if not already in there. And it won't be in there usually, since the default is to use a network install and the closest mirror on your Server A. In that case, there is no installation source and no repos listed in the generated KickStart file.
Since Fedora 19, the Network Installer DVD generates a
KickStart file lacking both the URL and the list of
repos to use!
(See Bug 972265.)
The easiest fix is to configure the KickStart file to use “the closest
mirror”.
Add the following lines to your
anaconda-ks.cfg file,
between the “System language” section and the “Network
information” sections:
# Installation Source repo --name=fedora --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch repo --name=updates --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch #repo --name=updates-testing --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f$releasever&arch=$basearch install url --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch
If you don't want to use the closest mirror, you can specify a
specific mirror site to use.
In the KickStart guide, look in the “install”
section for a list of mirror sites; pick one.
Pick some geographically close repository (USF if listed),
from the list at mirrors.FedoraProject.org:
click on the correct architecture link in the row for your Fedora
version (i386 or x86_64).
Make sure the mirror you select works (by visiting the HTTP
link for that mirror).
httpd to start at boot (that is, the service is enabled),
and so on.
You should take a few minutes to see what else can be put into the
Fedora KickStart file.
List your final KickStart file. 127.0.0.1”!)
How did you determine your host's
IP address?
For this project, you can't use a Fedora Live DVD.
This is because (any type of) Fedora Live DVDs
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 DVD by
modifying the image and burning that to a new DVD.
However it will probably be easier just to use a different
“network install” version on some media (such as a DVD).
Go to fedoraproject.org/en/get-fedora-all and download and burn the “Network Install DVD” ISO file. (You could also use the install DVD.)
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 DVD with an argument that specifies
the URL of your KickStart configuration file:
boot: linux inst.ks=http://your-IP-address/name-of-kickstart-file
What changes did you need to make to your first host to allow other hosts to use it for KickStart? (For example, did you need to make any firewall holes?)
Make a copy of your system journal pages that document in detail the Linux install done in class, including any post install steps done. Note that including a copy of a KickStart file used for the install in the journal is a good idea! 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 your real IP address.) 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.) Keep in mind that your wiki pages are publicly readable.
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 to
work on 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-2301C 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 dnf.
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 DVD
in the directory /images.
Mount that DVD 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 DVD instead, first create the
directory structure used for a bootable DVD, 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 DVD.
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 DVD, use the command
“linux ks=cdrom:/ks.cfg” instead.
If you were to use a network KickStart install you would still need a boot DVD/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, and a copy of your final KickStart file. 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.