CTS 2301 (Unix/Linux Administration I) Project #2
Install

 

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

In this project you will install a new operating system on your classroom computer.  You have a few requirements you must meet, in order to allow future projects to work without rebuilding the system.  Remember you are here to learn, so feel free to install several times — it takes about an hour.

Be very sure you are installing to the correct disk!  If you have any doubts ask a lab tech to make sure your removable disk is being used.

Perform the following tasks, and answer the following questions:

Part I — Initial Install

For the install (as well as other projects) you will need to keep a detailed system journal showing exactly what you did.  Once the system is installed you can maintain the journal as a text file.  But unless you have a laptop or PDA handy you will need to write down on paper each step of the install, as you do them!  You will never remember all the steps you did if you don't write them down as you go.  (One option for our class is to maintain your journal on your private page on the class wiki site.  (More information about the system journal can be found below.)

Install Linux from the CD or DVD provided to you, on your assigned computer and hard drive.  You should only install the minimum set of packages needed.  The reason is that the distribution media is almost certainly out of date so you must update most of the software anyway from some Internet archive (or repository).  If you installed all packages, you will end up installing them a second time!

If you don't want to wait until we can provide you an install DVD, you can download an ISO and burn it yourself to a DVD.  (Or if installing on a virtual machine at home, just use the ISO file directly.)  The Fedora 16 install image can be found at download.fedoraproject.org/pub/fedora/linux/releases/16/Fedora/i386/iso/.

You must use the approved partitioning scheme that you designed in project #1, or something very close to it.  You should use ext4 for the partition types (other projects later require this).

For this project you must use Logical Volume Management (or LVM).  You should partition your disk into two partitions only, one for the /boot partition (which might cause problems if placed under LVM), and the rest into one large LVM physical volume.  You will then implement the rest of your partitioning scheme using logical volumes.  (Note that having the root partition under LVM will require a RAM disk boot setup (i.e., using initrd).

Fedora Linux has support for LVM built into its installer, making this step very easy.  (Previously you needed to use command line tools after the install to set up LVM.)  When you get to the Disk Druid partitioning tool part of the Fedora installer (named anaconda), you can either manually implement your partitioning scheme, or let the system do it for you.  For a manual or custom layout, after setting up /boot click on the LVM button to complete the setup.  This is much easier than trying it later using the command line tools, but feel free to explore those.  (If you mess up the disk, it is better to have to re-install now than later!)  I recommend you let the installed automatically create a disk layout, using the entire drive.  Then make sure to select the checkbox review and modify the layout.  This will create a sensible layout that uses LVM, that will only need a few changes for your partition plan.  Note that the Fedora installer handles the boot setup (including initrd) for you.

Be sure to enable all the features discussed in class, including at least the following:

Part II — Updating The System

Before installing any additional software, you should update the software you did install to the current versions.  This will often update the kernel, possibly requiring you to reconfigure networking, /etc/grub.conf, and needing a reboot of the system.  Use the GUI tools to configure your system now.  You can use the command line tool yum to install and update software packages on any Red Hat like Linux distribution.  (Read the man page to see how to use it; we will learn how later in the course.)

Most desktop environments such as KDE and Gnome include an applet (or widget or other such term) that uses yum to check for updates and display a notification on the GUI.  This is usually set to run by default all the time.  The problem is only one instance of yum can be run at a time, or the package database could become corrupted.  You will need to turn this applet off (or possibly wait for it to finish checking) before you can run yum manually.  With KDE use the system menu to launch Applications→System→System Settings).  Then click on Settings, and change Check for Updates to Never.  With Gnome you'll find this under Preferences→Software Updates.

What is the exact command you used?  About how many packages were updated?

Part III — Installing Additional Software

For many of the remaining projects in this course, you will need software that was not part of the minimal install you did.  For this part of the project you will add an additional yum repository to your system.  Then you will install some additional packages.

Note!  If you attempt some command and the software doesn't appear to be installed, you must first check your PATH and command line for errors.  If the software is truly not installed you will need to install it.  The remaining projects won't specify that you may need to install the software referenced.  You will just need to realize you need to install anything required but not yet installed!

Update the yum repositories to include the rpmfusion.org repository.  An easy way to do this is to use rpm to include the rpmfusion-free-release-stable.noarch.rpm package, available at their website.  Exactly what command(s) did you use to add this repository?  (You can also consider adding the RPMforge repository, which is a part of RPMrepo.org project.)

Using yum from the command line, install the package that provides the nmap utility.  Exactly what command(s) did you use?

Using a GUI tool, install the telnet server package.  If using Gnome use the Add and Remove Software tool; if using KDE use the Software Management tool (in the menus, look under Applications→System).  (Note there is also a telnet client package which is most likely already installed!)

Install any other software at this time you think you might need.  Remember you can always install it later too!  Note that individual packages of software are bundled into groups.  You can install whole groups of packages more easily than installing all the individual packages in that group.  Both the GUI tools and yum allow you to list and install groups.

System Journal

Make a copy of your system journal pages that document the Linux install done in class.  The system journal is a vital document that is used frequently for documentation of changes and work performed, and for trouble-shooting.  You will start a system journal for your system with this project.

The journal should be readable, dated, and loose pages stapled together.  Your name should appear on the first page.  Except for the initial install, you can maintain your system's journal as a text file on the server.  As you work on your server, you can have the journal open in an editor window, and record (even copy and paste) what steps you take.  Another option is to use the class wiki to host your journal.  (Other on-line options could be used too.)

Documenting the install is harder.  Don't forget to start with a system descripting including name, purpose of system, hardware present, and your partition map.  During the install you need to keep track of your steps, as you won't remember them all later.  Either write down each choice as you go, or you can use a feature of the Fedora Anaconda installer: hitting SHIFT+Print_Screen will make screen-shots and should save them in /root/anaconda-screenshots/.  In Fedora 16, a bug means the saved screen-shots won't be moved into /root/anaconda-screenshots/ at the end of the install.  You need to copy the saved screen-shots before rebooting, onto the new disk image.  After you've taken the last screen-shot and before rebooting, switch to a non-GUI console with “ALT+F2”, and then run the commands:

mkdir /mnt/sysimage/root/anaconda-screeenshots
cp /tmp/anaconda-screenshots/* /mnt/sysimage/tmp/anaconda-screenshots/* \
   /mnt/sysimage/root/anaconda-screenshots/

In addition to saving screen-shots, all your installer choices are saved in a file, /root/anaconda-ks.cfg.  (This is a “KickStart” file; while it is text, it may not be easy to read.)

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, video card, 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 completely duplicate your setup if necessary, using only your journal.  (Vague entries such as selected defaults should be avoided.)

System Journal Hints:

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 fbarr 

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 "fbarr" 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. 

After your install and first boot, the system will likely spin the disk heavily for a while.  This activity is normal.  Right after you boot, the system initializes several databases via crontab.  If possible keep your system up long enough for this process to complete.

It is usually best to keep an on-line text file as the system journal.  This is easy to add to, and you can copy and paste commands and error messages to the journal easily.  However, it is very important to keep an up-to-date copy of the journal off-line!  A hard copy is also most useful, for when the system fails to boot at all.  During a system install it is difficult or impossible to keep an on-line journal, but once the system is initially booted it is a good idea to copy your hand-written journal into an on-line one.

How to Shutdown the System:

After successfully installing and booting Linux, you will (eventually) need to shut it down.  From the GUI: when you logout you will see a Shutdown choice or a System menu (depends on the GUI used).  From the command line: enter poweroff or reboot.  Remember to remove all CDs and floppies.

To be turned in:

A copy of your journal pages with your name clearly printed at the top.  For this project you may submit email or a printout (or neatly hand written) copy of your journal.  If you submit a hardcopy, make sure your name is printed on the top of each page.  (Remember that multi-page documents should be stapled.)

Don't turn in your only copy of your 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).

You can type or send as email to .  Please use the subject similar to Unix/Linux Admin I, Project 2 (Install) Submission, so I can tell which emails are submitted projects.

Send questions about the assignment to .  Please use a subject similar to Unix/Linux Admin I, Project 2 (Install) Questions so I can tell which emails are questions about the assignment (and not submissions).

Please see your syllabus for more information about project grading and also about submitting projects.