Welcome back! Class has been dismissed, and now it's time to look back and examine what went right and what went wrong during our month of class. Being such a short semester--two hours a day, every week day, for four weeks--things started off fast and never really slowed down. We had a good time, and you still can check out the on-line version of the class here. You can log in as a guest and navigate to the computer science courses, and the Linux Administration course is there for you to peruse. A student put all of the notes and assignments into one PDF file for you to download, if you are interested.

Enrollment in the class was pretty interesting. There were 15 students physically in the classroom. However, because of the article that introduced the course, 70 or so other people signed up to take the class on-line. Although we did not have a live Webcast, plenty of people went to the Web site to download the assignments and notes to try to keep up with the material. Several people also started discussions in our social forum to try to make the class more of a community. In a sense, it was a typical global community that you find with Linux. We had people from Argentina, Lebanon, Canada, Singapore, Austria, Finland and many other countries. It really turned into a good experience for my students, and I hope it was for those who signed up to follow the class on-line.

This turned into a pretty tough issue for me. There were so many topics that I wanted to jump into, but I simply did not have time. This meant I had to pick and choose the topics as the semester went on. I was discussing the class with one of the on-line participants, and he made a good observation. The class was really turning into an amalgamation of Linux system administration and Linux on the desktop. I wanted to show some basic Linux administration skills, but I also wanted to show the students how to manage the desktop so they might be encouraged to put Linux on their PCs. This led to the following topics being discussed during class:

Our classes were two hours long. The ideal class period for me was to introduce the topic and lecture for 60 to 75 minutes. Following lecture, I would pass out a lab assignment based on the topic of the day. Sometimes the labs took more time than we had, but that's okay. It was not a race to see who could get the work done the fastest, but who would learn it the best. Here is an example of a lab assignment I passed out when we talked about user management:

Introduction to Linux Administration

Lab 5: User Administration

Use the command-line functions to carry out this assignment.

The students were given as much time as necessary to complete these tasks. Therefore, there was no reason for them not to learn the material and finish the assignment. I often encouraged the students to come into our lab and try the assignments multiple times. If the students tried to race through the assignment without thinking about the topic in depth, they were going to be in a bit of trouble when it came time for the practicums.

There also a few days when the lecture took all of our time or perhaps the topic did not warrant a lab exercise. For instance, the first day we talked about the history of Linux and Open Source philosophy. There aren't too many lab assignments one could make for this type of lecture. That's okay, though. You don't always have to pass out an assignment simply for the sake of having something for the students to do.

I wanted the grade from the class to reflect two main ideas. The first was learning the material and practicing what we did in lecture. This is where the assignments came into play. The labs and homework always built on what we talked about during our class. In fact, a couple of times I added an idea or two to the assignments that we had not discussed in class. For example, in the assignment above, I did not tell them how to enable quotas for users. The students had to research for themselves how to achieve this task. The next class period I went over the process with them, but I thought it would be nice for them to try solve a new problem on their own.

The second main grading element was practicums. I had these broken up into two days. The first day had two aspects the students had to complete. The first aspect was a troubleshooting practicum. In order to get them ready for this, I had a couple of practice runs that actually were harder than the final practicum. One dry run that was really fun was to stick init 6 into the /etc/rc.d/rc.local file. This usually is the last script run when the system is booted up. The init 6 command tells Linux to go into run level 6, which is a reboot. So, the system would boot up, run all the initialization scripts and then shut them all down and reboot. The students thought they could edit the /etc/inittab file to get back to normal, but that was not the case. They needed a good idea of the boot process to know when the scripts were run to solve the problem quickly. These dry runs were useful in getting them ready for their troubleshooting practicum.

The troubleshooting practicum was a total of six problems, and they had one hour to complete the tasks. A couple of students fixed all six issues, and a couple struggled, but for the most part the students did pretty well on this part. Once time was completed, I went around, graded the lab stations and then proceeded to the second half of the first practicum. The second half was a basic fresh installation of the operating system, Fedora Core 3. The students had 60 minutes to complete this task. Everyone did well on this aspect. This was good, because the workstations we were using also had a Windows XP partition. This should give the students confidence enough to try to install Linux on their own systems, if they desire.

The system administration practicum was fairly straightforward. You probably can imagine some of the tasks, many outlined in the assignment above. The students had to set up accounts, quotas, password expirations, cron jobs, minor security and more. Ten tasks needed to be completed in the required two hours. The trickiest part of this practicum probably was setting up a small RAID. Note that we only had one hard drive, but the skill set is the important issue.

One more component to the grading was a small 5-7 page paper on students' topics of choice, as long as the topics were related to open source. Several interesting ideas were presented, ranging from open-source adoption issues to the current job market to applications needed for the desktop. This assignment was intended to make the students look more deeply into the philosophy and applications of open source.

Here is how grading for the class was structured:

Basically, as long as students did their work, they got half of their grade for free. You can see that the paper itself was not a major component of the grading rubric. This means that in order for the students to get a high grade in the class, they needed to do well on the two practicums. In order to insure this, the students needed to know that they must practice their work. The couple of students who took this to heart did well. Other students thought they could cruise through the practicums, but this was not the case. If they had an unlimited amount of time, they might have figured out the problems. However, when you are operating on a fixed amount of time, you really need to know most of the commands off the top of your head. If not, as time flies by, the pressure increases and your performance drops off the table. The old adage really is true in this case--practice makes perfect.

Luckily, a lot of things went really well for us during the semester. Upon reading the student's comments, I discovered that they liked many aspects of the class. First of all, they liked the format. They enjoyed being able to have a lab that reinforced the ideas from the lecture. It was, in a sense, instant gratification in that the students could put the theory into practice right away.

The students also seemed to appreciate the depth we went into about the boot process. They told me that they never really thought about what went on from power-up to login. They now know what the messages actually mean when they are scrolling down the screen. Instead of seeing a lot of "stuff", they now see the grub stages, init starting and all the services that are started on their run level of choice. The words actually mean something to them now, and they can see when an error occurs during the boot process.

Finally, the students enjoyed the practicums. I tried to make them as realistic as possible, and the students seemed grateful. They now are more prepared for the certification process than if they had taken a certification class for the first time. While our practicums were not as tough as a real certification exam, they now know the mindset that is needed in order to have a good chance at succeeding.

I don't have a whole lot to report here. The biggest drawback in any teaching assignment is grading. That certainly was the case here. For instance, I gave them an assignment on services in which they examined the services controlled by chkconfig. The students had to write a brief paragraph detailing the purpose of each service and then determine if the service is needed if one is running a Linux box as the desktop. In other words, what services do we need if we are a regular user and not running any servers. The main purposes were for the students to be able to know which services are available and then determine which services actually are needed. With this information, they should be able to improve the performance of their workstations.

Although this seems like a good idea, I think it might have been a little much for them. I knew it would be a lot of work, so I decided to let the students work in pairs on this assignment. This cut down on the work of the individual student, but it still was a daunting task. Each student still had to investigate and write a brief review of over twenty services. While this was a lot of work for the students, it was even more work for me! Most students turned in around ten pages for me to read. This is tough to get graded during a regular semester, but our shortened semester made it even worse. I still think this is a worthwhile assignment, but it needs to be thought out a little more on the implementation side.

The only other aspect that I have reservations about is the issue of a textbook. I decided to go with the book How Linux Works (No Starch Press, Brian Ward). I like this book for a lot of reasons (see my previous article), but it still is not what I would call a textbook. Most Linux books seem to tell you how to do something but do not necessarily explain why that something works. I am reminded of the old saying about giving someone a fish as opposed to teaching them to fish. If you tell someone to type something without explaining why it works, there is no depth to he knowledge. Yes, someone could remember how to solve the exact same problem if it arises again, but if a small variant of the problem comes up, they may not know how to solve that problem. Answering the "Why" question along with the "How" question would go a long way toward teaching people about the ins-and-outs of the operating system. As you can tell from the list of topics, we spent a lot of time talking about foundational issues--boot process, filesystems--as well as the practical issues--SSH, commands, upgrading.

Wow! I had a great time with this class. I had the opportunity to dig deeper into Linux than ever before. The students all commented that they got a lot out of the course as well. They even asked if we could make this a regular offering. Some people are thinking about starting a LUG. Since our school is named Transylvania, they thought of calling the group TLUG with a vampire penguin as the mascot. Opportunities abound!

Finally, I get to make a presentation in the fall to our faculty, and I have decided to talk about this experience. This will be my chance to introduce my colleagues to the realm of open source. Perhaps when they see some of the opportunities they are missing, I can convince them of the joy that is open-source software.

Class dismissed. Have a good summer. I'll see you in class this fall.