Linux system administration is best described as automating Linux system administration. Sometimes these tools are yours and yours alone. Other times, utilities are shared with others on your team, shipped, or offered as a service. This comes from the most casual understanding of the UNIX philosophy: Using small, purpose-built tools, and joining them in new, powerful, and unexpected ways. These can be complex commands, which become one-line scripts, which become multiple-line scripts. Some scripts you will keep and share, some you will forget about at your next coffee break.
[ You might also enjoy: Using Bash for automation ]
I can't throw around phrases like UNIX philosophy without remembering back to a time where not everything was Linux, or even when all Linux systems one might be responsible for were the same distro. The only confidence I have in the future is that it will be different. Therefore, some historic tricks for portability—forward and backward—are due, especially when they don't cost you anything.
This is all to say that the more standard tools I know about, the more powerful my throwaway commands become, the faster I can write them, and the quicker my clients get their actual problems solved.
I seldom go a month without picking up some new technique or trick while shoulder surfing someone else's style on the command line. COVID times and remote work make this more difficult, so I'd like to thank Ken Hess for introducing me to or reminding me of five commands I didn't know that well.
It's very common in build scripts to have to generate, for example, paths that describe a platform, a build environment, a yum repo path, etc. Usually, I'd use
uname -p to get the processor type, but
arch is faster to type and self-documenting. Thanks!
GitHub has much code in the form of:
This could all be replaced with:
Just last week, I was programming an API to create PTR records. It was in an Ansible role for a reasonably well-known IPAM, but if I had to do a bulk import with generic DNS tools, I'd be using
nsupdate. This command would be very handy. Quick code example:
[jwarnica@lappy ~]$ nsupdate <<EOF update add `arpaname $ipaddr` 86400 IN PTR $(hostname -f). send EOF
This would be easy enough to use inside a loop for when I might have a bunch of new IoT devices, VMs, or a fleet of laptops to install and already have their hostnames/IPs in a simple CSV file or otherwise generated them.
Bash can't do floating point math, so additional tooling is needed for scripting. With that said,
bc --expression got me thinking about how to script
dc, which is, of course, is possible.
I'll forget the details before I use it, but I'll remember forever this "ah-ha!" moment that
dc can be scripted.
While I don't want to sound like a high school math teacher, there are environments where one doesn't have their pocket supercomputer handy or even access to gnome-calculator. Or you simply want to save the five seconds and use the interactive
dc without taking your hands off the keyboard to use either the mouse or phone.
One of my annual volunteer days is doing the results for a running relay race. After years of optimizing the dumbest thing that works, this is now mostly data entry of times. With a laptop on my lap sitting in a car, this is the opposite of ergonomic, but I could at least make it one-handed by mapping the numeric keypad . to a :. Within X11,
xmodmap was the tool for this mapping. While hardly a bowling ball, Canada continues to make advancements in human-computer interaction.
Saving 10 minutes a year is hardly a reason to learn a new tool (or is it? -- ed). Mapping keys could be the difference between being able to type and not. Maybe in most places in the world, the US-104 keyboard isn't standard, and/or the local language isn't unaccented English.
dumpkeys has a close friend called
loadkeys. Together these make unusable consoles usable, and every Linux distro installer for decades has relied on them.
/proc is considered by the Linux kernel developers to be stable, and I'll grant
/proc/version is likely very stable, but I don't quite trust them. I sometimes use systems that don't have the Linux-only
/proc, anyway. The
uname command, being part of POSIX, will work anywhere.
I might find this command useless now because I now know about
arch, but it's still a goto command just to verify where I am. And scripting examples abound. A random example from Fedora's
case `uname -m' in x86_64 | ia64 | s390x | ppc64 | ppc64le) QT_PREFIXES="/usr/lib64/qt-3.3 /usr/lib/qt-3.3" ;; * ) QT_PREFIXES="/usr/lib/qt-3.3 /usr/lib64/qt-3.3" ;; esac
[ Improve your skills managing and using SELinux with this helpful guide. ]
Are these tools revolutionary? Not at all. What they are is solid, ubiquitous foundations for the daily work of millions, and will be for decades more. That makes them utilities worth keeping in mind the next time you sit down at a Linux system.