Compatibility lingers long after it's needed (until it gets noticed)

February 9, 2024

We have a system for propagating login and password information around our fleet. In this system, all information about user logins flows out from our 'password master' machine, and each other machine can filter and transform that global login information as the machine merges it into the local /etc/passwd. Normal machines use the login information more or less as-is, but unusual ones can do things like set the shells of all non-staff accounts to a program that just prints out 'only staff can log in to this machine' and logs them out. All of this behavior is controlled by a configuration file that tells the program what to do, by matching characteristics of logins and then applying transformations based on what matched. This system has existed for a very long time, probably since we started significantly using Ubuntu sometime in late 2006 or 2007.

Because this system is so old, it once existed in a world where we had a bunch of Solaris servers that users logged in to and the password master machine itself was a Solaris machine. These Solaris machines had quite different paths both for some user shells, like Bash, and 'administrative' shells like the program that told people this was a staff machine or their account was suspended (this was back in the days when you could reasonably use shells for that sort of thing). When we propagated login entries from these Solaris machines to our new Ubuntu machines, we needed to change these Solaris paths to Ubuntu paths, and by 'we' I mean that our password merging and mangling program did. For reasons beyond the scope of this entry, these Solaris path rewritings are specified as transformations in the configuration file, although in practice we applied them all of the time.

We long ago stopped having Solaris login servers or using a Solaris machine as the password master (that ended at the start of 2010, which is later than I expected and had vaguely remembered; at that point our Ubuntu environment was several years old). At the point where our password master became an Ubuntu server, all of that remapping of Solaris shell paths was unnecessary. However, our configuration files for password mangling have faithfully preserved those boiler plate directives for the Solaris shell path rewriting:

@hdir:  newhomedir /u fixlocalshell fixadmshell
@all:   fixadmshell

These 'fixlocalshell' and 'fixadmshell' directives are the lingering remains of that Solaris compatibility. They've been unneeded for more than a decade, but we never really noticed them and so they stayed. They would still be an ignored layer of now-unneeded compatibility if I hadn't wound up re-working some of the documentation for the program today, and in the process realized that we could and should take them out.

(We should remove them from the configuration file because they're confusing noise, especially if you don't work with this program very often and so you have to try to remember what all of the directives do.)

Are there other places with lingering pieces of compatibility with Solaris and other now-gone things in our environment? Probably. We don't particularly look for these things, and often our eyes probably just pass over them as a background thing that we're accustomed to. It's how things are done, and we don't think too much about it on a day to day basis (in other words, it's sort of a superstition, and also).

Written on 09 February 2024.
« Accidentally making windows vanish in my old-fashioned Unix X environment
My plan for backups of my home machine (as of early 2024) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 9 23:22:10 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.