[ This was sent to us by Warren back in August, but due to the downtime, we're just publishing it now. Sorry for the delay, Warren. ]

Introduction

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 have 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

This server runs FreeBSD, acts as a filtering router to an internal network, 131.236.210.0, and also provides the primary DNS, mail, and, web server for the SA3 course.

harpo

This server runs OpenBSD, and provides internal services such as DHCP, an NTP server, and secondary DNS services. I went to FreeBSD after 386BSD 0.1, but I felt it was time to try out OpenBSD and see what good things they have done.

chico

Because of it's popularity with the students, this server runs Linux. It provides other internal services like Samba, POP/IMAP, printing, mailing lists, IRC, and FTP.

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 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 package collections, 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, 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 disasterous on a production system.

The assessment for SA3 is broken into several categories:

• Students must install FreeBSD or Linux on their own sandbox PC, and write up a report on how it went. For many of the students, both CompSci and InfoSys, this is the hardest assignment to do, as there is such a big learning curve on how to install and configure a real system.

• Students must create non-root user accounts on the three servers.

• At the end of the course, I give a lab test which examines the UNIX sysadmin skills that they picked up during the course. I also find that the Linux users fare badly against the FreeBSD users; I'd guess that the Linux GUI prevents them from finding out what's really going on underneath.

• Also at the end of the course, I ask the students to write a short course summary, telling me any shortcomings, what they did right, and what they did wrong. These are usually an excellent read, and they get passed on to the next-year students.

• In 2000, each student must choose at least one course-long job on one of the three SA3 servers. This forces them to install and configure a specific service, and also to maintain that service throughout the course. I've tried to make the jobs interdependent, so that to get part of a job done, a student might need to ask another student to do some work in their job. Fortnightly, students have to submit activity logs which record what job-related work they have performed.

• Finally, to make up the marks, students can choose from a wide range of elective assignments broken into two categories:  install work and report writing. The install assignments give students a chance to install fun things like Apache, Samba, an IRC server, a new desktop, etc. The report work is oriented towards the InfoSys students who don't want to get too technical, but can do useful sysadmin things like draft system policy documents and so on.

All software installed as part of an assignment must be done from source code, as installing from a FreeBSD port or 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 ankle-biter/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 of 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 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 backdoors on the servers!

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

The next trick from the tiger team was to login as ordinary users and waste resources (i.e., 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(5) and quotas on FreeBSD. I'm hoping that we can set resource limits on the Linux and OpenBSD boxes too.

One major event in SA3 this year is to migrate the 16 SA3 machines onto their own private network. We've got the hub and patch cables, and groucho has two 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(s).

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 up your sleeves 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

Return to the February 2001 Issue