Linux in the Classroom: an Experience with Linux and Open-Source Software in an Educational Environment

Formerly tied to one proprietary OS, this multicampus college is broadening students' horizons with Linux, Samba, SquirrelMail and more.

Mountainland Applied Technology College (MATC) is one of several campuses that are a part of the Utah College of Applied Technology (UCAT) system. Our department teaches information technology courses to both high school and adult students. We provide individual technology courses, short-term intensive training (STIT) courses, custom fit courses and an education track that ends with an Associate of Applied Technology degree or Certificate of Completion in Information Technology. We currently have two satellite sites with a probability of adding two more in the 2005–2006 school year.

Until the last few years, we had been reliant solely on Microsoft operating systems in our classrooms. Unfortunately, when you give students sufficient rights to work on their course material and labs, spyware and viruses are introduced despite your best uses of firewalls and virus scanners. These problems have entered the network through means such as Web surfing, floppies and USB thumbdrives.

Our Evolving Use of Linux

Starting with the 2001–2002 school year, Mountainland Applied Technology College began offering Linux courses at the Orem MATC campus. Over the next several years, our Linux class enrollments and course offerings continued to grow, matching the growing use of Linux at home and in businesses. Coupled with individual Linux distribution evaluations, teaching these courses was a convincing experience that Linux was a viable operating system for the IT department's infrastructure and for hosting courseware on our classroom machines.

At the start of the 2000–2001 school year, individual classroom servers were running either Microsoft Windows 2000 or Novell Netware. We started using a Linux based firewall/router product called Freesco in the individual classrooms to help deal with the increasing amount of malware and the security inadequacies of Windows.

During the 2001–2002 school year, a Windows 2000 system continued as the main classroom server. Up until this time we still had no main department server. We brought up a system with Linux as a secondary server and started working on integrating Linux into Microsoft Active Directory with great difficulty and little success. We tried using Microsoft Services for Unix, winbind (Samba 2.2.x) and pam_smb, but we still couldn't make things work well and temporarily abandoned our attempt to integrate Linux authentication with Windows Active Directory. During this school year, we also taught our first Linux course for CompTIA Linux+ certification.

During the 2002–2003 school year, we replaced the classroom Windows 2000 server with a Linux system running Mandrake 9.1. We had an epiphany, so to speak, when we changed our paradigm in relation to what to use on our server(s) in the back end. We discovered that using Linux for the back end made it a much easier task to integrate different operating systems, such as Microsoft and Linux, as opposed to using Windows and Active Directory as the back end.

During the second half of the school year, various Linux distributions, such as Red Hat 9 beta and Mandrake 9.1, were beta tested on the desktop. NIS was used for user authentication on Linux clients and Samba, as a domain controller, for user authentication in Windows. Although this setup worked, it was frustrating to deal with multiple passwords for the same user account, and we started looking for a better solution. During this school year, we also taught the first incarnation of our Linux Server Administration course, using what we had learned through our experiences up to this point.

The 2003–2004 school year was a time when Linux technology, other open-source software and our understanding and ability to use it all caught up with their promised potential. The main IT classroom servers were moved from Netware and Windows 2000 to a single department server running Linux, in this case Mandrake 9.1. We started using OpenLDAP as a central repository for user authentication. LDAP was used as the back-end database for Samba, and we used the pam_ldap modules for Linux client authentication. We started using Linux on the desktop—initially Red Hat 9, Fedora Core 1 or SuSE 9—as the default option in a dual-boot configuration with Windows XP Pro. At this time, the majority of our students chose the Windows option with a few brave souls trying Linux.

We also retained Windows because several courseware packages either required Microsoft products, including the Windows OS, Internet Explorer or Media Player, or the browsers available for Linux were not sufficiently Microsoft-Internet-Explorer-compatible to use some sites. All things considered, we were pleased with the stability of Linux on the desktop. We were impressed particularly with the virtual elimination of problems with viruses, spyware and overly curious students that we suffered with desktop Windows systems.

The 2004–2005 school year has proven to be one of continued and significant improvements. We upgraded the main Information Technology department server to Fedora Core 2 to gain the advantages of the Linux 2.6 kernel. We also started offering students in the Information Technology Department e-mail using Postfix, Dovecot and Squirrelmail, with filtering provided by SpamAssassin and ClamAV. On the Microsoft compatibility front, we upgraded to Samba 3, which provides much better integration with OpenLDAP and creates a new opportunity for us in our quest for a true single sign-on solution.

We now have an environment where our users can log in to either Linux or Windows XP Pro using the same user name and password. Linux clients authenticate using pam_ldap, and users have home directories stored on the server, shared via NFS and dynamically mounted at login time using autofs. Windows clients are joined to a domain controlled by Samba, allowing users to authenticate using the same account information, user name and password as they would if they were logging in to a Linux client. The same home directories on the server that are used with Linux are available in Windows through automatic drive mappings. Windows users' roaming user profiles also are stored in their home directories on the server.

To take a step further in the single sign-on arena, users also use the same account information to access their e-mail. We have provided Web-based access to e-mail, which also is stored in their home directories on the server, through Squirrelmail. Standard POP3 or IMAP access is provided by Dovecot.

Fedora Core 2 or Fedora Core 3 is the primary desktop operating system, depending on the lab. Windows XP Pro also is available as a dual-boot option in some labs, but we strongly are encouraging our students to use Linux. We are finding that, for the most part, our students have had little difficulty making the switch to using Linux as their primary desktop operating system. In many cases, they are enjoying it more than Windows because of the capabilities of KDE and GNOME to be customized to a user's individual taste.

To support software updates and patches between re-imaging, we have set up a centralized software/package repository on our main IT department server that mirrors the updates available on the Web. The lab servers at the remote sites then mirror a copy of the updates from the main server. The individual Linux clients in each lab then are scheduled to pull the updates from their respective lab server using apt4rpm. This method allows for better bandwidth usage, particularly for our sites connected via T1, and a controlled set of software and patches.

What we have developed on our main campus is a robust infrastructure free from many of the problems related to Microsoft Windows. Samba has replaced Windows as our domain controller for those desktops that need to run Windows.The latest version of OpenLDAP has proven robust, and Samba, Apache, Postfix and PAM take full advantage of its capabilities. Refer to Figure 1 to see the complete MATC infrastructure.

Figure 1. MATC Infrastructure