Several years ago, when I was working on my Master's degree in Library Science, I took a course on Unix (Solaris) system administration. The course was supposed to involve setting up a web server on a Sun workstation, starting with a fresh, bare-metal install of the Solaris operating system and building things up from there.
Sounds great, right? I certainly thought so, but after the course started, the professor was told to tone things down because someone higher up in the university was concerned that student-administered machines could get hacked and the department would be held accountable. The course was modified so that we had to do a bunch of smaller, less complex tasks by logging into a workstation the professor had complete control over. We did not get to install Apache and PHP, but we did get to work through several interesting and challenging problems. As good as the course ended up being, it was still a pale imitation of what it could have been had we been given the freedom to administer our own machines.
A lot has changed technology-wise since I took that course, and because a new academic year is starting, I thought this was a great time to have a look at what a modern system administration class's homework should look like. Should a student's first system administration experience come with a safety net, so that there are not too many security problems when they make mistakes? Or should a course be as realistic as possible, even if that is supposedly dangerous? I lean heavily toward the "realistic" side, and I am going to share an excellent example of someone teaching that way. If you have different ideas, please share them in the comments section below.
Realistic system administration homework
Tom Clark from Otago Polytechnic gave a presentation at Linux.conf.au earlier this year that provided an excellent example of a modern, realistic system administration course. The content of the course is presented using Clark's three main teaching principles:
- Doing something is better than just talking about it.
- Use a consistent thread of development so that topics build on each other, and so that lessons from the first day are still relevant on the final day.
- Realism, which involves real tasks, real tools, and real assessment.
These three ideas permeate the course and are used to provide the students with a realistic, hands-on learning experience.
The learning experience
Students spend the 16-week long course learning practical skills using real tools. To support their systems, students learn about using support tickets and documentation by using RT and MediaWiki. To deploy and maintain their systems, they learn about configuration management using Puppet, system monitoring using Nagios, and backup and recovery using Bacula. But the broad concepts are more important than the specific software packages I just mentioned. The point is to learn, for example, configuration management, not to be trained to use Puppet. The software used by Clark is used because it works for him, but the software is flexible and changeable.
The major project involves pairs of students deploying, maintaining, and supporting a deployment of ownCloud. They are responsible for deploying on time and keeping the system up and running with a minimum of downtime for a two-week period. During this time, Clark functions as a user and a manager opening support tickets. In his user role, he requests help with password resets and other basic tasks. As a manager, he requests configuration changes, new Nagios checks, and other administrative tasks. Students are expected to handle the issues promptly, document their processes, and communicate effectively.
In addition to opening support tickets, Clark makes things difficult for the students by intentionally breaking things. He has root access on all the servers, so he just logs in and tweaks things, such as shutting down MySQL. At some point during the project, Clark does something brutal—basically simulating a real-world hacking by deleting important files and defacing the site. He says that for "optimal learning experience" he does this around 3:00 AM.
Grading is based on uptime and the students' handling of support tickets and other issues. Clark uses his own Nagios instance to monitor uptime and he reviews their ticket logs and wiki to see how well the students handled issues and worked together as a team. He then meets with the students face-to-face to discuss their performance.
My own experience as a student was sub-par because someone was worried that a bunch of students might mess up and cause problems for the department and/or university, even though messing up is part of the learning process, and the chance for our workstations to be hacked was minuscule. Clark's students, on the other hand, get to experience situations like they would in a real-world setting, except for the fact that if something does go horribly wrong, Clark is there to step in and resolve the problem, even if that means just shutting down the offending virtual machine.
Overall, Clark's course seems like an excellent way to introduce students to system administration. Students get hands-on, practical experience with a wide variety of software, and the experience gives them something to talk about during job interviews. A college course should not necessarily be job training in itself, but it should help develop skills that can be used in real situations. Clark's course provides experience with real tools and, more importantly, helps develops the problem-solving and critical-thinking skills needed in the modern job market.
I would love to hear what professional sys admins and people who teach system administration—both in and outside academia—think. As Clark notes in his presentation, we know far more about teaching programming than we do about teaching system administration. So if you have any thoughts on the subject, feel free to leave them in the comments section below.
This article is part of the Back to School series focused on open source projects and tools for students of all levels.