Discussions about how to efficiently run Linux in corporate networks pop up from time to time.

Originally shared by birger monsen

Discussions about how to efficiently run Linux in corporate networks pop up from time to time. I worked on such a setup some years ago, so here are a few of the thoughts we used to build our system.

Merge into existing infrastructure

Existing infrastructure at our site used a PXE-booted BartPE (customized mini windows environment) app that asked the person at the console a few basic questions before starting installation of windows. We had the Windows guys modify their installer with a windows/linux choice, and if linux was selected the user was offered a possibility to override the swap partition size (default was computed based on physical ram and available disk). The BartPE installer then patched in a small partition with anaconda set up to do a kickstart install.

The support-people who handled on-site support for windows could easily be trained to handle any linux-related tasks as well. Mostly it was just installing or removing hardware, and with linux they didn't even have to worry about installing drivers.

We also used LDAP/Kerberos for centralized administration. We had our own OpenLDAP based server since we were uneasy about having all clients depend on AD as LDAP/Kerberos server. What if some Microsoft patch one night rendered all Linux workstations inoperable next day? So we set up our OpenLDAP with replication from AD, enabling us to use existing data in AD. Today we would probably have gone with direct attachment to AD, sine at least Fedora now works very well directly with AD through realmd and sssd (winbind not needed anymore) and can work offline if AD should act up.

Printing was greatly simplified since a 'follow me' print system was already used for windows. Using the same centralized user administration enabled us to just offer the follow me print queue and spool to existing print servers. Users then just swiped their card at any printer to fetch their documents.


Modularity

During kickstart we installed a bare minimum to enable people to start working. Today the list would be Gnome, Chrome, LibreOffice and Evolution. That way the workstation would boot and be operational within 10 minutes. after it was first PXE-booted for install. 10 years ago that was fast! Additional software to install was then determined based on LDAP group membership of the host. KDE was always installed as alternative desktop. For some departments the installation of the rest of the software could take hours, but happened in the background.

We mirrored all external repositories we used into our 'alpha' repos. We also had one repo for our own add-on modules. The Linux desktop team (all 3 of us) had workstations that got their updates directly from the alpha repos. When new updates didn't crash our PCs the updates were migrated to the 'beta' repos. Through AD/LDAP memberships 1 or 2 workstations at each department/faculty were set up to use the beta repos. The users of those workstations knew they had a responsibility to react quickly if something broke. After a week packages would then migrate from beta to prod and find their way to all workstations. This setup enabled us to run a bleeding-edge distro like Fedora safely across a whole university.

We didn't use puppet back then, but would definitely do it today. The puppet-server for your workstations should not be the same as for your servers. The whole philosophy is too different, and your rulesets should be have completely different strategies. On the other hand you may want to use the same puppet server for both Linux and Mac clients.


support

We decided that since gnome had facilities for centralized profiles that could do full or partial lock-down of the desktop as well as selecting profiles based on group membership it would be our 'supported' desktop. KDE would be supported in the sense that we would make sure it worked, but the help desk only had procedures for helping with gnome problems. KDE users would have to help each other. This worked very nicely since (as we expected) KDE users were least inclined to have any kind of centralized configuration. they wanted to tweak everything.

With fedora it was easy to let users have the ability to install any package they wanted from the pre-configured repositories. In our case that would be our own beta and prod repos.


conclusion

A system like this could be set up by 3 linux specialists, and could be run long-term by 2. Given a help-desk that could handle the easy problems as well as dispatching people for problems that needed hands-on the tasks for the linux desktop group were mainly
- test new hardware proactively
- create custom configurations for packages
- package software for our local repo
- 2nd level support