CTS 2333 (Unix/Linux Networking) Project #1
Install Linux

 

Due: by the start of class on the date shown on the syllabus

Background:

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.)

Requirements:

Part I — Install On The First Host

  1. You must install Fedora Linux using the CDs provided on your first assigned classroom computer and hard drive.  In this class you have been assigned at least two computers.  The first computer is set up normally using the directions below (which are the same as for CTS-2311 (Unix/Linux Security) install, so you can use the same setup and install once only.)

    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.

  2. For the other hosts you have been assigned you must install using KickStart based on the first install.  (As noted above, you can't do a network install from a “Live CD”; you must use the regular install disks provided, or the Fedora Network Install disk image.) 
  3. First gather system information for your assigned computer(s).  It may have changed since last term!
  4. Next, plan your hard disk partitioning scheme.  You will need to have a /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.
  5. You should use a default network (DHCP client) setup, and use an initial firewall that blocks nearly everything, but should allow SSH and HTTP (at least).  If you fail to do this, the KickStart file won't be accessible from your second host and you will need to make a firewall hole later (or temporarily turn off the firewall, not generally a good idea).
  6. You must enable SE Linux during the install.  However you should initially configure it for permissive mode.
  7. After the basic install is complete, bring your system up to date with all available updates for your operating system.  This may require you to configure 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).

  8. Finally perform any other post-install steps you see fit.  (See a list of post install steps for some ideas.)  I would suggest setting up printing at least.  What changes did you make to the initial (default) setup?
  9. Install the Apache web server using its default configuration.  You will need this to serve your KickStart file to the other hosts that will use a network KickStart install.  Be sure your web documents are accessible on the local LAN (that is, check your firewall and other security related configuration).

Part II — Install Remaining Hosts With KickStart

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.

  1. Read the KickStart Guide on the Red Hat web site for 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 the list of packages to install, as shown in the following steps.

    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.

  2. While it is common to use a network (PXE) boot with KickStart this requires you to setup a DHCP server and, for your own custom repository, an NFS or HTTP server on the first host.  Instead you will boot using the Fedora Install CD-ROM and obtain packages from a standard Internet repository.

    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.)  Pick some geographically close repository from the list at mirrors.FedoraProject.org, by clicking on the Fedora 16 row, for i386 or x86_64 depending on the architecture of your computer.  Make sure it works (by visiting that URL).

  3. Edit your KickStart file to make any additional desired changes.  List your final KickStart file.
  4. Place a readable (in the Unix permissions sense) copy of your KickStart configuration file under the document root of your web server.  What is the URL of your KickStart file?  Verify you can read the file using a web browser, using the IP address of your first server in the URLHow did you determine your host's IP address?
  5. Without a PXE boot ability you will need to use bootable media on the target host.  You could create and use custom boot media such as floppies, CDs, or USB disks.  While this can be difficult, feel free to try; you can find directions at FedoraProject.org/wiki/FedoraLiveCD/LiveCDHowTo or FedoraProject.org/wiki/How_to_create_and_use_Live_USB.

    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?

Part III — Document your install in your system journal

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!

Hints:

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.)

Creating and Using Custom Boot Media:

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).

To be turned in:

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.