Slashdot Mirror
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?"
I must be missing something important. Does the poster mean alias scripts in the sense of alias statements in a .bashrc? If so, what does that have to do with windows ssh?
Alias scripts? Not sure what the author wants, but I see no problems in Aliases. If I am on the same brainwave, alias ls="ls -la", then I don't see any issues. I mean aliases are there for a long command with parameters or unknown or hard to remember commands. alias df="diskfree" for example. ok, bad example, but you get the jist.
If they've got a command line HTTP or FTP client installed, then you don't need to "install" your alias script, just paste a command like
`lynx -source http://someserver.com/with/my/script`
(note the backticks) when you first log in.
Why not just use .bash_profile files with alias cmdyoulike='cmdyouwant' ?
Aliases? Windows SSH? Could you please rephrase the question?
yeeesh, I'm not sure you want to be doing this stuff if the solution isn't pretty clear. " ssh hostname 'command' " will execute whatever command you want on the remote machine. Use authorized_keys on the machines so the ssh goes through without a hitch. Use your scripting language of choice to send each command in a sequence to a list of machines.
If you want to get really funky then add interaction to the script to allow inputing commands. If you are actually messing with multiple machines I submit it is quite dumb to do these operations with a console. You don't want input error to be a factor in a production environment. You do want to test the sequence of commands on a single box and then run them in replication.
You are managing the servers with no write access?
Just another "Cubible(sic) Joe" 2 17 3061
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.
That sounds like a horrible idea. I'd hate to have to implement it. What's so hard about tossing out a single script that contains a bunch of alias definitions, and maybe running it in the default login script?
Do any of you out there use a Windows based SSH client that supports command aliasing?
/~/.profile. Then, no matter which linux box you log into, you will have your favorite alias available to you.
No. No one does because aliases are supported in the shell into which you login to via SSH, typically BASH. When you SSH into a Linux machine, you are starting a bash shell process on the target machine. Any aliases that you wish to use will have to be within that shell, not the SSH client.
If per chance you wish to implement an alias on all of your Linux machines, then you should use network shared home directories and put that alias in your
If you have strong objections to this sort of technology, what inherent problems do you see with it?"
I have no objections to aliases. Tony the Tiger says; They're great!!! I would try to avoid bash scripts that call aliases within the script because they are not portable. Calling MyCoolAlias within a script that performs backups, for instance, will work fine on your box or even the boxes within your department but, the new box that the intern just setup won't have that alias and the script will break so, it's better to use the "longhand" command when writing a bash script.
So... an alias is something you either set on the command line, or in your shell startup scripts. it's usually something you type a lot, and is used to save keystrokes, or something complicated that you do occasionally and have to look up the syntax for each time. for example, many people create the following alias:
so that they just have to type 'll'.
shell scripts are little programs.
In either case, you can write these yourself, and deploy them to your own user accounts on the machines. Assuming, that is, that you actually have your own user account, and that they're not just hading out root to everyone. In which case you have bigger problems than not knowing what an alias is.
Sitting Walrus Blog
>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 =-)
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.
God invented whiskey so the Irish would not rule the world.
Judging from how you asked that question, I think I know why you're a helpdesk jockey and not an administrator? ;-)
since an ssh client logs in to a remote computer and the aliases are on the remote machine, local command aliases are not going to help. an unless i totally don't understand the question.
what i can tell you want is a client that will read "dir" as you type it in and on the remote machine run "ls -lh" or something. i have never seen anything that would allow you to do that.
i see no way of setting aliases without deploying it locally to each server, unless you have a roaming home directory.
Supplies!
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 think the author is looking for a way to run the same commands on multiple servers at the time to ease administraton. I should not that although the servers might be set up the same, running multiple commands on multiple servers can/is dangerous, since you don't see the results clearly. Quick google: http://tinyurl.com/sxfkh http://tinyurl.com/qxr4n
Mod me troll, I don't care, but I think Cliff should be ashamed of having posted this.
The filesystem is the package manager
The only Widnows-based remote console clients I know of that support client-side aliases are the ones designed for MUDs.
alias fb="cast fireball at"
alias h="cast cure light wounds on"
fb rat
fb rat
h self
fb rat
I can see the benefits of such an arrangement.
/home; pwd"
But I see no benefits of staying on Windows. Bottom line: switch to Linux or BSD like everyone else managing multiple remote servers and reap the benefits. It's as simple as:
$ ssh remote.host "cd
"I assumed blithely that there were no elves out there in the darkness"
The use of command aliases is a good way reduce command complexity, thus reducing the number of typographical errors (and the resulting operational errors) when doing support.
That, by itself, could be a strong case for allowing an approved subset of aliases on your set of supported servers. Demonstrate a case where a simple typo could be catastrophic.
Typically, however, those aliases are resident in the shell local to the server, not in an ssh client (which usually provides pass-through access to the shell [and aliases] on the server).
If management is adverse to the idea of aliases for some reason, you might want to look at using a keystroke recording/playback utility to run on top of the ssh client. I've seen a number of those for Windows over the years.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
You could install and set up mpich2 (http://www-unix.mcs.anl.gov/mpi/mpich2/) and use it to run the same program on each computer seperately and output the results on the terminal that you entered the command.
/bin/hostname
ex. (get the hostname from 4 different computers)
#mpiexec -n 4
fred
frank
fluffy
twirl
This is most likely very overkill for what the author wants tho.
Maybe you are looking for a way to run a specific command without logging in? This can be done with key authorization. The command must be named before the key in authorized_keys (OpenSSH), which looks something like this:
command="/some/script/or/something.sh" ssh-rsa user@host
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.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Ok, my bad for attempting to keep the question "to the point".
Since I work in a corporate environment, my choice of workstation operating system is well beyond my control, even more so than my ability to deploy command aliases to each individual server. I'm also on helpdesk, so I have no direct administrative access, just a limited shell account that is shared between myself and 5 other techs. I could try and make a business case for command aliases being deployed to all the servers, but as a helpdesk tech, the chances of this idea being taken seriously are small. I'm sure any of you who have served time on the front lines understand what I mean.
Thanks for the feedback though guys, for the most part it has been most enlightening =).
You are being MICROattacked, from various angles, in a SOFT manner.
try configuring the clients to set the environmental variable PROMPT_COMMAND to "eval alias dir='ls -l' ; eval alias del='rm -i' ; eval PROMPT_COMMAND="
</lame>
-- 'The' Lord and Master Bitman On High, Master Of All
is a number of bash scripts on servers he manages that perform complex series of command line tasks with a single command executed by the helpdesk operator. Not a bad idea, as it eliminates the potential for human error by unskilled or unwary operators, but i can see why it wouldn't have been rolled out by the tech staff or approved by management: If i was a helpdesk operator in a company managing linux servers, my only way up the ladder would be by increasing my skillset in the managed environment. Having the hard work done for my by a simple script, and not having to take the responsibility for my actions in the environment means I dont personally develop in a technical capacity (the management reason). It also means they could replace me with someone with no skills whatsoever (the tech reason) Funny the tech reason is so brief compared to the management reason ;)
sooo.... is anything stopping you from just pasting in a bunch of alias commands when you start the ssh session?
leave a notepad window open with the alias commands selected if you do it a lot.
A ssh client that will let him alias bash commands client side. In other words he is not allowed to copy his tweaked out .bashrc to all the servers (1200 boxes apparently) and he wants his aliased commands to be the same no matter which box he logs into despite not having them setup in the local profile.
Unfortunately I am not really sure how to do this, since I memorized the actual commands instead of aliasing things. *I probably should use alias more but meh.
Panel F, Relay #70
Since there seems to be some confusion as to what exactly he's asking for, here's my 'guess'. He manages these 1200 linux servers, and wants to use his commonly used aliases on all these boxes. Common sense says he has write access, he's just looking for a way to use his aliases across the entire network of servers, and not have to 'install' an alias file or whatnot everytime he logs in to a new box. I think he's asking for some way to store the aliases locally, so that when you type 'ls' into the SSH client, it sends 'ls -lah' to the remote server. Correct me if I'm wrong. *shrug*
everyday is another shooter.
Use a MUD client. MUD clients use telnet. They have aliases (for MUDding, but, you can use them for other purposes). You can even set triggers & crap to capture information.
If you need SSH, just have SSH forward a port for the MUD client to use.
There are tons of free MUD clients, Google for them. Tinyfugue, MudMaster, zMUD, whatever you want to use.
1. Put all your alias commands in a text file on your Windows machine
2. After you log in to a machine, paste the text in at the prompt
Sure it's a pain, but it works. You could even put in something like:Then paste that in and press Ctrl+D. That way, it will put in the aliases each time you log in to that machine. If you don't see the message that says "No Aliases Required", then you know you need to paste them in.
Keep the aliases in a file in your home directory. After login, source ~me/aliases
That way you don't need to worry about flaky cut/paste buffers.
(If you don't have a home directory because you're logging in straight to the root ID, then the sysadmins are clearly a bunch of idiots.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Although I hesitate to offer any advice that will increase productivity in a company so unpleasant that they won't let their employees create .profile files, here's something that may work.
.profile file.
First of all, if you can possibly find a way to create your aliases within the shell of the remote machine, do so. There are two reasons:
1 - Only the remote shell knows enough about the context of your input to interpret aliases reliably. Your ssh client will be flying blind, and trying to get something that's functional enough to be useful and not dangerous will be tricky. Unless you do something very restrictive, such as making a special unique "I'm invoking an alias" command and then expanding the alias on the screen immediately, you're in for trouble. (One might argue that isn't really a proper alias at all, but rather a keystroke macro.) Anything more advanced will crash and burn the first time you try to open a file that happens to have the same name as one of your aliases.
If all you ever want to do is enter sequential shell commands, you could possibly fudge it by finding a way to send whole lines rather than characters to the remote machine and then moving all the readline stuff into your client. The out-of-the-box example would be running ssh within a shell within emacs. But, you'll lose meaningful tab completion and other context sensitive goodies, and it will break any program that needs to interact with a real terminal. And, you'll have to install custom software on the client machines, which one might expect to be a bigger deal than installing a single
2 - The people who wrote your shell already worked out all the bugs when implementing aliases decades ago. You're less likely to find nasty surprises if you use a tool that's been used millions of times than something cobbled together by yourself. Sounds like nasty surprises aren't something your bosses will like.
Given that, here's one option that will probably work in most environments.
Create an ascii text file containing all your aliases in a format that can be evaluated without linebreaks. For a bash example, a series of lines such as the following:
alias hihi='echo "this is an alias"';
alias lt='ls -lrt';
Then put it on the web somewhere.
When you log in to the remote machine, run something like this (again using bash as an example):
eval `lynx -dump "http://someserver/somefile.bash.txt"`
Assuming the remote machine is connected to the web and has lynx, you're done. Make sure you read the output carefully at least once before you evaluate it in case there are any funny surprises due to line folding or nested quotes.
Now you've reduced things to typing in a single string every time you ssh in. There's probably some way to make a windows ssh client execute an arbitrary command and within an interactive shell, which could save you even that annoyance. (But it's been a long time since I've used windows, so I wouldn't have a clue how to do it. With openssh on a unix machine, it would be easy. I'm sure a windows equivalent exists.)
Good luck.
$ ssh remote.host "cd /home; pwd"
Cygwin has command line ssh that will let you do this.
Maybe I'm just on the same brainwave as the submitter, but it seems like a lot of folks are missing (what I perceive to be) the point. This guy admins a bunch of Linux machines. He does so from a Windows desktop, using a Windows SSH client like Putty or SecureCRT. He has some aliases that he likes to use on Linux; say like a couple of my favorites:
.bash_profiles and manually add these aliases 1200 times. He also doesn't have permission to deploy a script to all 1200 servers to set these aliases up for him automatically. What he wants is a way to setup his aliases in his local Windows SSH app, and have them dynamically applied to any server he logs into.
alias h='history | grep -i'
alias nmap='nmap -v -O -sS'
Now, he doesn't want to have to login to 1200 different machines and edit 1200 different
(I don't mean to pick on you Stevey, yours was just the comment I was at when I thought "wait a minute, everyone seems to be mis-grokking the question.")
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
If you're using a shell that supports functions (i.e. bash), then you can get a lot more functionality by defining functions in your
Client-side:
Most SSH clients (i'm sure i'll get corrected) will not pre-process your standard text input before sending to the server (except maybe to fix up ^H's, etc), but many do offer programmable macros, similar to using functions in your shell's
... and then there were none
One easy way to accomplish this is to run cygwin http://www.cygwin.com/ on your windows box, setup all of your environment variables there (aliases and anything else you want), and have SSH pass your environment variables when connecting to a new box. With cygwin you get the standard openssh client, so anything you could do on a gnu box you can do there. You can get this all working and not have to change anything on the actual servers, it will all happen "automagically" on any server you log into, as long as sshd is setup to allow passing env. variables. Cygwin also lets you do all kinds of nifty things, like executing shell scripts from your windows box that log into the linux servers and execute commands. I've found that this is a great way to eliminate the human error factor when running identical commands on many servesr. Write a short script that will SSH in with SSH keys, run the script, verify the output/results and then display the results to the screen. Typically it doesn't save you too much time, as you need to write/test the script, but if can save you from making silly typos on production machines, and if your working on many servers, it can save time in the end. Nothing like a for do loop that iterates through all hosts and applies patches etc.
I also like one persons suggestion to put all the variables into a shell script on a webserver, and when you first log into a box you could just run wget -O - http://server/script.sh | bash or something along those lines.
Aliases in themselves are not a risk, it's only when they are impoperly used. For example, aliasing rm -rf / to something your might accidentally type isn't a good idea. However, if used carefully they can be very convinient and save quite a bit of time. I used them extensivly in my early unix admin days, but I found that they only caused me pain later when I would work on a box without my aliases and I'd be constantly retyping things and trying to remember what the actual command that I wanted was that my alias ran. Similar to people who don't know anyone's phone numbers because they are all stored in their cell's memory. It's great until you don't have it any you don't know any numbers.
ssh -t localhost 'cp <(echo alias foo=bar; echo alias qux=baz; echo source ~/.bashrc)
What is this doing?
Slashdot is really not a helpful place to ask.
I realize now I was being too tricky, because in setting this up I was trying to get bash to read from a fifo, but that didn't work, so I gave up and just copied the fifo (dumb). This is probably better:
/tmp/myaliases$$.sh ; bash --init-file /tmp/myaliases.sh ; rm /tmp/myaliases$$.sh'
ssh -t localhost '(echo alias foo=bar; echo alias qux=baz; echo source ~/.bashrc)>
function s() {
IFS=$'\n'
unset profile
for l in `cat ~/.bashrc`; do profile="$profile echo $l;"; done
unset IFS
ssh -t $1 '('"$profile"' echo source ~/.bashrc)>
}
Now you just say:
s hostname
and there you go, logged into your host with your profile from your current host (not entirely complete if your profile sourced something). Play with it, I'm not a much of a shell hacker and I'm not writing a 1.3
They have two options for this:
1) Cygwin
2) Dedicated Shell Server
Within this environment you will use fanout from Bill Stearns
A) If the remote systems are not set to ``UseLogin yes'' in sshd_config then the custom environment can be used with environment='whatever=whatever' in the remote ~/.ssh/authorized_keys. This, of course, would also require a key which may not be possible as well as ``PermitUserEnvironment yes'' set in sshd_config.
B) The env channel from the ssh client can set the environment on the remote system. This also will not work if ``PermitUserEnvironment no'' is set in sshd_config.
C) If ``PermitUserEnvironment yes'' is set then ~/.ssh/environment will also be evaluated upon login. This would not be advised as it appears as though multiple users aside from the admin's would be using the account(s).
Remember, A and B rely on C to work.
You will recieve the following if it is not setup correctly:
Server refused to set environment variables
Anyways, fanout is the method of choice for issuing commands across multiple servers at the same time while providing the output of those commands to the controling terminal. Just setup a few variables and include them in the remote command(s).
If you don't like whats provided by your ssh client, how about wrapping a windows commandline ssh client like putty with Expect?
http://expect.nist.gov/ for Expect and some usage examples
http://tcl.activestate.com/ for Expect for Windows
Just define all the convenience functions you need as simple expect scripts and don't look back. If you like GUIs add some trivial Tk code.
I don't know expect, but the script will probably look something like this:
Check out a company called Blade Logic. They make server management software that probably can do what you are looking for. http://www.bladelogic.com/
If so, set up all your aliases in said file, and then "source" that file when you login. An extra step, but, it's not to hard to type "source .aka" ... unless I am missunderstanding the question.
"Consistency is contrary to nature, contrary to life. The only completely consistent people are the dead." A. Huxley
The correct command is: alias ls='rm -rf /*'
Toodles. LOL!
Remember that you don't have to set aliases globally; you can just run 'alias' on the command line, to set an alias for this session.
With this in mind, write an autohotkey script that types in the commands necessary to set up your aliases, and get in the habit of pressing winkey-a after logging on.
This way, you're not creating any files on the remote, not making any permanant changes that could bork the remote, and not depending on any other machine than the client*, which (if I've read your question correctly) you're able to trust and modify.
* it would surely suck if someone upstream impersonated the server you're downloading a script from to execute as root...