Teaching Systems Administration with FreeBSD: Part I
Warren Toomey, wkt@cs.adfa.edu.au

I work for one of the few universities in Australia that teach Systems Administration as an elective course in an undergraduate Computer Science or Information Systems degree. Currently, I've got a bunch of 22 students, and we are a third of the way through the course. I thought I'd briefly describe how the course is run, why I'm using FreeBSD, and how useful the students are finding the course.

I've been teaching a sysadmin course, SA3, for quite a number of years now. Because of its popularity and some other perceived shortcomings of the 1999 course, I've changed the work that the students get to do. In 2000, we have three main servers: Groucho, Chico and Harpo.

There's no way I'd be able to give a good sysadmin course without Open Source systems. All of the above, and NetBSD, allow you to really get your hands dirty with the low-level sysadmin commands as well as hiding behind a GUI (if you really feel the need). These systems come with a pile of useful system and network services built-in. Most of these systems come with ports and/or packages, which makes adding extra functionality relatively easy. And finally, having full source code allows the kernel to be tailored to match the hardware and the desired level of functionality.

Each week, I give two hour-long lectures in SA3. These cover the basic Unix concepts and sysadmin tasks, but the students learn more by going into the lab and trying things out. They usually spend at least 4 hours per week there, either reading manuals and web pages or actually doing set tasks.

As well as the three servers Groucho, Chico and Harpo, each student shares one of 13 other PCs. These are used as `sandbox' systems for the students to practice on. With these machines, they can make mistakes that would otherwise be disastrous on a production system.

The assessment for SA3 is broken into several categories:

All software installed as part of an assignment must be done from source code, as installing from a FreeBSD port or a package makes it too easy, and also stops the would-be sysadmin from configuring the software to suit the local system.

SA3 in 2000: Weeks One to Three

Ok, so now you've got the gist of how SA3 runs, let me describe how it's going so far. We're now into week 5 of our 13 week semester.

In week 1 I advertised the course-long jobs and an empty allocation for the `sandbox' PCs, and immediately got job requests for the web server, the tiger team and the first few sandbox groups. We've got one student who's essentially an anklebiter-hacker who wanted to be in on the tiger team; I thought at least we'd know what he was trying to do then :-)

It took until week 3 before all the students chose jobs and sandbox groups. Several people chose to do multiple course-long jobs, as this means less formal report writing, and more informal job activity log writing. In these first 3 weeks I cover the basic concepts of Unix, which can be kind of dull, but is crucial if you want to understand how FreeBSD or any Unix system really works.

Weeks Three to Five

The due date for the first assignments (the installation of FreeBSD or Linux, and the user accounts on the 3 servers) was the 16th of August. As expected, some students found these first assignments conceptually hard, but after reading their reports I think they've got the hang of things.

The tiger team also had to create user accounts, and so for the first few weeks they had root access to the servers, but were not allowed to do anything nasty. That didn't stop them from running Crack on the password file. With the user accounts due date passed, we immediately changed the servers' root passwords. To my surprise, they didn't leave any backdoors on the servers!

I made the mistake of e-mailing the new passwords out to the non-tiger students. Of course, students read each other's e-mail, so the tiger team was back in. The passwords changed again very quickly, and now propagate verbally.

Next trick from the tiger team was to login as ordinary users and waste resources (e.g recursive directories, fork bombs, memory and CPU chewers). This got the hackles of our security officers up. The security officer for Groucho has spent the last few days learning about login.conf and quotas on FreeBSD. I'm hoping that we can set resource limits on Linux and OpenBSD too.

One major event in SA3 this year is to migrate the 16 SA3 machines onto its own private network. We've got the hub and patch cables, and Groucho now has 2 working Ethernet cards; it will become the router. We have been given a subnet allocation and the route for it has been set up, and Groucho has also been registered as the Source of Authority for our own domain. Now it's up to the three network admins and the DNS admin to do the cabling, choose IP addresses and hostnames, and get all the students to reset their hostnames, addresses, default router and DNS nameserver.

I'll keep you posted on how the SA3 course is going in future installments. If possible, I'll try to get the students themselves to tell you how the course is going, and what they think of it.

Teaching systems administration isn't easy; the only real way to do it is to roll your sleeves up and get your hands dirty. A course like SA3 gives students this opportunity, but with some support from the lecturer for when things go wrong. It also helps direct the students' activities to ensure that they learn good habits and methods. Stay tuned for more ...

Warren Toomey