Setting up a Linux school

A Linux school network has one particularly useful property: a student can sit down at almost any lab computer, log in, and find their own files and settings. The computers can be rebuilt without losing student work. That simplicity for the users depends on a few carefully coordinated services behind the scenes.

This is a description of the Linux systems at Lorien Novalis School in Sydney, and an example for anyone contemplating something similar. The configuration samples use fictional names and a sample LDAP suffix. They are illustrations to adapt and test, not a complete drop-in installation. I distinguish what we run from improvements I would consider today.

What the school needs

Schools have distinctive demands: a fresh intake every year, classes arriving at the computers together, staff and students moving between machines, and an IT budget that favours keeping good hardware in service. The Sophos firewall also handles DHCP and web access policy, using the same LDAP class groups.

• One identity: accounts are managed centrally, with consistent numeric user and group IDs.
• One home directory: the same files are available whichever lab machine is used.
• Disposable clients: the lab machines hold the OS and applications; important user files live on the server.
• Repeatable maintenance: computers can be re-imaged; user creation and group management are automated.
• Recoverability: directory replication and separate backups reduce the damage from failures, although they do not remove every single point of failure.

These are operational goals, not a claim that a central server can never fail. When storage or LDAP has a bad day, a room full of students notices immediately.

A brief history

The Linux lab began around 2000 or 2001, and it began with the students. A senior class wanted to set up a computer room using Linux. At the time I was a parent at the school, and one of the teachers asked whether I knew anything about Linux. That was the start of my involvement, entirely as a volunteer.

Equipment was donated, including the desktop computers and an old Sun SPARCstation 10. The early client distribution was Mandrake Linux; I also remember CentOS on the server side, although the precise sequence of server hardware and distributions is worth confirming. We used NIS, also known as Yellow Pages, for central account information, straightforward NFS mounts, and fixed IP addresses for all the lab computers. It was a practical system assembled with whatever the school could obtain.

Around 2007, one of the teachers administering the network moved account management to LDAP. Some of the directory's conventions, such as distinguished names based on a person's full-name cn, have been around since approximately 2010 and remain in use today. Changing a long-established naming scheme is not something to do casually when thousands of files and accounts depend on it.

After about 2010 the school employed me casually for a few days each month to maintain the growing system. I have since retired from my full-time career, and now work at the school two days a week. The project has outlasted several generations of computers and a good many Linux distributions.

Over the years we replaced static client configurations with a more maintainable arrangement: OpenLDAP for accounts, SSSD for Linux identity and authentication, and NFS with autofs for students' and staff members' home directories. The current lab runs Linux Mint 22.3, with approximately 40 Intel NUC7i5BNK computers. Older Apple computers and some dual-boot laptops are also in use.

In 2026 the central services moved to a Dell PowerEdge R740 running Ubuntu Server 24.04 with SSD RAID10 storage. It now hosts the main file tree and KVM virtual machines including LDAP, Koha and Zimbra. The older HP server suffered a RAID-controller failure that July. LDAP replication and Samba also needed repair that year. These are useful reminders that a school network evolves through repairs and compromises, not just elegant diagrams.

The architecture

These are the principal pieces. More than one role can run on the same physical host, but keeping the roles conceptually separate helps with diagnosis.

Networking, DHCP and student web access

The NetworkManager setting ipv4.dhcp-reject-servers is a reject list, not an allow-only-this-server list. It can block specified IP addresses or subnets; it does not, by itself, guarantee that only Sophos may answer DHCP. Truly enforcing that would require network-side controls such as DHCP snooping where supported. See the NetworkManager setting reference.

# Address, route and DNS actually received
ip -4 addr show
ip -4 route
nmcli device show | grep -E 'DHCP4|IP4.GATEWAY|IP4.DNS'

# Find the NetworkManager profile and its rejected DHCP servers
nmcli -f NAME,UUID,DEVICE connection show --active
nmcli -f ipv4.dhcp-reject-servers connection show 'PROFILE_NAME'

# See the documented option and its format
nmcli connection describe ipv4.dhcp-reject-servers

Before Sophos handled web filtering, we used SquidGuard with category-based blocking lists. Keeping those lists and software current became increasingly difficult as maintenance of the upstream project declined. The move to firewall-managed filtering removed a recurring maintenance burden.

OpenLDAP: accounts and groups

One of the most important agreements is that a user's uidNumber and gidNumber resolve consistently on the file server and the clients. NFS permissions depend on those numeric IDs, not the names displayed by ls.

The Sophos firewall provides DHCP and authenticates students against the school's LDAP directory when they first open a web browser. It also applies website blocking and filtering policy. The amount of filtering depends on the student's class, using the graduation-year group identifiers already held in LDAP. One directory therefore supports Linux login, file ownership and group-based browsing policies.

Sophos, LDAP and differentiated filtering

Why we abandoned 192.168.1.x

Our original network used 192.168.1.0. Teachers and students occasionally brought old home routers to school to use as inexpensive switches, not realising that their DHCP servers were still enabled. An unexpected DHCP server could hand out its own gateway and DNS settings, causing chaos. Diagnosing the failure was bad enough; finding the physical router responsible could take much longer.

The school now uses 10.10.10.0/23, covering addresses from 10.10.10.0 to 10.10.11.255. Student-owned laptops and other guest devices are generally assigned 10.10.11.x addresses. Those addresses are within the same /23 range; the address pattern alone does not imply a separate VLAN.

Moving to the 10.x.x.x private address range made collisions with routers still using their usual home defaults much less likely. It was not a complete security fix: a rogue DHCP server can cause problems on any subnet. On our managed Linux clients we also configure NetworkManager to reject DHCP offers from known unwanted servers, while the Sophos firewall is the school's intended DHCP server.

Our actual LDAP suffix is dc=lorien, with people under ou=people and groups under ou=groups. To make the examples reusable, the samples below use the fictional suffix dc=school,dc=example.

One historical quirk is worth documenting: the distinguished name of a person uses their full name as its cn RDN, although the account also has a separate short uid. A new installation might prefer uid-based DNs, but the samples below intentionally reflect our model.

dn: cn=Demo Student,ou=people,dc=school,dc=example
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: Demo Student
sn: Student
givenName: Demo
uid: demostudent
uidNumber: 36142
gidNumber: 2027
homeDirectory: /lorienNet/classes/class2027/demostudent
loginShell: /bin/bash
# userPassword is set by a secure provisioning process, not published here.

Student primary groups use the graduation year as the numeric GID: class2027 has GID 2027, and class2028 has GID 2028. Staff use a separate primary group (currently GID 500). Student UIDs are unique identifiers and do not encode a class or year. Preserve them when migrating data.

dn: cn=class2027,ou=groups,dc=school,dc=example
objectClass: top
objectClass: posixGroup
cn: class2027
gidNumber: 2027
memberUid: demostudent

The group memberUid list represents supplementary membership. The primary group is determined by the user's gidNumber, so do not rely on memberUid alone to enumerate everyone whose primary GID is 2027.

Our ldap_admin_flask application handles new students and staff, password changes, groups, user deletion, group audits, and Excel exports by primary group. Account changes can create and check the home directories at the same time. It has saved a considerable amount of repetitive LDAP work.

SSSD on Mint clients and the file server

SSSD connects Linux authentication and name resolution to OpenLDAP. It is installed on the lab clients and also on the file server, so a given UID and GID have the same meaning on both ends of the NFS connection.

The following is a recommended secure starting example, not a literal copy of the school's current configuration. Use your own certificates, hostnames, LDAP paths and restricted service account. Test connectivity to both servers before switching authentication over.

[sssd]
config_file_version = 2
services = nss, pam
domains = SCHOOL

[domain/SCHOOL]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldaps://ldap1.school.example, ldaps://ldap2.school.example
ldap_search_base = dc=school,dc=example
ldap_default_bind_dn = cn=readonly,ou=services,dc=school,dc=example
# Supply the secret securely: never publish a real credential.
ldap_default_authtok = REPLACE_WITH_SECRET
ldap_tls_cacert = /etc/ssl/certs/school-ldap-ca.pem
ldap_tls_reqcert = demand
cache_credentials = true
enumerate = false
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell

Use chmod 600 /etc/sssd/sssd.conf with ownership root:root. On Ubuntu/Mint, install and configure the SSSD LDAP, NSS and PAM integration packages, and check the effective NSS/PAM configuration. The correct final settings depend on your release and login manager.

getent passwd demostudent
id demostudent
getent group class2027
sssctl domain-status SCHOOL
sssctl user-checks demostudent
journalctl -u sssd --since '30 minutes ago' 

At the school, we have previously had a configuration with certificate checks disabled. That should be understood as a security weakness to address, not copied as a teaching example. Cached credentials can help during a directory outage, but a missing NFS home may still prevent a useful desktop session.

NFS: the central file tree

The principal shared filesystem is /lorienNet, stored on ext4 on the main server. It includes staff and student homes and a separate public sharing area. There is no need for each lab computer to store everyone's home locally.

/lorienNet/
├── classes/
│   ├── class2026/
│   │   └── examplegraduate/
│   └── class2027/
│       └── demostudent/
├── staff/
│   └── examplestaff/
└── public/

On the server, export the appropriate tree to the trusted lab network. This is an illustrative /etc/exports line, not the school's literal export definition. Check the NFSv4 namespace and your network ranges before applying it.

/lorienNet 192.0.2.0/24(rw,sync,root_squash,no_subtree_check)

root_squash is the sensible default; avoid no_root_squash for an entire student network. The example's 192.0.2.0/24 range is reserved for documentation and will not be your actual subnet. With NFS sec=sys, trusted clients can assert numeric identities, so limiting export access and securing client machines matter. NFSv4 with Kerberos would provide stronger identity assurances, but involves considerably more infrastructure.

sudo exportfs -rav
sudo exportfs -s
sudo systemctl status nfs-server
getent passwd demostudent
id demostudent
ls -ldn /lorienNet/classes/class2027/demostudent

The shared public directory is intentionally different from private home directories. A broadly writable area needs its own permissions, ownership and cleanup policy. Never treat it as a confidential submission folder.

autofs: mounting only when needed

We use autofs to make the central share available on Linux clients. The client path remains /lorienNet, matching the homeDirectory attribute held in LDAP. This is an important simplification: each new student needs a home directory, not a new mount rule.

The following is one possible direct-map setup. Substitute your NFS server name and verify that the exported path is visible as shown. Other valid NFSv4 export-root layouts require a different server path.

/-  /etc/auto.nfs --timeout=300

/lorienNet -fstype=nfs4,rw,hard,_netdev,vers=4.2 nfs1.school.example:/lorienNet

sudo systemctl restart autofs
automount -m
ls /lorienNet/classes
findmnt /lorienNet
nfsstat -m

Our clients have used NFSv4.2 with large transfer sizes. Defaults are normally a good starting point: measure before adjusting rsize or wsize. A hard NFS mount can block a process during a server outage; this is normally preferable to silently losing writes, but it must be understood when investigating apparently frozen desktop processes.

Home directories and yearly groups

Each student's LDAP homeDirectory points to their class directory, such as /lorienNet/classes/class2027/demostudent. The graduation year remains fixed as students progress through school: class2027 remains class2027, rather than being renamed with each school year.

Make homes during account provisioning and verify ownership before students log in. A local pam_mkhomedir policy is not automatically a safe substitute for creating server-side directories on a squashed NFS export.

sudo install -d -m 0750 -o demostudent -g class2027 \
    /lorienNet/classes/class2027/demostudent
getent passwd demostudent
ls -ld /lorienNet/classes/class2027/demostudent

A new school year involves bulk-creating accounts, setting primary and supplementary groups, checking home ownership, and retaining former students' work according to school policy. In our arrangement, student accounts are retained for approximately twelve months after departure, while staff files may need longer retention. Exact disablement and deletion procedures must also account for privacy and school policy.

Samba for Windows and Macs

Linux lab computers use NFS. Windows and Mac devices can use Samba/SMB instead, which is a better fit for their usual file-sharing tools and avoids assuming their local numeric UID conventions match Linux. The main server was rebuilt with Samba in standalone mode in 2026; integration with Active Directory is a separate, ongoing design direction.

Do not copy an invented Samba authentication configuration from this article. For a new deployment, decide first whether accounts will be managed by Samba locally, by an AD domain, or through another supported integration. Existing LDAP identity and filesystem ownership must be reconciled with SMB access, not assumed to happen automatically.

There is also a public shared area used for exchanging files. Public write access is a deliberate policy choice and must not be confused with private student or staff homes.

Student login, desktop management and SSH

The lab clients use Mint and a graphical login. SSSD supplies the identity, while PAM handles authentication and session setup. Local policy includes application launchers and browser-cache placement, keeping disposable data off the main NFS homes where practical. We also use centrally managed desktop applications and occasionally an AppImage when a suitable packaged version is unavailable.

SSH is restricted to administrators on student machines. The previous version of this article described LDAP-stored SSH public keys and allowed students to connect by SSH; that was not an accurate account of the deployment. A simple equivalent policy might use an administrative allowlist, adjusted to your actual users and management approach.

PermitRootLogin no
# Replace with actual administrator accounts, and test access first.
AllowUsers schooladmin
# Set authentication method according to the school's policy.

When changing SSH restrictions, keep a console or another working session available. On our lab clients the most important point is that student access to the desktop does not imply access to SSH.

Backups, failures and monitoring

Our main server is backed up using rsync to other storage. LDAP also has a replica, which protects availability rather than historical data. Restorable copies of LDAP data, filesystem snapshots or backups, and periodically tested recovery procedures are separate requirements.

We monitor the machines using straightforward tools: iostat, nfsstat, iotop, logs, and scripts run from cron. We have also planned daily temperature records for ageing NUCs, whose fans and thermal paste need attention after years of service. This is a description of the estate, not a claim that Prometheus and Ansible are deployed everywhere.

We have had actual NFS and LDAP disruptions, including a server incident in June 2026, and a failed older server in July. Those experiences reinforce a simple rule: write recovery commands down and test them before you need them.

What I would improve next

There are worthwhile improvements without pretending they have already happened:

• Secure LDAP transport throughout: eliminate any remaining disabled certificate checking and verify the authentication path end to end.
• Review NFS identity trust: consider Kerberos-backed NFS where its operational cost is justified.
• Explore Active Directory integration: make Windows/Mac access easier while preserving the existing Unix UIDs that own files.
• Systematise client configuration: Clonezilla is effective for imaging, but configuration management could reduce drift between images and routine updates.
• Make restores routine: periodically rehearse file and LDAP recovery on spare hardware or isolated VMs.

I would not replace the working directory with a new identity suite simply for elegance. After many years, the numeric IDs and the data they own are more important than the label on the directory software.

A small diagnostic runbook

These commands are useful on Mint and Ubuntu; substitute names for your own environment. They are deliberately diagnostic rather than commands that alter LDAP or erase data.

# Network / DHCP
ip -4 route
nmcli device show | grep -E "DHCP4|IP4.GATEWAY"

# Identity
getent passwd demostudent
id demostudent
getent group class2027
sssctl domain-status SCHOOL

# LDAP connectivity (supply trusted CA and valid hostname)
ldapsearch -x -H ldaps://ldap1.school.example \
  -b dc=school,dc=example -s base dn

# NFS and autofs
automount -m
findmnt /lorienNet
nfsstat -m
sudo exportfs -s      # server

# Logs and load
journalctl -u sssd -u autofs -u nfs-server --since today
iostat -xz
nfsstat -s           # server
iotop -oPa

There is no magic configuration file that makes a school network reliable. It is the agreement among the LDAP directory, numeric IDs, server-side file ownership, NFS export, client mount, login configuration and backups that makes the arrangement work.