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?"

Comments

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.

Bad idea... here's why

[TheSkyIsPurple]

>I don't have the weight to convince management to deploy alias scripts to all of the servers we support.

I've only watched one episode of Alias, but it didn't really draw me in. But, irrespective of that, I don't know why you'd want to put the scripts to copyrighted shows on your servers, especially if they are publicly available.

Maybe it's a Linux thing? people just want to do everything on Linux =-)

what are you asking?

[corbettw]

Are you asking how to set up an alias kind of like this:

ruptime=`ssh $1 '/bin/uptime'`

Then when you want to check the uptime on a remote box, you run:
ruptime remote_host

And do all this from a Windows box?

If that's the case, you should use Putty. The Putty configuration can be set up to run a remote command, linked to a given hostname. Then when you open Putty, just select the proper 'alias' from the list, just like you would any host.

I would expect SecureCRT has a similar function, but I haven't used it in a few years.

Re:what are you asking?

[eric2hill]

I use SecureCRT on a daily basis.

When you're editing the properties of a session, you can check the "Logon script" box and choose a logon script to use for that session. You can do that either per-session, or as a global setting so it happens for all of your sessions.

Your logon script can contain as many aliases as you'd like.

bleh

[Intangion]

some of the ask slashdot questions are really getting stupid...

do you guys think i should wear a blue shirt tomarrow? ive heard alot of people like blue shirts but i was curious if anyone knew of any problems wearing blue shirts?

I get what he wants.

[Valdrax]

Okay, I get it now. Here's what the guy wants:

He has no power to install his favored command aliases on all of the machine he has to administrate. He wants to have an SSH client (that he can run on Windows to connect to the Linux machines) that will interpret what he types and substitute aliases so that he doesn't have to set up his favored commands every time he logs into a system.

I don't know if you can set an SSH session into a line-based instead of keystroke-based communication mode. By default, it sends messages to the remote server after every keystroke and not after enter is hit at the end of a line -- otherwise using curses-based applications would really, really hurt as would using tab-completion, vi mode, and other advanced shell features. If this can't be done, then a client couldn't interpret your commands before you send them.

I don't forsee anyone providing this functionality because the demand is so low. This is the kind of thing that the remote end is expected to handle for you.

Re:I get what he wants.

[Valdrax]

The guy's not too stupid to figure out how to copy his aliases everywhere. He doesn't have permission to do so. That why both he and I both said so (including in the text you quoted).

I am all too familiar with his conundrum, especially when it comes to being forced to work with inferior tools. I work in an environment where I am responsible for keeping production systems running, and I don't have admin install privileges. Even our admins don't have the political power to change things without serious peer-review and management approval. This is the way and enterprise-level IT organization has to work. Making changes in production without verification and authorization can result in revenue loss or loss of data that you may one day be required by court to cough up.

Re:I get what he wants.

[CarrotLord]

If this really is what he wants, and it seems the most logical interpretation, then I'd suggest simply placing a script like .my_aliases on each server, and then running ". .my_aliases" after each login.

However, I have a STRONG aversion to lots of aliases, particularly for someone learning systems administration. When I first started using unix, the sysadmins in the Engineering department had set up a bunch of DOS-like aliases on our servers, so we would feel more at home. We came to depend on these, and a few non-DOS aliases too. I think some were there to make csh look more like sh, or vice versa.

The problem came when I went to use a unix machine in the Computer Science department, which didn't have these aliases (I guess the CS students were considered clever enough to learn Unix, whereas the Engineering students expected everything to be DOS). I was lost for some time, and needed to copy the aliases file over (and just finding that took me ages, as I wasn't familiar with /etc), in order to use the system, even for things like ls. I then asked my local guru about this, and he recommended that I just stick to the defaults, so I'd be able to move between systems without pain.

Since then, and 10 years of sysadminning later, I've got a huge aversion to customising environments. For eg, I always use sh (well, ksh), as it's always available and is always installed in the root filesystem. Likewise, the reason every sysadmin should know vi is because it's always there (apart from the fact that it's better for quick edits of small files than emacs). I tend to avoid vendor-specific tools, as I have needed to move between Solaris, IRIX, Linux and BSD too often to "reprogram" my fingers each time. Obviously, it depends on your situation, and now that I have been using Solaris exclusively for about three years, I've become a little less flexible, but generally, I try to stick to the lowest common denominator, and just be really good at it.

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.

Re:Actually it seems like he is looking for is....

[runswithd6s]

The type of interface you're thinking about is something along the lines of a text-based MUD or IRC client, where your commands are hooked BEFORE being sent to the server. I personally don't know of any, but can't imagine that it hasn't been considered. Currently, OpenSSH uses the "~" character to indicate that an SSH command will follow. "~C" drops you to an "ssh>" prompt to add things like tunneling while you're still connected to the host. Evidently, the ability to intercept input and redirect it to a local function is already built in to the software. IIRC, you can change the command character if "~" is too clunky for you. The next task is to extend this to provide an alias function. For example, you could bind "~a" to a theoretical "run-alias ALIAS ARGS" command. The desired effect is to output the expanded or constructed shell commands to the host. You will likely want to bind an interpreter to the run-alias command rather than creating your own. Find a license that is compatible with the OpenSSH client or whatever client you might be using.