1,885
edits
Changes
no edit summary
::: My passionate $0.02...
[[User:Chris Tyler|Chris Tyler]]
Murray, there are a couple of things to bear in mind with OPS235:
* This is the first time that the students are the system administrator -- the first time that they have root privilege.
* It's been structured as a very experiential course -- students learn by doing hands-on work. They need to learn that:
** When you're the system administrator, the buck stops with you -- you have absolute power over the system, but also absolute responsibility for the state of the system.
** Linux doesn't baby you, and it's easily possible to destroy things.
It took me a while to get used to this approach, but I think it works well for this course material.
The basic flow of the course is this:
# System installation - labs 2-3
## Installation from installation DVD (includes runlevels)
## Installation from Live CD (in a VM)
## Installation across the network (in a VM)
## Automated installation using a kickstart file (network install in a VM)
# Disk space management using LVM - lab 4
# Miscellaneous Admin Skills - lab 5
## Loopback mounting
## Compiling from source
## Working with archives
## Managing services
# Basic network configuration - lab 6
# Network services and firewalls - lab 7
# Configuring and using DHCP - lab 8
Notes:
* Lab 1 was added a few years ago to let students get started before they had a hard disk pack. This lab generally causes confusion and messes students up right at the start of the course -- hence the decision to drop it. These concepts can and should be moved forward (e.g., to around lab 4), letting the students jump directly into installation right at the start of the course.
* Labs 1-5 are before the break, focusing on system installation and storage configuration
* Labs 6-8 are after the break, focusing on basic network administration
* The course used to involve only a single installation, and network labs were done by using SeneNET's "Pod mode" (groups of 4 machines) and working in groups of 4. This led to a number of issues:
** Mismatches between partners
** Inability to complete labs in the Open Lab if the students ran out of time during the course periods
** Problems if a group member was missing
** Pod Mode didn't always work
** The dual-NIC (gateway) machines in each pod were confusing to the students -- which interface was local and which was external was always unclear
* The use of VMs solved a lot of the network issues, and let each student set up a 4-machine network all on one physical computer. They also let the students perform different types of installation, and since VMs are relatively easy to back up, the students can destroy a VM and fairly easily restore it (a lot more easily than restoring their base installation) -- in fact, we have them intentionally destroy one of their VMs and then restore it from backup so that they understand the procedure. This provides a bit of a air bag when the students make a serious mistake (which is almost inevitable) -- hence we have them do the most dangerous things within VMs rather than on the bare-bones system.
* Where appropriate, the course introduces students to both GUI and command-line approaches to system administration tasks, with a focus on command-line (since command-line work is generally more productive, works across a wider range of systems, works better across a network, and is critical in installation and disaster-recovery situations when a GUI may not be available).
Because the students are doing low-level system administration, I think it's important that they work on real systems rather than a simulated environment, and do so with a minimum of hand-holding. Many of the labs are structured to walk the student through a task in detail once (perhaps with a GUI), then with less hand-holding a second time (e.g., from the command line on a second VM), then with no hand-holding (asking them to apply what they've learned and practised on the last VM).
For this reason, I oppose giving the students scripts to walk them through the preparation for the lab, or to mark the lab -- I think the students need to either ''be'' beyond that or ''move'' beyond that in this course. The labs are generally marked on a binary (done/not done) basis; lab monitors are permitted to sign off on completion of a lab but cannot grade a lab, so binary marking lets us utilize them to check labs (which is critical).
