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 may take about an hour, depending on network speed and the amount of stuff you initially install.
Be very sure you are installing to the correct removable disk! If you have any doubts ask a lab tech to make sure your removable disk is being used.
Many of the projects can be done on a home computer running the same software as in the classroom, but on a virtual machine (such as VirtualBox). Feel free to do work at home, but remember you will need to reproduce the results in the classroom (which is easy and fast if you have a good system journal). (If you have problems with the GUI using VirtualBox, be sure to turn off “3D acceleration”.)
To share your files from home to the classroom, use your personal wiki user page (which is public), or use a service such as Dropbox. Of course you can also use a Flash drive or simply email files to yourself.
Perform the following tasks, and answer the following questions:
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 user page on the class wiki site (keep in mind that page is public). (Unless you have two computers, you will need to keep hand-written notes on your install.)
(More information about the system journal can be found below. Also, I have made a screencast (movie) of a Fedora install available, that you might want to watch before attempting your own install. The link can be found in the course resources.
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 for the standard GUI desktop system. (Don't use a minimal install, as that doesn't install a GUI or most of the utilities you will need.) 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 with 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 Network Installer “netinst”) image can be found at https://getfedora.org/en/server/download - Fedora-Server-netinst-x86_64-25-1.3.iso.
Why do we use the Fedora Server Network installer? Because Red Hat (and its many look-alikes) are the most popular for servers, so it is Red Hat systems you should learn. Today's Fedora is tomorrow's Red Hat Enterprise Linux (RHEL), so you should be well-prepared when you enter the workforce. Additionally, the current Fedora release usually has some rough spots, providing excellent learning (trouble-shooting) opportunities.
Using the network installer is faster, since most of the original packages will have updates by the time you need to install. If you did a traditional install from a DVD, you'd need to download hundreds of packages anyway during your first update. (The Server network installer image is the only network installer image for Fedora. But despite the name, it can be used to install a Workstation or any other type of Fedora system.)
For installation help, see the resources provided on our class web page. (Especially the Fedora Installation Guide.)
You must use the approved partitioning scheme that
you designed in project #1,
or something very close to it.
You must use
ext4 for your
storage volumes (other projects later require this).
Note that if the installer adds partitions automatically (for example one
for BIOS boot), you must document those in your journal even though
your original partition plan from project #1 did not include those.
For this project, you must use
Logical Volume Management
You should partition your disk into two partitions only, one for
/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
(Note that having the root partition under LVM
will require a RAM disk boot setup (i.e., using
When configuring storage, you may notice a checkbox to encrypt the volume. Encrypting your volumes may be useful on a laptop, but will complicate future projects in our course. So, don't do it at this time on your classroom PC.
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
/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
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
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
initrd”) for you.
Be sure to enable all the features discussed in class, including at least the following:
/dev/sda”) and not the boot blocks of some partition (e.g., “
Depending on the distro and versions installed, and other factors, networking may not be enabled initially. If you did the default install, on the top-right of the Gnome system tray, there should be an icon for networking. You can click on that to enable networking (configure for DHCP, and to enable automatically at boot time).
/etc/selinux/configand follow the comments to change the default mode. Make sure you put a note on your SELinux configuration in your journal!
Before installing any additional software, you should always update the
software you already installed to the current versions.
This will often update the kernel, possibly requiring you
to reconfigure networking,
needing a reboot of the system.
Use the GUI tools to configure your system now.
You can use the command line tool “
to install and update software packages on any Red Hat like Linux
(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
dnf 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
be run at a time, or the package database could become
You will need to turn this applet off (or possibly wait for
it to finish checking) before you can run
With KDE, use the system menu to launch
Then click on “Settings”, and change
“Check for Updates” to “Never”.
With Gnome, you'll find this under
What is the exact command you used? About how many packages were updated?
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
repository (Although the tool changed its name to
the repos are still known as “yum repos”) to your system.
Then you will install some additional packages.
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
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!
yum repositories to include the
An easy way to do this is to use
rpm to include the
package, available at their website.
Exactly what command(s) did you use to add this
(You can also consider adding other repos, such as the
repository, which is for Red Hat Enterprise Linux, but those
packages should work on Fedora.
Google also maintains a yum repo for its software.)
dnf from the command line,
install the package that provides the
Exactly what command(s) did you use to
find the package name and to install it?
Using any GUI tool, install
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
(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
You can install whole groups of packages more easily than installing
all the individual packages in that group.
Both the GUI tools and
dnf allow you to
list and install groups.
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 description 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
In older versions of Fedora, a bug means the saved screen-shots won't be moved
/root/anaconda-screenshots/ at the end of the
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,
(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 type (and name), video card type, 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, especially since defaults sometimes change. If you don't change some setting, record the setting anyway in your journal.)
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
command to record every keystroke you type and all output.
(You can also use the
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
/etc), make a copy of the current version of
Then when done playing with the file and all is working again, you
can copy the output of
diff to your journal, to show
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.) Sometimes, what you were thinking when you did something is more important to the future reader than exactly what you did. Do not be afraid to write down your thoughts and questions.
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. Updated the Wiki to require new accounts must be approved, since we noticed a large number of "spam" accounts were being created and used.
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
If possible keep your system “up” long enough for this process
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.
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
menu (depends on the GUI used).
From the command line: enter “
Remember to remove all CDs and flash disks.
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).