glebspy
asked on
rsync with expect
I am using expect to anticipate a password prompt during an invocation of rsync over ssh. Unfortunately, expect prevents rsync from working properly in some way .. the rsync command has the desired effect when I run it directly, but when it is run by expect, it does nothing.
I am very new to expect, so please expect the mistake to be stupid.
Heres my expect script
#!/usr/bin/expect
set password [lindex $argv 0]
spawn rsync --recursive --rsh=ssh --size-only --archive --update --modify-window=900 --exclude='*.o' --exclude='*.ps' --exclude='*~' vil@libra1.rccp.tsukuba.ac
expect "vil@libra1.rccp.tsukuba.a
send "$password\r"
expect eof
spawn rsync --recursive --rsh=ssh --size-only --archive --modify-window=900 --exclude='*hosts*.static'
expect "vil@libra1.rccp.tsukuba.a
send "$password\r"
expect eof
How do I need to modify this so that rsync commands work correctly under expect?
I asked this question previously but mistakenly accepted a wrong answer, so I am re-opening the thread. The previous discussion can be found at the link below, but please feel free to just dive in.
Thank you
https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=unix&qid=20326509
I am very new to expect, so please expect the mistake to be stupid.
Heres my expect script
#!/usr/bin/expect
set password [lindex $argv 0]
spawn rsync --recursive --rsh=ssh --size-only --archive --update --modify-window=900 --exclude='*.o' --exclude='*.ps' --exclude='*~' vil@libra1.rccp.tsukuba.ac
expect "vil@libra1.rccp.tsukuba.a
send "$password\r"
expect eof
spawn rsync --recursive --rsh=ssh --size-only --archive --modify-window=900 --exclude='*hosts*.static'
expect "vil@libra1.rccp.tsukuba.a
send "$password\r"
expect eof
How do I need to modify this so that rsync commands work correctly under expect?
I asked this question previously but mistakenly accepted a wrong answer, so I am re-opening the thread. The previous discussion can be found at the link below, but please feel free to just dive in.
Thank you
https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=unix&qid=20326509
ASKER
Do you agree?
yes! totally. That is completely the logical order in which to proceed.
This is how far we got with ssh:
ahoffmann:
did you create new keys? did you install new keys on r
remote host? did you check for old/invalid keys?
glebspy:
yes, yes and yes.
There were some old keys in the remote authorized_keys file, but they were for other machines, so I guess I did the right thing in not deleting them.
Maybe the superuser on the remote has activated some option which stops me from turning off the password prompt. If you have any ideas, or anything else for me to try, please say.
yes! totally. That is completely the logical order in which to proceed.
This is how far we got with ssh:
ahoffmann:
did you create new keys? did you install new keys on r
remote host? did you check for old/invalid keys?
glebspy:
yes, yes and yes.
There were some old keys in the remote authorized_keys file, but they were for other machines, so I guess I did the right thing in not deleting them.
Maybe the superuser on the remote has activated some option which stops me from turning off the password prompt. If you have any ideas, or anything else for me to try, please say.
ASKER
For the benefit of anyone visiting this question, who does not want to trawl through the link to find out what ground has already been crossed, here is a summary:
It's generally agreed that the expect script is correct. So the question becomes, what is special about the rsync command (either something about the application itself, or the specific invocation) which causes it to fail when it is spawned from expect and the password is supplied. Also is the failure to do with the fact that it has been spawned from expect, or is the failure to do with the fact that we are trying to circumvent the password prompt. This question requires a theoretical solution.
There is also the possibility of a practical solution, which on expert has suggested, which is to try to stop rsync (in fact, ssh) even asking for a password prompt. So far this hasn't worked, although it's not clear why not .. the measures which one would naturally take to stop ssh asking for a password (making an rsa key and ftping it across) have been taken and yet the password prompt persists.
Hopefully this summary is useful to experts who are new to this question.
It's generally agreed that the expect script is correct. So the question becomes, what is special about the rsync command (either something about the application itself, or the specific invocation) which causes it to fail when it is spawned from expect and the password is supplied. Also is the failure to do with the fact that it has been spawned from expect, or is the failure to do with the fact that we are trying to circumvent the password prompt. This question requires a theoretical solution.
There is also the possibility of a practical solution, which on expert has suggested, which is to try to stop rsync (in fact, ssh) even asking for a password prompt. So far this hasn't worked, although it's not clear why not .. the measures which one would naturally take to stop ssh asking for a password (making an rsa key and ftping it across) have been taken and yet the password prompt persists.
Hopefully this summary is useful to experts who are new to this question.
Hi glebspy,
Could you please post the information about which version of ssh you are running at both end.
Could you please post the information about which version of ssh you are running at both end.
ASKER
Sure, here's the output of `which ssh` -V
local:
[vil@localhost vil]$ `which ssh` -V
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
remote:
vil@libra1:~>`which ssh` -V
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
local:
[vil@localhost vil]$ `which ssh` -V
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
remote:
vil@libra1:~>`which ssh` -V
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
My expect script is now:
#!/usr/bin/expect
set password [lindex $argv 0]
spawn rsync --recursive --rsh=ssh --size-only --archive --update --modify-window=900 --exclude='*.o' --exclude='*.ps' --exclude='*~' vil@libra1.rccp.tsukuba.ac
expect -timeout -1 "vil@libra1.rccp.tsukuba.a
send "$password\r"
expect -timeout -1 eof
and it works!
Congratulations on getting the right answer.
#!/usr/bin/expect
set password [lindex $argv 0]
spawn rsync --recursive --rsh=ssh --size-only --archive --update --modify-window=900 --exclude='*.o' --exclude='*.ps' --exclude='*~' vil@libra1.rccp.tsukuba.ac
expect -timeout -1 "vil@libra1.rccp.tsukuba.a
send "$password\r"
expect -timeout -1 eof
and it works!
Congratulations on getting the right answer.
Great that it works.
Once upon a time I wrote some fairly elaborate expect scripts (when does a script turn into a program? this was 2000+ lines of expect/tk code).
I found expect to be a great help, but at the same time ... "expecting" isn't always as straightforward as one would expect:-).
The timing issues, and (not) understanding how matching was done and on what (the anchoring part, which isn't to line ends, but rather to the buffer boundaries) had me running in pretty much the same circles you've been doing.
I then turned to open2 (in perl), which opened my eyes... There I could easily follow what was happening, but had to take care of the timing bit myself. The scripts (called from the Tk code) turned ugly fast. So it was back to expect and the solution of disabling timeouts.
Ah for the bygone days....;-)
-- Glenn
Once upon a time I wrote some fairly elaborate expect scripts (when does a script turn into a program? this was 2000+ lines of expect/tk code).
I found expect to be a great help, but at the same time ... "expecting" isn't always as straightforward as one would expect:-).
The timing issues, and (not) understanding how matching was done and on what (the anchoring part, which isn't to line ends, but rather to the buffer boundaries) had me running in pretty much the same circles you've been doing.
I then turned to open2 (in perl), which opened my eyes... There I could easily follow what was happening, but had to take care of the timing bit myself. The scripts (called from the Tk code) turned ugly fast. So it was back to expect and the solution of disabling timeouts.
Ah for the bygone days....;-)
-- Glenn
first try to get ssh working with keys, then try it with rsync, and if then rsync fails we should talk about expect
Do you agree?