Linux in the Classroom: a Look Back

Class is over, so how did the course work go and how did the students do?

Welcome back!
Class has been
dismissed,
and now it's time to look back
and examine what went right and what went wrong during our month of
class. Being such a short semester--two hours a day, every week day, for
four weeks--things started off fast and never really slowed down. We had a
good time, and you still can check out the on-line version of the class
here. You can log
in as a guest and navigate to the computer science courses, and the Linux
Administration course is there for you to peruse. A student put all of the
notes and assignments into one PDF file for you to download, if you are interested.

Class Enrollment

Enrollment in the class was pretty interesting. There were 15 students
physically in the classroom. However, because of the article that
introduced the course, 70 or so other people signed up to take the class
on-line. Although we did not have a live Webcast, plenty of people went
to the Web site to download the assignments and notes to try to keep
up with the material. Several people also started discussions in our
social forum to try to make the class more of a community. In a sense,
it was a typical global community that you find with Linux. We had
people from Argentina, Lebanon, Canada, Singapore, Austria, Finland
and many other countries. It really turned into a good experience for my students,
and I hope it was for those who signed up to follow the class on-line.

Topics

This turned into a pretty tough issue for me. There were so many topics
that I wanted to jump into, but I simply did not have time. This meant
I had to pick and choose the topics as the semester went on. I was
discussing the class with one of the on-line participants, and he made a
good observation. The class was really turning into an amalgamation of
Linux system administration and Linux on the desktop. I wanted to show
some basic Linux administration skills, but I also wanted to show the
students how to manage the desktop so they might be encouraged to put
Linux on their PCs. This led to the following topics being discussed
during class:

Day 1 : Introduction and History

Days 2 and 3 : The Boot Process

Day 4 : Basic Commands

Day 5 : Directory Structure

Days 6-8 : Filesystems

Day 9 : Intermediate Commands

Day 10 : User Administration

Day 11 : User Quotas

Day 12 : Shells

Day 13 : Out of Class Assignment : CHKCONFIG

Day 14 : Software Management with RPM

Day 15 : SSH

Day 16 : Desktop Sharing and Security

Day 17 : NFS

Day 18 : CUPS and CRON

Day 19 : Troubleshooting Practicum

Day 20 : System Administration
Practicum

Class Structure

Our classes were two hours long. The ideal class period for me was to
introduce the topic and lecture for 60 to 75 minutes. Following lecture,
I would pass out a lab assignment based on the topic of the day. Sometimes
the labs took more time than we had, but that's okay. It was not a race to
see who could get the work done the fastest, but who would learn it the
best. Here is an example of a lab assignment I passed out when we talked
about user management:

Introduction to Linux Administration

Lab 5: User Administration

Use the command-line functions to carry out this assignment.

Create an account for the person in your row, as well as for me. Use
their Transy ID names. For example, mine should be mlevan. Set my user
ID to 1000. Set the password to be Linux2005. Let your partner pick
the password.

Set up a limit to how much space these two new users can have in their
home directory. Make the quota 100MB for both new users. Note that you
will have to do a little research on your own to get this
done.

Make a new group called TRANSY. Place the three regular users on your
workstation into this group. Set the group ID to 666.

Create a new directory in /home called Pioneer, and make the directory
owned by the TRANSY group.

Have mlevan create a file in the Pioneer directory that has permissions
-rwxrwx--- . Make sure the file is owned by the group TRANSY.

Disable the mlevan account.

The students were given as much time as necessary to complete these
tasks. Therefore, there was no reason for them not to learn the material
and finish the assignment. I often encouraged the students to come
into our lab and try the assignments multiple times. If the students
tried to race through the assignment without thinking about the topic
in depth, they were going to be in a bit of trouble when it came
time for the practicums.

There also a few days when the lecture took all of our time or perhaps
the topic did not warrant a lab exercise. For instance, the first day we
talked about the history of Linux and Open Source philosophy. There aren't
too many lab assignments one could make for this type of lecture. That's
okay, though. You don't always have to pass out an assignment simply for
the sake of having something for the students to do.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.