Designing a Course in Linux System Administration

How one professor designed a class on Linux system administration--and how you can follow the class along on-line.
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

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



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Josh More's picture

When I was working on my RHCE, I needed the ability to 'break' a system for me to practice fixing it. To ease this, I started the trouble-maker
project. It is designed for both the person studying at home and for use in a classroom environment. It might be helpful to those of you creating break/fix tests.

While work has stalled due to me focusing on my new job, the project is certainly not dead. I will happilly accept any new scenarios that
people feel like adding.

rhce dumps

shaik's picture

it would be pleasure if u send the dumps of rhce

Usefullness of trouble-maker

Larry Vidrine's picture

I'm a home user of SuSE 9.3 Pro and Knoppix 3.8. Trouble-maker is made for people like me (who are adept at creating problems for themselves and not so adept at solving them), as well as for sys-admins whose job it is to solve problems other people have created.

I have a few other problems to resolve first, but when they're taken care of, I will try touble-maker: just to create problems for myself, and work my way through them. It would be really handy to create problems, and if I can't solve them (I'm sort of a bulldog in my efforts to solve problems), then I can easily recover (I like that idea).

So far, I've found 17 ways to trash my system, and an equal number of ways to protect myself from myself. A way to test something without thouroughly trashing the system would be just awesome.

Keep working on it. This is just too valuable to let lie fallow!

Additional GPU Tutorials

Mike Chirico's picture

The following link "Souptonuts" contains GPU tutorials that I have put together, which include building a Linux system on cdrom using BusyBox and the latest 2.6 source kernel. Plus, getting Gmail with Postfix. There are also over 150 Linux tips that are updated weekly.

Hope this helps,

Mike Chirico

Other resources of information you might want to check out.

James's picture

"Rute User's Tutorial and Exposition" by Paul Sheer might be another resource for you to investigate.

Linux Certified has an excellent class outline for Linux fundenmentals. You might want to check with them about using their course flow.

Also don't forget to mention the Linux Documentation Project.

I hope your course, is fun and thought provoking for you and your students.


Conclusion: computers are hard to use

Anonymous's picture

It's wonderful that you would like to teach the students about free (as in freedom) software!

However, I think that in 2005 users come with expectations of ease of use, so given you have only 40 hours, I think you should go GUI all the way for the first 30, then leave 10 for CLI related work.

System administration at the level of a single machine can mostly be done using a GUI, so it's unfair to make free software seem less familiar and dated than Microsoft's Windows or Apple's OS X.

Most distributions have GUI package managers to install or remove software. Teach them how to get all security patches through the available tool. The first thing I noticed about Linux coming from a MS Windows-environment was that I didn't have to reboot each time I wanted to try new software or updates - fantastic!

Teach them how to turn on the firewall feature, and teach them that an email is a networked postcard anyone can read, unless you put it in an encrypted envelope using GNUPG. Teach them it is rude to forward infected email to unlucky Windows users, so have them install ClamAV and teach them how to update it.

Teach them to write, calculate, and present their papers using on of the Office suites, most likely 2.0.

Teach them to drag-and-drop files to move, copy or delete using the GUI file manager. Have them create archive files using a GUI archive tool.

Summary: free software is easy and familiar, but power-users tend to make things difficult for newbies by saying "The only way to get your feet wet is to get up on the 10 meter high-board and do a double into the pool - it's so easy!". Please don't do that.


Anonymous's picture

However, I think that in 2005 users come with expectations of ease of use, so given you have only 40 hours, I think you should go GUI all the way for the first 30, then leave 10 for CLI related work.

I beg to differ. If someone's going to learn Linux administration, teach them the command line interface 100%. If someone's too lazy to learn the CLI, they shouldn't do Linux administration; keep them away from my systems.

I don't know what being in 2005 has to do with whether or not a person should learn the CLI. If they don't want to to work 100% on the command line, then they can learn to be a MCSE.

It's the difference between paper administration and real time administration - theorizing or doing. I think it's hard to explain but if one hasn't done command line administration they cannot possibly understand the difference. Once you've done it, you don't want to work with GUI's because they slow you down and they don't catch every possibility.

Finaly a outline for a Linux Course

Nicolas Kassis's picture

I've been trying to create a linux tutorial to present at my university but I never had any thing to base it on. This might be a good outline for it.

Book writers should take a look at this list of topics.


In general I like the idea but I'd like to add.

James's picture

1. Teach them how to read a man page...... Don't let them spend ages spinning their wheels when so much help is right there. This doesn't have to be more than 10 minutes and a lot of "what does the man page say" being asked when they ask questions. The more you teach how to read a man page the more they will carry beyond the class.

2. Move from teaching NFS to remote file systems and administration. The idea that beyond the bootloader and the initrd image the need to have anything physically local is a matter of choice not necessity. Let student A play with launching an app not even installed on his/her box but rather installed on another students. I've sat half way round the world reading mail over ssh forwarding with a mailreader installed on my home system not on my laptop, all with the click of an icon.

Heck, If your school is like so many that require students to have laptops,or if they have some kind of computer access. I would highly recommend handing out copies of Knoppix on the first day. That way they can play at home and not lose anything they have. 1 knoppix CD plus 1 floppy and they can carry thier desktop anywhere. (the floppy is for configs) If they have a usb Pendrive/keyring drive, they can carry their desktop and their home.

Only hand out a LiveCD if you use it in class!

Anonymous's picture

My son is 6 years old and my daughter is 4 - they don't know which system is "right for them", so they are happy clicking any menu that lets them play Supertux. My wife is a Windows user, and accustomed to certain ways of doing things, and if Linux differs in any way what so ever "Linux sucks". The point is this: if you don't use Knoppix in class, don't give them Knoppix to play with. Give them what they use in class. You are there to teach them, so teach them by dipping their toes, then, if they are confident - teach them to swim.

Things to add

Jason Coutu's picture

When talking about man pages, it is important to talk about serching techniques, and tools. Man is useless without appropos or some other serach tool. Google is also a great resource. Some students will take offence to having to look things up for them selves. This year I had a student tell me that if I didn't teach it in class he shouldn't have to look it up. I told the student that the class should also teach the student how to learn. :)


Lab Tasks for Linunx

barryp's picture

Great article ... rings true for me, as I am in the same boat: one of forty lecturers working with Linux within a sea of Microsoft OSes ... everyone else is on XP (except for one, who uses Mac OS X). I've intergrated Linux into as many of my courses as I can. On one, a final year SysAdmin course, I have my students work exclusively with Linux. I've developed a collection of Lab Tasks based on Marcel Gagne's first book that they work through,and that work well. The students seem to enjoy working through them ... even though, for some, using Linux after years of XP is a bit of a shock at first!

Paul Barry
IT Carlow, Ireland

Paul Barry