The Elusive Command Alias Function?

Meph_the_Balrog asks: "I work as a helpdesk jockey for a company that manages over 1200 linux based servers, across a huge area. Currently we use a Windows SSH client to provide remote server support, and I don't have the weight to convince management to deploy alias scripts to all of the servers we support. I admit this question may seem frivolous to some, perhaps dangerous to others, so I have a twofold question. Do any of you out there use a Windows based SSH client that supports command aliasing? If you have strong objections to this sort of technology, what inherent problems do you see with it?"

What kind of aliases?

[stevey]

I'm guessing from the mention of Windows that you're thinking of things like:

alias del='rm'
alias dir='ls'

Hard to say with such a vague question though, especially with the idea that the client must support the aliases. The clients I've used terraterm and PuTTY are the most commonly used, and putty at least doesn't support aliases. (Can't recall terraterm using them either, but I admit I didn't use it often).

Personally I think that having DOS-style aliases is a mistake. Even though they might seem helpful to users of DOS/Windows it can cause problems when people realise the commands, even aliased, don't work in the way that they'd expect.

Unless you could offer a 100% compatible environment it would be best to let people realise that Unix is different and work with it as it should be.

Re:I get what he wants.

[Anonymous Coward]

With good key management lots of role accounts are the right way to go. Create accounts for semi-root, one for read-only logs access, one for daemon control, etc. Give certain people different role access to different machines by copying their public keys appropriately and you have a very secure and easily managed infrastructure.

Problem is, I happen to like vi-mode bash (set -o vi) but everyone would kill me if I put that in a .bashrc file on a few hundred machines for the debug role account.

Ya dig?

Re:I get what he wants.

[Valdrax]

There are two scenarios that I can think of off the top of my head could prevent him from doing so:

1) He doesn't have permission to modify his own user account. Unlikely, but possible -- especially if /home is deliberately kept free of space or he's not given an actual home directory to prevent user customization and all he has is the shared shell resource scripts in /etc.

2) He's got to use several shared administrative accounts (like root or various accounts for specific services), or the account he has to use is shared with production processes that might be impacted by adding aliases willy-nilly without knowledge of the whole of all command runs by the system. That's bad security, but it's probably not his design.

I have to deal with both of these problems at my job. I don't have an actual home directory on most of our test servers due to a lazy IT department and immense bureaucratic red tape in getting it fixed, so I'm stuck using the main production user on the test box, and I can't customize it. In actual production, no one is allowed to use this particular ID for accountability purposes, but on a different system we all have to use a different shared production ID which hasn't been obsoleted to do anything. Both of these scenarios are irritatingly bad and beyond my ability to do much about.

At any rate, it's safe to assume from his description that he doesn't have permission to do what you suggested. Reread the article text. He's a "helpdesk jockey" without "the weight to convince management to deploy alias scripts to all of the servers [he supports]." The requirements presented explictly state that your solution is not allowed.

Sorry, try again. The real world of business sometimes sucks in ways that common sense suggests it wouldn't.