Попробуем распечатать цитату:

/bin/sh -c 'sudo -H -S -n -u root /bin/sh -c '"'"'echo BECOME-SUCCESS-kgkgdyonvybkjovhnpcbhsocdkkukikb'"'"''

Это /bin/sh выполняется

sudo -H -S -n -u root /bin/sh -c 'echo BECOME-SUCCESS-kgkgdyonvybkjovhnpcbhsocdkkukikb'

что мне кажется нормальным, но по какой-то причине не работает - не выводится (и нет ошибок от sudo):

$ ssh -C -o ForwardAgent=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o Port=2222 -o 'IdentityFile="/home/mg/src/deployments/provisioning/.vagrant/machines/precise/virtualbox/private_key"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=10 -o ControlPath=/home/mg/.ansible/cp/ansible-ssh-%h-%p-%r -tt 127.0.0.1 sudo -H -S -n -u root sh -c 'echo BECOME-SUCCESS-kgkgdyonvybkjovhnpcbhsocdkkukikb'
Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.

Ага. Если я отброшу sh -c и кавычки, то получу желаемый результат:

$ ssh -C -o ForwardAgent=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o Port=2222 -o 'IdentityFile="/home/mg/src/deployments/provisioning/.vagrant/machines/precise/virtualbox/private_key"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=10 -o ControlPath=/home/mg/.ansible/cp/ansible-ssh-%h-%p-%r -tt 127.0.0.1 sudo -H -S -n -u root echo BECOME-SUCCESS-kgkgdyonvybkjovhnpcbhsocdkkukikbWarning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.
BECOME-SUCCESS-kgkgdyonvybkjovhnpcbhsocdkkukikb
Connection to 127.0.0.1 closed.

Я этого не понимаю.

Эй

$ ssh -C ... -tt 127.0.0.1 strace -f sh -c 'echo wat'
execve("/bin/sh", ["sh", "-c", "echo", "wat"], [/* 16 vars */]) = 0
...

И вот почему это не удается.

Добавление еще одного уровня цитирования заставит его работать:

$ ssh -C ... -tt 127.0.0.1 "sh -c 'echo wat'"
wat

Неважно: ansible-playbook -vvv _ принадлежит мне_ и на самом деле не выполняет команды, которые он утверждает, что выполняет.

Я попытался воспроизвести и увидел вывод -vvv, содержащий

<localhost> SSH: EXEC ssh -C -q -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=/home/mg/.ansible/cp/ansible-ssh-%h-%p-%r -tt localhost /bin/sh -c 'sudo -H -S -n -u mg /bin/sh -c '"'"'echo BECOME-SUCCESS-jidcfzolsnlaytjnjowgjiesjkijtqrh; LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /tmp/ansible-tmp-1448352781.72-65353427623045/command'"'"''

что также не работает, если я выполняю его из оболочки, но Ansible действительно преуспевает, а strace подтверждает, что бит "/ bin / sh -c '...'" передается как единственный аргумент:

execve("/usr/bin/ssh", ["/usr/bin/ssh", "-C", "-q", "-o", "ControlMaster=auto", "-o", "ControlPersist=60s", "-o", "KbdInteractiveAuthentication=no", "-o", "PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey", "-o", "PasswordAuthentication=no", "-o", "ConnectTimeout=10", "-o", "ControlPath=/home/mg/.ansible/cp/ansible-ssh-%h-%p-%r", "-tt", "localhost", "/bin/sh -c 'sudo -H -S -n -u mg /bin/sh -c '\"'\"'echo BECOME-SUCCESS-hxrdsqwlxhfaqeaaukwemxnyglaizznx; LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /tmp/ansible-tmp-1448353157.19-275587866328999/command'\"'\"''"], [/* 73 vars */])

Да, это "ложь вам", но когда я переделывал этот код, я решил оставить эту часть в покое. В конце концов, он не передает всю команду в оболочку как одну строку, а использует execve (косвенно, через subprocess.Popen ). Можно оставить как есть или ввести другой уровень pipes.quote() только для отображения, чтобы команда была полностью вырезана и вставлена. Учитывая, что цитата и без того ужасная и неверная (например, # 12290, # 13179), я решил не зацикливать ее дальше.

Но, учитывая, что cmd отправляется как единственный аргумент, я озадачен вашей ошибкой sudo (на данный момент у меня это работает с devel).

Я проверил с помощью pstree -aup в виртуальной машине во время работы ansible.

Я вижу, как Ansible успешно выполняет клонирование git для foo.pov.lt, bar.pov.lt, а затем вижу, как он делает

sshd,1166 -D
  ├─sshd,4422
  │   └─sshd,4524,vagrant 
  │       └─bash,4525
  │           └─pstree,7332 -aup 1166 -l
  └─sshd,6708
      └─sshd,6810,vagrant 
          └─sh,6988 -c sudo -H -S -n -u root /bin/sh -c 'echo BECOME-SUCCESS-twujfdrxzucbaagtolwawxsskbxgnrmt; LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/git; rm -rf "/home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/" > /dev/null 2>&1'
              └─sudo,6989,root -H -S -n -u root /bin/sh -c echo BECOME-SUCCESS-twujfdrxzucbaagtolwawxsskbxgnrmt; LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/git; rm -rf "/home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/" > /dev/null 2>&1
                  └─sh,6990 -c echo BECOME-SUCCESS-twujfdrxzucbaagtolwawxsskbxgnrmt; LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/git; rm -rf "/home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/" > /dev/null 2>&1
                      └─python,6991 /home/vagrant/.ansible/tmp/ansible-tmp-1448355742.59-61543405843328/git
                          └─git,7062 clone --origin origin [email protected]:/git/ivija.pov.lt.git /var/www/ivija.pov.lt
                              ├─git,7098 index-pack --stdin --fix-thin --keep=fetch-pack 7062 on vagrant-ubuntu-precise-64
                              ├─ssh,7063 [email protected] git-upload-pack '/git/ivija.pov.lt.git'
                              └─{git},7097

Затем наступает тайм-аут.

Вывод: сообщение echo BECOME-SUCCESS ... где-то находится в буфере, поэтому, если для запуска модуля требуется больше времени, время ожидания недоступно преждевременно.

О боже. Если я переупорядочу элементы в своей задаче:

- git: [email protected]:/git/{{ item }}.git dest=/var/www/{{ item }}
  with_items:
    - baz.pov.lt
    - foo.pov.lt
    - bar.pov.lt
  tags: websites

тогда Ansible v2 преуспеет!

Вывод: сообщение echo BECOME-SUCCESS ... где-то находится в буфере, поэтому, если для запуска модуля требуется больше времени, время ожидания преждевременно истекает.

Это неправильно .

Посмотрел исходный код:

                    raise AnsibleError('Timeout (%ds) waiting for privilege escalation prompt: %s' % (timeout, stdout))

stdout - это результат, полученный из подпроцесса.

Каким-то образом конечный автомат заклинивает и не понимает, что sudo уже был успешным.

Я добавил несколько отладочных отпечатков, и вот что происходит:

 --> state = 1
 --> stdout = 'BECOME-SUCCESS-iihpirenpoxwdzpoqpoktzmlirjtrozu\r\n'
 --> tmp_stdout = ''
 --> success_key = 'BECOME-SUCCESS-zcnvwvktilslzifcbygketvntxvhiqbt'

Код отладки:

diff --git a/lib/ansible/plugins/connection/ssh.py b/lib/ansible/plugins/connection/ssh.py
index 8bbc031..776aaa9 100644
--- a/lib/ansible/plugins/connection/ssh.py
+++ b/lib/ansible/plugins/connection/ssh.py
@@ -414,6 +414,15 @@ class Connection(ConnectionBase):

             if not rfd:
                 if state <= states.index('awaiting_escalation'):
+                    import sys
+                    sys.stderr.write('\n\n'
+                                     ' --> state = %r\n'
+                                     ' --> stdout = %r\n'
+                                     ' --> tmp_stdout = %r\n'
+                                     ' --> success_key = %r\n'
+                                     '\n'
+                                     % (state, stdout, tmp_stdout, self._play_context.success_key))
+                    sys.stderr.flush()
                     # If the process has already exited, then it's not really a
                     # timeout; we'll let the normal error handling deal with it.
                     if p.poll() is not None:

git bisect обвиняет 9a8e95bff3d01cd06f193ead91997e21dc137bdb

Действия по воспроизведению

• test.yml:

---
- hosts: localhost
  gather_facts: no
  tasks:
    - command: sleep {{item}}
      become: yes
      with_items:
        - 1
        - 15

Ожидаемый результат

$ ansible --version
ansible 1.9.4
  configured module search path = None
$ ansible-playbook -i localhost, test.yml 

PLAY [localhost] ************************************************************** 

TASK: [command sleep {{item}}] ************************************************ 
changed: [localhost] => (item=1)
changed: [localhost] => (item=15)

PLAY RECAP ******************************************************************** 
localhost                  : ok=1    changed=1    unreachable=0    failed=0   

Фактический выход

$ ansible --version
ansible 2.0.0 (stable-2.0 90021104d5) last updated 2015/11/24 08:59:25 (GMT +300)
  lib/ansible/modules/core: (detached HEAD 273112c56d) last updated 2015/11/24 09:00:04 (GMT +300)
  lib/ansible/modules/extras: (detached HEAD e46e2e1d6f) last updated 2015/11/24 09:00:04 (GMT +300)
  config file = 
  configured module search path = Default w/o overrides
$ ansible-playbook -i localhost, test.yml 

PLAY ***************************************************************************

TASK [command] *****************************************************************
fatal: [localhost]: FAILED! => {"failed": true, "msg": "ERROR! Timeout (12s) waiting for privilege escalation prompt: BECOME-SUCCESS-nxrqutnmapmtdleunwcwmxyetitrrlyv\r\n"}

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1   

+1 может подтвердить эту проблему

@stephanadler, если вы установите _connected = False в строке 63 lib/ansible/plugins/connection/ssh.py , это исправит?

@amenonsen Да, это

Здравствуйте

это происходит и в версии 2.0.0.2:

$ ansible --version
доступный 2.0.0.2
файл конфигурации = /Users/misko/.ansible.cfg
настроенный путь поиска модуля = по умолчанию без переопределений

TASK [copy ssh key(s)] ********************************************************* fatal: [myhostname.local]: FAILED! => {"failed": true, "msg": "ERROR! Timeout (12s) waiting for privilege escalation prompt: "}

Просто происходит с 2.0.0.2

планируется ли это исправление для 2.0.1 или будет более ранний патч для 2.0.0.x?

работает 2.0.0.2 и тоже испытывает проблему.

спасибо за исправление btw: cake:

Это тоже влияет на нас и вызывает серьезные головные боли.

То же самое для меня здесь:

Ansible 2.0.0.2

+1 для анзибля 2.0.0.2

Все еще происходит со мной с 2.0.0.2

@ cho-is @zamotivator @cblakkan https://github.com/ansible/ansible/issues/13278#issuecomment -159254725, если вы его еще не видели

Да, это решает проблему, есть ли график, когда это исправление будет выпущено?

это не помогло мне (уже в 2.0.0.2)

@michalmedvecky , вот как выглядят строки 63-65 в lib/ansible/plugins/connection/ssh.py ?

_connected = False
def _connect(self):
    return self

@MrMMorris У меня 2.0.0.2, но строка _connected = False отсутствует

Вывод для версии:

andres<strong i="9">@HALCON</strong>:~ → ansible --version
ansible 2.0.0.2
   config file = /etc/ansible/ansible.cfg
   configured module search path = Default w/o overrides

@ sascha-andres ага, вы должны добавить _connected = False

поэтому это должно произойти в 2.0.0.2, но не в 2.0.1 (открыто, поскольку в 2.0.1 сообщалось, что проблема все еще существует)

cc @ jimi -c

+1

В понедельник, 29 февраля 2016 г., в 23:26, Брайан Кока [email protected]
написал:

cc @ jimi-c https://github.com/jimi-c @amenonsen
https://github.com/amenonsen

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/ansible/ansible/issues/13278#issuecomment -190426855.

Только что видел это снова с 2.0.1.0

+1 для 2.0.1.0

Может ли кто-нибудь опубликовать подробные отладочные данные о неудачном запуске? ANSIBLE_DEBUG=y ansible-playbook -vvvvv … .

Трудно воспроизвести, случается спорадически :(

Полагаю, проблема с долгими задачами.
Например, я время от времени получаю этот тайм-аут при загрузке большого архива> 200 МБ на сервер или при экспорте образа докера из архива tar.gz в докер

Отключение мультиплексирования SSH устранило эту проблему для меня.

[ssh_connection]
ssh_args = -o ForwardAgent=yes -o ControlMaster=no -o StrictHostKeyChecking=no

Я провел немного больше отладки, и оказалось, что при моем подключении к удаленной машине уровень потери пакетов составлял 6% (неравномерный Wi-Fi). Размещение его в той же сети, что и хост Ansible, устранило эту проблему. Так что это был тайм-аут сети, а не тайм-аут «ожидания sudo», но я не уверен, может ли Ansible заметить разницу.

Я не думаю, что это проблема сети, потому что я тестировал в той же сети, когда получил эту ошибку. Однако мультиплексирование ssh, похоже, доставляет мне много проблем. Например, когда второй сеанс ssh пытается создать управляющий сокет с именем, уже существующим в каталоге ControlPath, происходит сбой с тайм-аутом.
Обычно это происходит при использовании with_items в задачах. Отключение мультиплексирования ssh, похоже, исправляет. По крайней мере для меня.

@vutoff Я отключил мультиплексирование, но ошибка все еще возникает.
ansible-2.0.1.0

Та же проблема повышения привилегий с Ansible 2.0.1.0 на серверах Solaris 11.3 x86 .
Хотя 2.0.0.2 работает нормально, become: yes на уровне playbook не работает на 2.0.1.0 ...

---

- hosts: all
  gather_facts: no
  become: yes
  become_user: root
  become_method: su

  tasks:
    - shell: /bin/true

~/git/s11-test ▸ ansible-playbook -i inventory.ini test.yml --ask-become-pass
SUDO password:

PLAY ***************************************************************************

TASK [command] *****************************************************************
fatal: [example.com]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: \r\n\r"}

NO MORE HOSTS LEFT *************************************************************
  to retry, use: --limit @test.retry

PLAY RECAP *********************************************************************
example.com : ok=0    changed=0    unreachable=0    failed=1  

@ passw0rd123 Не могли бы вы опубликовать подробные отладочные данные о неудачном запуске? ANSIBLE_DEBUG=y ansible-playbook -vvvvv …. ?

@amenonsen Я
https://gist.github.com/passw0rd123/aa63b554bd136cbbe95d

@ passw0rd123 Спасибо! Я пройду через это и посмотрю, смогу ли я выяснить, что не так. Между тем, если кто-то еще может воспроизвести проблему, не стесняйтесь публиковать еще одну суть.

Итак, я могу понять, в чем проблема (по крайней мере, в вашем случае):

 38332 1458312677.34175: _low_level_execute_command(): executing: /bin/sh -c 'su  root -c /bin/sh -c '"'"'echo BECOME-SUCCESS-rvajtyhgcqtodequifwsdrooxaxrgwzp; /bin/sh -c '"'"'"'"'"'"'"'"'LANG=de_DE.UTF-8 LC_ALL=de_DE.UTF-8 LC_MESSAGES=de_DE.UTF-8 /usr/bin/python /export/home/admin/.ansible/tmp/ansible-tmp-1458312677.07-145981842056304/command; rm -rf "/export/home/admin/.ansible/tmp/ansible-tmp-1458312677.07-145981842056304/" > /dev/null 2>&1'"'"'"'"'"'"'"'"''"'"''
…
 38332 1458312677.41075: stdout chunk (state=0):
>>>Password: <<<

 38332 1458312677.41093: become_prompt: (source=stdout, state=awaiting_prompt): 'Password: '
 38332 1458312677.41115: Sending become_pass in response to prompt
 38332 1458312677.41177: stdout chunk (state=1):
>>>
<<<

 38332 1458312677.53112: stdout chunk (state=1):
admin<strong i="6">@host</strong>:~$ <<<

Я не могу себе представить, почему выполнение "ssh host cmd" привело бы к запросу. @bcoca имеет некоторое объяснение, но я его не понял, и я не смог воспроизвести его, например, открыв постоянное интерактивное соединение ssh, а затем выполняя команды отдельно и так далее. (Я даже не знаю, могут ли это вызвать ограничения команд в .ssh / authorized_keys.)

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

О, цитата неверна:

/bin/sh -c 'su  root -c /bin/sh -c '"'"'echo BECOME-SUCCESS…

Итак, мы видели, что некоторые команды su игнорируют -c /bin/sh и пытаются выполнить все, что указано для второго -c . Я никогда не видел, чтобы он помещал вас в оболочку, но приведенная выше команда явно неверна, и мы должны это исправить. Но я думал, мы уже применили патч для этого? @bcoca , какие мысли?

О, возможно, он игнорирует _second_ -c и просто выполняет /bin/sh . Это действительно объяснило бы подсказку.

Я хотел бы получить известие от других людей, у которых была такая же проблема, пока у меня есть только один полный журнал отладки для этого (еще раз спасибо @ passw0rd123).

@amenonsen Добро пожаловать! Если вам нужна дополнительная информация, я могу изучить ее в понедельник.
Я могу воспроизвести эту проблему su с 2.0.1.0 на Solaris 11.2 (вместо 11.3) Vagrant Box (на VirtualBox) после установки пароля для root, возможно, это поможет?

https://atlas.hashicorp.com/dariusjs/boxes/solaris_11_2

Воспроизводится с помощью ansible 2.0.1.0 на FreeBSD 11.0-CURRENT для хостов, на которых работает FreeBSD.

Отладочный вывод @xmj , пожалуйста? ANSIBLE_DEBUG=y ansible-playbook -vvvvv …

@amenonsen Вчера я видел эту ошибку с Ansible 2.0.0.2 и 2.0.1.0 , оба с become_method = su AND become_method = sudo на хостах, работающих под управлением FreeBSD 10.2-RELEASE и 10.3-BETA3 ---- но удалось перезаписать файлы журнала (нет, я не пробовал все возможные комбинации).

Сегодня я не смог воспроизвести это снова - похоже, что-то происходит с sudo и файлом sudoers без NOPASSWD.

Я получил то же самое с ansible 2.0.1.0 при попытке подготовить чистый Debian 8.3 на EC2. Очевидно, что я настроил ansible_user=admin но я не ожидал, что мне понадобится что-то еще, чтобы заложить машину.

+1 для ansible 2.1.0 (devel 60c943997b) последнее обновление 2016/03/18
установка ssh_args = (...) ControlMaster = no (...) в [ssh_connection] решила проблему для меня, как это было предложено @vutoff

@amenonsen Это то, что я получил, воспроизводимое на 100%.
https://gist.github.com/grenas/bc758aa38a11df8c6302e3c113406e2f

@amenonsen Я воспроизвел проблему с Ansible 2.0.1.0 (установка pip) в Ubuntu 14.04 при работе с только что запущенным сервером Ubuntu 14.04 EC2.

После запуска сервера я запустил:
ANSIBLE_DEBUG=y ansible <EC2_ID> -s -m shell -a '/bin/true' -vvvvv

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

Есть идеи, почему это работает время от времени?

Вот результаты отладки этих двух шагов, о которых я упоминал выше:

• https://gist.github.com/Lowess/cd34d59c6718bd99cdf8921f4bad4b03

+1 также происходит здесь для только что запущенного Ubuntu 14.04 EC2.

Такой же:
+1 также происходит здесь для только что запущенного Ubuntu 14.04 EC2

+1 происходит здесь случайным образом в экземплярах Ubuntu 14.04 EC2 на Ansible 2.0.2.0 - может быть запущен недавно или после десятка задач.

+1 То же CentOS 7.x
Linux nat-10-0-39-170 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Для людей, столкнувшихся с этой проблемой, попробуйте каждое из следующих изменений перед публикацией:

1. https://github.com/ansible/ansible/issues/13278#issuecomment -187979124
2. https://github.com/ansible/ansible/issues/13278#issuecomment -194349084

@ jimi-c @amenonsen здесь недостаточно информации для исправления? Похоже на довольно распространенную и серьезную проблему

Ни одно из двух предложенных решений у меня не сработало :(

Обновления: кажется, что он не выполняет задачи / игры с установленным become: yes . Мы работаем с Ansible 2.0.1.0 на Ubuntu 14.04 LTS.

В настоящее время я устанавливаю transport = paramiko в ansible.cfg в качестве временного решения. пока эта ошибка не будет исправлена

@MrMMorris Я тоже столкнулся с этой ошибкой в @JohanTan ), но это все еще обычная головная боль. Я заметил, что когда есть другие, запускающие playbooks на том же хосте (в нашем случае у нас есть jumphost, с которого все запускают ansible-playbook), это становится намного хуже и постоянно повторяется.

С transport=paramiko мы действительно теряем способность --diff что немного раздражает. Надеюсь, эта ошибка скоро будет исправлена.

Воспроизводится ли для меня _всегда_, когда _в первый_ раз ssh обращается к недавно запущенным экземплярам ubuntu 14.04 EC2. Застрял только при первой попытке доступа по ssh, все последующие попытки подключаются без ошибок.

11:05:58.294 TASK [setup] *******************************************************************
11:05:58.487 <ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com> ESTABLISH SSH CONNECTION FOR USER: ubuntu
11:05:58.489 <ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o 'IdentityFile="/very/secret/path/.ssh/id_rsa_zzzz"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ubuntu -o ConnectTimeout=10 -o ControlPath=/very/secret/path/.ansible/cp/%h-%p ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-asdfasdfasdf; /bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"''"'"''

11:05:58.550 <ec2-yy-yy-yy-yy.ap-northeast-1.compute.amazonaws.com> ESTABLISH SSH CONNECTION FOR USER: ubuntu
11:05:58.554 <ec2-yy-yy-yy-yy.ap-northeast-1.compute.amazonaws.com> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o 'IdentityFile="/very/secret/path/.ssh/id_rsa_zzzz"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ubuntu -o ConnectTimeout=10 -o ControlPath=/very/secret/path/.ansible/cp/%h-%p ec2-yy-yy-yy-yy.ap-northeast-1.compute.amazonaws.com '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-lksjdhflasdf; /bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"''"'"''

Обновление: эта проблема, похоже, сохраняется в Ansible 2.1.0.0 в соответствии с моим последним тестом.

Я тоже получаю эту ошибку на ansible 2.1.0.0.

24113 1464705052.69173: _low_level_execute_command (): выполнение: / bin / sh -c 'su root -c' "'"' / bin / sh -c '"'" '"" "" "" "" "'" 'echo СТАТЬ -УСПЕХ-zpbisiksiuvwdpwkoahuhghbuwyukulw; / bin / sh -c "/ bin / echo фрактальные ячейки: {url: http://pkg.fractalcells.com/packages/FreeBSD:10:amd64/, включено: true, приоритет: 10}> / etc / pkg / фрактальные ячейки .conf "'"' "'"' "" "" "" "" "''" '"' && sleep 0 '
24113 1464705052.69947: Исходное состояние: awaiting_prompt:
24113 1464705064.70193: завершено выполнение TaskExecutor () для itgitlab / TASK: добавить конфигурацию Fractalcells
24113 1464705064.70409: отправка результата задания
24113 1464705064.70541: отправка результата задачи завершена
24113 1464705064.70589: ВЫХОД ИЗ РАБОЧЕГО ПРОЦЕССА
24112 1464705064.70802: работник 0 имеет данные для чтения
24112 1464705064.71035: получен результат от worker 0:
24112 1464705064.71129: отправка результата: [u'host_task_failed ', u'']
24112 1464705064.71322: результат отправки готов
24105 1464705064.71529: получен результат от обработчика результатов: [u'host_task_failed ', u'']
24105 1464705064.71583: пометка itgitlab как сбойная
24105 1464705064.71644: маркировка хоста itgitlab завершилась неудачно, текущее состояние: СОСТОЯНИЕ ХОСТА: block = 2, task = 1, rescue = 0, always = 0, role = None, run_state = ITERATING_TASKS, fail_state = FAILED_NONE, pending_setup = False, дочернее состояние задач? Нет, спасти детское государство? Нет, всегда дочернее состояние? Нет, началось с задачи? Ложь
24105 1464705064.71779: ^ состояние сбоя теперь: СОСТОЯНИЕ ХОЗЯТА: блок = 2, задача = 1, спасение = 0, всегда = 0, роль = Нет, run_state = ITERATING_COMPLETE, fail_state = FAILED_TASKS, pending_setup = False, дочернее состояние задач? Нет, спасти детское государство? Нет, всегда дочернее состояние? Нет, началось с задачи? Ложь
фатальный: [itgitlab]: НЕ ПРОШЛО! => {"failed": true, "msg": "Тайм-аут (12 с), ожидание запроса на повышение привилегий:"}

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

Есть ли в этом прогресс? Я начал наблюдать это случайным образом с такими модулями, как copy и другими основными модулями, become: true похоже, является тем, что у всех них общего.

Я тоже сталкиваюсь с ними с экземплярами ec2 в 2.1.0.0. Пока вроде только новые экземпляры. Если это не так, я отправлю ответ.

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

Что-то я только что заметил. Ошибка возникает, только если я использую --tags.

+1 происходит случайным образом с использованием 2.1.0.0 на экземплярах EC2, и я не использую --tags

У меня случается с ansible local в OS X, с модулем npm и списком элементов.

Все эти ответы «я тоже» не очень полезны. С этого момента включите:

• версия Ansible
• количество используемых вил
• -vvvvv вывод
• нагрузка на вашу систему в то время (на которую повлияет количество вилок)
• любые измененные настройки SSH, которые могут включать настройку тайм-аута

Для меня:

• Оба Ansible 2.0.1.0 и 2.1.0.0
• 50, но один хост
• извините, в настоящее время недоступно, постараюсь захватить
• минимальный
• Только в ansible.cfg :

[ssh_connection]
control_path = /tmp/ansible-ssh-%%h-%%p-%%r
pipelining = True

Всем привет,
Прежде чем объявить свой случай проблемой доступной, убедитесь, что вы действительно можете подключиться к экземпляру по ssh в то время, когда задача ansible не работает. Экземпляры AWS могут временно не отвечать из-за большого объема дисковых операций EBS, среди прочего, что может повлиять на способность ansible получить доступ к экземпляру.

Есть несколько вещей, которые вы можете сделать, чтобы предотвратить сбой playbook:

1. Увеличьте значение тайм-аута. По умолчанию это 10 секунд, а ansible добавляет еще 2, в сумме 12 секунд. В ansible.cfg просто добавьте строку с более широким таймаутом, например «timeout = 600».
2. Проанализируйте задачи, которые выполняются до той, которая истекает. Если они интенсивно используют диск, скорее всего, это причина проблемы. Есть способы минимизировать проблему, если не устранить ее полностью. Если вы не можете придумать способ улучшить производительность или просто ищете быстрое исправление, добавление ожидания перед неудачной задачей поможет вашей книге без сбоев.

Подсказка: при анализе того, какие задачи замедляются, я считаю, что встроенный профилировщик ansible очень помогает. Добавьте callback_whitelist = profile_tasks в ansible.cfg, чтобы включить его.

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

Я использую ansible 2.0.2.0, и он дает мне ту же ошибку в случае перезапуска службы. Это происходит, когда я пытаюсь перезапустить nginx на моем удаленном компьютере с помощью служебного модуля.

@oleyka Я добавил timeout = 60 но у меня все еще есть «Тайм-аут (12 с), ожидающий запроса на повышение привилегий:» - это означает, что это не тот тайм-аут, о котором вы говорите. Что касается интенсивного использования диска - для меня это всегда первая задача, запущенная на только что загруженном экземпляре EC2, которая дает сбой с этим сообщением.

@adamchainz Возможно, вы захотите вставить задачу wait_for ssh перед своей первой задачей в только что запущенном экземпляре, если у вас ее еще нет. Что-то вроде:

- name: wait for ssh to come up
  wait_for:
    port: 22
    host: "{{ item.private_ip }}"
    delay: 20
    timeout: 600
  with_items: "{{ new_instances.instances }}"

где new_instances - результат вашей задачи запуска ec2.

У меня есть такая задача 😢

Есть ли у кого-нибудь гипотезы, почему это происходит? Есть ли какие-то конкретные строки в источнике, по которым мы могли бы копнуть глубже?

https://github.com/ansible/ansible/blob/de185668829a95fb531d81761d1e36d4427b216b/lib/ansible/plugins/connection/ssh.py#L420

Может ли кто-нибудь воспроизвести это при сборе strace? Т.е. strace -ttf
Было бы интересно посмотреть, появляются ли какие-либо сигналы непосредственно перед ошибкой.

Собираюсь попытаться воспроизвести, но это не очень часто происходит в наших системах.

@isegal

Есть ли у кого-нибудь гипотезы, почему это происходит?

В очень похожей проблеме https://github.com/ansible/ansible/issues/14426#issuecomment -183565130 @bcoca упоминает «переписанное« быстрое обнаружение »», что может быть чем-то, поскольку кажется, что у людей не было проблема с ansible 1.9.x

(извините, впереди длинный пост)

У нас тоже есть эта проблема. Вот сценарий, в котором он встречается:

---
- hosts: backupservers
  vars:
    transfer_snapshot: storage/backup/mssql<strong i="7">@transfer</strong>
    destination_dataset: mssql
    timeout_for_transfer: 21600
  become: true
  tasks:
  - name: List all USB-disks
    shell: "zpool import | awk '/pool:/ { print $2 }' | head -n 1"
    register: usb_pool

  - name: Ensure USB pool is imported
    command: "zpool import {{ usb_pool.stdout }}"

  - name: Cleanup old transfer snapshot
    command: "zfs destroy -r {{ transfer_snapshot }}"
    ignore_errors: yes

  - name: Take transfer snapshot
    command: "zfs snapshot -r {{ transfer_snapshot }}"

  - name: Remove USB datasets
    command: "zfs destroy -r {{ usb_pool.stdout }}"

  - name: Start sending MSSQL snapshots to USB disk
    shell: "zfs send -R {{ transfer_snapshot }} | mbuffer -q -m 128M | zfs recv -u -F {{ usb_pool.stdout }}/{{ destination_dataset }}"
    async: "{{ timeout_for_transfer }}"
    poll: 0
    register: zfs_sender

  - name: Check if zfs sender is done
    async_status: jid={{ zfs_sender.ansible_job_id }}
    register: job_result
    until: job_result.finished
    retries: "{{ timeout_for_transfer // 60 }}"
    delay: 60

  - name: List all backup datasets
    shell: "zfs list -H -t filesystem -r {{ usb_pool.stdout }} | awk '{ print $1 }'"
    register: backup_datasets

  - name: Ensure the backup datasets aren't mounted
    shell: "zfs set mountpoint=none '{{ item }}'"
    with_items:
      - "{{ backup_datasets.stdout_lines }}"

  - name: Export USB pool
    command: "zpool export {{ usb_pool.stdout }}"

  - name: Remove transfer snapshot
    command: "zfs destroy -r {{ transfer_snapshot }}"

А когда не удалось, это выглядело так:

$ ansible-playbook playbooks/backup_copy_to_usb_disk.yml
SUDO password:

PLAY [backupservers] ***********************************************************

TASK [setup] *******************************************************************
ok: [hodor.live.lkp.primelabs.se]

TASK [List all USB-disks] ******************************************************
changed: [hodor.live.lkp.primelabs.se]

TASK [Ensure USB pool is imported] *********************************************
changed: [hodor.live.lkp.primelabs.se]

TASK [Cleanup old transfer snapshot] *******************************************
fatal: [hodor.live.lkp.primelabs.se]: FAILED! => {"changed": true, "cmd": ["zfs", "destroy", "-r", "storage/backup/mssql@transfer"], "delta": "0:00:00.206180", "end": "2016-05-10 16:08:41.515365", "failed": true, "rc": 1, "start": "2016-05-10 16:08:41.309185", "stderr": "could not find any snapshots to destroy; check snapshot names.", "stdout": "", "stdout_lines": [], "warnings": []}
...ignoring

TASK [Take transfer snapshot] **************************************************
changed: [hodor.live.lkp.primelabs.se]

TASK [Remove USB datasets] *****************************************************
changed: [hodor.live.lkp.primelabs.se]

TASK [Start sending MSSQL snapshots to USB disk] *******************************
ok: [hodor.live.lkp.primelabs.se]

TASK [Check if zfs sender is done] *********************************************
FAILED - RETRYING: TASK: Check if zfs sender is done (359 retries left).
FAILED - RETRYING: TASK: Check if zfs sender is done (358 retries left).
fatal: [hodor.live.lkp.primelabs.se]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: "}

NO MORE HOSTS LEFT *************************************************************

PLAY RECAP *********************************************************************
hodor.live.lkp.primelabs.se : ok=7    changed=4    unreachable=0    failed=1

Мы не запускаем этот сценарий так часто, как раз в две недели, и каждый раз с начала мая он терпел неудачу.

Думаю, стоит рассказать, что сделал мой коллега, пытаясь воспроизвести проблему:

Я создал «фиктивный» сценарий, чтобы попытаться отладить это, я могу воспроизвести ошибку, моделируя неисправную сеть (с помощью Network Link Conditioner) в середине учебника.

«Пустышка»:

---
  - hosts: elasticsearch-marvel
    become: yes
    tasks:
      - name: Simulating slow task
        shell: echo "yellow"
        register: result
        until: result.stdout.find("green") != -1
        retries: 600
        delay: 10

Некоторые разные сообщения об ошибках в зависимости от того, используем мы или нет:

Ansible 2.0.2.0

Со стать

$ ansible-playbook playbooks/slow-playbook.yml
SUDO password:

PLAY [elasticsearch-marvel] ****************************************************

TASK [setup] *******************************************************************
ok: [marvel02.live.lkp.primelabs.se]
ok: [marvel01.live.lkp.primelabs.se]

TASK [Simulating slow task] ****************************************************
FAILED - RETRYING: TASK: Simulating slow task (599 retries left).
FAILED - RETRYING: TASK: Simulating slow task (599 retries left).
FAILED - RETRYING: TASK: Simulating slow task (598 retries left).
FAILED - RETRYING: TASK: Simulating slow task (598 retries left).
fatal: [marvel01.live.lkp.primelabs.se]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiti
ng for privilege escalation prompt: "}
fatal: [marvel02.live.lkp.primelabs.se]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiti
ng for privilege escalation prompt: "}

NO MORE HOSTS LEFT *************************************************************

PLAY RECAP *********************************************************************
marvel01.live.lkp.primelabs.se : ok=1    changed=0    unreachable=0    failed=1
marvel02.live.lkp.primelabs.se : ok=1    changed=0    unreachable=0    failed=1

С помощью sudo

$ ansible-playbook playbooks/slow-playbook.yml
SUDO password:
[DEPRECATION WARNING]: Instead of sudo/sudo_user, use become/become_user and make sure
become_method is 'sudo' (default).
This feature will be removed in a future release. Deprecation
 warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

PLAY [elasticsearch-marvel] ****************************************************

TASK [setup] *******************************************************************
ok: [marvel01.live.lkp.primelabs.se]
ok: [marvel02.live.lkp.primelabs.se]

TASK [Simulating slow task] ****************************************************
FAILED - RETRYING: TASK: Simulating slow task (599 retries left).
FAILED - RETRYING: TASK: Simulating slow task (599 retries left).
fatal: [marvel01.live.lkp.primelabs.se]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation > prompt: "}
fatal: [marvel02.live.lkp.primelabs.se]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation > prompt: "}

NO MORE HOSTS LEFT *************************************************************

PLAY RECAP *********************************************************************
marvel01.live.lkp.primelabs.se : ok=1    changed=0    unreachable=0    failed=1
marvel02.live.lkp.primelabs.se : ok=1    changed=0    unreachable=0    failed=1

Не становясь

$ ansible-playbook playbooks/slow-playbook.yml
SUDO password:

PLAY [elasticsearch-marvel] ****************************************************

TASK [setup] *******************************************************************
ok: [marvel02.live.lkp.primelabs.se]
ok: [marvel01.live.lkp.primelabs.se]

TASK [Simulating slow task] ****************************************************
FAILED - RETRYING: TASK: Simulating slow task (599 retries left).
FAILED - RETRYING: TASK: Simulating slow task (599 retries left).
fatal: [marvel02.live.lkp.primelabs.se]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh.", > "unreachable": true}
fatal: [marvel01.live.lkp.primelabs.se]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh.", > "unreachable": true}

PLAY RECAP *********************************************************************
marvel01.live.lkp.primelabs.se : ok=1    changed=0    unreachable=1    failed=0
marvel02.live.lkp.primelabs.se : ok=1    changed=0    unreachable=1    failed=0

Это ansible.cfg использованное для реального прогона выше, и тестовая книга:

[defaults]
hostfile=hosts
log_path=logs/ansible.log
callback_plugins=callback_plugins
callback_whitelist=log_plays_per_host
ask_sudo_pass=True
retry_files_enabled=False
vault_password_file=vault_password.sh
forks=25

[privilege_escalation]
become_ask_pass=True

Я собираюсь запустить наш проблемный сценарий с ANSIBLE_DEBUG=y , -vvvvv , timeout увеличенным до 600, как предлагает @oleyka , и запустить с profile_tasks. Отчитаюсь.

С указанными выше настройками плейбук запустился без проблем. На его прохождение ушло 2 часа 16 минут 32 секунды.

...

PLAY RECAP *********************************************************************
hodor.live.lkp.primelabs.se : ok=12   changed=9    unreachable=0    failed=0

Monday 04 July 2016  18:56:54 +0200 (0:00:00.581)       2:16:28.898 ***********
===============================================================================
Check if zfs sender is done ------------------------------------------ 8149.41s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:32 -------
Remove USB datasets ---------------------------------------------------- 24.60s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:23 -------
Ensure USB pool is imported --------------------------------------------- 3.64s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:13 -------
setup ------------------------------------------------------------------- 2.74s
None --------------------------------------------------------------------------
List all USB-disks ------------------------------------------------------ 2.18s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:9 --------
Ensure the backup datasets aren't mounted ------------------------------- 1.85s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:43 -------
Start sending MSSQL snapshots to USB disk ------------------------------- 1.30s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:26 -------
Take transfer snapshot -------------------------------------------------- 0.83s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:20 -------
Export USB pool --------------------------------------------------------- 0.75s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:48 -------
Remove transfer snapshot ------------------------------------------------ 0.58s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:51 -------
List all backup datasets ------------------------------------------------ 0.52s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:39 -------
Cleanup old transfer snapshot ------------------------------------------- 0.46s
/Users/dentarg/twingly/ansible/playbooks/backup_copy_to_usb_disk.yml:16 -------
 23955 1467651414.69994: RUNNING CLEANUP

Не обращайте внимания на мой последний комментарий ... Я думал о конфигурации sshd, а не о клиенте.

Для клиентской стороны соответствующий параметр может быть ServerAliveInterval , который по умолчанию равен нулю. Это может помочь установить для него ненулевое значение (и настроить ServerAliveCountMax тоже), чтобы получить около 60 секунд до разрыва соединения.

Кто-нибудь захочет попробовать это?

Я столкнулся с той же проблемой с Ansible 2.1 на RHEL 6.7, выполняя playbook на RHEL 7.2. Сбой playbook на модуле копирования.

Я решил проблему, включив -T60 в команду ansible-playbook.

@oleyka Я совершил ошибку, когда реализовал timeout = 60 в нашем репо и обновил неправильный ansible.cfg (у нас есть один, который можно применить только к ящикам Vagrant). Я добавил его в ansible.cfg которые повлияли на наши экземпляры EC2, и с тех пор мы не видели ошибки, спасибо.

@amenonsen с Ansible 2.1.1.0 и включением pipelining = False Проблемы с повышением привилегий ( su ) в Solaris 11.3 x86 вроде бы исчезли. Я должен посмотреть глубже и проверить, сохраняется ли установка, о которой я упоминал в последнем посте ...

Я не уверен, что какое-либо из этих решений мне подходит, у меня есть следующая задача, которая выполняется через ansible local на моем Mac (10.11.5).

- name: Update brew daily
  become: yes
  cron: name="brew autoupdate" special_time="daily"
        user="{{ansible_user_id}}" job="/usr/local/bin/brew update"

И каждый раз я получаю следующую ошибку

TASK [dev : Update brew daily] *************************************************
fatal: [localhost]: FAILED! => {"failed": true, "msg": "timeout waiting for privilege escalation password prompt:\n\nWARNING: Improper use of the sudo command could lead to data loss\nor the deletion of important system files. Please double-check your\ntyping when using sudo. Type \"man sudo\" for more information.\n\nTo proceed, enter your password, or type Ctrl-C to abort.\n\n[sudo via ansible, key=kocvgfumdmtfjadtjmjelblnyhyuzdrn] password: "}

Задача должна занять миллисекунды, поэтому я не уверен, что истекает и почему.

Я использую ansible с ansible-playbook -i "localhost," -c local --ask-become-pass playbook.yml

@SteveEdson, ваша проблема не связана с тайм-аутом, откройте новую проблему. Похоже, ваш sudo ожидает ввода.

@adamchainz , это не та же проблема? Моя ошибка «Тайм-аут ожидания запроса пароля для повышения привилегий» совпадает с заголовком этой проблемы? (За исключением «пароля»)

Я думаю, что это другое, потому что в нем нет «(12s)», поэтому он исходит из другого тайм-аута. Также здесь никто не сообщает о "ожидании ввода"

Далее следует отладочная информация, когда случаются случайные таймауты. Те же самые доступные команды и playbooks отлично работают против хоста Sol11 в более ранней версии, работают нормально без проблем, например целевая версия: 0.5.11 (Oracle Solaris 11.3.1.5.0) a-OK.

Версия Ansible 2.1.1.0
Управляющий хост Centos 7.1
Целевой хост Solaris 11.3 x86 Версия: 0.5.11 (Oracle Solaris 11.3.10.5.0)

https://gist.github.com/asil75/1eabfa921790d5825f1d9c9c26fd27c8

annsible.cfg:

[по умолчанию]
remote_tmp = /tmp/.ansible/tmp
тайм-аут = 30
jinja2_extensions = jinja2.ext.do, jinja2.ext.i18n, jinja2.ext.loopcontrols
[привилегия_эскалации]
[paramiko_connection]
[ssh_connection]
[ускоряться]
[selinux]
[цвета]

hth.

Ansible 2.0.0.2 на моем Ubuntu 16 64 бит все еще получает эту ошибку. Но в моем случае я могу без проблем применить свой playbook на моем образе Vagrant, просто получаю эту ошибку, когда я пытаюсь запустить его на моем экземпляре EC2.

ansible -i my_inventory my_aws_server -m ping работает: ok_hand::
ansible-playbook -i my_inventory -l aws_server playbook.yml fail: hankey:
ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml работает: ok_hand:

Если я использую -vvvv , скопируйте команду / параметры exec ssh и запустите ее вручную, она без проблем подключается к моему экземпляру ec2.

Попытка добавить ssh_args = -o ForwardAgent=yes -o ControlMaster=no -o StrictHostKeyChecking=no к /etc/ansible/ansible.cfg безуспешно;

Попытка добавить transport = paramiko в / etc / ansible / ansible.cfg` безуспешно;

МОЕ РЕШЕНИЕ

Добавлен timeout=30 в /etc/ansible/ansible.cfg . Это не тайм-аут «задачи», поскольку у меня есть задачи, которые занимают гораздо больше времени, чем обновление linux apt, установка python3 и т. Д.

Проблема не обязательно в ansible, она может быть в неправильно настроенном / etc / hosts или в другой проблеме с DNS.

Пожалуйста, проверьте две вещи:

1. Убедитесь, что вы можете войти на хостинг достаточно быстро по ssh. Обычно это занимает менее одной секунды.
2. Убедитесь, что вы можете запускать sudo достаточно быстро. Обычно это намного меньше одной секунды.

Большие задержки ssh обычно вызваны неполной настройкой DNS. То же самое и с задержками sudo.

Общая проблема с медленным sudo - это неполный / etc / hosts. Должно получиться примерно так:

127.0.0.1 localhost
127.0.1.1 example.com

(Пользователи Openstack: обратите внимание на параметр manage_etc_hosts. Это решит эту проблему)

Чтобы предупредить:
Моя среда:

ansible 2.1.1.0
  config file = /foo/ansible.cfg
  configured module search path = ['/usr/share/ansible']
Python 2.7.12+
OS: Kali rolling

Я запустил сценарий, содержащий несколько ролей против локальной виртуальной машины. Без сознательного изменения я внезапно получил ошибку тайм-аута, упомянутую выше. Сначала я попробовал решение @vutoff, упомянутое в этом комментарии , которое, похоже, работает для меня. В настоящее время я слежу за этим комментарием от @vmenezes.

Я отредактирую этот комментарий, если получу новую информацию.
Спасибо всем, кто здесь помогает!

Спасибо @vmenezes , добавление timeout = 30 в /etc/ansible/ansible.cfg помогло мне. Я использую ansible 2.1.1.0 в среде MAC + CentOS-Vagrant.

Привет всем, надеюсь, это поможет некоторым людям:

Мы столкнулись с этой проблемой, т.е. «Тайм-аут ожидания запроса на повышение привилегий». Мы потратили время на его отладку, и вот что мы обнаружили. Надеюсь, люди более умные и более вовлеченные в ansible смогут использовать это как отчет об ошибке.

1. целевой хост разрешается записью / etc / hosts в доступной системе
2. нет проблем с сетью или задержек
3. оба узла rhel7
4. ssh на целевой хост работает с использованием ключей, без подсказок или задержек
5. однажды на целевом хосте sudo to root работает должным образом, без запросов или задержек
6. ansible-playbook версии 2.2.0

Используя ПУСТОЙ файл ansible.cfg как в / etc, так и в ~ / .ansible.cfg, мы создали тестовую книгу, которая дает сбой в 100% случаев.

testcase.yml:

---

- name: testcase
  hosts: testhost
  become: true
  tasks:

  - name: testcase
    shell:
      cmd: sleep 30

Мы запустим этот тестовый пример с помощью команды:
/usr/bin/ansible-playbook -i ./testhost ./testcase.yml

Ошибка, которую мы получили примерно через 12 секунд после начала игры, была следующей:
fatal: [testhost]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: \u001b[?25h\u001b[0G\u001b[K\u001b[?25h\u001b[0G\u001b[KBECOME-SUCCESS-beunzsdqhofnfczeeceajvbxfmzldrxn\r\n"}

Обратите внимание, что, хотя в play и говорилось, что это не удалось, команда sleep 30 действительно была запущена и явно выполнялась. Выполнение команды «sleep 30» и доступное соединение с целевым хостом были прерваны на отметке 12 с, когда он определил, что ему не удалось получить приглашение на повышение уровня доступа.

Основываясь на этом потоке, мы предположили, что если выполняемая команда (например, сон 30) не завершится ДО значения тайм-аута, возникнет эта ошибка. Для проверки, если бы мы повторно запустили то же самое с большим таймаутом, и действительно, мы обнаружили, что это будет успешно. Это, возможно, объясняет, почему некоторые плакаты показывали успех с 30-секундным таймаутом - если их игра завершается в течение 30 секунд, ошибок нет. Для тех, у кого команды занимают> 30 секунд, они все равно столкнутся с ошибкой.

Мы могли бы успешно запустить этот тестовый сценарий, используя следующую команду:
/usr/bin/ansible-playbook -i ./testhost ./testcase.yml -T35

Результат успеха:

TASK [testcase] ****************************************************************
changed: [testhost]

В нескольких параллельных испытаниях, где изменено только значение -T тайм-аута: наличие тайм-аута <время воспроизведения всегда будет отображать эту ошибку, а наличие тайм-аута> время воспроизведения всегда будет приводить к успеху.

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

В любом случае мы пошли дальше. Мы смогли обнаружить, что если мы установим pipelining = true в ansible.cfg, то нам НЕ нужно будет настраивать значение тайм-аута, и воспроизведение будет выполняться, как ожидалось. Пример ansible.cfg

[ssh_connection]
pipelining=true

С включенной конвейерной обработкой и идентичным описанным выше тестовым случаем, даже когда мы запускали playbook с очень коротким таймаутом (например, 5 секунд), воспроизведение все равно завершалось, как ожидалось.
/usr/bin/ansible-playbook -i ./testhost ./testcase.yml -T5

В нескольких последовательных испытаниях, где тайм-аут был намного меньше времени воспроизведения (5 секунд против 30, что вызвало бы ошибку согласно нашему предыдущему тестированию значений тайм-аута), и где единственное, что изменилось между испытаниями, это конвейерная обработка = true / false: наличие ssh pipelining = true всегда будет приводить к успеху, а ssh pipelining = false всегда будет отображать эту ошибку.

Надеюсь, это поможет некоторым людям, если потребуется дополнительная информация, ответьте.

Спасибо,

Всем привет,
Я тоже столкнулся с этой проблемой с доступной версией: 2.1.1.0
Я пробовал все эти обходные пути, упомянутые в этом посте. но не повезло ...
пожалуйста предложите

Думаю, я тоже столкнулся с этой проблемой. Задача, которая висит в моем playbook, выглядит так:

- name: deploy static config files and scripts
  copy: src=rootdir/ dest=/

Он должен рекурсивно копировать несколько файлов конфигурации - в основном в /etc и подпапки.
Я также получаю указанную выше ошибку тайм-аута.
Как я могу проверить, такая же ли проблема? Что я могу сделать, чтобы обойти это?

тоже происходит здесь. timeout = 30 в ansible.cfg исправьте это, но с большой медленностью (1 час 36 минут до 15 минут до появления ошибки)
единственная цель хоста в digitalocean

$ ansible --version
ansible 2.2.0.0
  config file = /opt/tmp/vagrant/homelab/ansible.cfg
  configured module search path = Default w/o overrides
$ egrep -v '(^#|^$)' ansible.cfg 
[defaults] 
log_path=ansible.log
roles_path = ./
transport = ssh
forks=5
callback_plugins = callback_plugins/
timeout = 30
[ssh_connection]
ssh_args = -o ForwardAgent=yes
pipelining=True
scp_if_ssh=True
$ ansible-playbook -i inventory --limit target playbook.yml -vvvvv
[...]
TASK [sketchy : git clone sketchy] *********************************************
task path: /home/user/Documents/script/homelab/roles/sketchy/tasks/main.yml:35
Using module file /usr/local/lib/python2.7/dist-packages/ansible/modules/core/source_control/git.py
<10.5.1.29> ESTABLISH SSH CONNECTION FOR USER: root
<10.5.1.29> SSH: ansible.cfg set ssh_args: (-o)(ForwardAgent=yes)
<10.5.1.29> SSH: ANSIBLE_PRIVATE_KEY_FILE/private_key_file/ansible_ssh_private_key_file set: (-o)(IdentityFile="/home/user/.ssh/keys/mysshkey")
<10.5.1.29> SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-key
ex,hostbased,publickey)(-o)(PasswordAuthentication=no)
<10.5.1.29> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=root)
<10.5.1.29> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
<10.5.1.29> SSH: PlayContext set ssh_common_args: ()
<10.5.1.29> SSH: PlayContext set ssh_extra_args: ()
<10.5.1.29> SSH: EXEC ssh -vvv -o ForwardAgent=yes -o 'IdentityFile="/home/user/.ssh/keys/mysshkey"' -o KbdInteractiveAuthentication=no -o P
referredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 10.5.1.29 '/bin/s
h -c '"'"'sudo -H -S -n -u _sketchy /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-rvizprhpalwltpdgmkyrsznzvhtcvmwg; /usr/bin/python'"'"'"'"'"'"'"'"' && sle
ep 0'"'"''
fatal: [target]: FAILED! => {
    "failed": true, 
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}
...ignoring

TASK [sketchy : install pip virtualenv] ****************************************
task path: /home/user/Documents/script/homelab/roles/sketchy/tasks/main.yml:42
Using module file /usr/local/lib/python2.7/dist-packages/ansible/modules/core/packaging/language/pip.py
<10.5.1.29> ESTABLISH SSH CONNECTION FOR USER: root
<10.5.1.29> SSH: ansible.cfg set ssh_args: (-o)(ForwardAgent=yes)
<10.5.1.29> SSH: ANSIBLE_PRIVATE_KEY_FILE/private_key_file/ansible_ssh_private_key_file set: (-o)(IdentityFile="/home/user/.ssh/keys/mysshkey")
<10.5.1.29> SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-key
ex,hostbased,publickey)(-o)(PasswordAuthentication=no)
<10.5.1.29> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=root)
<10.5.1.29> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
<10.5.1.29> SSH: PlayContext set ssh_common_args: ()
<10.5.1.29> SSH: PlayContext set ssh_extra_args: ()
<10.5.1.29> SSH: EXEC ssh -vvv -o ForwardAgent=yes -o 'IdentityFile="/home/user/.ssh/keys/mysshkey"' -o KbdInteractiveAuthentication=no -o P
referredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 10.5.1.29 '/bin/s
h -c '"'"'/usr/bin/python && sleep 0'"'"''
ok: [target] => {
    "changed": false, 
    "cmd": "/usr/bin/pip2 install virtualenv", 
    "invocation": {
        "module_args": {
            "chdir": null, 
            "editable": true, 
            "executable": null, 
            "extra_args": null, 
            "name": [
                "virtualenv"
            ], 
            "requirements": null, 
            "state": "present", 
            "umask": null, 
            "use_mirrors": true, 
            "version": null, 
            "virtualenv": null, 
            "virtualenv_command": "virtualenv", 
            "virtualenv_python": null, 
            "virtualenv_site_packages": false
        }, 
        "module_name": "pip"
    }, 
    "name": [
        "virtualenv"
    ], 
    "requirements": null, 
    "state": "present", 
    "stderr": "You are using pip version 8.1.1, however version 9.0.1 is available.\nYou should consider upgrading via the 'pip install --upgrade pip' command.\n", 
    "stdout": "Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages\n", 
    "stdout_lines": [
        "Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages"
    ], 
    "version": null, 
    "virtualenv": null
}

TASK [sketchy : install sketchy pip dependencies inside virtualenv] ************
task path: /home/user/Documents/script/homelab/roles/sketchy/tasks/main.yml:44
Using module file /usr/local/lib/python2.7/dist-packages/ansible/modules/core/packaging/language/pip.py
<10.5.1.29> ESTABLISH SSH CONNECTION FOR USER: root
<10.5.1.29> SSH: ansible.cfg set ssh_args: (-o)(ForwardAgent=yes)
<10.5.1.29> SSH: ANSIBLE_PRIVATE_KEY_FILE/private_key_file/ansible_ssh_private_key_file set: (-o)(IdentityFile="/home/user/.ssh/keys/mysshkey")
<10.5.1.29> SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
<10.5.1.29> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=root)
<10.5.1.29> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
<10.5.1.29> SSH: PlayContext set ssh_common_args: ()
<10.5.1.29> SSH: PlayContext set ssh_extra_args: ()
<10.5.1.29> SSH: EXEC ssh -vvv -o ForwardAgent=yes -o 'IdentityFile="/home/user/.ssh/keys/mysshkey"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 10.5.1.29 '/bin/sh -c '"'"'sudo -H -S -n -u _sketchy /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-gashrpsdazspmuutfkzlacolenowlxkz; /usr/bin/python'"'"'"'"'"'"'"'"' && sleep 0'"'"''
fatal: [target]: FAILED! => {
    "failed": true, 
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}

target$ sar
[about 70% idle, 10-15% system, 10-15% user]

Также получите это из оркестратора macos 10.11 в гостевую 10.12 (та же LAN)
timeout = 30 обходной путь в порядке. разница продолжительности была более приемлемой. около ~ 2 мин против ~ 6 мин

$ ansible --version
ansible 2.2.0.0
  config file = /Users/julien/script/homelab/ansible.cfg
  configured module search path = Default w/o overrides
[same ansible.cfg as above]
$ ansible-playbook -i inventory --limit air mac.yml -vvvv
[...]
TASK [harden-darwin : add application to allow incoming] ***********************
task path: /Users/myuser/roles/harden-darwin/tasks/firewall.yml:24
Using module file /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ansible/modules/core/commands/command.py
<10.0.1.7> ESTABLISH SSH CONNECTION FOR USER: deploy
<10.0.1.7> SSH: EXEC ssh -vvv -o ForwardAgent=yes -o 'IdentityFile="/Users/myuser/.ssh/keys/key-201612"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=deploy -o ConnectTimeout=10 10.0.1.7 '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-jxassxqmjklqyzqlthojhnqljcxexifg; /usr/bin/python'"'"'"'"'"'"'"'"' && sleep 0'"'"''
fatal: [air]: FAILED! => {
    "failed": true, 
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}

UNREACHABLE! => {
    "changed": false, 
    "msg": "SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", 
    "unreachable": true
}

работает со второй попытки

$ ansible --version
ansible 2.2.0.0

@jamesongithub , это другая ошибка, нежели обсуждаемая здесь.

Извините, я также получал ошибку повышения привилегий. В OSX.

Я получил ту же ошибку в MacOSX El Capitan и Yosemite, но не в macOS Sierra после перехода с Ansible 1.9.1 на 2.2.0. После целого дня устранения неполадок мне, наконец, удалось определить виновника значения переменной sudo_flags, которое в нашей конфигурации было -i . Я не мог понять почему, но при вызове ssh <user>@<host> 'sudo -i -u builder /bin/sh -c '"'"'echo a; echo b; echo c; echo BECOME-SUCCESS-ykvssengiokabkumhzrlbnxinmsjxfpz; '"'"' && sleep 0' первая строка всегда опускалась из вывода. Первая строка Ansible - это строка Become Success, и если она отсутствует, время ожидания команды истекает. В конце концов, мы заменили этот параметр на -H который в нашем случае работал нормально. Разница в том, что он прекратил выполнение сценариев профиля пользователя, как это было с -i .

Если вы измените имя хоста целевой машины на;

Файл имени хоста

/ etc / hostname
вы также должны добавить новое имя;

Файл локальных DNS-хостов

/ etc / hosts
127.0.0.1 имя_нового_хоста

Иначе, каждый раз, когда вы запускаете # sudo su, сервер будет задерживать запрос на эскалацию, потому что он пытается разрешить новое имя.

Вы также можете изменить ansible.cfg на;
# Тайм-аут SSH
тайм-аут = 60
gather_timeout = 60

@mgedmin Привет! Спасибо, что нашли время, чтобы открыть этот вопрос. Чтобы сообщество могло эффективно решить вашу проблему, нам нужно немного больше информации.

Вот элементы, которые мы не смогли найти в вашем описании:

• тип проблемы
• имя компонента

Задайте описание этой проблемы с помощью этого шаблона:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

нажмите здесь, чтобы получить помощь по ботам

Эта проблема давно исчезла в Solaris 11 x86, но теперь снова появилась в Ansible 2.3.0.0 😞 Если я правильно помню, она всегда выходила из строя, если был включен Pipelining , но без этого все работало нормально.

Соединение через SSH работает, но время ответа на повышение привилегий до root через su истекает.

fatal: [host.example.com]: FAILED! => {
    "failed": true, 
    "msg": "Timeout (62s) waiting for privilege escalation prompt: "
}

Вот полный вывод отладки в этом разделе:

<host.example.com> ESTABLISH SSH CONNECTION FOR USER: admin
<host.example.com> SSH: ansible.cfg set ssh_args: (-C)(-o)(ControlMaster=auto)(-o)(ControlPersist=60s)
<host.example.com> SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
<host.example.com> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=admin)
<host.example.com> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
<host.example.com> SSH: PlayContext set ssh_common_args: ()
<host.example.com> SSH: PlayContext set ssh_extra_args: ()
<host.example.com> SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath=/Users/username/.ansible/cp/d6313ea46e)
<host.example.com> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=admin -o ConnectTimeout=10 -o ControlPath=/Users/username/.ansible/cp/d6313ea46e -tt host.example.com '/bin/sh -c '"'"'su  root -c '"'"'"'"'"'"'"'"'/bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-oqvkeuwptoqgvjiknvhcsreimefzsmvo; /usr/bin/python /home/admin/.ansible/tmp/ansible-tmp-1493043257.92-168849063784581/setup.py; rm -rf "/home/admin/.ansible/tmp/ansible-tmp-1493043257.92-168849063784581/" > /dev/null 2>&1'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"' && sleep 0'"'"''
  6133 1493043258.53019: Initial state: awaiting_prompt: <function detect_su_prompt at 0x10cced050>
  6133 1493043258.53967: stderr chunk (state=0):
>>>OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 21: Applying options for host.example.com
<<<

  6133 1493043258.54051: stderr chunk (state=0):
>>>debug3: kex names ok: [diffie-hellman-group1-sha1]
debug1: /Users/username/.ssh/config line 291: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: UpdateHostKeys=ask is incompatible with ControlPersist; disabling
debug1: auto-mux: Trying existing master
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 6137
debug3: mux_client_request_session: session request sent
<<<

  6133 1493043258.54203: stderr chunk (state=0):
>>>debug1: mux_client_request_session: master session id: 2
<<<

  6133 1493043258.56315: stdout chunk (state=0):
>>>Password: <<<

  6133 1493043270.56450: done running TaskExecutor() for host.example.com/TASK: Gathering Facts
  6133 1493043270.56487: sending task result
  6133 1493043270.56571: done sending task result
  6133 1493043270.56617: WORKER PROCESS EXITING
  6061 1493043270.56744: marking host.example.com as failed
  6061 1493043270.56785: marking host host.example.com failed, current state: HOST STATE: block=0, task=0, rescue=0, always=0, run_state=ITERATING_SETUP, fail_state=FAILED_NONE, pending_setup=True, tasks child state? (None), rescue child state? (None), always child state? (None), did rescue? False, did start at task? False
  6061 1493043270.56804: ^ failed state is now: HOST STATE: block=0, task=0, rescue=0, always=0, run_state=ITERATING_COMPLETE, fail_state=FAILED_SETUP, pending_setup=True, tasks child state? (None), rescue child state? (None), always child state? (None), did rescue? False, did start at task? False
  6061 1493043270.56838: getting the next task for host host.example.com
  6061 1493043270.56848: host host.example.com is done iterating, returning
fatal: [host.example.com]: FAILED! => {
    "failed": true, 
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}
  6061 1493043270.56973: no more pending results, returning what we have
  6061 1493043270.56995: results queue empty
  6061 1493043270.57005: checking for any_errors_fatal
  6061 1493043270.57017: done checking for any_errors_fatal
  6061 1493043270.57027: checking for max_fail_percentage
  6061 1493043270.57042: done checking for max_fail_percentage
  6061 1493043270.57053: checking to see if all hosts have failed and the running result is not ok
  6061 1493043270.57064: done checking to see if all hosts have failed
  6061 1493043270.57074: getting the remaining hosts for this loop
  6061 1493043270.57115: done getting the remaining hosts for this loop
  6061 1493043270.57136: building list of next tasks for hosts
  6061 1493043270.57143: getting the next task for host host.example.com
  6061 1493043270.57150: host host.example.com is done iterating, returning
  6061 1493043270.57156: done building task lists
  6061 1493043270.57165: counting tasks in each state of execution
  6061 1493043270.57175: done counting tasks in each state of execution:
    num_setups: 0
    num_tasks: 0
    num_rescue: 0
    num_always: 0
  6061 1493043270.57185: all hosts are done, so returning None's for all hosts
  6061 1493043270.57191: done queuing things up, now waiting for results queue to drain
  6061 1493043270.57198: results queue empty
  6061 1493043270.57203: checking for any_errors_fatal
  6061 1493043270.57207: done checking for any_errors_fatal
  6061 1493043270.57212: checking for max_fail_percentage
  6061 1493043270.57217: done checking for max_fail_percentage
  6061 1493043270.57221: checking to see if all hosts have failed and the running result is not ok
  6061 1493043270.57225: done checking to see if all hosts have failed
  6061 1493043270.57232: getting the next task for host host.example.com
  6061 1493043270.57238: host host.example.com is done iterating, returning

Те же проблемы возникают с виртуальными машинами MacOSX (Sierra) и Debian8.7 в Parallels Desktop с запросом пароля SU.

Проблема, похоже, связана с тем, что сторона Python не получает «Пароль:» (или «отсутствует»), поскольку я могу выполнить команду -vvvv ssh с копией-вставкой в ​​оболочке, и она подключается, предоставляет приглашение Пароль: , Я ввожу пароль, и он отлично выполняет su и т. Д.

Запустил sshd -dd на пультах дистанционного управления, и я могу подтвердить, он действительно читает информацию, особенно отладочную информацию в поле msg, просто не «видит» приглашение Password: (
Возможно что-то еще в настройках команды su и перенаправления конвейера / терминала?

"msg": "Timeout (32s) waiting for privilege escalation prompt: Environment:\r\n USER=debian\r\n LOGNAME=debian\r\n HOME=/home/debian\r\n PATH=/usr/local/bin:/usr/bin:/bin:/usr/games\r\n MAIL=/var/mail/debian\r\n SHELL=/bin/bash\r\n SSH_CLIENT=10.10.10.2 61637 22\r\n SSH_CONNECTION=10.10.10.2 61637 10.10.10.114 22\r\n SSH_TTY=/dev/pts/1\r\n TERM=xterm-256color\r\n LANG=en_US.UTF-8\r\n LANGUAGE=en_ZA:en\r\n SSH_AUTH_SOCK=/tmp/ssh-80HbP4JU39/agent.2224\r\n"

Те же проблемы возникают с виртуальными машинами MacOSX (Sierra) и Debian8.7 в Parallels Desktop с запросом пароля SU.

В версии 2.3 есть проблема с su которая была решена в https://github.com/ansible/ansible/pull/23710.

@sivel теперь, как получить эту версию, которая исправлена ​​на моем MacOSX с помощью pip ?? знак равно

@ passw0rd123 Некоторые мысли, глядя на этот вывод отладки ...

РЕДАКТИРОВАТЬ : я смотрел на более новый код, я подозреваю, что это проблема, упомянутая @sivel, исправлена ​​в # 23710

host.example.com> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=admin -o ConnectTimeout=10 -o ControlPath=/Users/username/.ansible/cp/d6313ea46e -tt host.example.com '/bin/sh -c '"'"'su  root -c '"'"'"'"'"'"'"'"'/bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-oqvkeuwptoqgvjiknvhcsreimefzsmvo; /usr/bin/python /home/admin/.ansible/tmp/ansible-tmp-1493043257.92-168849063784581/setup.py; rm -rf "/home/admin/.ansible/tmp/ansible-tmp-1493043257.92-168849063784581/" > /dev/null 2>&1'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"' && sleep 0'"'"''
  6133 1493043258.53019: Initial state: awaiting_prompt: <function detect_su_prompt at 0x10cced050>
  6133 1493043258.53967: stderr chunk (state=0):
>>>OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 21: Applying options for host.example.com
<<<

  6133 1493043258.54051: stderr chunk (state=0):
>>>debug3: kex names ok: [diffie-hellman-group1-sha1]
debug1: /Users/username/.ssh/config line 291: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: UpdateHostKeys=ask is incompatible with ControlPersist; disabling
debug1: auto-mux: Trying existing master
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 6137
debug3: mux_client_request_session: session request sent
<<<

  6133 1493043258.54203: stderr chunk (state=0):
>>>debug1: mux_client_request_session: master session id: 2
<<<

  6133 1493043258.56315: stdout chunk (state=0):
>>>Password: <<<

  6133 1493043270.56450: done running TaskExecutor() for host.example.com/TASK: Gathering Facts
  < misc debug cut here >
  6133 1493043270.56617: WORKER PROCESS EXITING
  < misc debug cut here >
fatal: [host.example.com]: FAILED! => {
    "failed": true, 
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}

Это похоже на то, что я ожидал, если мы никогда не выйдем из цикла обработки начального события в
https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/ssh.py#L629 -L651

                for key, event in events:
                    if key.fileobj == p.stdout:
                        b_chunk = p.stdout.read()
                        if b_chunk == b'':
                            # stdout has been closed, stop watching it
                            selector.unregister(p.stdout)
                            # When ssh has ControlMaster (+ControlPath/Persist) enabled, the
                            # first connection goes into the background and we never see EOF
                            # on stderr. If we see EOF on stdout, lower the select timeout
                            # to reduce the time wasted selecting on stderr if we observe
                            # that the process has not yet existed after this EOF. Otherwise
                            # we may spend a long timeout period waiting for an EOF that is
                            # not going to arrive until the persisted connection closes.
                            timeout = 1
                        b_tmp_stdout += b_chunk
                        display.debug("stdout chunk (state=%s):\n>>>%s<<<\n" % (state, to_text(b_chunk)))
                    elif key.fileobj == p.stderr:
                        b_chunk = p.stderr.read()
                        if b_chunk == b'':
                            # stderr has been closed, stop watching it
                            selector.unregister(p.stderr)
                        b_tmp_stderr += b_chunk
                        display.debug("stderr chunk (state=%s):\n>>>%s<<<\n" % (state, to_text(b_chunk)))

Если мы получили фрагменты stderr и stdout, показанные в журнале, то либо:

1) заблокирован на одном из вызовов read (). Не должно происходить в этом сценарии, но может быть ошибка селектора?
2) Цикл for продолжал получать события, отличные от stderr / non-stdout?

Может что-то конкретное для соляриса?

Тем не менее, любой из них должен в конечном итоге разблокироваться, и будет вызвана explore_prompt (), которая установит флаг begin_success и отправку пароля. Но похоже, что этого не происходит ...

Для людей, которые попали сюда из-за поиска в Google, я поднял # 25437 для случая с тем же сообщением об ошибке, но вызванным переполнением целевых дисков.

Раньше у меня было это периодически (с клиентской OS X и целевой CentOS 7.3).

Теперь у меня есть 100% воспроизводимый случай использования Ansible 2.2.3.0 с тривиальным учебником. ( ОБНОВЛЕНИЕ: это исправлено в 2.3.1.0 из-за https://github.com/ansible/ansible/pull/23710)

Это происходит только тогда, когда я использую -vvvv или -vvvvv - если я использую -vvv , -vv или меньше, этого не происходит (проверено много раз, только варьируя этот коэффициент). Клиент - OS X 10.11, цель - Ubuntu 14.04. Пособие просто:

- hosts: all
  become: yes

Я могу предоставить полную информацию, если это вас интересует - излишняя многословность, вызвавшая это, была довольно неожиданной.

Нужна помощь в решении проблемы синтаксиса pbrun. ---

имя: коснитесь файла
хосты: тест
становятся истинными
стать_метод: pbrun
стать_пользователем: ops
стать_flags: 'ops'
задачи:
имя: запустить touch cmmand
команда: "touch /tmp/1.txt"
SSH: EXEC sshpass -d12 ssh -vvv -C -o ControlMaster = auto -o ControlPersist = 60s -o User = portal -o ConnectTimeout = 10 -o ControlPath = / home / ops / .ansible / cp / ansible-ssh-% h-% p-% r -tt xxx.xx.xxx.xxx '/ bin / sh -c' "'"' pbrun ops -u ops '"'" "" "" "" "" "" "" ' echo СТАТЬ-УСПЕХ-oiqkzexpuphtwjesfjmrzmqfcrjdccre; / usr / bin / python /tmp/ansible-tmp-1498555805.91-140035303656300/setup.py '"'" '"" "" "" "" "" "' && sleep 0 '"' "''
фатальный: [168.72.164.236]: НЕ ВЫПОЛНЕНО! => {
"не удалось": правда,
"msg": "Тайм-аут (12 с) ожидания запроса повышения привилегий: \ r \ n \ r \ n \ r \ n"
}

@ctidocker ваша проблема выглядит совсем иначе - предлагаю вам открыть новую проблему.

Мы считаем, что исходная проблема, о которой сообщалось, была исправлена ​​в версии 2.3.1. Мы закрываем эту проблему, и если у вас все еще есть проблемы с SSH, пожалуйста, откройте конкретную проблему github с как можно более подробными сведениями вместе с репродуктором, спасибо!

Вот как я решил проблему. Все сводилось к параметрам, используемым в файле yaml
Параметр стал_метод был виноват
Предыдущая настройка была
стать: да
стать_метод: su

Изменил это на
стать: да
стать_method: sudo
он начал работать без проблем. Поэкспериментируйте с этим параметром, должно быть, что-то связано с оболочкой, как я на suse 12
ansible --version
ansible 2.7.0.dev0 (devel 27b85e732d) последнее обновление 2018/06/20 16:15:16 (GMT +000)
версия python = 2.7.13 (по умолчанию, 11 января 2017 г., 10:56:06) [GCC]

также для устранения неполадок эта команда была очень полезна
ANSIBLE_DEBUG = 1 ansible-playbook test2.yml -vvv
ссылка ниже также помогла https://docs.ansible.com/ansible/latest/user_guide/become.html?highlight=assume%20root
Надеюсь, это решит проблему
PS: Увеличение тайм-аута и параметра конвейера, похоже, не помогло мне

С Уважением
Рувим

@amenonsen Да, это

Пытался отремонтировать таким способом, но не удалось. Вы не могли бы мне помочь?