У нас есть инструмент автоматизации, который пытается войти в систему через ssh и отправить команды, который отлично работает, когда сервер запущен. С другой стороны, пока сервер загружается, наш инструмент проверяет, открыт ли порт ssh (22), и если он открыт, он пытается подключиться к серверу и отправить команды.
Однако, когда сервер находится в последовательности загрузки и наш инструмент автоматизации проверяет, открыт ли порт 22, он пытается подключиться к серверу с помощью клиента ssh, но сервер отклоняет его или клиент ssh возвращает ошибку «порт ssh не открыт».
Мы попытались исследовать эту проблему с помощью telnet и увидели, что во время загрузки sshd запускается и открывает порт 22 и начинает прослушивание, но каким-то образом он снова закрывает порт и через некоторое время снова его открывает. И это то же самое время, когда наш инструмент автоматизации пытается войти в систему.
У меня вопрос; как мы можем убедиться, что порт ssh успешно открыт и готов принимать команды?
Спасибо, что нашли время, чтобы ответить, С уважением
Сначала кажется, что инструмент автоматизации не проверяет статус выхода ssh. Я бы попытался исправить проблему там.
Одно из решений - попытаться исправить ошибку для команды, создавшей инструмент.
Другое решение - заключить команду ssh в скрипт, который сделает это прозрачно. Например. создать скрипт в /opt/myproject/ssh_wraper.sh
Здесь может быть что-то вроде:
SSH_EXIT_STATUS=255
while [[ $SSH_EXIT_STATUS -eq 255 ]];do
ssh ....
SSH_EXIT_STATUS=$?
done
Вы можете попробовать поэкспериментировать со статусом выхода из чего-нибудь вроде ssh user@host "echo 0 > /dev/zero"
Если команда завершится успешно, вы получите 0
(указывает на то, что система готова). Неудачная попытка приведет к коду выхода 255
.
Возможно, вы захотите использовать -o ConnectTimeout=
и -o ConnectionAttempts=
, слишком.
Хотя я тоже согласен со Стивом. Может, просто подожди еще немного. В зависимости от того, насколько агрессивно ваш инструмент пытается найти порт, увеличьте задержку перед попыткой входа в систему.
Вы можете поставить цикл перед входом в систему, чтобы дождаться открытия порта.
until nc -zvw 1 $host 22; do
sleep 2
done
ssh $host $cmd
Если вам не нужен риск бесконечного цикла, если условие никогда не будет выполнено, вы можете каким-то образом установить значение 'или'. Упражнение предоставляется читателю. :)
Самым простым решением было бы, если бы инструмент автоматизации попытался войти в систему, если он не удастся, подождать x минут и повторить попытку?
Все время, пока сервер загружается, могут происходить такие странные вещи.
Вы можете попробовать добавить сценарий в последовательность загрузки вашего сервера (например, в /etc/rc.local), который отключит брандмауэр на порту 22. Этот сценарий (как указано в комментариях к файлу / etc / rc.local) будет выполнен после всех остальных сценариев инициализации. Итак, пока ваш сервер не завершил свою загрузочную последовательность, порт 22 все еще недоступен за брандмауэром. Его преимущество заключается в том, что инструмент автоматизации не изменяется.
На базе ОС RHEL6. Возможно, в вашем дистрибутиве сценарии инициализации отличаются.
Вот что я делаю, когда запускаю сервер в AWS и жду, пока он станет доступен для подключения по SSH, для этого я использую bash:
status="notknown"
until [[ $status == "running" ]]; do
status=$(EC2 tools command to get the status)
if [[ $status != "running" ]]; then sleep 3; fi