Ssh on ping result?

I still haven't had chance to read the entire Debian manual, which I promise I will do as soon as I can, and I will start putting info back into this forum.

However, for the mean time, could someone please help with a small script? I understand what I've got to do and how to do it, but I'm struggling with getting the syntax right.

I have a loads of nodes I need to connect to from time to time, but I'm never sure if they're alive. So instead of ssh'ing and waiting ages to either get a connection, or not, I'd sooner start with a ping, if there is a good response, set off the ssh. At this point I might have 10 terminal sessions open for different nodes, so I want to automate as much as possible.

So the pseudo would be:

User types:
con user@192.168.xxx.xxx

#!/bin/bash
Strip ip from $1 to str-IP
Start loop from 1 to 10 (arbitrary):
Create a bln-Connection variable and set value = False
Start loop from 1 to 10 (Arbitrary)
--Ping the str-IP
--If response | grep includes ttl or time, or ms I guess:
----set bln-Connection = True
----exit the loop

If bln-Connection = True:
--ssh $1
else
--echo "The blooming thing is down again."

Something like that. I hope that's clear enough, and I know I'm using about 3 different languages, just none of it bash!

Many, many thanks.

Why not use ping's return code as intended instead of grepping text?

#!/bin/bash

for X in "$@"
do
        X="${X/*@/}"
        ping -c 4 -w 1000 "$X" || echo "The blooming thing is down again"
done

Or use the respective option to ssh :

ssh -oConnectTimeout=1 user@FreeBSD
ssh: connect to host freebsd port 22: Connection timed out

I've actually had some time to look into this today, and with 'some help' from google I think I have it sorted out. Or will when I get the wrong lines right!

While I'm at it, could someone please explain why:

-# command="user@192.168.xxx.xxx"
-#*echo $command | cut -d'@' -f1
-# user

but-

-# command="user@192.168.xxx.xxx"
-# user=$command | cut -d'@' -f1
-# echo $user

gives no output? Or at least an empty line. Do I need to present the variable in brackets or quotes? I've tried every combination that makes sense from examples in help topics.

Thanks.

------ Post updated at 05:22 PM ------

Thanks folks so far...
Corona688, that certainly helps me set the flag.
RudiC, -o ConnectTimeout doesn't appear to be part of this branch of Debian.

A pipe | captures the output of the previous command.

What gets printed when you type echo $command ? It prints user@192.168.xxx.xxx

What gets printed when you type user=$command ? Nothing.

There is basically no reason to ever use echo "line" | cut , that's inefficient and the shell has better builtins to do it.

Try

$ user="username@192.168.xxx.xxx"
$ echo "${user/@*/}"

192.168.xxx.xxx

$

If your shell doesn't have ${VAR/SUB} type substitution, try "${user##*@}" instead.

What exactly happens when you try? Show exactly what you did, word for word, letter for letter, keystroke for keystroke.

You certainly want

-# command="user@192.168.xxx.xxx"
-# user=$(echo $command | cut -d'@' -f1)
-# echo $user

The shell builtin for this is

user=${command%%@*}

It's easier to compose long strings from short strings

-# user=user
-# command="$user@192.168.xxx.xxx"
-# echo $user

What be that branch, actually? And, the ssh version?

At one time we had to check a number of branches. The following code shows the "ping" as run in a "do" loop followed by the "sed" control file. Run sed with the -n option and "p" something appropriate when you find "0 packets".

ping -c 1 $in >>mylog1 2>&1


/ ping statistics / {
                    N
                   / 0 packets / {
                        s/^....br//
                        s/ .*//
                        p
                      }
                   }


sed -n -f ping.sed mylog1 > mylog2

If mylog2 exists, the blooming thing is down.

That's rather the long way around. Why not just check ping's return value?

Or, if your OS supports it, check the return code from nc -z a.b.c.d 22 to check if ssh is listening.

Robin

Thanks folks. Some of this made it into the script and it works perfectly.

There is one outstanding issue which I can't find a way around. I thought it would be great if the ssh session could open with sudo su, it's not a work network, and also changing directory to where I do most of my work.

After blooming hours of trying all sorts of different things I got the sudo working, but concatenating another command gets ignored.

Obviously I'm opening another shell and any commands still in the original script aren't going to get to the new shell, what I don't understand is I can send a command with ssh, but I can't send two, I just can't see any bash reason why it wouldn't work.

sh="ssh -t"
command="user@192.168.xxx.xxx"
sud="sudo su"
run="$sh $command $sud"
exec $run

This works great, but it would be even better if after the sudo I could be dumped into a directory that I use a lot. But;
sud="sudo su; cd /usr/folder/folder"
Doesn't work. The sudo runs ok but the cd is ignored.

I'm trying to understand why. As I said I know I'm opening another shell and the script can't communicate with it directly, but if sudo su works why does the cd go missing?

Thanks again everyone, nothing here is work related or that important, but I'm enjoying the learning bit!!

It wouldn't even work locally. Go ahead and try it, see what happens. su will run, and cd will not run inside it - but it will run, after su quits, because that's what semicolon means. Run this command, wait for it to quit, then run that other command.

To feed something into a program, you need to use redirection.

What I do to run scripts remotely is something like:

ssh username@host exec sudo su <<EOF
echo "Local hostname is $HOSTNAME"
echo "Remote hostname is \$HOSTNAME"
cd /usr/folder/folder
ls
EOF

The final EOF can't be indented, at all.

When in doubt, replace 'ssh' with 'cat' to see exactly what script you're trying to send to the far side!

No problem if only one remote site. In our shop we had to check a number of remote sites so we checked all of them then looked at the log to see if there was a problem.