As a system administrator, I work in many different environments

March 11, 2023

Many people work primarily or entirely in a single environment (for example, their work laptop). For many people, this makes it quite worthwhile to significantly customize that environment, carefully curating things like their editor, setting up an advanced shell configuration, and so on. I'm not one of those people. It's true that I have a very customized X desktop, but it's more that I work through that environment than that I work in it. My actual work takes place in a disparate set of environments on a disparate set of systems.

I do a fairly large amount of work (as much as I can reasonably manage) on either my own desktop or in my primary environment on our Ubuntu servers, where I have a NFS mounted home directory, X forwarding, and so on. In both of these environments I have a custom shell, Git aliases, a relatively evolved GNU Emacs configuration with multiple packages, LSP servers for various things I use, and so on. But my energy to keep several copies of this environment in sync has limits and so I don't go too deep into various other things I could customize.

(As a practical matter much of this environment is also relatively old, inherited from a past era when I dealt with many fewer systems, and I might not recreate it if I was starting from scratch today.)

However, I also do a lot of work in additional environments. This can be as myself on systems that don't NFS mount my normal home directory, as root on various different systems that have my regular environment, as root on systems that don't have my regular environment, and sometimes as other accounts on some of our systems. Often these environments are shared with my co-workers, who don't necessarily agree with my tastes. In all of these other environments I have limited ability to customize things and often limited energy to make and update extensive customizations.

This is a common pattern in system administration but not a universal one. In this day of fleets of cattle that are run by orchestration systems, a system administrator may spend much of their time in their own desktop environment, editing code and orchestration configurations locally and then pushing them out; ssh'ing in to some random remote server to do something on it would be an anti-pattern that's used as rarely as possible. But this isn't my pattern of system administration, and instead I follow the much older one of working on all sorts of accounts on all sorts of systems.

All of this creates biases in what I'm interested in learning and customizing today. I need to maintain at least a basic ability to function effectively in a random login on a random, mostly or entirely un-customized Ubuntu server. And because I regularly work in those environments, there's a higher payoff for learning things that apply across all of my environments than things that only apply in my primary high-touch ones, unless it's an activity that I'm only likely to do in the high-touch ones (such as doing significant amounts of programming).


Comments on this page:

By Ian Z aka nobrowser at 2023-03-12 12:09:25:

One of the ways I try to deal with this is doing the absolute minimum as root. For example to edit config files I try to force myself to copy the file in question, edit it in my familiar environment (emacs) and then "take" it with root (this is more involved than `cp` , due to:)

https://openwall.info/wiki/internal/accessing-users-files-as-root-safely

This way I can leave the root account almost completely uncustomized.

The other way I have to attack these problems is syncthing, though firewalls / packet filters do get in the way.

-- Ian

By Andrew at 2023-03-12 12:57:47:

In ye olde days of ~2006 I had a coworker who used vim, as I did, and who left his custom vimrc in the root profile of our servers. I didn't mind the green-on-black color scheme, but he was a gamer who remapped movement from hjkl to wasd, and the functions that would normally be on wasd to hjkl. Which was real fun when I would try to scroll down a few lines in a config fully and delete a few lines instead.

By Phil! Gold at 2023-03-13 09:01:14:

I deal with this through configuration management.

We don't use root for anything. Instead, we have a set of accounts with sudo access, one for each member of the team. Those accounts are always local to each system, with local home directories, and are managed by Puppet. Given that infrastructure, it's not too hard to add the ability for people to drop personalized config files into the Puppet source directories so everyone can have their own custom environment, even on arbitrary remote servers. (Even the "pet" servers use Puppet to establish a standard baseline. Given that baseline, the "cattle" servers get all the customization, too, even though we don't need to make use of it there.)

By Arnaud Gomes at 2023-03-14 03:55:25:

We do customize root's environment on our servers, and it's actually quite easy. We make use of the environment parameter in SSH authorized_keys files (this has to be enabled in sshd_config) to identify the user from their SSH key. Our common bash configuration then looks in a user-specific directory and sets up a number of tools to look for their configuration there if it exists.

All of this (including per-user conf files) is managed with Puppet, but you could use any other tool to distribute the conf files.

Written on 11 March 2023.
« Some bits on Linux NFS(v3) server filesystem IDs (and on filehandles)
Getting a Python 2 virtual environment (in 2023's twilight of Python 2) »

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

Last modified: Sat Mar 11 23:16:52 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.