Linux in the Classroom: a Look Back
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.
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.
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
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development