User talk:Chris Tyler/OPS235 Updates

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
  for feedback and confirmation to proceed by fellow OPS235 instructors. I want to start on this asap...

• I like lab #1! Learning these manual override concepts are essential! Don't throw out the baby with the bathwater! My previous students loved the ability to use these tools to help "get them out of a situation". I wanted to make a YouTube video on practical use of skills used in lab #1...
  
  
• I'm OK with ditching written test #2 (but then how does this affect mark weighting?)
  
  
• I think it could work if we just took one assignment and split it into 2 sections. I got idea from Chris Jankul when he was teaching OPS435. He had two stages (the second built upon the other). In this way, marking doesn't have to be "massive". I believe that students gain the most experience from performing the labs any-ways...
  
  
• Which official version of Fedora are we using? (Fedora 16 live CD, and Fedora 16 DVD)? Need confirmation, so I can test-out the labs.
  
  

• I also want to create some YouTube videos placed prior to the "Review Questions" section for "Connecting the Dots" so to speak. These would be short videos to provide reasons why they are using these tools. Especially LAB1!! Hint, Hint, (i.e. I don't want students to lose lab1!!!!)
  
  
• Which lab (i.e. in relation to "fall lab line-up") would be affected by SysVInit -> Systemd ?
  
  
• I am in STRONG AGREEMENT with "re-factoring" wiki labs and course notes content. I strongly believe in "forward" and "backward" linkages as well. Let's take a journey down a river (hopefully no waterfalls). In addition to preamble about what student will be performing, it would be nice to "tie-in" the previous lab to allow a "flow" ("end-to-end"). This would relate to a "forward linkage" of what students can expect in the next lab. I strongly believe that well designed courses provide a "flow". This is NOT to indicate "spoon-feeding", but a nice "fit" in a practical container (yet not too constrained). I like the steps listed in the "re-alignment".
  
  

As a "follow-up" to this "flow":

• For debugging, I would stress common problems that students have made in the past, and a general suggestion that the student take to remedy the situation. Careful "check-points" should be indicated (perhaps with a "check-point icon" (a good "gaming" connection) to have students CAREFULLY confirm their contents with the suggested output, and then direct them to debugging. I would NOT recommend YouTube videos for fixing the problem (that should still be "hands-on" and text-based), but videos for confirmation checks... and call over instructor for major difficulties...
  
  

The concept of a "check-point" works well with the "graphics" discussion at the bottom of the "user page". Many students are "gamers" and are "visually stimulated". I agree to revamp the wiki and reduce the "text overload". Don't get me wrong - students need to research to learn, but learning now comes in different flavours.

I really like this course! I totally get the importance of "learning how to learn". On the other hand, just posting up links to content may "turn-off" students. I recalled, that I created some "slide-shows" for students to know where to focus on the important things. I would think this is the challenge to engage the students to "learn how to learn", but not get "overloaded" in too many details... On the other hand, alternative media can be used to foster this. I recall Chris that you once pushed for students to use graphical editor to break that "older concept of traditional cli editor. I think the same applies for learning content (lets work in the "modern age", with "modern media/learning objects"). In the future, more emphasis on demonstrations. For example, we could demonstrate using gtk-recordmydekstop, upload and link desktop recording to a YouTube of what the output from commands should be. Perhaps, this can reduce the "text-overflow". I did find that using YouTube greatly reduced the size of the "Sample Run" specifications of the OPS435 course immensely!

• I'm a big believer that if students are left to complete those "review questions" at the end of the lab, they won't. Why not change the perspective a little? We seem to be very good at programming the practical test results, can't we program mark the labs? I'm assuming that you guys may have thought of this already, but probably a BIG TASK (I understand and respect this). But if can be done, then I would think this would reduce a lot of checking from the instructor to "sign-off" at the end of the lab. Have it done by having instructor verify from automated lab submission. Perhaps shift of focus on "instructor checking" could be done at the check-points. I'm getting the impression that if we are going to go in for "adjustments", let's make a few more, and really make a great product! I'm willing to completely test, write (i.e. total rewrite labs - YIKES FOR ME!!, but I'm geared up for it!!!), as long as someone wants to automate the lab submission, and perhaps as a bow on top, build a quiz blank with questions asking random questions with immediate feedback.
  
  The only problem would be that students don't get their lab sheets checked manually by instructor, but they these marks would be updated at the end of the week my instructor, and should know where they stand...
  
  

Automation (via shell scripting) helped a great deal in OPS435 to manage tracking online tutorials and labs, perhaps OPS235 would benefit from that as well. Sure, steady end of week commitment for a couple of hours, but most likely well worth it, and relates to the "automation" of administrative tasks (i.e. "lead by example")...

Tell me, and I forget, show me and I will watch, involve me and I will learn...

No pain, No gain. So let's have No fear. Time to "rock and roll"...

My passionate $0.02...

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:

1. System installation - labs 2-3
   1. Installation from installation DVD (includes runlevels)
   2. Installation from Live CD (in a VM)
   3. Installation across the network (in a VM)
   4. Automated installation using a kickstart file (network install in a VM)
2. Disk space management using LVM - lab 4
3. Miscellaneous Admin Skills - lab 5
   1. Loopback mounting
   2. Compiling from source
   3. Working with archives
   4. Managing services
4. Basic network configuration - lab 6
5. Network services and firewalls - lab 7
6. 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