Customizing Debian-based Systems for an Organization

2023-07-06

Mention cloud-init.

It seems quite common for an organization — say a university — to want to provide GNU/Linux distributions configured/customized for the organization, particularly for using networked resources (e.g. NFS and authentication), and maybe local packages or ones outside the default set, either for accessing those resources or for convenience.

The way I’ve seen that done is to distribute ‘an image’ of, say, Ubuntu or a RHEL-based system like CentOS (before CentOS 8’s demise). The package set is potentially changed, there may be proprietary software installed,Such as for VPNs.

and default configuration files will be changed — this in what The University of X distributes as the ‘UoX Ubuntu image’, say.If you’re unlucky it’s produced by an external ‘partner’…

That has a legal issue as well as technical ones.

The legal one is that such distribution of Ubuntu would appear to be unlawful.But I Am Not A Lawyer.

There are trademarks associated with UbuntuSee, e.g., the Ubuntu ‘intellectual property rights’ policy (but please don’t use propaganda term ‘intellectual property’.)

(and other major distributions) which prohibit it without an extra licence to do so. Both Ubuntu/Canonical and CentOS/Red Hat have taken action on more-or-less innocent trademark infringement, as they must to avoid losing trademarks. (HPC cluster vendors that were providing customized versions of CentOS noted the problem when the rules changed.) Rebuilds of, say, RHEL scrupulously avoid mentioning Red Hat as well as replacing all the trademark-protected bits, and usually refer to ‘EL’ (‘Enterprise Linux’).

While you can avoid legal problems by avoiding all the trademarks with effort, the approach isn’t very satisfactory technically anyhow.

• It depends on doing an initial installation, and doesn’t configure a previously-installed system, like someone’s personal computer on which they may need to work — whether or not mixing personal and work use should be avoided;

• It’s likely only available as a single version of Ubuntu, or whatever, that may not satisfy a user’s requirements;

• Either the configuration doesn’t get updated when things change, may be clobbered by updates if auto-updating is actually turned on, or there needs to be some separate mechanism to update it. Any separate configuration management system like that needs managing too.The old “Now you have two problems…”.
  
  

Config packages

There’s a better way for dpkg-based systems, included in Debian and derivatives, though I don’t know whether it’s in any way an ‘official’ one. Native packages can provide decent configuration management on their own, and it makes sense to use them. The system is based on the config-package-dev development package and ‘file diversion’ implemented by dpkg-divert(1). It might have special appeal for a university, since it comes from MIT’s Debathena project,Originally a student project by Tim Abbott and co — could that happen at your university?

associated with one of the original campus distributed computing systems, Athena,CMU’s Andrew seems slightly to have preceded it.

now trading as Athena Computing Environment.

For all the things you want to configure, you make packages to put in an organizational apt repository. Users just need to add that repo and install the relevant packages or, probably, a meta-package to pull in suitable dependencies. That’s maybe three lines in a simple script to execute or cut-and-paste, either at the end of an initial OS installation or on a previously-installed system. Depending on the packages involved, the same thing might work for different versions of Debian (presumably stable and oldstable) and also for some version(s) of Ubuntu. Any subsequent changes are made by package auto-updates. If necessary, changes can be undone by un-installing the relevant configuration packages; they save the state of configuration files at the time the configuration packages were installed.For additional history and rollback purposes, it’s worth installing the etckeeper package for version control of /etc integrated with apt etc.

Setting that up requires some familiarity with Debian packaging to produce the configuration packages and repository, but it’s fairly a straightforward to do and decently documented. The config packages basically just update configuration files, either with appropriate editing or by copying in new files, and perhaps add dependencies to ensure required packages are present. It might also be useful to set things appropriately in the alternatives system (e.g. selecting either MIT or Heimdal Kerberos tools) and possibly mess with daemons.

While it’s not customizing for an organization, something I recently did provides a simple example which reminded my to write about config-packages. It just installs an amended version of the configuration file for libccid so that pcscd can communicate with recent/nascent free hardware and software security keys (Solo 2 and Nitrokey 3).See a bug report.

Arguably the file should be edited rather than replaced, but that makes it harder to deal with multiple versions.

A hook: cloud-init

At least some distributions, and typical virtual machine or container images, ship with a cloud-init packageSoi-disant ‘industry standard’.

to deal with initialization. That may be a useful hook for getting your config packages going.

RPM-based systems

Unfortunately, RPM doesn’t have the basic facility needed to do the same thing as configuration dpkgs.Somewhere on the Fedora devel list is a thread when I asked about it.

The best you can do is to hack configuration files in a package %postinst and try to preserve the original. (Obviously dependencies are no problem.) You might even be able to re-instate it in %prerem. However, the process is unclean and fragile.