How should IT support faculty-managed Linux servers and teaching labs?

Document the things needed to rebuild the environment, not just general descriptions. Capture package and OS versions, custom scripts, license requirements, data locations, configuration management, and a small validation job with an expected result. Have someone besides the original researcher rebuild it on a spare VM. Define support boundaries in advance: IT restores the platform and storage, while the lab restores and validates the research software. Also plan for faculty departures so systems never depend on one person’s undocumented access.

Dual-boot teaching machines are difficult to patch and manage remotely because neither operating system is reliably available for background maintenance. If possible, separate the environments with dedicated machines, managed virtual machines, or shared Linux servers accessed over SSH. For the remaining labs, test the full setup before every term. Keep the number of supported distributions small, use full-disk encryption, and tie access to institutional identities where practical.

Get faculty and IT leadership aligned before changing anything. If people have managed their own systems for years, there is usually a reason, such as missing tools or inflexible policies. Agree on the actual research and teaching requirements first, then standardize the controls that genuinely need to be uniform. A written service agreement should define who handles the OS, hardware, backups, incidents, and research software.

For servers, we require the security agent, centralized log collection, unattended security updates, backups, and placement in an appropriately restricted network. We also prohibit using research hosts for personal or general university administrative data. A standard OS image and approved management tools make this much easier. Researchers can customize the application stack, but changes that break required security controls should result in the system being repaired or administrative privileges being reconsidered.

A useful model is for IT to own the platform while faculty own the research environment. IT should control the base OS, identity integration, logging, endpoint monitoring, backups, encryption, and patching. Researchers can retain sudo on designated systems when their work requires it, but that access should be documented and subject to clear security requirements. For regulated or government-funded data, centralized logging, access control, and documented ownership may be mandatory rather than optional.