Our local changes to standard (Ubuntu) installs are easy to forget

October 13, 2024

We have been progressively replacing a number of old one-off Linux machines with up to date replacements that run Ubuntu and so are based on our standard Ubuntu install. One of those machines has a special feature where a group of people are allowed to use passworded sudo to gain access to a common holding account. After we deployed the updated machine, these people got in touch with us to report that something had gone wrong with the sudo system. This was weird to me, because I'd made sure to faithfully replicate the old system's sudo customizations to the new one. When I did some testing, things got weirder; I discovered that sudo was demanding the root password instead of my password. This was definitely not how things were supposed to work for this sudo access (especially since the people with sudo access don't know the root password for the machine).

Whether or not sudo does this is controlled by the setting of 'rootpw' in sudoers or one of the files it includes (at least with Ubuntu's standard sudo.conf). The stock Ubuntu sudoers doesn't set 'rootpw', and of course this machine's sudoers customizations didn't set them either. But when I looked around, I discovered that we had long ago set up an /etc/sudoers.d customization file to set 'rootpw' and made it part of our standard Ubuntu install. When I rebuilt this machine based on our standard Ubuntu setup, the standard install stuff had installed this sudo customization. Since we'd long ago completely forgotten about its existence, I hadn't remembered it while customizing the machine to its new purpose, so it had stayed.

(We don't normally use passworded sudo, and we definitely want access to root to require someone to know the special root password, not just the password to a sysadmin's account.)

There are probably a lot of things that we've added to our standard install over the years that are like this sudo customization. They exist to make things work (or not work), and as long as they keep quietly doing their jobs it's very easy to forget them and their effects. Then we do something exceptional on a machine and they crop up, whether it's preventing sudo from working like we want it to or almost giving us a recursive syslog server.

(I don't have any particular lesson to draw from this, except that it's surprisingly difficult to de-customize a machine. One might think the answer is to set up the machine from scratch outside our standard install framework, but the reality is that there's a lot from the standard framework that we still want on such machines. Even with issues like this, it's probably easier to install them normally and then fix the issues than do a completely stock Ubuntu server install.)


Comments on this page:

By Ian Z aka nobrowser at 2024-10-14 13:02:53:

This is why, despite internet advice to the contrary, when there is a choice of doing customizations either by editing foo.conf or by adding a foo.conf.d/99-local.conf bit, I prefer the former (and record it in git).

And historically, I think the foo.conf.d/ directories were introduced not for the purpose of manual customization, but to smooth the way when another package baz wanted a say in foo configuration so it dropped a foo.conf.d/10-baz.conf bit.

-- Ian

By Emacs User at 2024-10-14 14:39:26:

I use Emacs' org-mode to help. Not only taking notes of changes but often tangling configs with Babel, literate programming style.

Thanks to past advice from cks, we use RCS religiously across our systems. And we have a script "nr" which we've trained ourselves to use whenever we make changes in a "vanilla" directory. The "nr" script creates the RCS subdirectory as a symlink to /local/RCS/{flattened-pwd}/

eg.

 $ cd /usr/local/etc
 $ ls -l RCS
 lrwxr-xr-x  1 root  wheel  25 Mar 11  2023 RCS -> /local/RCS/,usr,local,etc
 $ 

Future uses of "ci ... {config}" in that directory then means that the RCS-ed copy of {config} is stashed outside of the OS's standard directories.

The flattening of the source directory name means that "ls /local/RCS/" is a quick way to show where local changes were made -- assuming all on the sysadmin team was meticulous about using "nr" and "ci" for logging changes.

eg.

$ ls /local/RCS
,boot
,data,www,apache,root
,data,www,root
,data,www,root,librespeed
,data,www,root,simplesamlphp,config
,etc
,etc,mail
,etc,pam.d
,etc,ssh
,usr,local,etc

$

Speaking just of decustomization, it actually should be surprisingly easy these days. I’m not aware of any distros that do this by default, but in principle you can just leave /etc empty. Entirely empty, not even including /etc/passwd or /etc/group! You only need to put config files in there when you actually want to customize something, so everything that ends up in /etc is a customization that you should back up and keep when you rebuild the machine.

See https://0pointer.net/blog/projects/stateless.html

Written on 13 October 2024.
« Some thoughts on why 'inetd activation' didn't catch on
We have lots of local customizations (and how we keep track of them) »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Oct 13 23:08:32 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.