Использование Expect для администрирования машин через SSH, но не завершает все задачи - PullRequest
Новая
       11

Использование Expect для администрирования машин через SSH, но не завершает все задачи

3 голосов
/ 12 июля 2010

* Пожалуйста, не накапливайте и говорите мне просто использовать SSH-ключи.Если вас не устраивает то, что я так делаю, сделайте вид, что вместо этого я пытаюсь войти по телнету.:-) *

Я использую сценарий ожидаемого запуска некоторых рутинных команд на наборе серверов под моим контролем через ssh.Скрипт должен запускать набор команд (например, svn update ~ / folderx \ r ") на каждой из машин. Мой текущий скрипт делает все, что я хочу, чтобы он делал ... иногда. В других случаях он выходит из соединения ssh до того, как завершитиз нескольких последних команд.

Есть ли у вас какие-либо мысли о том, как сделать так, чтобы соединение оставалось до тех пор, пока не будут выполнены все команды?и один из обновлений SVN), а затем отключается. 

#!/usr/bin/expect -f

spawn ssh username@ipaddress
set timeout -1
expect "Are you sure you want to continue connecting" {send "yes\r"; exp_continue} "password:" {send "*******\r"; exp_continue
    } "username@machine" {send "sudo apt-get update\r"}
expect "password" {send "*******\r"; exp_continue} "username@machine" {send "sudo svn update ~/folder1\r"}
expect "password" {send "*******\r"; exp_continue} "username@machine" {send "sudo svn update ~/folder2\r"}
expect "password" {send "*******\r"; exp_continue} "username@machine" {send "sudo svn update ~/folder3\r"}
expect "password" {send "*******\r"; exp_continue} "username@machine" {send "sudo reboot\r"}
close

Ответы [ 2 ]

3 голосов
/ 12 июля 2010

Использование Expect - это, как правило, неправильный способ делать подобные вещи.Правильный способ - настроить ssh-ключи, чтобы вы могли ssh и запускать команды на удаленном компьютере без ввода пароля.Вот как это сделать: 

0. Create public/private key pair on local machine.
   (Only needs to be done once on local machine for all remote machines.)
   Go to the ~/.ssh directory on your local machine and do this:
   % ssh-keygen -t rsa
1. Copy the public key to the remote machine:
   % scp ~/.ssh/id_rsa.pub you@foo.com:.
2. Append that key to the authorized_keys file on the remote machine:
   % ssh you@foo.com 'cat id_rsa.pub >> .ssh/authorized_keys; /bin/rm id_rsa.pub'
3. Finally, in case it doesn't work, check permissions, which must be just so: 
   (or maybe it's just that they can't be group/world writeable)
   % cd ~; ls -ld . .ssh .ssh/authorized_keys
     drwxr-xr-x  .
     drwxr-xr-x  .ssh
     -rw-r--r--  .ssh/authorized_keys

Вот скрипт, который выполняет все одним махом:

http://jakehofman.com/code/sshkey

Затем вы можете запускать команды на пультемашина выглядит так: 

ssh alice@remote.com ./foo args

Выполнение команд на удаленной машине с помощью sudo, однако, может быть другой историей.Надеюсь, что другие могут вмешаться в это.Но в качестве первого шага вам следует избегать Ожидать начального входа в систему.

2 голосов
/ 14 июля 2010

Оказывается, причина, по которой он выходил раньше, заключалась в том, что шаблон приглашения, с которым я сопоставлял, соответствовал не только приглашению, но и некоторым выводам команд svn, которые я выполнял.Я сопоставлял только часть имени пользователя в шаблоне подсказки (форма подсказки была «username @ machine: ~ $»).После того, как я изменил скрипт, чтобы он соответствовал только «username @», он начал работать как положено.

ps ssh-скрипт, который убирает ссылки на вышеприведенные ссылки, работает очень хорошо.

...