Всякий раз, когда ansible вносит изменения в sshd в CentOS7, случайная игра в будущем не может соединиться


8

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

По сути, в любое время в CentOS 7.x, конфигурациях sshd или любой части sshd происходит изменение, и демон перезапускается / перезагружается в некоторой «случайной точке» в течение следующих 3 минут, все соединения ssh сбрасываются, и затем этот сервер недоступно в течение нескольких секунд через ssh.

Это особенно проблема для ansible в том смысле, что он иногда должен сам вносить эти изменения в sshd, а также перезагружать его (например, в новых сборках сервера CentOS 7x). Но затем в будущих играх он просто случайно не может подключиться к ssh, и он взрывает остальную часть playbook / play для того хоста, с которым не удалось связаться. Это особенно плохо для большого шаблона хоста, так как некоторые из них будут случайным образом завершены, но другие потерпят неудачу на различных этапах вдоль книги воспроизведения после манипулирования sshd. Следует отметить, что ничего подобного не происходит в CentOS 5x, 6x или даже в Solaris.

Лучшее, что я могу сделать, чтобы избежать этого, это создать 90-секундное ожидание после любых изменений в sshd, и даже это не является абсолютно надежным. Это заставляет эти пьесы запускаться более 20 минут, хотя их вызывают 7-8 раз.

Вот некоторые факты об этой среде:

Все новые установки с официальных ISO DVD. Каждый сервер является гостем Hyper-V 2012. Каждый сервер, имеющий эту проблему, - CentOS 7.x.

Вот некоторые фактические результаты проблем и некоторые избитые решения:

Провал:

fatal: [voltron]: UNREACHABLE! => {"changed": false, "msg": "All items         completed", "results": [{"_ansible_item_result": true, "item": ["rsync", "iotop", "bind-utils", "sysstat.x86_64", "lsof"], "msg": "Failed to connect to the host via ssh: Shared connection to voltron closed.\r\n", "unreachable": true}]}

Пример одного из изменений в sshd:

- name: Configure sshd to disallow root logins for security purposes on CentOS and Redhat 7x servers.
    lineinfile:
      backup: yes
      dest: /etc/ssh/sshd_config
      regexp: '^(#PermitRootLogin)'
      line: "PermitRootLogin no"
      state: present
    when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
    notify: sshd reload Linux 7x

Следующий обработчик:

- name: sshd reload Linux 7x
   systemd:
     state: restarted
     daemon_reload: yes
     name: sshd

Наконец, мое гетто исправлено, чтобы попытаться объяснить эту проблему:

- name: Wait a bit on CentOS/Redhat 7x servers to ensure changes don't mess up ssh and screw up further plays.
    pause:
      seconds: 90
    when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")

Должно быть лучшее решение, чем то, что я придумал, и трудно поверить, что все сталкиваются с этим и тоже с этим мирится. Что-то мне нужно настроить в серверах CentOS 7.x, чтобы предотвратить это? Есть ли что-то в ansible, что необходимо для решения этой проблемы, например, несколько попыток ssh за игру при первом сбое?

Заранее спасибо!


1
Вы уверены, что видели, как это сбрасывает существующие соединения SSH? Обычно перезапуск ssh не должен влиять на существующие соединения, так что это может быть своего рода подсказкой.
sourcejedi

Пожалуйста , укажите точную анзибль версию вы используете (например , если есть ошибка в модуле Systemd, люди будут интересоваться , какую версию он был).
sourcejedi

@sourcejedi ansible --version ansible 2.2.0.0 config file = /etc/ansible/ansible.cfg сконфигурированный путь поиска модуля = по умолчанию без переопределений Ну, я имею в виду, что это «может» быть ошибкой, но если это так, почему я единственный, кто испытывает это? Если только никто не использует CentOS 7x с ansible .... Однако вы правы в том, что обновление службы не должно влиять на существующие соединения. Действительно, на моих серверах CentOS 6x все работает безупречно на одной и той же пьесе.
Вязкость

Когда вы говорите, что он перезапускается - в системном журнале, это все, что вы получаете? Или systemd сообщает, что sshd вышел и был перезапущен в соответствии с Restart=on-failure? Если так, каков был статус выхода? И sshd не регистрирует сообщение об ошибке?
sourcejedi

Это не проблема Ansible, а проблема с SSH или сетью. Перезапуск SSH не влияет на текущие соединения SSH, так что здесь есть что-то еще. Вы пробовали регулярно подключаться через терминал по SSH, перезагружать sshdи что происходит с вашим соединением? Также вы используете SSH ControlMasterс Ansible? Вы можете включить его в ansible.cfg ssh_args = -o ControlMaster=auto -o ControlPersist=60s.
Страхиня Кустудич

Ответы:


0

Вместо того, чтобы использовать systemdмодуль, попробуйте serviceмодуль:

- name: Restart secure shell daemon post configuration
  service: 
    name: sshd
    state: restarted

1
Интересно, я попробую это и вернусь на эту страницу, чтобы люди знали. Но разве сервисный модуль не просто манипулирует «сервисным» двоичным файлом, который на самом деле просто перенаправляет через systemctl? Хорошо, я сделаю это.
Вязкость

DopeGhoti, к сожалению, ваше предложение не сработало. Я получаю точно такую ​​же проблему, как и раньше, и, похоже, она не зависит от модуля между службой или системными модулями. У кого-нибудь еще есть предложения?
Вязкость

0

Кажется, это общая проблема. Патч для Ansible SSH повторов с 2016 года

Лучшим решением может быть ожидание готовности sshd для подключения. Оригинальный поток с этим решением для ANSI-кода:

[Задачи создания ВМ ...]

  - name: дождаться завершения установки Kickstart и перезагрузки виртуальной машины local_action: wait_for host = {{vm_hostname}} port = 22 delay = 30 timeout = 1200 state = start

  - имя: теперь настройте ВМ ...

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.