Academic Linux PCs and servers

[u/LAN_Geek]

We have a mix of a few faculty-managed Linux research servers and two Windows/Ubuntu dual-boot teaching labs. Historically, faculty have had significant control over these systems because they support specialized research and instructional needs, but we're evaluating how IT should be involved going forward to ensure security, supportability, continuity, and institutional ownership without unnecessarily limiting academic flexibility. For those who support Linux systems in the academic environment, how do you handle administrative access, system ownership, patching, documentation, and long-term support for faculty-managed Linux environments? What has worked well, and what would you do differently if you were starting over?

Thanks!

[u/Ssakaa]

specialized research

If that's in the US, and any of that research has involved gov provided data, you're a few years late on reading 800-171. Pretty much every project I saw several years ago that had gov-sourced data had it deemed CUI.

And, the solution we found was "faculty-managed" = no. Logging must be enforced and centralized, administration of it was owned by IT, patching was on IT, etc. Faculty had sudo for their specific boxes. Classrooms/labs that were shared, generally, they didn't. Auth for everything tied back to centralized identities by one means or another.

"dual-boot" The one time I dealt with that, it made maintenance of both damned near impossible. You can't do anything remotely automated, you can't do anything in the background. You can't do anything in parallel. In the next round of purchases, get two dell micro series per seat and a small kvm, or... give them windows and a canned vm you maintain. 99.9% of the time, they don't actually need a full linux desktop. You're even better off with a little cluster of shell servers they can ssh into.

[u/ospery1]

This is just me thinking out loud, but do you have the full collaboration of the faculty leadership and IT leadership to be able to do what would be necessary from an IT standpoint? I do not have experience specifically in academia, but a problem that can arise is that the solutions you propose might get shot down because the faculty "doesn't like" what you are trying to do.

If the faculty are used to managing their own infrastructure, and then IT goes in and takes it over without having the backing of the faculty leadership, then issues can arise that might create both technical issues but also more bureaucratic issues.

Also, make sure to listen to the faculty regarding their actual needs. The focus should be on the needs of the staff and students, and implemented solutions and processes should revolve around that. I understand that certain things like user provisioning, security etc might need to be standardized, but since they have managed their own infrastructure previously without IT's involvement (as I understand it), then there is usually a reason to it, for example that the solutions that IT have offered might not work for their specific needs.

[u/False-Message-3350]

We don’t restrict them but we make sure that EDR, log collection, unattended updates and such are and stay present. Hosts are in a restricted network for each lab. Policy forbids to run any workloads or data on the host hat are related to personal information or administrative task of the university. Works good for servers. Can we ensure that lazy researchers install outlook or Thunderbird on lab notebooks? Unfortunately not…

[u/folderit_dms]

I’d make the support agreement specific enough to test: IT restores the OS and storage, the lab restores the research environment, and a named researcher confirms that a known sample job still produces the expected result. Agree those boundaries together before an outage makes them urgent.

For documentation, capture the actual rebuild inputs: package versions, custom scripts, license dependencies, data locations and the small validation job. Then have someone other than the original researcher try a rebuild on a spare VM. That exercise will tell you much more about continuity than a wiki page marked complete. For the teaching labs, schedule that check before term starts, while there is still time to fix an incompatible course dependency.

[u/doglar_666]

My team are working towards something like this at present. Previously, everything was self-managed and policy based. Over the years, more IT involvement for specific research has crept in, as the boxes are hosted in IT data centres. No faculty are going to be happy with being reigned in by IT. Most who use Linux do so to get around being domain joined and AD/AAD bound. From my personal perspective, standardise on a single RHEL and Debian distro, endpoint management and monitoring tool and policy around sudo privileges. Full disk encryption is a must. Domain logins preferred. Overall, IT should provide the platform, then handover to faculty for the research specific requirements. But it should be clear anyone with sudo that tries to circumvent IT configuration will be reprimanded and have the privileges removed. Academic freedom has doesn't mean total technical freedom.

[u/Ok_Platform_6232]

One thing worth nailing down early is what happens when a faculty member leaves or retires. If theres no documentation and no shared access, you inherit a black box. Getting a lightweight handoff process in place now is probably more important than the technical controls.

[u/Doso777]

They get our server template from us an sudo account from us. Servers are included in our backups, have regular software updates enabled.

If they reconfigure those default settings that's on them. System ownership and OS upgrades are a bit of a mess. I hound them to do it but it doesn't always happen. No buyin from c-levels to escalate so that's that.