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

Question

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

Мой предшественник написал похожие сценарии с использованием rsh.

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

$ rsh -l username hostname 

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

$ ssh username@hostname 

я нашел expect быть слишком привередливы, но мой опыт работы с ней не существенна.

Answer 4

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

• Ожидать через телнет, 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 существует и т. д.), но это идея.