EXPECTing a reply

[tony.chamberlain at lemko.com]

I am doing a remote query on a machine.
I am using a cron job to do it.

To do this I have to go through a Cisco
VPN (including making the connection).
There are two ways, a graphical way
and a non-graphical way. I have to use
the second of course, but even with the 
non-graphical way the VPN requires input
(where it asks for userid and password).
It has no way to specify them on the
command line, so my auto script wouldn't
work.

After some experimenting I got it to work
with expect. Basically, here is the snippet:

spawn /opt/cisco/vpn/bin/vpn connect a
expect "Username.*"
send "mylogin\r"
expect "Password:.*"
send "mypassword\r"
expect "%"
wait

(user name and password changed for security reasons. And "a" equates to an IP
address in /etc/hosts). ANyway this works generally. I do this in the background
and sleep for 40 seconds or so. When I can ping the machine (which I eventually
can each time) then I know I can do my ssh -l tony MACHINEIP script. This works.

Once however I ran the program and it didn't work. Doing some investigation I realized
that every once-in-a-while (seems unpredictable) the VPN also asks something like

Unable to verify certificate 1d:3a:4c:1b:2a:3d:41:5e
 accept [y/n]:

(again the hex digits have been changed for security reasons). So what I am expecting
(Username) does not come up yet. First I have to send a "y". But I can't do this
automatically or sometimes it will send "y" as my username.

I can see two possible solutions, but not sure how to implement either:

 1) Make it so it never (or always) asks to accept the certificate
 2) Add some sort of if/then/case logic to my expect program
 to react differently depending on whether it receives an "accept" string
 or not.

I have seen examples in expect where they do similar things but can never seem to
get it to work right for me.

Any suggestions?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080220/8ece97d2/attachment-0001.htm>