Каковы преимущества rsh по сравнению с Perl Expect.pm? - PullRequest
Новая
       31

Каковы преимущества rsh по сравнению с Perl Expect.pm?

2 голосов
/ 21 апреля 2009

У меня есть Perl Expect.pm скрипт, который выполняет некоторые довольно сложные вещи, такие как упаковка приложений, развертывание приложения, проверка журналов и т. Д. На нескольких удаленных хостах Unix.

Мой предшественник написал похожие скрипты, используя rsh.

Есть ли лучший подход между двумя? Или я должен использовать что-то совсем другое?

Я предполагаю, что кто-то поднимет SSH; это в основном замена rsh, верно? К сожалению, сейчас SSH для меня не вариант.

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

Ответы [ 4 ]

4 голосов
/ 21 апреля 2009

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

Для решения этой конкретной проблемы: с помощью rsh (или ssh) вы можете указать, каким пользователем стать в удаленном сеансе: 

$ rsh -l username hostname

Нет необходимости использовать sudo в этом случае. Сейчас определенно настало время взглянуть на ssh из-за проблем с безопасностью. Синтаксис тот же, но ssh также допускает немного другой (и я бы сказал лучше) синтаксис: 

$ ssh username@hostname

Я нашел expect слишком привередливым, но мой опыт работы с ним не значителен.

3 голосов
/ 22 апреля 2009

Я вижу несколько способов сделать это:

  • Ожидайте через telnet, rsh или ssh
    • плюсы: одно соединение, меньше проблем с выходом
    • минусов: хрупкость в меняющейся среде
  • rsh / ssh каждая команда в отдельности
    • плюсы: меньше проблем, более надежных в изменяющейся среде
    • минусов: для каждого соединения требуется время для аутентификации, а для ssh - рукопожатие для шифрования
  • rsh / ssh все команды одновременно
    • плюсы: одно соединение (меньше накладных расходов), более надежно, чем ожидалось
    • минусы: хрупкость в обслуживании, особенно когда вы получаете больше, чем горстку операторов, проблемы с выходом из строя являются более распространенными (экранирование в perl, так что по-прежнему избегается rsh / ssh, так что по-прежнему экранируется удаленной оболочкой, так что он правильно обрабатывается удаленной оболочкой sudo'd?)
  • rsh / ssh и запустите скрипт
    • плюсов: одно соединение, более надежное, более удобное в обслуживании
    • минусы: найти способ получить его там (работа с rcp / scp, работа с NFS, вам нужно определить лучший способ для вас).

Учитывая все обстоятельства, это самый незначительный мошенник, так как вы можете просто сделать что-то вроде 

 open my $fh, "|ssh user@host 'cat > /tmp/myscript'";
 print $fh $script;
 system qw(ssh user@host), "chmod u+x /tmp/myscript; /tmp/myscript; rm /tmp/myscript";

Конечно, вы бы добавили некоторую обработку ошибок (не удалось открыть, что, если / tmp / myscript существует и т. Д.), Но это идея.

3 голосов
/ 21 апреля 2009

Они делают разные вещи. Expect - это способ написания сценариев, которые в противном случае были бы ручными ответами. rsh - удаленная оболочка, неограниченная оболочка, неудачное столкновение имен - позволяет удаленно запускать команды в другой системе.

При этом дыры в безопасности и другие недостатки использования rsh для выполнения удаленных команд, запуска sudo и т. Д. Огромны.

2 голосов
/ 21 апреля 2009

Учитывая выбор между rsh и telnet через expect, я бы выбрал rsh. Expect скрипты хрупкие. Все, что нужно, чтобы сломать кого-то, это изменить значение PS1 на удаленной машине. Использование rsh также подготавливает вас к тому дню, когда вы, наконец, войдете в 90-е и начнете использовать ssh (поскольку вы в основном можете просто изменить rcp на scp и rsh на ssh и все по-прежнему работает) .

...