Anything wrong with having aliases on a production server?

Question

On my local server, I create aliases like these to speed up my work:

alias bashrc='vi ~/.bashrc;source ~/.bashrc;echo bashrc has been sourced'
alias bashprofile='vi ~/.bash_profile;source ~/.bash_profile;echo bash profile has been sourced'
alias aliases="clear;cat ~/.bash_profile|grep --color \"alias\""
alias home='cd;ls;pwd'
alias root='cd /;ls;pwd'
alias desktop='cd ~/Desktop;ls;pwd'
alias f='cd ..;ls;pwd'
alias ff='cd ../..;ls;pwd'
alias fff='cd ../../..;ls;pwd'
alias ffff='cd ../../../..;ls;pwd'
alias pa='vim /Users/nav/workspace/someproject/src/main/resources/application.properties'
alias sql="mysql -uSomeDB -p"
alias updatedb='sudo /usr/libexec/locate.updatedb'
alias node1='ssh -i ~/.ssh/somepem.pem ubuntu@vis.someserver.com'
alias datanode='ssh name@db.someserver.com'
alias zoostart='/Users/nav/prog/zookeeper-3.4.8/bin/./zkServer.sh start'
alias zoostop='/Users/nav/prog/zookeeper-3.4.8/bin/./zkServer.sh stop'
alias zoocli='/Users/nav/prog/zookeeper-3.4.8/bin/./zkCli.sh'

These shortcuts allow me to work faster, as I don't have to remember long lines and some of these aliases are just one or two characters long, so I don't have to type something long either, so I used some of them on the production server too, and that's a server the other developers use too. These shortcuts can be used by them too, as they do pretty much the same work.

My supervisor differs, and says that one should never have user defined aliases on a production server. He says it's wrong of me to "use the server as your plaything".

There was one instance I remember (in a previous company where nobody had any issues using aliases) when I created aliases on bashrc and we weren't able to log on to a server via ssh, but the solution to that was to keep aliases in bash_profile instead of bashrc. Apart from that, I don't see why one shouldn't use aliases on a production server as long as the other developers are informed of the aliases. What does the community feel about this?

Answer 1

In general, scripting common tasks in order to prevent mistakes and work faster is a good idea. As that I agree with your intention.

But I am shocked that you were able to make such changes in the first place on a production system. You apparently made these changes without talking to your team first. That does not seem like a professional administration culture. Ideally, you have some written or scripted procedure to set up and deploy that server. Either your adaptions are part of that procedure and are vetted by other team members, or your changes introduced unnecessary risk.

Recent high-profile examples of small mistakes by a single dev bringing down the whole production system include the Amazon AWS S3 outage (caused by a typo while using an internal administration tool) or the GitLab database outage (where a dev deleted the database, but confused a testing system with the production system). I highly recommend reading the GitLab post-mortem analysis. That you managed to break your SSH login is bad enough, and completely merits the supervisor's reaction.

Instead of defining your own aliases, set up a repository of administration scripts that everyone on your team uses. Unlike your aliases, these scripts can be version controlled, tested, documented, reviewed, and audited. Any knowledge you encode in these scripts also benefits your team members. This also avoids the problems of your aliases going out of date, e.g. I see that you have hard-coded various paths and version numbers.

Personal anecdote: I once had a coworker with many shell aliases. Watching them work on the console was magical. But when they left, and I had to go through their bash history in order to understand how they configured a particular server, I had a hard time following along. Of course the aliases weren't the problem – we as a team simply didn't value documentation and scripting enough. But when you write down everything that you do so that others can do the same, your personal aliases won't help them.

Answer 2

What does the community feel about this?

How is that relevant? Some will tell you to do it, some will tell you not to do it. Has your supervisor decided not to do it? ... then listen to your supervisor. You don't agree with your supervisor? ... then try to provide good arguments for how this is beneficial to everyone.

But here is how I read your question:

I did something good. Why don't you people see the light and agree it's a good thing? You don't agree it's a good thing? Well boo hoo... I'll ask what the community feels about this.

You caused a problem by using aliases and your supervisor took note and now he does not want you to do it anymore. That's a natural response. Protecting the production server is more important than you being able to work faster by a few seconds.

There is also a problem with aliases. People tend to remember the alias and forget the commands that are behind it. Install a new server and now you need to add the aliases to it so people can work the same.

I'm not going to tell you it's good or bad. You need to talk to everybody to see if they can use them too, what are the advantages and disadvantages. Then decide together. Whatever you then decide, you must accept (even if you don't agree with the rest of the team).

There is also a compromise: instead of aliases just install a script that takes parameters and does the same (something like prodScript zoostart, prodScript editprops, etc). You can then keep this in source control, you can make it part of the deployment, of the server setup, you have history versions, you can add a prodScript help parameter that explains each command, etc. People will still forget the commands behind the parameters but you will have just one source of truth if they need to look it up, instead of looking in bash_profile, bashrc, or whatever.

Just my 2 cents.