Designing a Course in Linux System Administration

I have been a Linux advocate for about ten years now. The first
version of Linux I installed was Red Hat 3.0.3. I had used a UNIX-based
system in graduate school, and I was somewhat familiar with
how to get around (read: how to screw things up). I work at a school
that is inundated with Microsoft products. After being there a year or
so, I decided to branch out on my own and install Linux on my desktop
machine. I have never looked back, and I have been using Linux as my desktop
of choice ever since, at home and the office. I occasionally have booted
into Windows if I wanted to play a game or read an occasional PowerPoint
presentation, but that has been about it. Yes, I know about WINE and
CrossOver, but a few games and programs inherently run better when
run in a Windows environment. However, more often than not,
there are options under Linux that are equally as good as, if not better, than
those available under Windows. This is part of the main message I have
been touting to our students, faculty and staff for the past few years.

As a result, I have come to be known on campus as a Linux
advocate. If people have questions about Linux, they usually find their
way to my office as often as they find themselves in the IT office. I
also have been bugging our Director of Academic Computing
about when the entire campus is going to switch over to Linux. We do have some Linux
boxes buried deep in the recesses running our mail server, Blackboard
and a few other applications, but we have nothing in the way of a visible Linux
presence on campus. The Computer Science department recently converted the Computer
Science lab from SGI boxes to Linux boxes, but that is about the extent
of Linux on our campus. Is it possible that Linux will be used more
widely on campus in the future? I am not sure. It probably will be a
long, uphill battle, but one that luckily can be won. If you check out the
May 2005 issue of
LJ, you can see how a few people got the job
done at the Mountainland Applied Technology College.

As you probably can tell, it has been my mission to make Linux more widely
accepted on our campus. A colleague from the computer science
department, Dr. Kenny Moorman, and I ran a Linux class in our May term a few years
ago. May term is a short four-week semester that runs, coincidentally
enough, during the month of May. I am running the class again
this May. My goal is to try to teach the course in such a way that our students can
integrate their PCs into our existing framework. I have to
show them how to set up their desktop systems so they can surf, check e-mail,
burn CDs, but I also need to teach them some basics on administration.
Although I will be teaching them how to turn services on and off, I don't think
it would be wise for them to use their boxes as DHCP servers, mail
servers or anything of that ilk. I think it would be a nightmare for the campus
administrator if students started to hand out IP addresses. At this
point, the big question then becomes how I should set up the class?

While Dr. Moorman and I were trying to plan out the class the last time
it was taught, we realized that few resources were available in terms of how
to make a class like this one successful. A few years later, I still have not found many resources
to help develop this class. So, I decided that now might be the time to write
down what I think might make the class a success. To start, I have identified
four main ideas that I want to address when constructing this course.

1. Why is Linux important? What is the open-source philosophy? What is
   the history of Linux?
2. Are there any good Linux text books out
   there?
3. What information should be contained in the
   course?
4. What types of assessment should be
   used.

Let's address these issues one at a time.
Why is Linux Important?
Why is Linux important? I can sum it up for you in one word: freedom.
If you have been following the Open Source movement, you know I am not
talking about the price of the software when I say freedom. That simply
happens to be a nice perk. No, the freedom I speak of is being able to
use your computer and software in the manner that you wish. It is about
not being tied down to any certain vendors who roll out "upgrades"
that are incompatible with your current projects. I am talking freedom
from viruses; freedom from monopolistic companies that use unfair business
tactics to squash their competition; freedom that leads to imagination and
innovation. This is the type of freedom to which open source can lead, and
it is the type of freedom that should be important on college campuses.

It seems a natural fit that a class on open source should be available
on a college campus. If there is to be a change in the open-source
vs. closed-source discussion, then we need to teach the up-and-coming
engineers and computer scientists about a world in which there are options. We
need to teach them where Linux came from, why it has grown and where it
is going. This class needs to talk about the differences and philosophies
of the Cathedral and the Bazaar. By giving students the arguments for
and against both sides of the story, they can make informed decisions
and form educated opinions, instead of simply sticking with the status quo. If
you can win their hearts, it is much easier to win their minds.
Books? We Don't Need No Stinking Books!!
This has been a tough one. A plethora of books about
Linux are available, but I have not found one that I felt would be a great one to
use all by itself in a classroom setting. Naturally, the first book I
thought about using was Running Linux (Welsh, et.
al., O'Reilly), because it
tells you how to do just about everything in Linux. However,
it doesn't contain too much in terms of open-source and Linux history and philosophy. The
last time I ran this course, we used Running Linux in conjunction with
The Cathedral and the Bazaar (Raymond, O'Reilly). Again, this a great book on its
own, but for students only beginning to get involved in Linux and open source,
it can be a little over their heads. These book also is available online
(see Resources), so you can pick and choose which parts might be applicable at the time,
instead of ordering the entire book.

Last summer I ran a Linux camp for high school students. We used the
book Linux for Non-Geeks (Grant, No Starch Press). This book is nice if you are
going to work with Linux on your desktop--which was fine for the
camp--but it does not contain much about system administration. Transylvania is a liberal arts school, so we tend to ask
the question "Why?" a bunch. I want to be able to show the students
what is going on from the boot process to shutdown and most everything in
between. When a student boots Linux for the first time, a lot of
information scrolls across the screen. I want to make sure that students
know what it all means or at least most of it. Knowing why and how
things are working makes it easier to troubleshoot when they aren't.

These boundaries led me to a couple of books. The first was How Linux
Works (Ward, No Starch Press), and the second was Learning Red Hat Enterprise
Linux and Fedora (McCarty, O'Reilly). Both books went into
some detail on the boot process, from the boot loader, to init,
to the login prompt. These were ideas I wanted my students to
understand. Most books skip or haze over these concepts, but these two
books take some time and depth to explain what was happening. I wound
up going with How Linux Works.

This choice obviously varies according to the audience. Being a liberal artsy
kind of guy, I wanted a book that is fairly non-technical yet has
a lot of essential information. I feel that How Linux
Works does that, but I am not knocking any of the other books at all. I have all of
them, and I think they all are useful. But, when you are choosing
a book for your class, you shouldn't simply pick
your favorite. Make sure you pick a book that caters to the material
you are going to teach, as well as the level of the class. If you have a
room full of upper-class computer science majors, the more technical
book might be a better choice. I am running an introductory course this
time, though, so I wanted to find a book that was readable, yet covered the material I
felt was important. I plan to use Learning Red Hat Enterprise
Linux and Fedora as a reference, as well as a few others.
Here are some of the other books I considered: Linux
Cookbook (Sturtz, No Starch Press), Linux
Cookbook (Schroder, O'Reilly), Red Hat Linux Fedora
Linux 3 Bible (Negus, Wiley Press), Official Red
Hat Linux Administrator's Guide (Red Hat Press) and RHCE Red
Hat Certified Linux Study Guide (Jang, McGraw-Hill).

By the way, a book called Linux: The Textbook is
available. With a name like that, you might think this is an obvious choice. Unfortunately,
it did not cater to what I wanted to do in the course. It talks a good bit
about applications and programming, but I am not going to touch on those
topics too much. It also is a bit dated; there has not been an update since 2001.
Topics, Schmopics!
Okay, we have four weeks for our class, five classes per week at two
hours per class. In sum, we are looking at forty hours for the class,
which is not much time. Here are the topics I am hoping to cover in some
kind of approximate order of introduction:

• A brief history on the origins of
  Linux.
• Open source vs. closed source
• Superuser versus regular user
• The directory structure
• Basic commands, including cd, ls, mkdir and cp
• The boot process
• Installation
• Command line versus GUI
• User administration
• Intermediate commands
• Security, including SSH, packet sniffers, rootkits and logs
• Services
• NFS
• cron
• Software administration, including source, RPM and apt-get
• Printing
• Applications, including XMMS, The GIMP and
  OpenOffice.org
• Eye candy, including the X Window System and Flash
• Compiling the kernel
• Backups/adding hardware

Can I get all of this done in only 40 hours? Obviously these topics
are not set in stone. A lot will depend on the speed of the class. If
they can assimilate the knowledge in a reasonable amount of time, we
should be able to hit most of these topics. If it goes a little slow,
though, I will have to cut a few topics.
A Pain in the Assessment
This is the part of any class that students love, tests! In
an academic institution, you usually have to assign some type of
grade to the students at the end of the term. What are reasonable
methods that can be used to measure the proficiency of the
students. Tests? Yes. Quizzes? Sure. Trouble shooting? You bet. Term
paper? Maybe.

How can assessment be carried out so that it is not simply another hoop the
student has to jump through to get his or her grade? Assessment itself should
be another learning experience. So instead of the traditional tests where
students get to fill in the blanks, be creative! After class one day, go
in and "break" the students machines. That way, when they all get to
class the next day, they won't be able to log on. Give them 30 minutes
to fix the problem, and at the end of the time, give them some hints
or explain the problem. Troubleshooting can be fun unless, of course,
it is your own machine. When Dr. Moorman and I last ran the class, it
was only a matter of days before a student had his machine cracked from the
outside. Luckily, we had planned a demonstration on security that day,
so it worked out perfectly.

I also have used the RHCE book mentioned earlier to come up with
multiple-choice questions the students can access on-line. This allows them to
quiz themselves to see if they are understanding the material. Although
you may not want to do this for an official quiz and/or test score,
it is a fun exercise the students can do at their own pace and time.

Testing itself probably will come in two forms, written and hands-on. For
the writing portion, I can ask the students to write out certain commands
they might use to complete a certain task. In the past, we allowed the
students to use their workstations to test the commands before they
gave their final answer. We then asked the students to answer the questions
by memory. In other words, we did not allow the use of man pages,
the Internet, their notes or their neighbor. Although this is not how it
will be in the real world, I feel it makes for a better system
administrator. After all, would you rather have a sys admin who can fix
a problem off the top of her head or one who has to take time to look
on the Internet to see is someone else has had a similar problem.

The second portion of testing will be the hands-on method of lab
practicums. Students will have to set up their machines to a
particular state. The state could be setting up new users, permissions,
services or many other types of problems. I should be able to log on
to their machines and check to see if they have set up their system
successfully. I think the students will enjoy this portion of the test
much more than the written portion, because there is a certain satisfaction
in knowing you have fixed a problem. I know I thoroughly enjoyed this
aspect when I became an RHCT. The scary part for the students will be
not having access to any resources for this part of their test. Again,
they will have to rely solely on themselves to see if they can understand
and solve a broken system. Although this may seem harsh, it is my hope
that doing this will motivate students to dive deeper into the material.
Besides, this is the process they will have to go through if they ever want
to become certified.

I can be more lenient on the homework portion. I will give certain
assignments and problems for the students to complete before the next
class period. Here, they will be allowed to use their books, notes
or whatever they want to help them solve a problem. These exercises
hopefully will cement the basic knowledge required to pass the tests,
if nothing else.

The final method of assessment could be the most unpopular--a term
paper. This assignment may not be your cup of tea, so some people might
omit this aspect. However, I feel it is important for the students to
be able to write as well as to solve problems. If you are at a technical
college, you might not think this is important, but being able to
express oneself well in written words is a part of our mission as a liberal
arts school. For the paper, you
could ask the students to write on many different topics. For instance,
you could ask them to develop a plan for a small liberal arts college to
change their computing structure from closed source to open source. You
could discuss the history and importance of Linux and open source. There
are many interesting topics for students to choose. The last time we ran this
class, we asked our students to talk about the decision Netscape made
to open the source code for its browser.
Class Dismissed
Okay class, time is up. I hope you enjoyed our discussion for the day. If
you want to follow the class, feel free to check out
our Web site. You can
use the username guest1 and the guest password is guest42. The
class begins April 27th, so make sure you get there by the time the
bell rings at 9:00am. If you have any questions or comments, feel free
to raise your hand in class or to send me an e-mail at
mlevan@transy.edu.
Resources
The
Cathedral and the Bazaar

"Putting Linux in
Classrooms around the World"

"Linux in the
Classroom: an Experience with Linux and Open-Source Software
in an Educational Environment"

Dr. Mike LeVan is a professor at Transylvania University. He can
be reached at mlevan@transy.edu.