Net::Telnet Error handling/trapping

[Chris G.]

I have a script that reads in a csv files, parses the data, and uses the
info to run down a list of IP addresses and make telnet connections to
them. I do this to automate the backing up of my Foundry switch
configurations. This works great until I have an error. When I have an
error at connect time, it catches the error and reports it, just like I
want. However, it doesn't recover from the error and never makes any
more connections to the other switches, even though it says it does.

Here is my (relevant) code:

use warnings;
use strict;
use Net::Telnet;

sub GetCF;


sub GetCF {
my $telnet;
$telnet = new Net::Telnet ( Timeout=>10,
Host=>$ip,
Errmode=>\&uhoh,
);

<skipping commands executed after the connection is established>
}

sub uhoh {
if ( $@ ne "") {
print ("$@\n");
} else {
print "Success\n";
}
}

 

[Martijn Lievaart]

I have a script that reads in a csv files, parses the data, and uses the
info to run down a list of IP addresses and make telnet connections to
them. I do this to automate the backing up of my Foundry switch
configurations. This works great until I have an error. When I have an
error at connect time, it catches the error and reports it, just like I
want. However, it doesn't recover from the error and never makes any
more connections to the other switches, even though it says it does.

I use rancid for this. Actually I use it to backup the configs, but when
it's installed, it's a great way to run commands on any of the installed
network devices. And obviously parse the results in Perl.

And I actually had bad experiences with Net::Telnet to access Cisco
routers. It would sometimes just act weird. Never got to the bottom of it
though.

HTH,
M4

 

[DJ Stunks]

I have a script that reads in a csv files, parses the data, and uses the
info to run down a list of IP addresses and make telnet connections to
them. I do this to automate the backing up of my Foundry switch
configurations. This works great until I have an error. When I have an
error at connect time, it catches the error and reports it, just like I
want. However, it doesn't recover from the error and never makes any
more connections to the other switches, even though it says it does.

Here is my (relevant) code:

use warnings;
use strict;
use Net::Telnet;

sub GetCF;

sub GetCF {
my $telnet;
$telnet = new Net::Telnet ( Timeout=>10,
Host=>$ip,
Errmode=>\&uhoh,
);

<skipping commands executed after the connection is established>

}

sub uhoh {
if ( $@ ne "") {
print ("$@\n");
} else {
print "Success\n";
}

}

how about something like this:

#!/usr/bin/perl

use warnings;
use strict;

use Net::Telnet;

my $t = Net::Telnet->new( Timeout => 10,
Errmode => sub { warn $_[0] },
);

HOST:
while ( my ($user,$pass,$host) = split /[,\n]/, <DATA> ) {

$t->open( $host ) or next HOST;
$t->login( $user,$pass ) or next HOST;

# do something with $t telnet session

$t->close;
}

__DATA__
user1,pass1,host1.example.com
user2,pass2,host1.example.com
user1,pass1,host2.example.com
user2,pass2,host2.example.com

-jp

PS - in the future please post only complete scripts including sample
data. if this means you have to do a little extra work putting
together a good question, you will be the better for it

 

[Chris G.]

DJ,

I would have posted the entire script, but it's >220 lines of code. Do
you really want all that code??? I will post it, if you want. I
understand the reasoning behind your request. I was just trying to save
some bandwidth for others.

 

[Chris G.]

Hi,

I like this idea and see that I did not provide enough information. I
apologize. But, in what you have given me, this is a good start for
future thinking.

In the code below, you do the
$t->open( $host ) or next HOST;

If I use that, what happens to that current attempt to open the telnet
session? Does that just go away and the script continues? I will get
some more info and post it to help clarify why I ask.

Regards,

Chris

 

[Guest]

how about something like this:

#!/usr/bin/perl

use warnings;
use strict;

use Net::Telnet;

my $t = Net::Telnet->new( Timeout => 10,
Errmode => sub { warn $_[0] },
);

HOST:
while ( my ($user,$pass,$host) = split /[,\n]/, <DATA> ) {

$t->open( $host ) or next HOST;
$t->login( $user,$pass ) or next HOST;

# do something with $t telnet session

$t->close;
}

__DATA__
user1,pass1,host1.example.com
user2,pass2,host1.example.com
user1,pass1,host2.example.com
user2,pass2,host2.example.com

-jp

Hi,

I like this idea and see that I did not provide enough information. I
apologize. But, in what you have given me, this is a good start for
future thinking.

In the code below, you do the
$t->open( $host ) or next HOST;

If I use that, what happens to that current attempt to open the telnet
session? Does that just go away and the script continues?

Yes. If the open fails, the program ignores that host and moves to the
next host.

I will get
some more info and post it to help clarify why I ask.

Regards,

Chris

Please bottom-post your replies, like I am doing in this message, and
please read the posting guidelines for this newsgroup:

http://www.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

 

[DJ Stunks]

how about something like this:

use warnings;
use strict;

use Net::Telnet;

my $t = Net::Telnet->new( Timeout => 10,
Errmode => sub { warn $_[0] },
);

HOST:
while ( my ($user,$pass,$host) = split /[,\n]/, <DATA> ) {

$t->open( $host ) or next HOST;
$t->login( $user,$pass ) or next HOST;

# do something with $t telnet session

__DATA__
user1,pass1,host1.example.com
user2,pass2,host1.example.com
user1,pass1,host2.example.com
user2,pass2,host2.example.com

In the code below, you do the
$t->open( $host ) or next HOST;

If I use that, what happens to that current attempt to open the telnet
session? Does that just go away and the script continues? I will get
some more info and post it to help clarify why I ask.

[top posting repaired]

ok, let's break it down. as the Net::Telnet docs indicate, the open()
method returns undef on failure. So if the open is unable to connect
to the host (no telnetd running on the host, host name not resolvable,
host not contactable, etc) the open command returns undef. Since
undef is a false value, Perl tries the right hand side of the
statement to see if it will evaluate to true. The second half of the
or is to give up on the remainder of the statements in the body of the
while loop and just go on to the next iteration (if there is one).

Hope that answers your question,
-jp

 

[DJ Stunks]

I might do a new Telnet before each open.
<snip spew>

Might you, robic? Why? Instantiating a new object each time
accomplishes nothing and wastes cycles.

-jp

 

[Sherm Pendley]

I would have posted the entire script, but it's >220 lines of code. Do
you really want all that code???

The guidelines suggest posting *a* complete script that demonstrates the
problem you're having. There are two reasons for this:

First and foremost, in the process of winnowing out the parts of the script
that aren't actually relevant to the problem, many people find that they've
actually found the solution. That's what DJ was talking about when he said
it might take a little extra effort, and why it might be better for you than
just dumping your whole original script here.

And second, no one's going to wade through 220+ lines to do step one for you,
so dumping it all here would be pointless anyway.

sherm--

 

[Sherm Pendley]

Might you, robic? Why? Instantiating a new object each time
accomplishes nothing and wastes cycles.

Kind of like Robic0 himself...

sherm--

 

[Chris G.]

I appreciate your concern over my posting habits, but I prefer
top-posting and that's my client's default setting. That setting
controls both email and newsgroup replies, so changing it isn't really
an option. Sorry.

Regards,

Chris

 

[Uri Guttman]

CG> I appreciate your concern over my posting habits, but I prefer
CG> top-posting and that's my client's default setting. That setting
CG> controls both email and newsgroup replies, so changing it isn't really
CG> an option. Sorry.

and you will lose many of the regulars here who will killfile you. and
there is NO default setting called top posting. it is just where the
editor leaves the cursor after you quote a post. is it so hard for you
to move the cursor down? do you have RSI? are you brain dead? do you
care about what others think? or the extra work you make others do? or
breaking longstanding guidelines in the group? did you learn anything in
kindergarten?

uri

 

[Chris G.]

I am sorry that the group is so intolerant of top-posting, but how I
post it my choice, just others have a choice to respond or not. This is
not a flame, just a statement of fact. In the interest of not further
polluting the ng with non-perl postings, this is the last I will comment
on it. Let's just agree to disagree and move on.

Regards,

Chris

 

[Uri Guttman]

CG> I am sorry that the group is so intolerant of top-posting, but how I
CG> post it my choice, just others have a choice to respond or not. This is
CG> not a flame, just a statement of fact. In the interest of not further
CG> polluting the ng with non-perl postings, this is the last I will comment
CG> on it. Let's just agree to disagree and move on.

it is not intolerant. it has been know for decades that interpersed
edited quotes are much better for technical discussion as they are
commonly q&a. do you want answers before the questions? not all posts
are received in the same order so it is better to read top down as
english is normally written. this group has kept these basic usenet
rules and encourages them. individuals will decide to killfile those who
deliberately top post as you want to do. it is your choice to step on
the toes here and not anyone else's. it is not a case of agreeing to
disagree but your choosing to not adhere to the groups guidelines. it is
all on you. enjoy the fact that you will just get less and worse help
than if you didn't top post. is that something you want to tradeoff? it
is like choosing a class with a stupid but lenient teacher vs one with a
much smarter but stricter one. you want a useless teacher or kingsfield
from the paper chase?

uri

 

[Tad McClellan]

I am sorry that the group is so intolerant of top-posting, but how I
post it my choice, just others have a choice to respond or not. This is
not a flame, just a statement of fact.

I am sorry that everyone is so intolerant of farting at the dinner table,
but how I pass gas is my choice, just others have a choice to respond
or not. This is not a flame (unless you hold a match near my butt),
just a statement of fact.

Let's just agree to disagree and move on.

I agree to never see any of your posts again.

 

[Tad McClellan]

Uri Guttman ([email protected]) wrote on MMMMCML September MCMXCIII in
<URL:``
`` CG> I am sorry that the group is so intolerant of top-posting, but how I
`` CG> post it my choice, just others have a choice to respond or not. This is
`` CG> not a flame, just a statement of fact. In the interest of not further
`` CG> polluting the ng with non-perl postings, this is the last I will comment
`` CG> on it. Let's just agree to disagree and move on.
``
`` it is not intolerant. it has been know for decades that interpersed
`` edited quotes are much better for technical discussion as they are
`` commonly q&a. do you want answers before the questions?


Yeah, but the same holds for proper use of capitals.

Amen!