Linux File Server

Abstract

At the School District where I work, recently completed a file server migration. Rather major, actually. We completely ripped out our server infrastructure and replaced it with something completely different. This is a brief writeup on the new servers.

Background

Our school district was a Netware shop for some time. Until I started working there in 2004, with the exception of a terminal server, we were 100% Netware on the server side. After I started there, we had some minor Linux penetration, in the form of a database server and a couple backup servers.

In the 4.11 days, Netware was rock-solid and utterly stable. In fact, we still have a Netware 4.11 server at one of the smaller schools, and it is only failing now because it is running out of disk space. However, later versions of Netware have added more features at the expense of stability, until Netware 6.5, which is the worst of the lot. And the latest round of service packs has taken everything on a rather sharp downturn.

In the fall of 2006, the decision was made to migrate away from Netware. I mean, why not? Even Novell is moving away from Netware. Our first decision was what we should migrate to. We tossed around the idea of Novell's OES product, along with some Suse/Samba solutions, but I also had a couple prototype servers in place already, running Debian and Samba, at two of our smaller schools, and it was ultimately that route which we chose.

We eventually laid out an accelerated timeline that basically deploys one server per week for the elementary schools, until the summer of 2007, where we will deploy new servers in the high schools. By September 2007, all our file servers, as well as our webserver and student email system, were running Debian Linux.

Design Goals

Centralized user administration
We had leveraged eDirectory quite extensively; nearly all of our servers were in the same tree, which made user administration much simpler. We needed the new system to do at least as much.
Simplicity
Netware was becoming far too complex and feature-rich for our goals. In fact, though we had Zenworks (the server/workstation management system) installed on all our servers, we were using but a tiny fraction of it. The new system should not do much more than we need, as the extra complexity tends to get in the way and reduce overall stability of the system
Scalability
Like Netware, we wanted a system that could be easily expanded to meet changing needs of our district.
Robustness
This is one of the biggest areas where Novell was dropping the ball with Netware. We needed a system that, once in place, would require minimal maintenance.

Basic Configuration

Ultimately, it was decided that our servers would look like this:

Operating System

The servers are all currently Debian Etch. They will remain this way until Etch becomes too outdated for our purpose, or until the next stable release, at which point they will be upgraded.

LDAP

User accounts (both UNIX and Samba) will be stored in an LDAP directory, that is replicated to all locations in the district (ie., no server will need to cross a WAN link to contact an LDAP server.) Replication is performed with slurpd. This means that there is effectively one master and many read-only replicas of the database. While not as scalable as Netware's system, it is far simpler and less prone to failure. (for example, stuck obits and synthetic time, two nightmare scenarios for Netware admins, just don't happen in this setup.)

Print Server

I used CUPS for the print server, because the web interface makes remote administration a snap, and because CUPS integrates well with Samba.

File and printer sharing

We set up Samba 3, with full domain support through LDAP. There is one Samba PDC with an LDAP master database, and there is a Samba BDC at each site, with a slave LDAP database. This means that any user can log in at any site, which is something our current eDirectory setup does not permit us to do. (workstations are bound to a specific context)

Workstation Management

Since Samba 3 does not have any AD or Group Policy support, I collected and created some Administrative Templates for Windows NT4 System Policies, which allow us to control the workstations reasonably well.

Home directories

Each server has an NFS mount point for the home directories on each other server. This means that a given user's home directory is located in the same spot on every server, regardless of where the data actually live. This works not only for Samba, but for UNIX as well, so I can ssh into any server and see my files.

User administration

User administration is currently done through LDAP Account Manager, which provides support for UNIX and Samba accounts, and also stuff like Quotas.

Quotas

XFS has built-in support for quotas, and I am beginning to activate it across the server network. So far, the Quotas are integrating nicely with the NFS filesystems, and also through Samba to the Windows machines (in fact, administration of the Quotas through Windows might be the easiest way to do it, for everything except mass-edits.)

Current Progress

As of February 2008, we have completely migrated our network of fileservers to Linux/Samba servers. There are three Netware machines left in our district. One for the Groupwise MTA, one for the Groupwise post office for staff email, and a third to function as an eDirectory replication master. This is all that remains of our once-large Netware network.

The Samba servers are going well. I find myself learning to be an NT4 admin and a Linux admin at the same time, to be able to cope with the interoperability issues that always crop up. I've found that most things that can be done with Group Policies can also be done using custom System Policy templates. This means that we have excellent control over our workstations, even though they're in an NT4 domain.

During the 2007/2008 year, I added Squid to our fileservers, and integrated it to Samba. This allows us to monitor and control where the users can surf, as well as allowing teachers to turn internet access on and off in their classrooms with the flick of a switch.