Ansible: KESALAHAN! Waktu tunggu (12 detik) menunggu permintaan eskalasi hak istimewa:

Persis masalah yang sama bagi saya: khawatir :

Versi yang memungkinkan: 2.0.0.2
Versi Python: 2.7.6.0
Lingkungan: Ubuntu 14.04

Saya memiliki masalah yang sama dengan:
Versi yang memungkinkan: 2.0.0.2
Lingkungan: Ubuntu 14.04

Sama. Mengalami hal ini di awal pada Tahap Penataan.
Versi yang memungkinkan: 2.0.0.2
Versi Python: 2.7.6.0
Lingkungan: Ubuntu 14.04

Sekadar catatan, saya mengalihkan koneksi ke paramiko dan masalahnya hilang dan buku pedoman berjalan dengan baik. Tampaknya ada masalah dengan implementasi OpenSSH default.

Jadi bagi mereka yang mengalami masalah ini, coba gunakan -c paramiko untuk saat ini, sampai mereka memperbaikinya.

menipu dari # 14020

Pesan kesalahan tidak sama dengan # 14020 dan keadaan yang saya jelaskan di sini jauh lebih luas. Tetapi jika Anda mengatakan mereka sama, saya tidak akan membantah.

itu tidak persis sama dengan ini di 'ssh' dan yang lain menggunakan koneksi 'lokal' tetapi saya yakin mereka terkait dengan 'deteksi cepat' yang ditulis ulang, tetap, akan membuka kembali ini.

Bisakah seseorang mengeposkan kutipan dari pedoman di mana masalah terjadi (saya mengerti itu terjadi secara tidak terduga; saya tidak meminta cara untuk mereproduksinya, hanya beberapa konteks), serta keluaran dari kegagalan menjalankan dengan ANSIBLE_DEBUG=y dan -vvvvv ?

Saya memiliki masalah yang sama dengan:
Mungkin: 2.0.1.0-1ppa ~ tepat
Ubuntu 12.04

# ansible 'web01' -m shell -a 'dmesg | tail -20' --become -vvvvv
Using /etc/ansible/ansible.cfg as config file
Loaded callback minimal of type stdout, v2.0
<web01> ESTABLISH SSH CONNECTION FOR USER: ansible
<web01> SSH: ansible.cfg set ssh_args: (-o)(ControlMaster=auto)(-o)(ControlPersist=60s)
<web01> SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
<web01> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=ansible)
<web01> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
<web01> SSH: PlayContext set ssh_common_args: ()
<web01> SSH: PlayContext set ssh_extra_args: ()
<web01> SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath=/home/user01/.ansible/cp/ansible-ssh-%h-%p-%r)
<web01> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ansible -o ConnectTimeout=10 -o ControlPath=/home/user01/.ansible/cp/ansible-ssh-%h-%p-%r web01 '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-shpsnlhxruskuujwzskohueoshfyifah; /bin/sh -c '"'"'"'"'"'"'"'"'

web01 | FAILED | rc=0 >>
Timeout (12s) waiting for privilege escalation prompt:

Kadang berhasil, tetapi yang paling GAGAL.

@nghnam Bisakah Anda menempelkan keluaran dari proses yang gagal dengan ANSIBLE_DEBUG = 1 yang disetel di lingkungan?

# ansible-playbook playbooks/test.yaml -vvvv  
TASK [setup] *******************************************************************
<my.ip.address.com> ESTABLISH SSH CONNECTION FOR USER: my_remote_user
<my.ip.address.com> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/ansible-ssh-%h-%p-%r -o IdentitiesOnly=yes -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o 'IdentityFile="/home/padraic/.ssh/my_totally_secure_identity_file"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=my_remote_user -o ConnectTimeout=10 my.ip.address.com '/bin/sh -c '"'"'sudo
 -i -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-jpxmltbgxmgjairqscynmjxlxpgbtotc; /bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python'"'"'"
'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"''"'"''
fatal: [my.ip.address.com]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: "}

Hai teman-teman, kesalahan serupa di sini pada v2.0.1.0 . -c paramiko disarankan oleh @bbyhuy bekerja setiap saat tetapi saran penonaktifan multiplexing @vutoff di # 13278 tidak saya khawatirkan. Apa pun itu, menurut saya salah satu dari ini harus ditandai sebagai penipuan yang lain?

Berikut log debug ANSIBLE_DEBUG=y ansible all -m ping -vvvvv saat masalah terjadi: https://gist.github.com/oliver/e5a24a5b37c0006bb220

Ini dengan Ansible 2.0.1.0-1ppa ~ tepat di Ubuntu 12.04, menghubungkan ke VM Debian 8.2 yang berjalan di host lokal (jadi masalah jaringan tidak mungkin terjadi). Saya menggunakan become=True dan become_method=su , dan telah menambahkan kata sandi root di file hosts dengan ansible_sudo_pass='pass' . Pengaturan ini bekerja dengan baik dengan Ansible 1.9.4-1ppa ~ presisi.

Tidak yakin apakah laporan ini harus # 14426 atau # 13278, tetapi karena kesalahan ini tampaknya tidak terkait dengan with_items sama sekali (ini terjadi dengan buku pedoman sederhana dan bahkan dengan -m ping ), saya mempostingnya sini.

@oliver dalam kasus Anda tampaknya tidak cocok dengan keluaran yang diharapkan, Passwort: tidak cocok dengan penangan prompt su i18n.

@bcoca Tangkapan yang bagus (dan argumen yang bagus untuk tidak menggunakan i18n di server)!
Sayangnya itu masih tidak berfungsi jika saya menyetel $ LANG ke string kosong dan menyetel lokal default pada sistem target ke Tidak Ada. Saya telah memperbarui Intinya dan sekarang menampilkan prompt "Password:" yang seharusnya dikenali tetapi masih mengarah ke timeout.

Saya percaya masalahnya ada di sisi penanganan cepat 'su' (meskipun itu berhasil untuk saya dalam pengujian saya).

Masih mengalami masalah yang sama (2.0.1.0), pesan

GAGAL! => {"gagal": true, "msg": "Timeout (12 dtk) menunggu permintaan eskalasi hak istimewa:"}

Konfigurasi buku bermain saya

• host: dev-server
  
  menjadi: ya
  
  menjadi_user: root
  
  menjadi_metode: su
  
  * * * * * * * * * * * * * * * * * * * * *
  
  ouput dari -vvvvv

MEMBANGUN KONEKSI SSH UNTUK PENGGUNA: ubuntu
SSH: ansible.cfg set ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking dinonaktifkan: (-o) (StrictHostKeyChecking = tidak)
SSH: ansible_password / ansible_ssh_pass tidak disetel: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / pengguna / -u set: (-o) (User = ubuntu)
SSH: ANSIBLE_TIMEOUT / set batas waktu: (-o) (ConnectTimeout = 10)
SSH: Set PlayContext ssh_common_args: ()
SSH: PlayContext set ssh_extra_args: ()
SSH: hanya ditemukan ControlPersist; menambahkan ControlPath: (-o) (ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r)
SSH: EXEC ssh -C -vvv -o ControlMaster = otomatis -o ControlPersist = 60s -o StrictHostKeyChecking = tidak -o KbdInteractiveAuthentication = tidak -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, berbasis host, publickey -o PasswordAuthentication = tidak -o Pengguna = ubuntu -o ConnectTimeout = 10 -o ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r -tt 52.76.16.117 '/ bin / sh -c' "'" '(umask 22 && mkdir -p " echo $HOME/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027 " && echo " echo $HOME/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027 ")' "'"' '
PUT / tmp / tmpMYXpV0 KE /home/ubuntu/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027/setup
SSH: ansible.cfg set ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking dinonaktifkan: (-o) (StrictHostKeyChecking = tidak)
SSH: ansible_password / ansible_ssh_pass tidak disetel: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / pengguna / -u set: (-o) (User = ubuntu)
SSH: ANSIBLE_TIMEOUT / set batas waktu: (-o) (ConnectTimeout = 10)
SSH: Set PlayContext ssh_common_args: ()
SSH: PlayContext set sftp_extra_args: ()
SSH: hanya ditemukan ControlPersist; menambahkan ControlPath: (-o) (ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r)
SSH: EXEC sftp -b - -C -vvv -o ControlMaster = otomatis -o ControlPersist = 60s -o StrictHostKeyChecking = tidak -o KbdInteractiveAuthentication = tidak -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, berbasis host, publickey -o PasswordAuthentication = tidak -o Pengguna = ubuntu -o ConnectTimeout = 10 -o ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r '[machine1]'
MEMBANGUN KONEKSI SSH UNTUK PENGGUNA: ubuntu
SSH: ansible.cfg set ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking dinonaktifkan: (-o) (StrictHostKeyChecking = tidak)
SSH: ansible_password / ansible_ssh_pass tidak disetel: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / pengguna / -u set: (-o) (User = ubuntu)
SSH: ANSIBLE_TIMEOUT / set batas waktu: (-o) (ConnectTimeout = 10)
SSH: Set PlayContext ssh_common_args: ()
SSH: PlayContext set ssh_extra_args: ()
SSH: hanya ditemukan ControlPersist; menambahkan ControlPath: (-o) (ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r)
SSH: EXEC ssh -C -vvv -o ControlMaster = otomatis -o ControlPersist = 60s -o StrictHostKeyChecking = tidak -o KbdInteractiveAuthentication = tidak -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, berbasis host, publickey -o PasswordAuthentication = tidak -o Pengguna = ubuntu -o ConnectTimeout = 10 -o ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r -tt machine1 '/ bin / sh -c' "'"' su root -c / bin / sh -c '"'" '"'" '"'" '"'" 'echo MENJADI-SUKSES-lubjqfumkxawkkgetezusnctthxkfpju; / bin / sh -c '"'" '"'" '"'" '"'" '"'" '"'" '"'" '"'" '"'" '"'" '"'" '"'" '"'" 'LANG = en_US.UTF-8 LC_ALL = en_US.UTF-8 LC_MESSAGES = en_US.UTF-8 / usr / bin / python /home/ubuntu/.ansible/tmp/ansible-tmp- 1459250484.21-51977895368027 / setup; rm -rf "/home/ubuntu/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027/"> / dev / null 2> & 1 '"'" '"'" '"'" '"'" '"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "''" '"'" '"'" '"'" '" '' "'"' '

Jika saya menggunakan sudo: ya , semuanya berfungsi dengan baik.

Mengalami masalah ini saat menjalankan fase pengaturan terhadap server Ubuntu 14.04 EC2 yang baru dimulai.

Ketika saya menjalankan untuk kedua kalinya otomatisasi terhadap server yang sama berfungsi dengan baik. Itu terjadi setiap saat ketika saya pertama kali menjalankan otomatisasi yang memungkinkan terhadap server baru

Versi yang memungkinkan: 2.0.1.0
Versi Python: 2.7.6.0
Lingkungan: Ubuntu 14.04

Saya menjalankan perintah berikut:

ANSIBLE_DEBUG=y ansible-playbook test.yaml -t configure -l <EC2_ID> -vvvvv

silakan lihat inti berikut untuk hasilnya: https://gist.github.com/Lowess/77442cf0533629e80b55faa7d6d91eb0

Dapatkah saya setidaknya meningkatkan batas waktu 12 detik itu?

"Batas waktu 12 detik" adalah timeout pengaturan ssh.py ).

Ini bukan perbaikan, tetapi menyetel timeout ke 30 memberi kami batas waktu eskalasi 32 detik yang hingga saat ini cukup baik (bahkan untuk instans AWS EC2 kami yang lebih lambat) untuk mengatasi bug.

@somechris Saya baru saja mencoba pengaturan Anda dan berhasil!

Untuk beberapa alasan fase setup membutuhkan waktu sekitar 20 - 25 detik. Itu adalah pertama kalinya saya menghadapi masalah seperti ini saat menjalankan Ansible melawan AWS. Saya masih berpikir ada masalah di suatu tempat karena dengan Ansible V1 saya tidak perlu meningkatkan nilai batas waktu itu.

Terima kasih lagi!

Saya menduga batas waktu tidak berfungsi sebagaimana dimaksud di v1.

@amenonsen Dalam hal itu semua masuk akal bagi saya sekarang. Terima kasih atas ketepatannya.

Masalah yang sama.

Ansible Host: Ubuntu 14.04
Managed Hosts: CentOS 7.2

Solusi yang dijelaskan di sini telah membantu

pre_tasks:
  - name: disable fingerprint checking that may be enabled; when enabled, causes ssh issues
    command: authconfig --disablefingerprint --update
    become: yes

Gejalanya persis sama (ini syslog dari host centos)

Apr  7 22:44:12 srv-01 python: ansible-file Invoked with directory_mode=None force=False remote_src=None path=/etc/connector owner=connector follow=False group=connector state=directory content=NOT_LOGGING_PARAMETER serole=None diff_peek=None setype=None selevel=None original_basename=None regexp=None validate=None src=None seuser=None recurse=False delimiter=None mode=None backup=None 
Apr  7 22:44:13 srv-01 dbus[703]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Apr  7 22:44:13 srv-01 dbus-daemon: dbus[703]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Apr  7 22:44:13 srv-01 systemd: start request repeated too quickly for fprintd.service
Apr  7 22:44:13 srv-01 systemd: Failed to start Fingerprint Authentication Daemon.
Apr  7 22:44:13 srv-01 systemd: fprintd.service failed.
Apr  7 22:44:38 srv-01 dbus[703]: [system] Failed to activate service 'net.reactivated.Fprint': timed out
Apr  7 22:44:38 srv-01 dbus-daemon: dbus[703]: [system] Failed to activate service 'net.reactivated.Fprint': timed out

@szhem mengagumkan, itu memperbaikinya untuk saya!

authconfig --disablefingerprint --update

Apakah ada perintah yang setara di ubnutu 14.04? Terjadi pada kami juga

Di ansible.cfg setel transport = paramiko di bagian [defaults]

Di ansible.cfg , hal berikut telah memperbaiki masalah untuk 10+ server yang menyebarkan menggunakan ansible 2.0.1.0:

[defaults]
timeout = 30

Paramiko tampaknya tidak berfungsi dengan konfigurasi bastion saya, sementara ssh berfungsi seperti pesona (minus menjadi / be_user / be_method: su). Saya sedang digigit oleh bug ini dengan keras, apakah ada detail yang dapat saya berikan untuk membantu?

<vagrant.dev> PUT /var/folders/br/p6m9m2ks0v9868lpyphsxdfr0000gp/T/tmpqcF4PG TO /home/vagrant/.ansible/tmp/ansible-tmp-1466186263.1-239875858441470/setup <vagrant.dev> SSH: EXEC sshpass -d25 sftp -b - -C -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o Port=22 -o User=vagrant -o ConnectTimeout=15 -o ControlPath=/Users/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r '[vagrant.dev]' fatal: [vagrant.dev]: UNREACHABLE! => {"changed": false, "msg": "ERROR! SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", "unreachable": true}

Saya juga bertanya-tanya apakah penyiapan hanya lebih lambat di 2.x. Kami sangat sering melihat waktu tunggu penyiapan saat menjalankan versi 2.1, tetapi tidak pernah dengan 1.9. Kami telah meningkatkan batas waktu menjadi 30, tetapi itu masih cukup sering terjadi pada 2.1. (Akan meningkat lebih banyak untuk mencoba melihat apakah ini benar-benar batas waktu atau sesuatu yang tidak akan pernah selesai.)

FYI kami belum melihat kesalahan itu dalam beberapa bulan. Kami menerapkan solusi dari @szhem untuk host RHEL 6.7 kami dan tampaknya telah memperbaikinya. Untuk host RHEL 7.2 kami, mereka menggunakan versi terbaru dari authconfig (versi 6.2.8-10) yang tampaknya memperbaiki masalah tersebut, karena bagi mereka kami tidak memerlukan solusi.

Kami menggunakan RHEL 7.2 di server budak dan Menara Jenkins kami.

Menjalankan 2.2 dari sumber dengan host CentOS 7.2 dari Azure.

Anehnya beberapa panggilan layanan systemd berakhir ke Timout (12s).

Saya menghilangkan kesalahan ini dengan menambahkan nopasswd ke pengguna saya di / etc / sudoers
username ALL=(ALL) NOPASSWD:ALL

harus di akhir sudoers

@gandhar Saya mengalami kesalahan ini saat sudah mengaktifkan nopasswd. Sepertinya itu hanya salah satu dari banyak hal yang menghabiskan waktu tunggu.

Apakah Anda mencoba men-debug server ssh Anda di node? Berapa lama waktu yang dibutuhkan ssh login ke node? Coba tambahkan UseDNS no ke /etc/ssh/sshd_config file di node.

• 1
  Masalahnya terjadi saat saya menerapkan lebih dari 3 AWS EC2 pada saat yang bersamaan.
  @somechris terima kasih atas pekerjaannya, ini berfungsi dengan baik bahkan dalam strategi: mode bebas.

GAGAL! => {"gagal": true, "msg": "Waktu tunggu (12 detik) menunggu permintaan eskalasi hak istimewa:"
OS: CentOS Linux rilis 7.2.1511 (Core)
Ansible: ansible 2.2.0

Untuk catatan. Saya melihat masalah dengan firewall FreeBSD PF. Port SSH terbuka dan koneksi SSH dari baris perintah berfungsi dengan baik. Batas waktu menghilang saat saya menonaktifkan firewall.

SOLUSI

./lib/ansible/plugins/connection/ssh.py baris 403 (commit 9fe430867063a0a63316e9bb71e9ba03a475a989):

dari:

timeout = 2 + self._play_context.timeout

untuk:

timeout = 30 + self._play_context.timeout

PENYEBAB UTAMA

Lingkungan yang lamban (awan publik, dll.) Dapat menyebabkan waktu tunggu karena batas waktu default yang ketat. Pengguna harus dapat mengkonfigurasi waktu tunggu agar sesuai dengan kebutuhan mereka tetapi konteks.timeout tidak diperbarui saat mengedit ansible.cfg .

melipat menjadi # 13278

masalah yang sama, menambahkan become_user: <username>
menghapus kesalahan

Menghadapi masalah yang sama, Menambahkan -c paramiko ke perintah ansible-play saya membantu menyelesaikan masalah ini.

Saya menjalankan 2.1.1.0 dan saya mendapatkan kesalahan ini. Satu-satunya cara saya membuatnya berfungsi adalah dengan yang berikut di buku pedoman saya:

remote_user: david
sudo: yes

Dan menambahkan --ask-become-pass ke perintah.

Pemula di sini, mengalami masalah ini. Diperbaiki dengan:

sudo:yes

Yang menggantikan:

become: yes
become_user: root
become_method: su

Saya cukup yakin itu kesalahan pengguna saya sendiri, tetapi untuk saat ini saya menggunakan metode yang tidak berlaku lagi.

Versi 2.0.0.2

Ternyata saya menggunakan be_method (su) yang salah, ini berfungsi dengan menggunakan default (sudo):

become: yes

Saya selalu mendapatkan kesalahan ini ketika saya mematikan kemungkinan (ctrl + c) dan mencoba memulai ulang pemutaran lagi. Menambahkan -c paramiko juga memecahkan masalah di sini. Setelah beberapa saat itu akan kembali berfungsi secara normal, jadi saya kira ada sesuatu yang perlu waktu tunggu di server ...
Namun, ini mungkin masalah yang berbeda, karena itu selalu terjadi di awal permainan, dan tidak pernah secara acak selama permainan.

Sejujurnya, apa gunanya mengubah ini? Dalam proses yang tampak seperti 2 revisi kecil, hampir semua buku pedoman saya saat ini rusak. Selain mengubah semua ini menjadi perilaku, ansible bekerja dengan sempurna.

https://github.com/ansible/ansible/issues/14426#issuecomment -205938301 dari @somechris menyarankan bahwa waktu tunggu memengaruhi waktu tunggu eskalasi. Namun dokumentasi yang ditautkan dengan jelas menyatakan:

Ini adalah waktu tunggu SSH default untuk digunakan pada upaya koneksi:

Jika orang melaporkan bahwa menambah waktu tunggu menyebabkan kesalahan prompt eskalasi hilang, tampaknya dokumentasinya rusak, atau ada masalah lain yang lebih mengerikan yang terkubur di suatu tempat di sana.

@tsoikkel membuat analisis kode sebenarnya di sini:
https://github.com/ansible/ansible/issues/14426#issuecomment -245256330

Yang menunjukkan bahwa dokumentasi sudah benar, tetapi tidak menyarankan mengapa mengubah waktu tunggu memperbaiki masalah eskalasi .

Tautan yang direferensikan komit tidak benar-benar menunjukkan kode yang relevan, tetapi ini dia di master saat ini:

https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/ssh.py#L418 -L421

Apakah masalah eskalasi adalah batas waktu SSH, atau batas waktu eksekusi perintah, atau yang lainnya? Tidak jelas dari diskusi ini apa akar penyebab sebenarnya.

Berikut kode spesifik yang berkaitan dengan kesalahan prompt eskalasi:

https://github.com/ansible/ansible/blob/ac51266e8fea1ac6312a9649fc5cf10dd0609925/lib/ansible/plugins/connection/ssh.py#L438 -L445

Sayangnya saya tidak cukup sebagai orang python untuk dapat melihat kapan ini akan terjadi. Mungkin seseorang dapat menjelaskan alirannya di sini, karena saya tidak yakin mengapa mencapai nilai timeout dalam contoh khusus ini akan menyebabkan kesalahan dimunculkan.

Dengan meningkatkan waktu tunggu, kami menyembunyikan alasan sebenarnya mengapa ssh gagal di tempat pertama dengan nilai percobaan ulang 12 detik yang masih signifikan.

adakah yang tahu mengapa mungkin gagal untuk terhubung ke host secara acak? misalnya, kami memiliki 50 node dalam pengaturan kami yang dikelola oleh ansible dan waktu habis terjadi 3% dari waktu pada node yang benar-benar acak dan tugas acak dan jika kami menjalankan ulang playbook untuk kedua kalinya, itu akan baik-baik saja.

Hai,
maaf sudah berkomentar untuk tiket tertutup.
Kami mengalami masalah yang sama dengan kemungkinan 2.2.0 dan 2.2.2 dan kami berhasil masalah hanya muncul dengan Python 3.5. Di Python 2.7 semuanya tampak baik-baik saja.

masih bermasalah dengan itu

Saya memiliki masalah ini. Mengapa masalah ditutup?

Saya juga melihat ini. Ini tidak diperbaiki dan tidak boleh ditutup.

Melihat ini di kemungkinan terbaru. Mengapa ini ditutup?

Saya juga melihat ini di 2.3.0

Silakan mengomentari masalah di atas komentar Anda. Mod akan menjawab bahwa ini sudah ditutup.

Saya perlu menghapus bendera -n , yang menyebabkan masalah dengan sudo 'tanpa sandi.
Setelah saya melakukannya, kesalahan ini kemudian mulai terjadi.
Berdasarkan komentar @davidmoshal , saya mengubah become: yes menjadi become: root dan masalah saya hilang.

become: root salah, ini tidak mengatur pengguna, tetapi akhirnya menjadi True nilai untuk become jadi tidak ada perubahan.

Saya dapat mengonfirmasi bahwa memutar kembali ke ansible1.9 menyelesaikan semua masalah koneksi SSH saya yang aneh. Saya tidak tahu apa yang salah dengan ansible2.x tetapi saya tidak akan meningkatkan dalam waktu dekat karena ini sepertinya terus berlanjut. Saya telah melihat komentar bahwa ini bukan bug yang mungkin, dan saya sangat tidak setuju. Satu-satunya variabel yang saya ubah adalah peningkatan yang memungkinkan. Saya mengelola lebih dari 70 server tanpa masalah dengan ansible1.9, kemungkinan 2.0 gagal dengan setiap contoh yang saya miliki. Ini adalah bug yang mungkin. Bukan ssh, atau lapisan lainnya.

Baru saja mengalami masalah ini bagi saya yang terjadi 4-5 kali berturut-turut. Kemungkinan 2.3, Ubuntu 16.04.1.
Tetapi karena saya tidak memiliki masalah apa pun hari ini di area di mana hal itu mulai terjadi dan saya tidak melakukan perubahan apa pun di sana, saya hanya mulai berpikir bahwa ada yang tidak beres dengan node pengendali itu sendiri.
Saya memutuskan untuk memulai kembali mengontrol node dan mencoba lagi dan itu berhasil untuk saya tanpa masalah. Masalahnya hilang.

Juga memiliki masalah yang sama dengan 2.3.0.0 dan 2.4.1.0 dengan pipelining. Karena kesalahan konfigurasi di pihak kami, pipelining telah dinonaktifkan secara tidak sengaja untuk sementara waktu sekarang (tidak yakin berapa lama, saya menduga sakelar pra-2.0), tetapi mengaktifkannya kembali mengakibatkan batas waktu permintaan eskalasi hak istimewa yang disebutkan di sini.

Saya hanya menggunakan become = True dan become_method = sudo . Satu-satunya hal 'khusus' yang benar-benar saya lakukan adalah mengatur ANSIBLE_SSH_ARGS sehingga menulis UserKnownHostsFile ke lokasi khusus tertentu - tetapi saya ragu ini akan mempengaruhi apa pun?

Saya sudah mencoba beralih ke paramiko, tetapi itu macet & terbakar sepenuhnya dalam pengaturan pengujian saya dan menambah waktu tunggu juga tidak berfungsi, itu gagal baik dalam pengaturan pengujian saya seperti di lingkungan produksi kami.

Mendirikan:

• Mungkin mesin kontrol 2.4.0 Ubuntu 16.04 VirtualBox 5.1.30 VM (Vagrantbox: bento / ubuntu-16.04)
• Solaris 11.3 VirtualBox 5.1.30 VM (Vagrantbox: heavybeans / solaris11-small-server)

Dapatkan kesalahan ini secara acak saat menguji pedoman, terakhir kali saat tindakan file (folder sudah ada). Kedua VM memiliki pengguna yang sama "gelandangan" dan kotak Solaris tidak memiliki kata sandi root.

Saya menggunakan --ask-be-pass dan menekan ENTER. Tetap saja, kesalahan terjadi ...

Dalam kasus saya, ini adalah masalah nyata (bukan bug) di server saya di mana DNS tidak dapat diselesaikan. sudo tampaknya menggunakan DNS untuk menyelesaikan nama host mesin, dan jika gagal, waktu akan habis. Saya memperbaikinya dengan mengoreksi entri DNS di /etc/resolv.conf saya.

Sering mengalami masalah ini di GCE dengan Ansible 2.5 dari git juga. Sejauh ini, menggunakan paramiko tampaknya merupakan solusi yang layak.

Saya harus killall ssh , mungkin koneksi ssh basi jika Anda menggunakan ControlPersist .

Hai, saya mengalami masalah yang sama dengan menerapkan ke ubuntu 16.04 dengan kemungkinan 2.4.2.0, opsi --paramiko menyelesaikan masalah, tetapi dalam kasus yang sama jangan membaca ~ / .ssh / config saya, jadi alih-alih opsi --paramiko saya selesaikan menonaktifkan opsi pipelining (secara default adalah False) di add ansible.cfg:

[ssh_connection]
pipelining = False

Saya mengalami masalah yang sama ketika mencoba menjalankan buku pedoman pada wadah LXD Ubuntu 16.04. Saya bisa ssh ke dalam wadah dengan baik, tetapi akan memakan waktu lama untuk sudo su dan itu akan membuat kesalahan sudo: unable to resolve host ingest0: Connection timed out .

Saya menambahkan nama host ke /etc/hosts dan masalahnya hilang - saya dapat menjalankan playbook tanpa batas waktu eskalasi dan saya dapat segera sudo su .

root<strong i="11">@ingest0</strong>:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ingest0

Saya menggunakan ansible 2.4.3.0 dan python 2.7.12 .

masalah saya diselesaikan dengan mengubah file host dari

[sandbox]
fedora<strong i="6">@ip</strong>

untuk

[sandbox]
ip

di mana ip adalah alamat ip mesin.

Mengapa ini ditutup?
Saya baru saja menyiapkan server Ubuntu baru dengan Ansible dan Python terbaru dan bugnya masih ada.
Tidak ada solusi yang berhasil.

Mengapa ini ditutup?

Mungkin karena tidak mungkin untuk menanyakan setiap pengguna apakah solusi tersebut berhasil. Mungkin ada beberapa penyebab kesalahan yang berbeda. Orang tersebut membuat keputusan untuk menutup masalah.

Saya setuju,

Saya mengalami masalah yang sama, saya telah memberikan root sudoers pengguna .... Saya telah memaksa perubahan pengguna.

Tidak ada yang berhasil dan kesalahan yang wajar untuk diselidiki. Mungkin penanganan pengecualian yang lebih baik diperlukan di sini?

Playbook saya terlihat seperti ini:

• host: localhost

be_user: jenkins
gathering_facts: true
peran:
- {peran: Bareos, tags: local}

• host: dev-cluster
  remote_user: centos
  gathering_facts: true
  peran:

  • {role: Bareos, tags: client}

• host: cadangan
  remote_user: centos
  menjadi_user: root
  gathering_facts: true
  peran:

  • {peran: Bareos, tags: server}

Semua host lain berfungsi kecuali host: backup.

-vvv Acara

Menggunakan file modul /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
MEMBANGUN KONEKSI SSH UNTUK PENGGUNA: centos
SSH: EXEC ssh -o ControlMaster = otomatis -o ControlPersist = 30m -o ConnectionAttempts = 100 -o UserKnownHostsFile = / dev / null -o StrictHostKeyChecking = no -o 'IdentityFile = "/ var / jenkins_home / .ssh / demo.pem" '-o KbdInteractiveAuthentication = tidak -o PreferredAuthentication = gssapi-dengan-mic, gssapi-keyex, berbasis host, publickey -o PasswordAuthentication = tidak -o Pengguna = centos -o ConnectTimeout = 10 -o ControlPath = / var / jenkins_home / .ansible / cp / cd7d91cc23 backup.infra.com '/ bin / sh -c' "'"' sudo -H -S -n -u root / bin / sh -c '"'" '"'" '"'" '" '"' echo MENJADI-SUKSES-uywjmsrvdxhojzxfiqjygdwdsmbvvfzn; / usr / bin / python '"'" '"'" '"'" '"'" '&& tidur 0' "'"' '

Sever ada di AWS.
Saya memiliki perintah saya yang bertanggung jawab

ansible-playbook -vvv -i inventory / hosts bareos.yml --key-file "~ / .ssh / demo.pem" -b -e

Saya hanya punya masalah ini, ini akurat menjadi salinan pengguna dan model. Namun ketika saya menggunakan root langsung menjalankan playbook tidak apa-apa.

pesan kesalahan:

SSH: EXEC sshpass -d13 ssh -C -o ControlMaster = otomatis -o ControlPersist = 60s -o StrictHostKeyChecking = no -o User = vmuser -o ConnectTimeout = 20 -o ControlPath = / root / .ansible / cp / 48d4a08c2f -tt 192.168 .202.105 '/ bin / sh -c' "'"' su root -c '"'" '"'" '"'" '"'" '/ bin / sh -c' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' echo MENJADI-SUKSES-fkekucjxphrobughycoiecflsoiptmkg ; / usr / bin / python /home/vmuser/.ansible/tmp/ansible-tmp-1536311364.58-186480404230053/file.py '"'" '"'" '"'" '"'" '"'" '"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "''" '"'" '"'" '"'" '"' && tidur 0 '"'" ''
fatal: [192.168.202.105]: GAGAL! => {
"msg": "Waktu tunggu (22 detik) menunggu permintaan eskalasi hak istimewa:"

Saya setuju,

Saya mengalami masalah yang sama, saya telah memberikan root sudoers pengguna .... Saya telah memaksa perubahan pengguna.

Tidak ada yang berhasil dan kesalahan yang wajar untuk diselidiki. Mungkin penanganan pengecualian yang lebih baik diperlukan di sini?

Playbook saya terlihat seperti ini:

• host: localhost

be_user: jenkins
gathering_facts: true
peran:

• {role: Bareos, tags: local}

• host: dev-cluster
  remote_user: centos
  gathering_facts: true
  peran:

  • {role: Bareos, tags: client}

• host: cadangan
  remote_user: centos
  menjadi_user: root
  gathering_facts: true
  peran:

  • {peran: Bareos, tags: server}

Semua host lain berfungsi kecuali host: backup.

-vvv Acara

Menggunakan file modul /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
MEMBANGUN KONEKSI SSH UNTUK PENGGUNA: centos
SSH: EXEC ssh -o ControlMaster = otomatis -o ControlPersist = 30m -o ConnectionAttempts = 100 -o UserKnownHostsFile = / dev / null -o StrictHostKeyChecking = no -o 'IdentityFile = "/ var / jenkins_home / .ssh / demo.pem" '-o KbdInteractiveAuthentication = tidak -o PreferredAuthentication = gssapi-dengan-mic, gssapi-keyex, berbasis host, publickey -o PasswordAuthentication = tidak -o Pengguna = centos -o ConnectTimeout = 10 -o ControlPath = / var / jenkins_home / .ansible / cp / cd7d91cc23 backup.infra.com '/ bin / sh -c' "'"' sudo -H -S -n -u root / bin / sh -c '"'" '"'" '"'" '" '"' echo MENJADI-SUKSES-uywjmsrvdxhojzxfiqjygdwdsmbvvfzn; / usr / bin / python '"'" '"'" '"'" '"'" '&& tidur 0' "'"' '

Sever ada di AWS.
Saya memiliki perintah saya yang bertanggung jawab

ansible-playbook -vvv -i inventory / hosts bareos.yml --key-file "~ / .ssh / demo.pem" -b -e

>

Masalah saya terkait firewall. Bagi saya ini sudah diselesaikan.

Bagi saya, itu karena koneksi internet yang buruk.

Saya mendapatkan masalah ini juga:
Playbook:

- name: Configure cassandra.yaml common settings
  become: yes
  become_user: cassandra
  become_method: su
  become_flags: '-s /bin/sh'
  lineinfile:
    path: /usr/local/cassandra/conf/cassandra.yaml
    regexp: '{{ item.beginning }}'
    line: '{{ item.beginning }}{{ item.value }}{{ item.end }}'
  with_items: "{{ cassandra_yaml }}"

Yang memberikan kesalahan:

TASK [install-cassandra : Configure cassandra.yaml common settings] *************************************************
fatal: [10.142.0.3]: FAILED! => {"msg": "Timeout (32s) waiting for privilege escalation prompt: "}

Playbook memiliki banyak tugas lain yang diselesaikan tanpa masalah. Hanya yang satu ini dengan pilihan "menjadi" yang berbeda, gagal.

3 sen saya:
Masalah serupa di sini. Kesalahan yang sama. Saya tidak punya waktu untuk men-debug tetapi yang saya lihat:

1) Ini terkait jaringan (koneksi saya melalui terowongan HE6 ke Ubunut 18.04-> penampung LXD). Dengan satu pengaturan terowongan kesalahan yang sama seperti di atas. Dengan pengaturan terowongan lain berfungsi dengan baik (saya menebak di sini tetapi ini mungkin masalah MTU dari beberapa jenis).

1. ANSIBLE_SSH_ARGS = "- o ControlMaster = no" membantu sedikit - koneksi macet pada tugas yang berbeda saat digunakan.