Hello everyone
I am finishing a script allowing me to purge logs on multiple servers, i have one last pb with the ssh command.........it is throwing me the following error :
tcgetattr: Inappropriate ioctl for device (full screen in attached file 1, full script in attached file 2)
It seems like i am unable to process command through SSH....;
conf: redHat 5.5 64 bit and GNU bash 3.1.17 on all servers, .sh script
thanks for you replies
If you want the commands to run remotely, they must go to the ssh commmand line or the ssh stdin.
Often, there is no point in a full ssh login, no need for a remote tty, so I:
( . . . . )|ssh user@host ksh
and write a ksh script to stdin.
Hi DGpicket
Thanks for your reply:
If i put my remote server subroutine in a test.sh with 1 parameter and did this :
ssh jpassema@SERVER < test.sh $LE_PATH ?
Not quite! < just sends the file down to run on whatever shell logs in, the argument does not make the trip. You can copy the script down there and then call it with an argument, or merge the argument into the script and pipe it all down to ssh. I recommend specifying the shell command as the recipient, so there is no full login. "ssh host" is a login, but "ssh host bash" is a pipe to a remote bash command running on host with no controlling terminal, much like a cron there. You need to build your own environment, as you can see if you run "ssh host bash -c set".
Not quite. How about:
ssh jpassema@SERVER exec /bin/sh -b "$LE_PATH" < local-script.sh
By the by, it's usually not a good idea to name things test. UNIX already has a test utility that someone else might confuse it with.
I do not think you need exec or full path for sh, and exec just saves a fork. What does -b do, put that value on the command line (hope it's a well behaved value)?
A fork can be a thing worth saving, but yes, it's not strictly necessary.
The full path for a shell is just a habit of mine.
That should have been -s, pardon me. Don't know how I managed the mixup when I was doublechecking in man pages as I typed!
-s forces it to read from standard input, which makes it treat parameters as script parameters $1 $2 etc instead of file names. It's a very portable option which seems to have been inherited from ancient bourne into bash, dash, ash, zsh, csh, ksh, and beyond.
Neat, command line parameters for /dev/stdin as a script! I'd use ksh or bash, whatever my login was, so testing is easy.
Does sh honor #! in this case? I am guessing not, it is part of exec()!
Certainly not. Since you get to run your shell of choice from the get-go that's not too bad.
Well. I have the same problem while trying to copy some web content from one server called Server2 to another one called Server1. The script runs on Server2:
#!/bin/bash
#
# copying.sh
path=/var/web/somewhere
login=user
su $login <<EOF
ssh -tt server1
sudo chown -R $login:$login $path/somefolder1
cpdup -C -v -d -I -i0 server2:$path/somefolder2 $path/somefolder1
sudo chown -R ftp:ftp $path/somefolder1
exit
EOF
The script does what it's expected to do, but the output gets instantly messed up with this tcgetattr: Inappropriate ioctl for device warning which is really annoying and I want to get rid of it. The point is that the destination folder on Server1 is a vsftpd-folder that has ftp:ftp ownership. So I have to change it to user:user first, cpdup it, then change it back to the original ftp:ftp. Looks kinda messy, I know. But how is it possible to make it simpler while preserving the original ownership since it is necessary for the user to get to Server1 through vsftpd from time to time? Thank you.
Well, ssh without a remote command and maybe especially with -t or -tt thinks it will be somewhat like an interactive session, but your stdin is a flat file. Why do that? a simple "ssh user@host 'commands'" is usually sufficient, with no remote tty or terminal control error messages.
Thanks,
I missed I'd better just ssh to the server rather than su and ssh (it's a key-based authentication only):
update (sorry, missed some parts of the updated script)
#!/bin/bash
#
# copying.sh
path=/var/web/somewhere
login=user
ssh -t $login@server1 "
sudo chown -R '$login':'$login' '$path'/somefolder1
cpdup -C -v -d -I -i0 server2:'$path'/somefolder2 '$path'/somefolder1
sudo chown -R ftp:ftp '$path'/somefolder1
"
Now it goes with no warnings though I still need at least one -t while ssh-ing to have a tty-assignment to sudo since it ends up with "sudo: sorry, you must have a tty to run sudo" otherwise.
Yes, and often you cannot ssh to root. Is server2 where you start out? Can you ssh in as ftp, or even simpler, scp in as ftp?
Yes. Root is not allowed to ssh. And I used to use another script before which I created to mirror the content. It is an ftp-based one. And it's way simpler than using ssh in this case. A corresponding part of it is:
lftp -u $login,$password server1 <<EOF
lcd $path/$login
mirror -e -a --parallel=1 --reverse -v .
by
EOF
Much shorter and clearer I guess. The scripts reads the password from a hidden file. But the point is that it is not that safe as ssh.
I would think that root is not allowed to ssh in as root, but should be able to ssh out and scp between two IDs on two hosts. Trust is not symmetrical. That's why I think one scp can do this.
Well, the point is that I need a real mirroring tool rather that just a secure copy method. With cpdup (secure) and lftp (open) you indeed have the ability to mirror the content skipping unchanged remote data the way I mentioned earlier in this topic. Can I do the same with just scp meaning that I do not want to always recursively overwrite the remote copy?