Warum? “GPG error: http://repo.universe-factory.net sid InRelease: The following signatures were invalid: KEYEXPIRED 1452247109 KEYEXPIRED 1452247109 KEYEXPIRED 1452247109”
Warum? "[ 4.365081] systemd[1]: Cannot add dependency job for unit display-manager.se
rvice, ignoring: Unit display-manager.service failed to load: No such file or di
rectory.
[ 4.501499] systemd[1]: systemd-modules-load.service: main process exited, co
de=exited, status=1/FAILURE
[ 4.501823] systemd[1]: Failed to start Load Kernel Modules.
[ 4.501901] systemd[1]: Unit systemd-modules-load.service entered failed state"
Schon klar da hat jemand irgenwas display mässiges installiert aber warum?
Ziemlich bescheidener Zustand, open-vm-tools und open-vm-tools-dkms habe ich mal gefixt.
Fehlten auf greyworm-4 auch, habe ich da auch reingemacht.
Da ist ein “deb http://http.debian.net/debian/ jessie-backports main” eingetragen.
Da apt-transport-http nicht installiert war so hat das NIE FUNKTIONIERT.
“Ign http://ftp.de.debian.org jessie InRelease
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?”
zu 1.): Wir brauchen die Backports für den 4.2er Kernel, da nur dort das suppress_prefixlength=0 für IPv6 funktioniert. Auf allen VMs der neuen Domänen läuft der 4.2er Kernel.
zu 2.): Ansible stellt sich leider nicht sehr geschickt an bei allem rund um apt-get an. Ich vermute, dass dort schon eine Quelle drin war und diese dann durch die Common-Rolle nochmal hinzugefügt wurde, statt sie zu überschreiben.
zu 3.): Ich denke die Signierung ist ausgelaufen. Aus dem Repo stammt das fastd-Paket. Ich glaub da können wir nichts tun.
zu 4.): keine Ahnung, wir haben einen Display-Manager da drauf?
Ich kenne apt-transport-https nicht, der installiert aber den Kernel wunderbar, ist ja auch drauf, wie man uname -a entnehmen kann.
Ich sehe hier nicht die Ursache des Absturzes. Vermutlich war es Batman, das geht ja andere Communities auch so.
Das auf Ansible zu schieben ist IMHO etwas lame, da offenbar niemand auf den Output geschaut hat.
Da Ansible aber eben nicht Puppet ist sondern nur ein Scriptmonkey muss man das explizit auswerten oder aber draufschauen.
Was genau muss für vmware-Tools installiert sein? Habe da bisher keine Erfahrungen mit.
Der Hinweis auf die doppelte Quelle ist seit Beginn bekannt und hat derzeit glaube ich den won’t-fix-Status. Wenn du eine Lösung hast, freuen wir uns natürlich :).
VMware recommends using the Open VM Tools included with Debian 8.
Install Open VM Tools
Add the following line to the /etc/apt/sources.list file.
deb http://ftp.debian.org/debian/ jessie main contrib
Run the commands:
$ sudo apt-get update
$ sudo apt-get install open-vm-tools
These are dependencies of VMware Tools.
These packages must be available on the Linux operating system before
installing VMware Tools.
kernel sources als Abhängigkeit? Kompiliert das Paket automatisch ein Kernel-Modul? Da wir einen Nicht-Standard-Kernel haben, könnte das Probleme machen. Und wofür brauchen wir das überhaupt?
Und man braucht das für paravirtualiserte Hardware (=besser Performance und weniger Host Resourcenverbrauch) und um den Rechner mal neu zu starten ohne Reset drücken zu müssen.
Scheint kein Problem zu sein wenn man deinstalliert, ein purge macht und es neu installiert.
Ich würde immer die Empfehlung sprechen in größeren VMware Wolken die Tools zu installieren. Sie greifen an vielen stellen bei Interaktionen mit der VM im Bereich Host und Storage. Hinzu kommt, ob man DRS und HA am Start hat und vileicht Antwortzeiten interesant sind. Wenn die VM “nur” auf einem ESXi Server läuft und man das Ding ganz flach betreibt, geht es auch ohne meiner Meinung nach.
Wir sollten dafür eine Variable in der Host-Konfigurationsdatei im Ansible einführen, sodass, falls diese gesetzt ist, eine gewisse Rolle dann die oben genannten Pakete installiert.
Wir verstehen nicht, woher dieser apt-transport-https-Fehler kommt. Der war vorher definitiv nicht da. Wenn man aber dieses Paket installiert, geht es wieder.
Und es hat ja auch immer funktioniert und plötzlich nicht mehr. Ich denke, dass irgendeine unserer Quellen was auf ihrem Webserver verändert hat. Simon vermutet vielleicht eine Headerweiterleitung auf https.
Hmm, die Beschreibung im verlinkten Forum verstehe ich anders:
Es kann sein, dass alle Repo-Quellen mit http eingetragen sind, aber mindestens eine davon über redirects auf https umgeleitet wird. Damit apt dem folgen kann, braucht es apt-transport-https. Bei dem Fehlschlag von apt update kann apt die gecachten Quellen invalidieren, so dass nachfolgende apt install/upgrade nicht mehr funktionieren.
Also Http-nach-https-Redirect ist die Ursache und kaputte apt-get caches eine der Folgen.
Entscheidend ist halt, dass sich da kürzlich was geändert haben muss, da wir bisher keine Probleme hatten.
Ich hab in der common-Rolle jetzt apt-transport-https hinzugefügt. Wenn der sich weigert das auszurollen, einmal die Zeile etwas darüber mit der Cacheaktualisierung auskommentieren, dann installiert er das Paket.