Linux in the Classroom – A Look Back Dr. Mike LeVan Welcome back! Class has been dismissed and it is time to look back and examine what went right and what went wrong during our month of class. Being such a short semester (2 hours a day, every week day, for 4 weeks), things started off fast and never really slowed down. We had a good time, and you can still check out the online version of the class at http://www.cs.transy.edu/moodle/ . You can log in as guest and navigate to the computer science courses. The Linux Administration course will be right 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. Class Enrollment Enrollment in the class was pretty interesting. There were 15 students physically in the classroom. However, because of an article which introduced the course (http://www.linuxjournal.com/article/8193), there were 70 or so others that signed up to take the class online. While we did not have a live webcast, there were plenty of people that would go to the website 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 others. It really turned into a good experience for my students, and I hope for those that signed up to follow the class online. Topics This turned into a pretty tough issue for me. There were SO many topics that I wanted to jump into, but I just 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 online 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, and I also wanted to show the students how to manage the desktop so they might be encouraged to put Linux on their PC's. This led to the following topics being discussed during class: Day 1 : Introduction and History Days 2 and 3 : The Boot Process Day 4 : Basic Commands Day 5 : Directory Structure Days 6, 7, and 8 : Filesystems Day 9 : Intermediate Commands Day 10 : User Administration Day 11 : User Quotas Day 12 : Shells Day 13 : Out of Class Assignment : CHKCONFIG Day 14 : Software Management with RPM Day 15 : SSH Day 16 : Desktop Sharing and Security Day 17 : NFS Day 18 : CUPS and CRON Day 19 : Troubleshooting Practicum Day 20 : System Administration Practicum Class Structure Our classes were 2 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 OK. It is 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. 1. Create an account for the person in your row, as well as for me. Use their Transy ID names. For example, mine should be mlevan. Set my user ID to 1000. Set the password to be Linux2005. Let your partner pick their password. 2. Set up a limit to how much space these two new users can have in their home directory. Make the quota 100MB for both new users. Note that you will have to do a little research on your own to get this done. 3. Make a new group called TRANSY. Place the three regular users on your workstation into this group. Set the group ID to 666. 4. Create a new directory in /home called Pioneer, and make the directory owned by the TRANSY group. 5. Have mlevan create a file in the Pioneer directory that has permissions -rwxrwx--- . Make sure the file is owned by the group TRANSY. 6. Disable the mlevan account. 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 get the assignment finished. I often encouraged the students to come into our lab and to try the assignments multiple times. If the students tried to race through the assignment without thinking about the topic in depth, then they were going to be in a bit of trouble when it came time for the practicums. There were also a few days when 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 OK. You don't always have to pass out an assignment just for the sake of having something for the students to do. Grading 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 all the assignments came into play. The labs and homeworks always built on what we talked about during our class. In fact, there were a couple of times where 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 were 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 were actually 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 is the usually the last script that is 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 just 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 6 problems and they had one hour to complete the tasks. A couple of students fixed all 6 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 just 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 straight forward. You can probably 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. There were 10 tasks that needed to be completed in the required two hours. The trickiest part of this practicum was probably setting up a small RAID. Note that we only had one hard drive, but the skill set is the important issue. There was also one more component to the grading, and that was a small 5 to 7 page paper on their topic of choice, as long as the topic was related to open source. There were several interesting ideas presented ranging from open source adoption issues to the current job market to applications needed for the desktop. This was an assignment intended to make the students look more deeply into the philosophy and applications of open source. Here is how the grading for the class was structured: 1.Homeworks and Labs : 50% 2.Practicum 1 : 20% 3.Practicum 2 : 20% 4.Paper 10% Basically, as long as they did their work, they got half 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 very high grade in the class, they needed to do well on the two practicums. In order to insure this, the students need to know that they must practice their work, There were a couple of students who took this to heart, and they did very well. There were other students that thought they could cruise through the practicums. This was not the case. If they had an unlimited amount of time, then they might have figured out the problems. However, when you are on a fixed amount of time, you really need to know most of the commands off the top of your head. If not, then 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. What Went Right Luckily, a lot of things went really well for us during the semester. Upon reading the student's comments, I discovered that they like a lot of aspects of the class. First of all, they liked the format. They enjoyed being able to have a lab which 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. Lastly, the students enjoyed the practicums. I tried to make them as realistic as possible, and the students seemed grateful. They are now 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 to succeed. What Went Wrong 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. I gave them an assignment on services. They examined the services that are controlled by chkconfig. The students had to write a brief paragraph detailing the purpose each service and to then determine if the service is needed if one is running a Linux box as their 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 know which services are available, and then to determine which services are actually needed. With this information, they should be able to improve the performance of their workstations. While this seems like a good idea, I think it might have been a little much. I knew it would be a lot of work, so I decided to let the students work in pairs on this assignment. While this cut down on the work of the individual student, it was still 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! Bummer! Most students were turning 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 very worthwhile assignment, but it needs to be thought out a little more on the implementation issue. 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 the article listed above), but it still is not what I would call a textbook. Most Linux books seem to tell you how to do something, but 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, then 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, then they may not know how to solve the problem. By answering the “Why” question along with the “How” question would go a long way into 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, etc.) as well as the practical issues (SSH, commands, upgrading, etc.). Conclusion Wow! I had a great time! I had the opportunity to dig deeper into Linux than I ever have 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.