دعنا نحاول فك الاقتباس:

/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 */])

نعم ، هذا "يكذب عليك" ، لكن عندما كنت أعيد صياغة هذا الرمز ، اخترت ترك هذا الجزء وشأنه. إنه لا يقوم بتغذية الأمر بأكمله كسلسلة واحدة إلى shell ، بعد كل شيء ، ولكن باستخدام execve (بشكل غير مباشر ، عبر subprocess.Popen ). تتمثل الخيارات في تركه كما هو ، أو تقديم مستوى آخر pipes.quote() للعرض فقط لجعل الأمر قابلاً للقص واللصق بالكامل. نظرًا لأن عرض الأسعار مروع بالفعل ومكسور (على سبيل المثال # 12290 ، # 13179) ، فقد اخترت عدم إجراء المزيد من التفاصيل عليه.

ولكن ، نظرًا لإرسال cmd كوسيطة واحدة ، فأنا في حيرة من إخفاقك في sudo (إنه يعمل معي حاليًا مع التطوير).

راجعت مع pstree -aup في VM أثناء تشغيل 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!

الخلاصة: يتم تخزين رسالة الصدى 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:

بوابة 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 - الإصدار
أنسبل 2.0.0.2
ملف التكوين = / المستخدمون/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 وتواجه المشكلة أيضًا.

شكرا للإصلاح راجع للشغل: كعكة:

هذا يؤثر علينا أيضًا ويسبب بعض الصداع الشديد.

نفس الشيء بالنسبة لي هنا:

أنسيبل 2.0.0.2

+1 لـ ansible 2.0.0.2

لا يزال يحدث لي مع 2.0.0.2

@ تشو هوzamotivatorcblakkan 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 لدي _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 @ جيمي ج amenonsen

+1

يوم الإثنين ، 29 فبراير 2016 ، الساعة 11:26 مساءً ، Brian Coca [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 ٪ (شبكة wifi متقطعة). وضعه على نفس الشبكة مثل مضيف Ansible القضاء على هذه المشكلة. لذلك كانت مهلة الشبكة بدلاً من "انتظار sudo" - لكني لست متأكدًا مما إذا كان Ansible يمكنه معرفة الفرق.

لا أعتقد أنها مشكلة في الشبكة لأنني كنت أختبر من نفس الشبكة عندما تلقيت هذا الخطأ. ومع ذلك ، يبدو أن مضاعفة ssh تسبب لي الكثير من المشاكل. على سبيل المثال ، عندما تحاول جلسة ssh ثانية إنشاء مقبس تحكم بالاسم الموجود بالفعل في دليل ControlPath ، يفشل مع انتهاء المهلة.
يحدث هذا عادةً عند استخدام with_items في المهام. يبدو أن تعطيل مضاعفة ssh يصلح ذلك. على الأقل بالنسبة لي.

vutoff لقد عطلت مضاعفة الإرسال ولا يزال الخطأ يحدث.
أنسبل 2.0.1.0

نفس مشكلة تصعيد الامتياز مع Ansible 2.0.1.0 على خوادم Solaris 11.3 x86 .
بينما يعمل 2.0.0.2 بشكل جيد ، يفشل become: yes على مستوى قواعد اللعبة في 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 / author_keys يمكن أن تسبب ذلك.)

لكن هذا هو سبب انتهاء الوقت المناسب لك. لا يرى المفتاح BECOME-SUCCESS-xxx الذي يتوقعه بعد التصعيد ، مجرد مطالبة ولا شيء آخر.

أوه ، الاقتباس خاطئ:

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

لذلك رأينا أن بعض su's سيتجاهل -c /bin/sh ويحاول تنفيذ كل ما هو محدد للثاني -c . لم أشاهده مطلقًا وهو يسقطك في قذيفة ، لكن من الواضح أن الأمر أعلاه ليس صحيحًا على أي حال ، ويجب علينا إصلاح ذلك. لكنني اعتقدت أننا قمنا بتطبيق رقعة لهذا بالفعل؟ bcoca ، أي أفكار؟

أوه ، ربما يتجاهل _second_ -c وينفذ فقط /bin/sh . من شأنه أن يفسر بالفعل موجه.

أود أن أسمع من أي شخص آخر يعاني من نفس المشكلة ، حتى الآن ليس لدي سوى سجل تصحيح أخطاء واحد كامل لهذا (شكرًا مرة أخرى لـ passw0rd123).

amenonsen على الرحب والسعة! إذا كنت بحاجة إلى مزيد من المعلومات ، فيمكنني الاطلاع عليها يوم الاثنين.
يمكنني إعادة إنتاج مشكلة su هذه مع 2.0.1.0 على Solaris 11.2 (بدلاً من 11.3) Vagrant Box (في VirtualBox) بعد تعيين كلمة مرور للجذر ، فربما يساعد ذلك؟

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

أعيد إنتاجه مع 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 و become_method = sudo على المضيفين الذين يستخدمون FreeBSD 10.2-RELEASE و 10.3-BETA3 ---- لكن تمكنت من استبدال ملفات السجل (لا ، لم أجرب جميع المجموعات الممكنة).

اليوم لم أتمكن من إعادة إنتاجه مرة أخرى - يبدو أنه شيء يحدث مع sudo وملف sudoers بدون NOPASSWD.

حصلت على نفس الشيء مع 2.0.1.0 ansible أثناء محاولة توفير 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 (تثبيت النقطة) على 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 - للإصلاح ؟ يبدو وكأنه مشكلة واسعة الانتشار ومؤثرة

لم يعمل أي من الحلين المقترحين بالنسبة لي :(

التحديثات: يبدو أنه فشل في المهام / يلعب مع become: yes set. نحن نعمل مع Ansible 2.0.1.0 على Ubuntu 14.04 LTS

أقوم حاليًا بتعيين transport = paramiko في ansible.cfg كحل بديل. حتى يتم إصلاح هذا الخطأ

MrMMorris أواجه هذا الخطأ مع 2.0.0.2 أيضًا. لقد جربت كلا الحلين المقترحين (بعد ذلك سأحاول باراميكو كما اقترحه @ JohanTan ) لكنه لا يزال صداعًا شائعًا. لقد لاحظت أنه عندما يكون هناك آخرون يديرون قواعد اللعبة على نفس المضيف (في حالتنا لدينا jumphost حيث يدير كل شخص كتاب لعب منه) فإنه يصبح أسوأ بكثير ويمكن تكراره باستمرار.

مع transport=paramiko نفقد القدرة على --diff وهو أمر مزعج نوعًا ما. آمل أن يتم إصلاح هذا الخطأ قريبًا.

يمكن إعادة إنتاجه دائمًا بالنسبة لي عند _first_ time 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 وفقًا لاختباري الأخير.

لقد تلقيت هذا الخطأ على 2.1.0.0 ansible أيضًا.

24113 1464705052.69173: _low_level_execute_command (): تنفيذ: / bin / sh -c 'su root -c' "" "/ bin / sh -c '" "" "" "" "" "" "" صدى BECOME -النجاح- zpbisiksiuvwdpwkoahuhghbuwyukulw ؛ / bin / sh -c "/ bin / echo fractalcells: {url: http://pkg.fractalcells.com/packages/FreeBSD:10:amd64/ ، ممكّن: صحيح ، الأولوية: 10}> / etc / pkg / fractalcells .conf "" "" "" "" "" "" "" "" "" "" && سكون 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: حصلت على نتيجة من عامل 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 ، المهمة = 1 ، الإنقاذ = 0 ، دائمًا = 0 ، الدور = لا شيء ، run_state = ITERATING_TASKS ، fail_state = FAILED_NONE ، waiting_setup = خطأ ، حالة المهام التابعة؟ لا شيء ، إنقاذ الدولة الطفل؟ لا شيء ، دائما الدولة التابعة؟ لا شيء ، هل بدأت في المهمة؟ خاطئة
24105 1464705064.71779: ^ الحالة الفاشلة الآن: HOST STATE: block = 2 ، المهمة = 1 ، الإنقاذ = 0 ، دائمًا = 0 ، الدور = بلا ، run_state = ITERATING_COMPLETE ، fail_state = FAILED_TASKS ، waiting_setup = False ، حالة المهام التابعة؟ لا شيء ، إنقاذ الدولة الطفل؟ لا شيء ، دائما الدولة التابعة؟ لا شيء ، هل بدأت في المهمة؟ خاطئة
قاتل: [itgitlab]: فشل! => {"فشل": صحيح ، "msg": "مهلة (12 ثانية) في انتظار مطالبة تصعيد الامتياز:"}

تم التأكيد على أنه يمكن إعادة إنتاجه على 2.1.0.0 بشكل عشوائي ، بغض النظر عما إذا كان مثيل AWS تم نسجه حديثًا.

هل هناك أي تقدم في هذا؟ بدأت أرى هذا بشكل عشوائي مع وحدات مثل copy ووحدات أساسية أخرى ، يبدو أن become: true هو الشيء المشترك بينهم جميعًا.

أنا أيضًا أواجه هذه الحالات مع مثيلات ec2 على 2.1.0.0. حتى الآن يبدو أن هناك حالات جديدة فقط. إذا لم يكن الأمر كذلك ، فسأعيد النشر.

كلا ، إنها ليست مجرد حالات تم إنشاؤها حديثًا. على أي حال. عادة إذا فشل في مهمة الإعداد.

شيء لاحظته للتو. يبدو أن الخطأ يحدث فقط إذا استخدمت - العلامات.

يحدث +1 عشوائيًا باستخدام 2.1.0.0 على مثيلات EC2 ولا أستخدم --tags

يحدث ذلك بالنسبة لي مع محلي على OS X ، مع وحدة npm وقائمة بالعناصر.

كل ردود "أنا أيضًا" هذه ليست مفيدة جدًا. من الآن فصاعدًا ، يرجى تضمين:

• نسخة أنسبل
• عدد الشوكات المستخدمة
• -vvvvv الإخراج
• الحمل على نظامك في ذلك الوقت (والذي سيتأثر بعدد الشوكات)
• أي إعدادات SSH معدلة والتي قد تتضمن إعداد المهلة

لي:

• كلاهما أنسيبل 2.0.1.0 و 2.1.0.0
• 50 ، ولكن مضيف واحد
• آسف غير متوفر حاليا ، سيحاول التقاط
• الحد الأدنى
• فقط في ansible.cfg :

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

تحية للجميع،
قبل أن تعلن أن قضيتك مشكلة لا يمكن حلها ، تأكد من أنه يمكنك بالفعل إرسال مثيل في نفس الوقت الذي تفشل فيه مهمة ansible. يمكن أن تصبح مثيلات AWS غير مستجيبة مؤقتًا بسبب الحجم الكبير لعمليات قرص EBS ، من بين أشياء أخرى ، ويمكن أن يؤثر ذلك على قدرة Ansible على الوصول إلى المثيل.

هناك العديد من الأشياء التي يمكنك القيام بها لمنع فشل دليل التشغيل:

1. قم بزيادة قيمة المهلة. الافتراضي هو 10 ثوانٍ ، ويضيف ansible 2 آخرين إلى إجمالي 12 ثانية. في ansible.cfg فقط أضف سطرًا به مهلة أكثر سخاء ، على سبيل المثال "timeout = 600".
2. حلل المهام التي تحدث قبل انتهاء المهلة المحددة. إذا كانت مكثفة على القرص ، فمن المحتمل أن يكون هذا هو سبب المشكلة. هناك طرق لتقليل المشكلة إن لم يتم القضاء عليها تمامًا. إذا كنت لا تستطيع التفكير في طريقة لتحسين الأداء ، أو كنت تبحث فقط عن حل سريع ، فإن إضافة فترة انتظار قبل المهمة الفاشلة ستنهي كتاب التشغيل الخاص بك دون فشل.

تلميح: عند تحليل المهام التي تتباطأ ، أجد أن أداة التعريف المضمنة في Ansible تساعد بشكل كبير. أضف "callback_whitelist = profile_tasks" إلى ansible.cfg لتشغيله.

سأضيف المزيد من التفاصيل ، لكن يمكنني تشغيل نفس المسرحيات على 1.9 ولا أرى هذه المشكلة أبدًا.

أنا أستخدم 2.0.2.0 ansible وهو يعطيني نفس الخطأ في حالة إعادة تشغيل الخدمة أيضًا. يحدث ذلك عندما أحاول إعادة تشغيل 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 -ttf
سيكون من المثير للاهتمام معرفة ما إذا كانت أي إشارات تحدث قبل الخطأ مباشرة.

سنحاول التكاثر ، لكنه لا يحدث كثيرًا في أنظمتنا.

isegal

هل لدى أي شخص أي فرضيات حول سبب حدوث ذلك؟

في المشكلة المشابهة جدًا https://github.com/ansible/ansible/issues/14426#issuecomment -183565130 يذكر bcoca "إعادة كتابة" الاكتشاف الفوري "، قد يكون هذا شيئًا ، حيث يبدو أن الأشخاص لم يكن لديهم مشكلة مع 1.9.x ansible

(آسف ، نشر طويل في المستقبل)

لدينا هذه المشكلة أيضًا. هذا هو دليل اللعبة الذي يصادفه:

---
- 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

بعض رسائل الخطأ المختلفة بناءً على استخدامنا تصبح أم لا:

أنسيبل 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

مع سودو

$ 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. سوف يقدم تقريرا.

مع الإعدادات أعلاه ، تم تشغيل دليل التشغيل دون أي مشاكل. استغرق تشغيله ساعتين و 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 أثناء تنفيذ كتاب اللعب على RHEL 7.2. فشل دليل التشغيل في وحدة النسخ.

لقد قمت بحل المشكلة عن طريق تضمين -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 أليست هذه نفس المشكلة؟ الخطأ "مهلة انتظار المطالبة بكلمة مرور تصعيد الامتياز" هو نفس عنوان هذه المشكلة؟ (باستثناء "كلمة المرور")

أعتقد أن الأمر مختلف لأنه لا يحتوي على "(12)" ، لذا فهو يأتي من مهلة مختلفة. أيضًا لا أحد هنا يقوم بالإبلاغ عن شيء "انتظار الإدخال"

تواجه مهلات عشوائية أيضًا ، تتبع معلومات التصحيح. تعمل نفس الأوامر وكتيبات التشغيل بشكل مثالي مع مضيف Sol11 على إصدار سابق ، وتعمل بشكل جيد بدون مشكلة ، على سبيل المثال الإصدار المستهدف: 0.5.11 (Oracle Solaris 11.3.1.5.0) a-OK.

أنسبل فيرسون 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]
[تسريع]
[سيلينو]
[الألوان]

ح.

لا يزال Ansible 2.0.0.2 على Ubuntu 16 64 بت يحصل على هذا الخطأ. لكن في حالتي ، يمكنني تطبيق كتاب التشغيل الخاص بي دون أي مشاكل على صورة Vagrant الخاصة بي ، فقط أتلقى هذا الخطأ عندما أحاول تشغيله على مثيل EC2 الخاص بي.

ansible -i my_inventory my_aws_server -m ping يعمل: موافق:
ansible-playbook -i my_inventory -l aws_server playbook.yml فشل: هانكي:
ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml يعمل: موافق:

إذا كنت أستخدم -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 ، إلخ.

المشكلة ليست ضرورية بشكل غير مقبول ، فقد تكون في مضيف / etc / hosts أو مشكلة DNS أخرى.

يرجى التحقق من شيئين:

1. تأكد من أنه يمكنك تسجيل الدخول للاستضافة بسرعة كافية عن طريق ssh. عادة يجب أن يستغرق أقل من ثانية واحدة.
2. تأكد من أنه يمكنك تشغيل sudo بسرعة كافية. عادة ما يكون أقل من ثانية واحدة.

تحدث التأخيرات الكبيرة في ssh عادةً بسبب التكوين غير الكامل لنظام أسماء النطاقات. نفس الشيء مع تأخير sudo.

المشكلة الشائعة في sudo البطيء هي عدم اكتمال / etc / hosts. يجب أن يكون شيء من هذا القبيل:

127.0.0.1 localhost
127.0.1.1 example.com

(مستخدمو Openstack: يرجى إلقاء نظرة على خيار "manager_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

قمت بتشغيل كتاب قواعد اللعبة يحتوي على بعض الأدوار ضد VM محلي. بدون تغيير واعي فجأة حصلت على خطأ المهلة المذكور أعلاه. جربت أولاً حل vutoff المذكور في هذا التعليق ، والذي يبدو أنه يعمل بالنسبة لي. حاليًا أنا أتابع هذا التعليق منvmenezes.

سأقوم بتحرير هذا التعليق إذا حصلت على معلومات جديدة.
شكرا لكل شخص يساعد هنا!

شكرًا vmenezes ، أضافت timeout = 30 إلى /etc/ansible/ansible.cfg هي الحيلة بالنسبة لي. أنا أستخدم 2.1.1.0 ansible في بيئة MAC + CentOS-Vagrant

مرحبًا بالجميع ، أتمنى أن يساعد هذا بعض الأشخاص:

لقد واجهتنا هذه المشكلة ، مثل "مهلة انتظار مطالبة تصعيد الامتياز". لقد أمضينا وقتًا في تصحيحه ، وهذا ما وجدناه. نأمل أن يتمكن الأشخاص الأكثر ذكاءً والأكثر انخراطًا في Ansible من استخدام هذا كتقرير خطأ.

1. المضيف الهدف قابل للحل عن طريق إدخال / etc / hosts على نظام غير قابل للحل
2. لا توجد مشاكل في الشبكة أو تأخير
3. كلا العقدتين rhel7
4. ssh لاستهداف أعمال المضيف باستخدام المفاتيح ، بدون مطالبات أو تأخير
5. مرة واحدة على المضيف الهدف ، يعمل sudo إلى الجذر كما هو متوقع ، ولا توجد مطالبات أو تأخير
6. ansible-playbook الإصدار 2.2.0

باستخدام ملف EMPTY 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"}

لاحظ أنه على الرغم من أن المسرحية قالت إنها فشلت ، إلا أن أمر sleep 30 قد بدأ بالفعل وكان يعمل بشكل واضح. تم إنهاء تشغيل الأمر "sleep 30" ، والاتصال غير الآمن بالمضيف الهدف ، عند علامة 12 ثانية عندما قرر أنه فشل في الحصول على موجه تصعيد الخصوصية.

بناءً على هذا الخيط ، توقعنا أنه إذا لم ينته الأمر قيد التشغيل (أي سكون 30) قبل قيمة المهلة ، فسيحدث هذا الخطأ. للاختبار ، إذا أعدنا تشغيل نفس الشيء مع مهلة أعلى ، ووجدنا بالفعل أنه سينجح. قد يفسر هذا سبب إشارة بعض الملصقات إلى النجاح مع مهلة 30 ثانية - إذا اكتمل تشغيلهم في غضون 30 ثانية ، فلا يوجد خطأ. بالنسبة لأولئك الذين لديهم أوامر تستغرق أكثر من 30 ثانية ، لا يزالون يواجهون خطأ.

يمكننا تشغيل لعبة testcase هذه بنجاح باستخدام الأمر التالي:
/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

مع تشغيل خط الأنابيب ، وحالة الاختبار المماثلة أعلاه ، حتى عندما قمنا بتشغيل كتيب اللعبة بمهلة قصيرة جدًا (أي 5 ثوانٍ) ، فإن المسرحية لا تزال مكتملة كما هو متوقع.
/usr/bin/ansible-playbook -i ./testhost ./testcase.yml -T5

في العديد من التجارب المتتالية حيث كانت المهلة أقل بكثير من وقت اللعب (5 ثوانٍ مقابل 30 ، والذي كان من شأنه أن يتسبب في الخطأ وفقًا للاختبار السابق لقيم المهلة) ، وحيث كان الشيء الوحيد الذي تغير بين التجارب هو التسلسل = صواب / خطأ: وجود خطوط أنابيب ssh = صحيح سيؤدي دائمًا إلى النجاح ، ووجود خطوط أنابيب ssh = خطأ سيؤدي دائمًا إلى حدوث هذا الخطأ.

نأمل أن يساعد هذا بعض الأشخاص ، إذا كانت هناك حاجة إلى مزيد من المعلومات ، فيرجى الرد.

شكر،

تحية للجميع،
أنا أواجه هذه المشكلة أيضًا مع إصدار غير مرغوب فيه: 2.1.1.0
لقد جربت كل هذه الحلول المذكورة في هذا المنشور. لكن لا حظ ...
الرجاء الاقتراح

أعتقد أنني واجهت هذه المشكلة أيضًا. تبدو المهمة المعلقة في كتيب اللعبة كما يلي:

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

يجب أن ينسخ بعض ملفات التكوين بشكل متكرر - غالبًا في /etc والمجلدات الفرعية.
أحصل أيضًا على خطأ المهلة المذكور أعلاه.
كيف يمكنني التحقق مما إذا كانت هذه هي نفس المشكلة؟ ما الذي يمكنني فعله للتحايل عليه؟

يحدث هنا أيضًا. timeout = 30 in ansible.cfg إصلاحه ولكن ببطء شديد (ساعة و 36 للتشغيل مقابل 15 دقيقة قبل ظهور الخطأ)
هدف مضيف واحد في ديجيتال أوشن

$ 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 orchestrator إلى الضيف 10.12 (نفس شبكة LAN)
المهلة = 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 new_hostname

عدا ذلك ، في كل مرة تصدر فيها sudo su # ، سيؤخر الخادم مطالبة التصعيد لأنه يحاول حل الاسم الجديد.

يمكنك أيضًا تغيير ansible.cfg إلى ؛
# مهلة SSH
المهلة = 60
التجمع_وقت الخروج = 60

mgedmin تحية طيبة! شكرا لأخذ الوقت الكافي لفتح هذه المشكلة. لكي يتعامل المجتمع مع مشكلتك بفعالية ، نحتاج إلى مزيد من المعلومات.

فيما يلي العناصر التي لم نتمكن من العثور عليها في وصفك:

• نوع القضية
• اسم المكون

الرجاء تعيين وصف هذه المشكلة مع هذا النموذج:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

انقر هنا للحصول على مساعدة الروبوت

اختفت هذه المشكلة لفترة طويلة على Solaris 11 x86 ولكنها عادت للظهور الآن مع Ansible 2.3.0.0 😞 إذا كنت أتذكر بشكل صحيح ، فقد فشلت دائمًا إذا تم تمكين Pipelining ، ولكن بدون كل شيء يعمل بشكل جيد.

يعمل الاتصال عبر SSH ولكن الاستجابة لتصعيد الامتياز إلى الجذر عبر 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 VMs في Parallels Desktop ، مع مطالبة كلمة مرور SU.

يبدو أن المشكلة تتعلق بجانب Python الذي لا يتلقى "كلمة المرور": (أو "مفقود") حيث يمكنني تنفيذ الأمر -vvvv ssh مع نسخ ولصق في shell ، ويتصل ، ويوفر كلمة المرور: موجه ، أنا أكتب كلمة المرور ، وهي تنفذ su وما إلى ذلك.

أطلق ملف sshd -dd على أجهزة التحكم عن بُعد ، ويمكنني أن أؤكد أنه يقرأ الأشياء ، ولا سيما معلومات التصحيح في حقل msg ، ولا "يرى" كلمة المرور: موجه ؛ (
ربما شيء آخر في إعدادات الأمر 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 VMs في Parallels Desktop ، مع مطالبة كلمة مرور SU.

في الإصدار 2.3 ، توجد مشكلة في su تم حلها في https://github.com/ansible/ansible/pull/23710

sivel الآن كيف

@ 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) تم حظره على إحدى مكالمات القراءة (). لا ينبغي أن يحدث في هذا السيناريو ، ولكن يمكن أن يكون خطأ محدد؟
2) استمرار حصول الحلقة for على أحداث غير stderr / non-stdout؟

ربما شيء محدد للطاقة الشمسية؟

على الرغم من ذلك ، يجب في النهاية إلغاء حظر أيٍّ من هذين الأمرين واستدعاء () exam_prompt وتعيين علامة get_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
تصبح_المستخدم: العمليات
تصبح_علامات: "العمليات"
مهام:
الاسم: تشغيل اللمس 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'" "" "" "" "" "" "" " صدى تصبح النجاح - 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 ، فيرجى فتح مشكلة جيثب محددة بأكبر قدر ممكن من التفاصيل مع الناسخ ، شكرًا!

هنا كيف حللت المشكلة. لقد نزلت إلى المعلمات المستخدمة في ملف yaml
كان المعامل Bec_method هو الجاني
الإعداد السابق كان
تصبح: نعم
تصبح_ميثود: سو

تم تغييره إلى
تصبح: نعم
تصبح_ الطريقة: sudo
بدأت العمل بدون مشاكل. يجب أن يكون التلاعب بهذه المعلمة شيئًا له علاقة بالصدفة لأنني في suse 12
ansible - النسخة
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؟
آمل أن يحل المشكلة
ملاحظة: لا يبدو أن زيادة إعداد المهلة ومعلمة خط الأنابيب تعمل بالنسبة لي

مع تحياتي
روبن

amenonsen نعم ، هذا يعمل على إصلاح المشكلة.

حاولت إصلاحه بهذه الطريقة ، لكنني فشلت. هل تستطيع مساعدتي؟