System Administration: On using BASH, vi and no aliases
-
I was lucky enough to get my first IT job (rather than as a developer which I had done previously) as a Solaris / UNIX System Administrator in the early 1990s. Surprisingly, many of the lessons that were passed down to me from my mentors in that role when I was still a teenager have stuck with me and have formed much of the basis for my practices in systems administration. I find it interesting how many lessons I learned then seem to have been relatively unique and are often not taught still today.
One lesson I remember well, I still remember my mentor speaking, was the importance of using generic, standard, vanilla tools for our administration tasks. The temptation is obvious, download the latest, coolest tools, third party add ons and such. Our experience as end users suggests that we should go out, look for software, try all kinds of different things and use the stuff that is right for us, is just the right tool for the job or makes us productive. End users spend a huge amount of time tracking down and selecting their personal toolset.
System administrators are not end users, however. Our needs are quite different and we need to think differently about how we use computers.
End users can spend a lot of time tweaking everything that they do to be just as they like it. Their focus is on their own productivity. System admins cannot. Our focus is not productivity but is, instead, on reliability and availability. Need a different mindset.
So why would a system admin use bland, generic tools like BASH, vi and avoid making aliases for common tasks? Why not move to a handy modern shell, why not use nano to make text editing easier, why not go find some amazing utility that puts a handy new interface on our tasks?
Because, as my mentor liked to point out, those things are great when you have time to set them up, but that's not what matters. What matters is how much we are able to work when things go wrong. And when things go wrong, the tools that we use will often not be determined by us and setting them up will not be an option. When push comes to shove, we need to be able to work on the systems as they are, not as we can tweak them. A system admin earns their value when the system is on fire, not when things are pristine and relaxed. The opposite of an end user.
How this plays out, or could play out, is varied. It might be that we are stuck working on servers that we are not used to or have not seen before, it might be that we switch jobs or departments or a new policy comes out that forces us to stop using a tool, it might be that we have to train or mentor someone else or follow guides written by others. Becoming depentant on custom modifications or uncommon tools puts us at risk. Risk of not knowing how to use the available tools, not knowing what tools to use or just being slow and figuring out basic administration skills under pressure rather than when things are healthy.
Specifically, having started in the UNIX world, tools that I was told to always use were the default system shell, the vi text editor and to avoid aliases. The advice is much broader but these were common examples of things that people were easily tempted to modify (at the time.)
It was a sensible lesson and one that I came to appreciate some seven years later. At the time I was working as the head of IT for a sector at the world's largest manufacturing company. I got a call that manufacturing was down because one of the UNIX machines that controls the environment was not working and no one could work on it. So I went down to work on it myself.
It turned out to be an issue that could be resolved only in an emergency environment where the only available tool for text editing was vi, the much maligned universal UNIX text editor. It turned out that no one in the facility knew how to use it. Even by that time, over a decade and a half ago, replacements for vi were so common that most people had never actually used it. We got the system back up, and all was well.
As an example, vi is important because it is the base text editor available on every UNIX system. Not just Linux or Solaris or something old, but everything. Everything installed thirty years ago, everything installed new today. In an emergency, it is the one text editing tool that you are be certain is going to be available to you. And contrary to popular belief, quite often it is the only one available even in production working environments.
Over twelve years after that anecdote about vi in the manufacturing facility took place, I was on an online forum, much like this one, and had to help a manufacturing company on the other coast deal with a similar issue. After much discussion, checking invoices and such, we actually determined that the same aged Solaris server tied to the same equipment had been sold, shipped, set up and was still running and still had the same issues and still required the same knowledge and experience to support. I assume it is still running today. That other shop invested a large sum of money into deploy "new to them" a system with only vi as an option.
It may sound like an issue people would not have today, but they truly do.
Using base tools is important from a career perspective as well. It is rare that as a system administrator on an admin team that you will want to request special tools just for you or that you will be allowed to customize the server environments. In smaller shops you may be allowed to do this, but in many you will not. Even if only for reasons of respect, you want to be well versed and able to work in standard shells and tools when interfacing with coworkers. The majority of the UNIX world still expects the majority of tools to be standard ones. Not using them daily will put you at a disadvantage socially, if not technically.
The same, of course, is true in the Windows world. The culture is quite a bit different and the need for third party tools for many tasks is higher and the need for additional tools to make things "easy" is less. Or it was. This is changing as Windows moves towards GUI-less administration and will soon, very likely, have the same stigmas and tool availability issues that UNIX has long had.
As a system admin, it is important not to think of ourselves as end users, but as a different type of user where we have to adapt to the system rather than making the system adapt to us.
Part of a series on Linux Systems Administration by Scott Alan Miller
-
Great points. Even tho I like to use nano whenever it's available, that doesn't mean I can't use vi. The basics really are essential. If nothing else knowing how to do a quick edit, save and exit in vi is one of those essentials you'll need at some point.
-
I've always used vi as it is standard across the board from all flavours of UNIX and Linux. I know it'll always be there for me.
-
Knowing how to use
viand choosing to use something better for daily tasks are not mutually exclusive like you are trying to paint here.Additionally, you are calling, or at least grouping,
nanoas uncommon which is far from the truth. It is a core RHEL option, and beyond minimal installs, it is also pre installed. -
I generally use vi but, as I have mentioned in the past, there are some distributions that change how vi works by default which makes it frustrating to use, going from Fedora-esque distributions to Debian-esque distributions is painful as far as vi is concerned, at least for me.
-
@coliver Yes, like Ubuntu.
-
I can hack my way through working with vi... but I need to learn it better.
-
@JaredBusch said:
Knowing how to use
viand choosing to use something better for daily tasks are not mutually exclusive like you are trying to paint here.Additionally, you are calling, or at least grouping,
nanoas uncommon which is far from the truth. It is a core RHEL option, and beyond minimal installs, it is also pre installed.That's true, you can know both. Although it is very rare that someone maintains a proficiency in vi while using something else normally.
Nano is relatively rare. Have working in many UNIX environments and tens of thousands of servers, I'm not sure we've had it once until RHEL 7. (I definitely see it on my desktop installs, just servers, I mean.) Did RHEL 6 have it by default?
But, even if it is becoming more standard to include it, it's not ubiquitous. It was extremely common to have Joe installed back when I ran into the need for vi, but it wasn't there. People even in the 1990s often argued that emacs and joe were so common that vi wasn't needed to be known any longer. And that's why no one knew it.
Nano is certainly common today. But in an emergency, you don't know that it will be there. At least nano on RHEL is in /usr/bin. Traditionally those tools were not kept available to single user environments.
-
Scott, let me tell that you're completely right.
I use vi as my primary editor, with little customization.
Vi is everywhere, from the ESXi busybox to router firmware CLI… and I really like how it works.
My only non-standard temptation is ZSH, but I usually can do almost everything with plain bash (set -o vi, of course). -
@Francesco-Provino said:
My only non-standard temptation is ZSH, but I usually can do almost everything with plain bash (set -o vi, of course).
zsh is better than most because it is backwards compatible with bash, so nearly everything that you do is transparent between them. It uses the same conventions and everything, so that falling back to bash you barely notice.
-
The thing about vi is that at first you hate it and then later, you still hate it but you forget that you are using it.
-
@StrongBad said:
The thing about vi is that at first you hate it and then later, you still hate it but you forget that you are using it.
I never forgot I was using it. I learned it, and can use it, but I will never like it.
-
I've applied this same philosophy with my use of Windows server (and desktops). Try my best whenever possible to use the default tools, etc. An example, I never changed the default start menu while so many comrades usually would change the start menu back to an older view.
-
Very good read. I'm sharing your philosophy and like I said yesterday, I'm a console fetishist. You just need to use what you have when you are in a recovery console or when your server just does not have access to that NFS export or SMB share where all your fancy tools and scripts are.
I think it's way more important to understand how things actually work. This will also help a lot when it comes to tracking down errors.
PS: This is not about necro'ing an old thread, but the topic just came up once more.
