Our (Unix) staff groups problem

July 28, 2017

Last week, I tweeted:

The sysadmin's lament: I swear, I thought this was a small rock when I started turning it over.

As you might suspect, there is a story here.

Our central Unix systems have a lot of what I called system continuity; the lineage of some elements of what we have today traces back more than 25 years (much like our machine room). One such element is our logins and groups, because if you're going to run Unix for a long time with system continuity, those are a core part of it.

(Actual UIDs and GIDs can get renumbered, although it takes work, but people know their login names. Forcing changes there is a big continuity break, and it usually has no point anyway if you're going to keep on running Unix.)

Most people on our current Unix systems have a fairly straightforward Unix group setup for various reasons. The big exception is what can broadly be called 'system staff', where we have steadily accumulated more and more groups over time. Our extended system continuity means that we have lost track of the (theoretical) purpose of many groups, which have often wound up with odd group membership as well. Will something break if we add or remove some people from a group that looks almost right for what we need now? We don't know, so we make a new group; it's faster and simpler than trying to sort things out. Or in short, we've wound up with expensive group names.

This was the apparently small rock that I was turning over last week. The exact sequence is beyond the scope of this entry, but it started with 'what group should we put this person in now', escalated to 'this is a mess, let's reform things and drop some of these obsolete groups', and then I found myself writing long worklog messages about peculiar groups I'd found lurking in our Apache access permissions, groups that actually seemed to duplicate other groups we'd created later.

(Of course we use Unix groups in Apache access permissions. And in Samba shares. And in CUPS print permissions. And our password distribution system. And probably other places I haven't found yet.)


Comments on this page:

This is why I prefer having LDAP-backed users and groups, e.g. FreeIPA. You can describe group/account usage in description -attributes, query members/groups, add more attributes to model your dependencies etc. Also you should be keeping config files in version control, so that you can easily grep for (hopefully) unique identifiers, like users or groups.

LOL'ing at "this is why I prefer LDAP groups" - our groups in LDAP are also a historical mess. (We avoid using them on our Jnix systems, for this and other reasons cough sssd cough.) Those features are great though, if people use them.

Written on 28 July 2017.
« The continuity of broad systems or environments in system administration
The differences between how SFTP and scp work in OpenSSH »

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

Last modified: Fri Jul 28 02:49:44 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.