Ansible: apt: update_cache = yes schlägt in ansible 1.3 fehl (?)

Wie rufst du mit -K ansible-playbook auf? In 1.3 wurde geändert, dass sudo explizit angegeben werden muss, da das -K-Flag nicht dazu führt, dass Aufgaben sudo implizit verwenden.

Ja, ich habe -K und sudo an den meisten Orten explizit verwendet, aber nicht in
dieser spezielle Fall. Das ist wahrscheinlich die isse.

Sehr respektvoll,

Dan CaJacob

Am Dienstag, 17. September 2013, um 16:23 Uhr, James Cammarata
[email protected] schrieb :

Wie rufst du mit -K ansible-playbook auf? Es gab eine Änderung in 1.3
Dieses Sudo muss explizit angegeben werden, da das -K-Flag keine Aufgaben ausführt
Verwenden Sie sudo implizit.

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich auf Gi tHubhttps an: //github.com/ansible/ansible/issues/4140#issuecomment -24619163
.

Ok, ich werde Sie das bestätigen lassen und wenn ja, werden wir dies schließen. Vielen Dank!

Wird besorgt. Vielen Dank!

Sehr respektvoll,

Dan CaJacob

Am Dienstag, 17. September 2013, um 16:27 Uhr, James Cammarata
[email protected] schrieb :

Ok, ich werde Sie das bestätigen lassen und wenn ja, werden wir dies schließen. Vielen Dank!

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich auf Gi tHubhttps an: //github.com/ansible/ansible/issues/4140#issuecomment -24619465
.

Irgendwelche Folgemaßnahmen dazu?

Wenn Sie immer noch ein Problem haben, lassen Sie es uns wissen. Vielen Dank!

Ich stoße auch auf dieses Problem. Laufen 1.3.2, aber ich habe keine alten Versionsreferenzen.

Bei Verwendung von -KI tritt ein weiterer Fehler auf: Die SSH-Verbindung wurde geschlossen und auf die Eingabeaufforderung für das Sudo-Passwort gewartet.

Am Ende muss ich dies nicht im interaktiven Modus ausführen, daher kann das -K nicht die endgültige Antwort sein.

Weitere Details: Manuell ausführen: Host1. *** ist der redigierte vollqualifizierte Domänenname

vagrant @ ansible-head : ~ $ sudo -u vagrant ansible-playbook -i inventar ubuntu-apache2.yaml

PLAY [Webserver] * * * * * * * * * * * * * * * * * * * *

FAKTEN ZUSAMMENFASSEN * * * * * * * * * * * * * * * * * * * * * *
ok: [host1. **]

AUFGABE: [Apt Cache aktualisieren] * * * * * * * * * * * * * * * * *
fehlgeschlagen: [host1. **] => {"fehlgeschlagen": true}
msg: Fehler beim Sperren von apt für den exklusiven Betrieb

FATAL: Alle Hosts sind bereits ausgefallen - Abbruch

PLAY RECAP * * * * * * * * * * * * * * * * * * * * * *
Verwenden Sie zum erneuten Versuch Folgendes: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1. ***: ok = 1 geändert = 0 nicht erreichbar = 0 fehlgeschlagen = 1

Manuelles Ausführen von ansible get hat den gleichen Fehler:

vagrant @ ansible-head: ~ $ sudo -u vagrant ansible webserver -i inventar -m apt -a "update_cache = yes
""
host1. *** | FEHLGESCHLAGEN >> {
"fehlgeschlagen": wahr,
"msg": "apt für exklusiven Betrieb konnte nicht gesperrt werden"
}}

@ Ravenwater Das scheint ein anderes Problem zu sein.

Ich habe ein ähnliches Problem mit ansible 1.3.4.

Wenn ich benutze:

apt: update_cache=yes:

Ich erhalte die gleiche Fehlermeldung:

msg: Failed to lock apt for exclusive operation

Auch bei der Installation eines Pakets mit der Option update_cache:

apt: pkg=openjdk-6-jre-headless state=installed update_cache=yes cache_valid_time=604800

Ein ähnlicher Fehler wird angezeigt:

msg: 'apt-get install 'openjdk-6-jre-headless' ' failed: E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

Der Fehler tritt zeitweise auf. Tatsächlich wird ein Satz von 50 virtuellen EC2-Maschinen mit Ubuntu 12.04 verwendet (alle verwenden dasselbe Basis-Image, ami-e50e888c). Der Fehler tritt je nach Test in 5 bis 20 auf.

"sudo: true" ist im Playbook angegeben.

Dies ist normalerweise genau so, wie es in der Nachricht steht, entweder haben Sie es nicht
Berechtigungen zum Sperren der dpkg-Datenbank oder einer anderen Person (oder Sie in einem anderen Prozess)
hat es gesperrt (das passiert mir, wenn ich + C in der Mitte steuere und es versuche
nochmal).

Ja. Aber wenn Sie es mit 50 VMs mit demselben Betriebssystem und derselben Konfiguration verwenden, funktioniert es in einigen von ihnen und in anderen schlägt es fehl. Außerdem, wenn ich das Playbook 3 oder 4 Mal wiederhole, funktioniert es schließlich in allen Knoten.

@micafer Ist es möglich, dass andere Benutzer / Prozesse auf diesen Computern gleichzeitig apt aufrufen?

Ich teste es mit einem Satz von 50 VMs, die speziell für diese Tests erstellt wurden, und ich bin der einzige Benutzer in allen.
Ich weiß nicht, ob Ubuntu einen internen Prozess (Cron oder ähnliches) hat, der die apt-Befehle verwendet.

ubuntu hat täglich Cache-Updates erstellt, normalerweise so, dass dies nicht der Fall ist
Erstellen Sie ein Problem mit einer donnernden Herde, wenn Sie unbeaufsichtigt installiert haben und
Wenn diese Option aktiviert ist, erhalten Sie auch automatische Sicherheitsupdates, die ebenfalls gesperrt werden
diese.

Ich würde dafür stimmen, dieses Thema wieder zu eröffnen, da es im wirklichen Leben eine ernsthafte Chance gibt, dass dies geschieht, und ansible sollte eine Lösung dafür bieten, eine Lösung, an der kein Mensch beteiligt ist, der es versucht, bis es funktioniert.

Ubuntu 16.04

Für Ubuntu 16.04-Benutzer (obwohl ich denke, dass dies auch in 15.04 passieren könnte) wird Ubuntu standardmäßig mit unattended-upgrade aktiviert. Es wird regelmäßig (normalerweise täglich) nach Sicherheitsupdates gesucht, wie von @bcoca erwähnt. Die Lösung besteht also darin, eine Aufgabe hinzuzufügen, bevor Sie APT berühren:

- name: kill automatic updating script, if any
  command: pkill --full /usr/bin/unattended-upgrade
  become: true
  register: kill_result
  failed_when: kill_result.rc > 1 # rc == 1 if the script is inactive
  changed_when: kill_result.rc == 0

Es sollte sicher sein, da das Skript später vom System erneut gestartet wird.

Nur ein Kommentar, dass es bei mir nicht funktioniert hat, die Sperre blieb auch mit dem obigen Befehl bestehen. Bei der Bereitstellung auf EC2 habe ich mein Basis-Image einfach aktualisiert, indem ich unattended-upgrades manuell entfernt habe.