13,420
edits
Changes
no edit summary
'''msaul:(03-01-2012 @ 10:11 p.m.)''' :* Perhaps I can use my "non-contact summer" to look to develop a more graphical learning module for ops235 labs (if both Chris and Brian think it is worth doing). In the meantime, I don't know if we have the resources or time to launch a major tweak, but I like the idea of check-points, and perhaps automate at least some portions of the labs to verify successful student completion... :* Automation would be nice, but may not be available due to time constraints. On the other hand, it may be nice to add graphics to the labs... I will start to look at Lab 1 over Wednesday and Thursday to see if there are ways in which to reduce text, etc... :* I'm making some revisions to the OPS235 welcome page. Haven't changed bottom section relating to Fedora 13's specific issues... :* If looking to make ops25 welcome page more "graphical", here are some suggestions: ::* "What Course is About": Include a picture of a typical lab on right-hand-side.::* "Learning By Doing": Perhaps close-up of terminal showing Fedora Install, or a teacher or student typing in front of workstation (right-hand-side).::* "Supplies Checklist": Pics of supplies (right-hand-side)::* "Faculty": Pictures of Chris, Brian and myself (on right-hand-side) :* What will be the URL for downloading the Fedora16 Live CD and the Full-Blown Fedora 16 DVD install? :* In the "Supplies Checklist", may be a neat idea to show some pictures of a typical SATA drive and hard drive tray, as well as some usb keys, picture of the log-book, Freedom Toaster. This would be a nice "graphical" addition to the WIKI. '''msaul: (03-01-2012 @ 6:41 p.m.)''' :* Please see my notes below (03-01-2012 @ 6:09 p.m.) :* If emphasis has to be placed on two elements, the key would be the '''subject outline''' and the '''labs'''. For the subject outline to be completed, we need consensus on the evaluation element changes proposed. I would like to take a "crack" at the labs. I want to start working on a newer "lab1" (using more visual techniques) if that is OK with Chris and Brian. :* '''Would be neat to have students run program (Bash Shell script?) that walked students over procedure for lab preparation (DO's and DON'Ts) and then have then answer some questions and have results sent to instructor to record their participation.''' I could even do that... This would "bridge the gap" until a more sophisticated graphical presentation/program was created. In other words, baby-steps into an ''"intensely great product"'' (as Steve Jobs would say)... :* In the future, would an '''"object learning module"''' work better for the labs? In other words, students run an online program that discusses topic, then have the students perform the task. This "object learning module" could include evaluation for quiz, and have students submit to instructor. Also contain check-points. '''Apparently, Ian Tipson was associated with "Object Learning Models" and may provide useful insight / input.''' :* '''As for course content, I did create weekly slides (for my survival) to emphasise certain concepts in class. Perhaps this can be a discussion-point for tweaking and improving for course notes''', and then relegate text-based WIKI links to "Resources"... ::* Here are links to my slides for Week 1: :::* http://matrix.senecac.on.ca/~murray.saul/ops235/ops235w1_l1.odp:::* http://matrix.senecac.on.ca/~murray.saul/ops235/ops235w1_l2.odp ::* Let me know what you think... '''msaul: (03-01-2012 @ 6:09 p.m.)'''
'''In the future, I will just add content into this discussion area''', but perhaps create a section in "user page" to preview my editing suggestions
::: 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).
'''msaul: (03-01-2012 @ 11:03 p.m.)'''
:* Yeah, that is a good point. I also started to "sober up" (shown at the top), when I realised that would result in a lot of work. So you still see the benefit of lab 1. I recall that lab 4 is LARGE. Would it fit in just prior to networking? Also, I recall there was another lab that related to /etc/fstab, (I think it was lab5 - which was a little lite - maybe it would be better suited as an "add-on" there?
Thanks,
Murray
