Re: using expect to log into devices
Have you looked into utilizing Ansible? On Sat, Jul 21, 2018 at 8:22 PM wrote: > On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > > Fine as a personal exercise, of course. The inability to download > > modules seems sadistic to me, though. > > And given the adage "Never create a rule you can't enforce", I > wonder how they enforce it - have to be pretty hardcore to make > sure that stuff doesn't get imported via USB or tethering off a > cellphone. (Or more correctly, I know how they do those sort of > things if you're a spook agency or doing classified research - how > do you make it palatable to employees in corporate sites?) >
Re: using expect to log into devices
On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > Fine as a personal exercise, of course. The inability to download > modules seems sadistic to me, though. And given the adage "Never create a rule you can't enforce", I wonder how they enforce it - have to be pretty hardcore to make sure that stuff doesn't get imported via USB or tethering off a cellphone. (Or more correctly, I know how they do those sort of things if you're a spook agency or doing classified research - how do you make it palatable to employees in corporate sites?) pgpVpVUpj7aEG.pgp Description: PGP signature
Re: using expect to log into devices
* sur...@mauigateway.com (Scott Weeks) [Sat 21 Jul 2018, 22:38 CEST]: I had already done this in PERL, but, even though we have PERL, we are not allowed to download modules here. So, I'm redoing it in Expect. I thought someone would say a "oh just and you're done" type of response. Well, what you're doing right here is reimplementing rancid. Which is wholly unnecessary because we already have rancid, and a more modern alternative named oxidized. And you've gotten that response already. Fine as a personal exercise, of course. The inability to download modules seems sadistic to me, though. -- Niels.
Re: using expect to log into devices
--- ler...@gmail.com wrote:
From: Lee
> I have a file with 1000s of devices and another file
> with a list of commands. The program issues all
> commands for a device and then moves on to the next
> one using nested loops. In the debug I see the
> "spawn_id expNN" (where NN is a number that, I
> believe is representative of the number of file
> descriptors used in the system) increment only when
> a device does not respond. As long as a device
> responds before the timeout period I see the expNN
> number does not increase. As soon as a device
> doesn't respond the expNN count goes up and I can't
> figure out why. Once I hit a certain expNN the
:: 'close $spawn_id' is wrong, so maybe that's it?
:: man expect
:: close [-slave] [-onexec 0|1] [-i spawn_id]
:: closes the connection to the current process.
:: ... The -i
:: flag declares the
:: process to close corresponding to the named
:: spawn_id.
<.. snip ..>
I hand typed the close stuff in the email with just
'close spawn_id'. I did the -i in previous
iterations, but saw no difference. Maybe I should
try more. I saw the 'close' alone a lot on
Stackexchange a lot,so I was copying those in this
iteration. I also should have read the man page
more than I did, so a face slap to myself.
:: No matter whether the connection is closed
:: implicitly or explicitly, you should call wait to
:: clear up the corresponding kernel process slot.
:: close does not call wait since there is no guarantee
:: that closing a process connection will cause it to
:: exit. See wait below for more info.
:: The eof and timeout cases are basically
:: { catch {close}; catch {wait}; }
I always used wait after close and need to look into
those above. Maybe they close it different somehow.
:: get rancid from here... and take a look at clogin...
I'm going to be looking for a new job and want to up my
skills, in case I get a chance to do the SDN/NFV stuff,
which I read requires coding skills, so this is also an
exercise toward that. Plus it's fun.
I had already done this in PERL, but, even though we
have PERL, we are not allowed to download modules here.
So, I'm redoing it in Expect. I thought someone would
say a "oh just and you're done" type of
response.
Thanks a lot from everyone private and on the list.
I'll post for the archives if I find the answer.
scott
Re: using expect to log into devices
On 7/20/18, Scott Weeks wrote:
>
> I have looked extensively on the web for an answer
> and cannot find one, so I come to you guys. I am
> not allowed to use modules in PERL or Python or I
> wouldn't have to do it this way. I have to do this
> all in Expect and I am a newbie at it.
>
> Also, maybe I'm having the Friday afternoon "I want
> to go home" mental block and the answer is right in
> front of my nose.
>
> I have a file with 1000s of devices and another file
> with a list of commands. The program issues all
> commands for a device and then moves on to the next
> one using nested loops. In the debug I see the
> "spawn_id expNN" (where NN is a number that, I
> believe is representative of the number of file
> descriptors used in the system) increment only when
> a device does not respond. As long as a device
> responds before the timeout period I see the expNN
> number does not increase. As soon as a device
> doesn't respond the expNN count goes up and I can't
> figure out why. Once I hit a certain expNN the
> program exits ungracefully; usually somewhere between
> 2500 and 3500 devices because our FD is set to 256
> and that's how long it takes for 256 devices to not
> respond before the timeout period. Can anyone tell
> me why? Here is the relevant config snippet. I've
> tried every iteration of close and wait I found and
> no love...
'close $spawn_id' is wrong, so maybe that's it?
man expect
close [-slave] [-onexec 0|1] [-i spawn_id]
closes the connection to the current process. ... The -i
flag declares the
process to close corresponding to the named spawn_id.
<.. snip ..>
No matter whether the connection is closed implicitly or
explicitly, you
should call wait to clear up the corresponding kernel process
slot. close
does not call wait since there is no guarantee that closing a process
connection will cause it to exit. See wait below for more info.
get rancid from here
ftp://ftp.shrubbery.net/pub/rancid/
and take a look at clogin
(which allows you to do 'clogin -x fileName dev1 dev2 ... devN' to
run the commands
in 'fileName' on the list of devices)
The eof and timeout cases are basically
{ catch {close}; catch {wait}; }
Regards,
Lee
>
> You'll want to put this into a fixed width font like
> Courier New or it'll just be a mess.
>
>
> foreach element $device {
>
> send_user "\n\n"
>
> send_user "#\n"
> send_user "## BEGIN $element ###\n"
> send_user "#\n"
>
>spawn ssh -q -o StrictHostKeyChecking=no $username@$element
>
> expect {
> timeout { send_user "\nfailed to get password prompt\n\n"
> send_user "#\n"
> send_user "### END $element \n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
> }
> eof { send_user "\nssh failure for $element\n\n"
> send_user "#\n"
> send_user "### END $element \n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
> }
> "assword" {
> send "$password\n"
> }
>}
>
>
> expect {
> timeout { send_user "\npassword did not work or enable mode not
> achieved\n\n"
> send_user "#\n"
> send_user "### END $element \n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
> }
> eof { send_user "\npassword failure for $element\n\n"
> send_user "#\n"
> send_user " END $element #\n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
> }
> "" {
> send "term len 0\n"
> # send "skip-page-display\n"
>
> foreach command $commands {
> expect "#"
> send "$command\n"
> send_user "\n\n"
> }
> }
>}
>
> send "exit\n"
> send "exit\n"
>
> send_user "#\n"
> send_user "### END $element \n"
> send_user "#\n"
> send_user "\n\n\n"
>
> close
> wait
> }
>
>
> Thanks!
> scott
>
> ps; I realize my indenting of the curly braces and other
> things are not standard... :)
>
>
Re: using expect to log into devices
--- jwbens...@gmail.com wrote: From: James Bensley :: Do you need to write this yourself, No, but I'm tired of being a coding wussie, so this is 1) an exercise for me in getting better at it and 2) I want it to read a list of machines from one file and execute a list of commands from another. Then I just vi the files and done. :: I've used this expect script too many :: times such that I should be ashamed...It :: "just works": :: :: https://sourceforge.net/projects/cosi-nms/files/ciscocmd/ Thanks, it's beertime Friday, so I will look at it tomorrow. However, I'd sure like to know why I an using up all the file descriptors on the system. scott
Re: using expect to log into devices
Do you need to write this yourself, I've used this expect script too many times such that I should be ashamed...It "just works": https://sourceforge.net/projects/cosi-nms/files/ciscocmd/ Cheers, James.
Re: Proving Gig Speed
On 07/20/2018 11:22 PM, Scott Weeks wrote: > Oops, failure to communicate... They folks on the > eyeball end have consumer grade satellite internet > with VSATs in their yard. Thus my CDN in the > satellite joke. That idea would work better with a constellation of LEO satellites, as opposed to geosync. Especially if there was a link satellite-to-satellite for update purposes.
Re: Proving Gig Speed
On 21/Jul/18 08:22, Scott Weeks wrote: > > Oops, failure to communicate... They folks on the > eyeball end have consumer grade satellite internet > with VSATs in their yard. Thus my CDN in the > satellite joke. Ah, got you :-). Well, if the earth station on the other side is in a well-connected city, they've got the best they can get. Mark.
Re: Proving Gig Speed
--- mark.ti...@seacom.mu wrote: On 20/Jul/18 21:37, Scott Weeks wrote: > Could you explain that? Do you mean logically > near the ground stations? I mean physically in the ISP's backbone. -- Oops, failure to communicate... They folks on the eyeball end have consumer grade satellite internet with VSATs in their yard. Thus my CDN in the satellite joke. scott
Re: Proving Gig Speed
On 20/Jul/18 21:37, Scott Weeks wrote: > Could you explain that? Do you mean logically near the > ground stations? I mean physically in the ISP's backbone. They would use the satellite link for cache-fill, but then deliver content locally. This should speed things up a great deal. Having the cache on the other side of the satellite link doesn't help at all, since the biggest latency tax is on the satellite link itself. > I had a funny thought... CDN in the satellite. :) :-) - don't give them ideas, hehe... Mark.
