How to verify the connection to other unix server by script?

[Chinese Feng]

Hi, Expert

Our customer need us to develop some script to verify whether the connection to other unix server is ok or not ?
For Example: Work at server A, then want to use command "telnet server_B 383" to check the connection to server_B 383 is ok,
# telnet 16.173.244.124 383
Trying...
Connected to 16.173.244.124.
Escape character is '^]'.

So i write simple shell script like below :
telnet server_B 383 > telnet.log
I just want to get the output of command "telnet 16.173.244.124 383" to verify whether below keyword is exist or not
"Escape character"
if exist ,then the connection is ok ,otherwish the connection is broken, But when i run this script, it hang at that moment, i think may the script are waiting for my input the user/password.

Does anyone know how to solve it , thanks so much!

Could we set the time out of command telnet ?

[Raj D.]

Chinese Feng,

You can use simple ICMP reply to check the other unix servers connectivity.

- Create a script using # ping -c 2

It will ping two times, if response is 100% success , server is reachable, else not.

- Run the script from another server , that never goes down or less downtime, using crontab or background. (&) .

- redirect logs to a log file. and you can put email notification if any server is unreachable.

Hope this helps.

Cheers,
Raj.

[Hakki Aydin Ucar]

I believe to check other servers with telnet is not good with using a shell script, you need to write a TCL macro. TCL handles this type of control better, because it is in its nature as a programming language.

I believe an easy way to check is using ICMP that is:

ping other server and get RC to check if it is ZERO or NOT, thats all. if you want to use telnet check ,I recommend you to write both shell and TCL script , use shell as wrapper..

but due to my environment have lots of different servers I don t have any chance to write a generic TCL macro...

[Steven Schweda]

> [...] verify whether the connection [...]

Define "the connection". There are many ways
for one system to be connected to another.
"ping" tests low-level IP connectivity, but
it's often blocked by firewalls. A Telnet
script can check the remote system's Telnet
server. A Web browser or wget can check the
remote system's HTTP server. An FTP client
script or wget can check the remote system's
FTP server. And so on. It's a long list,
including rsh/remsh, ssh, and many others.

Are you interested in some particular service
or services (like, say, Telnet)? If so, then
it makes sense to test it or them.

You seem to be trying to connect to port 383,
which, with Google's help, I guess, may be
related to HP's Performance Data Alarm
Manager (about which I know nothing).

> i think may the script are waiting for my
> input the user/password.

That's what Telnet generally does. You can
use a program like "expect" to help script a
Telnet session. Other services may be easier
to test in a simple script. (I use wget on
my VMS system to check on its Web server,
for example.)

However, if you're connecting to port 383,
then you're talking to some server program
about which I know nothing, so I don't know
what it expects you to send. I'd guess that
you don't know, either.

Using Telnet manually to check access to
some arbitrary port makes some sense, but if
you're trying to write a script to check it,
then why not use some real Performance Data
Alarm Manager (or whatever) program/command
to do some real work?

As usual, it might make more sense to
describe the actual problem which you are
trying to solve, rather than asking how to
implement some sub-ideal solution to that
problem.

[Suraj K Sankari]

Hi,
go to this below links you will find different scripts.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1252344730386+28353475&threadId=766322

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1252344671437+28353475&threadId=960333

Suraj

[Maxim Yakimenko]

As mentioned above, first check connectivity using ping. But if you receive ping answer it does not mean that server is ready to login you via ssh or telnet - some cases of failures leave OS in state when base modules like TCP/IP are alive and can answer by ping, for example, but applications like telnet server can not work due to, for example, significant mem leaks. Thus it will be good idea to send ping and if it replies check it with ssh or telnet. I recommend you to look at soft called expect - it designed to handle situations like yours, also, if I remember you can set reply timeout and handle it in your own way - send email or someting

[Horia Chirculescu · Accepted solution]

Hello,

You can use EXPECT. This would do the job you asked for.

Take a look at this thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=951550

Just an ideea for your script:

---------------------------------
while {1} {
expect -nocase "password*" {
send "$password(login)\r"
} eof {
badhost $host "spawn failed"
break
} timeout {
badhost $host "could not log in (or unrecognized prompt)"
exec kill $pid
expect eof
break
} -re "incorrect|invalid|Denied" {
badhost $host "bad password or login"
exec kill $pid
expect eof
break
} -re $prompt {
set logged_in 1
break
}
}

if (!$logged_in) {
wait
continue
}
-----------------------------------


Best regards from Romania,
Horia Chirculescu.

[Steven Schweda]

> You can use EXPECT. This would do the job
> you asked for.

Except that he was trying to test port 383,
not a real Telnet server, so all that user
name and password stuff doesn't fit here.

[Horia Chirculescu]

To: Steven Schweda

"Except that he was trying to test port 383,
not a real Telnet server, so all that user
name and password stuff doesn't fit here."

The fact that it test the port 383 have nothing to do with EXPECT.

Chinese Feng could run expect -nocase for the string "Escape character" /whatever his daemon (not important if it is or not a telnetd daemon) listening on the port 383 (also, not important the port no.) replays with.

Best regards from Romania,
Horia Chirculescu

[kobylka]

Hello Chinese Feng!


Attached is a simple expect script that accomplishes your task.

Kind regards,

Kobylka

[Jannik]

There are tools like nmap and netcat but you could use this perl script to test the connection:

#!/usr/bin/perl -w
use strict;
use IO::Socket;

my $host = "";
my $port = "";
my $handle = "";

unless (@ARGV == 2) { die "usage: $0 host port" }
($host, $port) = @ARGV;

$handle = IO::Socket::INET->new(Proto => "tcp", PeerAddr => $host, PeerPort => $port) or die "False";
print "True";
exit;

Or you could test the simple way:
echo " " | telnet host port

[Steven Schweda]

> Chinese Feng could run expect -nocase for
> the string "Escape character" /whatever his
> daemon (not important if it is or not a
> telnetd daemon) listening on the port 383
> (also, not important the port no.) replays
> with.

How do you know that this (unidentified)
daemon replies with _anything_?

[Chinese Feng]

Thanks for your reply : )

[Horia Chirculescu]

Steven,

(Quotation)
Chinese Feng could run expect -nocase for the string "Escape character" /whatever his daemon (not important if it is or not a telnetd daemon) listening on the port 383 (also, not important the port no.) replays with.
(End quotation)

It is not important what this daemon behind the stated port replies (or if it ever replies!). The telnet client will allways (well, at least in most of the situations...) respond with some confirmation string like the one stated by Feng:

(Quotation)
# telnet 16.173.244.124 383
Trying...
Connected to 16.173.244.124.
Escape character is '^]'.
(End quotation)

If the daemon would reply something, Feng would actually continue the script (or ever ignore in the script the first part related to the output from telnet client) - and this situation I was talking about in:

"/whatever..." from the first quotation

My point is that EXPECT is a good solution as would cover all the situations we are talking about.


Best regards from Romania,
Horia Chirculescu

[Steven Schweda]

> My point is [...]

And _my_ point is that getting connected to
some daemon doesn't really tell you if it's
working properly. Whether getting connected
is good enough depends on what you really
want to know, and we were never really told
that.

[Horia Chirculescu]

"and we were never really told
that."

Well, this is how the input data sounds like.

In fact, just by checking connection to one daemon does not mean that the "whole" unix server is "ok" (If I understand right, this was the answer expected by Chinese Feng, not just finding out if some service is running or not on the target system).

There are situations when the server is not responding (from the point of the services that he provide) but still he responds to ping (I mention ping as it was a reffernce to it on other post), or telnet connections get in state "connected" but nothing more...

Best regards from Romania,
Horia Chirculescu