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

In this project you will install a new operating system (1) on a spare computer, (2) as a dual-boot on your home computer, or (3) on a virtual machine (preferred).  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.

If you have Windows 10 Pro, I recommend using Hyper-V for your virtual machine.  If you have Windows 10 Home or Windows 7, I recommend using VirtualBox.  There are many YouTube videos on how to set up both of these (or setup virtual machines on Macintosh or Linux).  Find a recent one and give it a try!  If you get stuck, your instructor will be happy to help with one-on-one Zoom meetings to walk you through the process.

Perform the following tasks, and answer the following questions:

The first step is to have your approved partition plan handy.  That will show how much memory and disk space you need to allocate to your new virtual machine.  Next, you will need the Fedora 33 network install image (ISO file) downloaded, so your virtual machine can boot from it as if it were an optical disk.  You should download this file (“Network Installer”)from https://alt.fedoraproject.org/.  Once downloaded, you can verify the file is not corrupted if you have gpg installed.  If you do, click the Verify button and follow the directions; the CHECKSUM file you need is “Fedora 33 x86_64 CHECKSUM”.

Before creating a virtual machine, make sure your system is configured for that.  First, check the BIOS and make sure virtualization features are enabled.  If using VirtualBox, that should be all you need.  For Hyper-V, you need to enable that in Windows 10 settings and features as well.  (Note Hyper-V is not available for Windows 10 Home edition.)

Once the virtual machine is configured, you should start it and begin the Fedora 33 install.  You can find the install guide and other official documentation at https://docs.fedoraproject.org/en-US/docs/.

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 smart phone 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.

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

You should only install the minimum set of packages needed for a 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.  If you installed many packages, you will end up installing them a second time to update them!

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.  Despite the name, it can be used to install a Workstation or any other type of Fedora system.)

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, /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 “dnf” 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.)  (As we did a network install, the software should already be up to date.)

Most desktop environments such as KDE and Gnome include an applet (or widget or other such term) that uses 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 dnf 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 dnf 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 setting under Preferences→Software Updates.

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 yum repository (Although the tool changed its name to dnf, the repos are still known as “yum repos”) 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 then 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 is 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 other repos, such as the repoforge repository, which is for Red Hat Enterprise Linux, but those packages should work on Fedora.  Google also maintains a yum repo for its software.)

Using dnf from the command line, install the package that provides the nmap utility.  Exactly what command(s) did you use to find the package name and to install it?

Using any 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 dnf allow you to list and install groups (something you will learn later).

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

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

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

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 flash disks.

(If you have problems with the GUI using VirtualBox, be sure to turn off “3D acceleration”.)

A copy of your journal with your name clearly printed at the top should be submitted to the correct Canvas dropbox for this assignment.  The name(s) of other classmates you worked with must be included.

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.