а причем тут это?

- name: Check connection for '{{ ssh_check_user_var }}' wait_for_connection: connect_timeout: "{{ ssh_check_connect_timeout }}" timeout: "{{ ssh_check_timeout }}" changed_when: false failed_when: false register: __check_connection

Остановился на этом, спасибо, ребята за помощь! - name: Check connection for '{{ ssh_check_user_var }}' wait_for_connection: timeout: 5 changed_when: false failed_when: false register: __check_connection - meta: end_play when: __check_connection.msg != ""

Зачем такие странные имена переменных?

Может чтобы отличать от стандартных

Ребята подскажите, пожалуйста, нужно сделать такую конфигурацию которая сначала войдет под root и создаст sudo пользователя и запретит вход от root по ssh, в дальнейшем ansible_user должен быть созданный sudo пользователь. Все сводится к тому, чтобы попробовать войти под root, если не получилось, работать от sudo пользователя. Как это лучше реализовать? Вариант изменения вручную ansible_user не подходит.

речь шла о том, что нужно как-то понять что вход под root уже не работает и продолжить остальное

первый будет фэйлиться

потом

Зафейлился - потому что все плохо, или потому что мы уже прокатали

Второй от юзера отработает

тем что живут до конца плейбука

Любые переменные в ансибле живут до конца плейбука

у меня немного другая задача, конфигурация будет накатываться одна и та же всегда по хуку

вы говорите с точки зрения админинистратора который запускает когда нужно и какие ему нужно плейбуки

а вот здесь вопрос у меня как у неадминистратора - почему инфраструктура не однообразно настроена и зачем весь этот движ вокруг то рутом то не рутом

а вот здесь вопрос у меня как у неадминистратора - почему инфраструктура не однообразно настроена и зачем весь этот движ вокруг то рутом то не рутом

Когда добавляется новый сервер провайдер дает root доступ с настроенным ssh ключем. Нужно автоматизировать процесс конфигурирования новых серверов, который состоит из того, чтобы закрыть root доступ и добавить sudo пользователя.

а как вы понимаете новый сервер или нет?

А никак, просто в инвентори добавляется новый хост

может именно в этот момент и запускать плейбук по руту-неруту?

Мне больше нравится вариант конфигурации которая может быть запущена многократно, результат которой предсказуем и приводит к одному финалу.

то есть перебирать кем пустит в систему чтоб отработал ансибл - это норма? ну ок ;)

речь шла о том, что нужно как-то понять что вход под root уже не работает и продолжить остальное

Когда добавляется новый сервер провайдер дает root доступ с настроенным ssh ключем. Нужно автоматизировать процесс конфигурирования новых серверов, который состоит из того, чтобы закрыть root доступ и добавить sudo пользователя.

Просто сделайте инвентарь, куда будут добавляться сервера только после смены настроек авторизации

Новый сервер должен добавиться в кластер путем добваления его в инвентори и коммита в гит

1 коммит и новый сервер конфигурируется

новый или все?

а зачем все?

а зачем все?

Затем чтобы привести систему в должное состояние

так они УЖЕ все приведены в предыдущих коммитах, разве нет?

Кроме добавления хоста коммит может изменить конфигурацию

так они УЖЕ все приведены в предыдущих коммитах, разве нет?

Так же добавление нового сервера может привести к изменению конфигурации других, ну к примеру добавляется новый slave базы данных, конфигурация мастера изменится (в нее добавится новый slave куда к примеру нужно делать репликацию)

я думал мы про начальное конфигурирование. а тут уже слейвы мускуля повсплывали

Если вы используете ansible чтобы сконфигурировать сервера и запускаете ручками какие надо плейбуки чтобы не заходить и не конфигурировать вручную - ок.. но у меня немного другие задачи.

я думал мы про начальное конфигурирование. а тут уже слейвы мускуля повсплывали

В итоге в чем проблема-то?

Когда вы не один администратор в системе возникает необходимость централизованного управления конфигурацией, ее версионинга и т.п.