Archiv der Kategorie: Software

Alles was mit Software zu tun hat

Windows-Update – Fehler 0x800f0831 beheben

Hinweis: Die Screenshots sind von einem älteren System, die Meldungen, Pfade und Vorgehensweisen sollten sich jedoch auch auf aktuelle Versionen übertragen lassen.

Und wieder das übliche Bild: Auf einem Windows-System sind nicht alle Updates installiert. Keine gute Idee, insbesondere bei Systemen, die an einem Netzwerk betrieben werden. Also schnell in die Einstellungen und Updates installieren – in der Theorie. Leider passiert es nach meiner Beobachtung immer wieder, dass Updates quer sitzen und sich nicht installieren lassen. Auch im aktuellen Fall sah man bereits: “Failed” war im letzten Installationsversuch zu erkennen.

8 offene Windows-Updates, letzter Installationsversuch fehlgeschlagen

Auch ein manueller Versuch über “Install updates” brachte kein Erfolg. Der Assistent schien fehlerfrei zu laufen, nach dem im Anschluss angeforderten Reboot war jedoch das Bild wieder identisch: Die Updates standen erneut als offen drin. Also erster Blick: Welche waren überhaupt betroffen. In den Details fanden sich neben den meist wenig aussagekräftigen Bezeichnungen auch die KB-Nummern, welche bei Microsoft die zugehörigen Dokumentationen beschreiben.

Liste der offenen Updates mit KB-Nummern

Hier kam dann der Microsoft Catalog unter https://www.catalog.update.microsoft.com/ ins Spiel: Über diese Webseite lassen sich per KB-Nummer einzelne Updates suchen und per Hand herunterladen. Hierbei etwas aufpassen: Oft sind die Updates für verschiedene Betriebssystemversionen und CPU-Architekturen mit der selben KB-Nummer eingestellt, beim Download lohnt es sich also doppelt hin zu schauen.

Microsoft Update Katalog-Webseite mit einzelnen Updates

Die zum Download angebotenen MSU-Dateien sollten sich direkt per Doppelklick öffnen lassen und einen Setup-Assistenten zeigen. Leider brachte auch die händische Installation keine Besserung – am Ende des Assistenten vermeldete das Ergebnis ein wenig aussagekräftiges “The following updates were not installed“. Auch die Ereignisanzeige des Betriebssystems verriet nicht mehr als eben jene wenig hilfreiche Statusmeldung.

An dieser Stelle wird oft eine Reparatur mit DISM.exe /Online /Cleanup-image /Restorehealth bzw. Sfc /scannow oder gar eine Neuinstallation empfohlen. Ist jedoch klar, dass das System keine weiteren Probleme hat, ist eine gezielte Reparatur jedoch oft weniger Zeitintensiv als eine vollständige Neuinstallation, insbesondere wenn die betroffenen Systeme nicht über ein Konfigruationsmanagement/Orchestration zur automatischen Installation verfügen.

Glücklicherweise erstellt Windows Update an diversen Stellen erweiterte Protokolle, welche die Fehlersuche erleichtern. Bei Installationsfehlern sind die CBS-Logs meist die hilfreichste Anlaufstelle. Die Korrekte Datei findet sich unter %systemroot%\Logs\CBS\CBS.log. Eine Suche nach ” Error ” (mit ein paar Leerzeichen dahinter) sollte die relevante Stelle schnell sichtbar machen. In diesem Fall handelte es sich um eine Inkonsistenz im Updatespeicher, die zugehörige KB-Nummer ist in solchen Fällen in der Fehlermeldung erkennbar. Wer diese vergleicht wird feststellen, dass es sich hierbei nicht um eins der zur Installation vorgemerkten Updates handelte. Stattdessen betraf es ein älteres Update, welches für die aktuelle Installation benötigt wurde. Das genannte, ältere Update war laut System installiert, fehlte in Realität jedoch. Ein solcher Zustand ist oft zu finden, wenn bei einem vorherigen Update der Rechner abstürzte.

Ausschnitt CBS-Log. Vorausgesetzte KB-Nummer in der Fehlermeldung erkennbar

Also zurück zum Catalog, dort kann man das defekte Update manuell herunterladen und nochmals installieren. Ist dies Erfolgreich sind Updatespeicher und Realität an dieser Stelle wieder auf einem konsistenten Stand und die Installation der neueren Updates kann fehlerfrei erfolgen. Möglicherweise muss der Vorgang für mehrere ältere Updates wiederholt werden. Hier kann es helfen in der Updatehistorie zu prüfen, welche Updates mit dem Betroffenen zeitgleich installiert wurden und diese – sofern nicht ersetzt – präventiv ebenfalls neu zu installieren. Am Ende sollten sich alle Updates installieren und das System so auf einen aktuellen Stand bringen lassen.

Windows 10: Fehlende Audioausgabe nach April 2020-Updates (Realtek)

Nach installation der April 2020 Updates für Windows 10 19.09 kam es auf einigen von mir betriebenen Systemen zum Verschwinden der Audio-Treiber. Somit war eine Ton Ein- und Ausgabe nicht mehr möglich. In Zeiten von dauerhaften Videoschalten eher ungünstig. Selbes wurde von anderen Nutzern berichtet. Allen gemein: Es handelt sich um PCs und Laptops mit Realtek-Sound auf Basis von Intel HD Audio.

Treiber-Updates zeigen keine Änderung, das Booten eines vernünftigenanderen Betriebssystems bingt funktionierenden Ton mit sich. Interessant dabei: Die Audio-Devices tauchen nicht einmal mehr im Gerätemanager auf. In den ausgeblendeten Geräten wird das Gerät noch angezeigt, jedoch mit der Info “Dieses Hardwaregerät ist zurzeit nicht an den Computer angeschlossen. (Code 45)”.

Sucht man etwas weiter findet man unter “Systemgeräte” einen Eintrag für “Intel(R) Smart Sound Technologie-OED”, welcher als “nicht gestartet” (Code 10) markiert ist.

Auch an diesem kann man sich lange erfolglos abarbeiten. Ursache ist der vermeintlich fehlerfreie eintrag drüber: “Intel(R) Smart Sound Technologie-Audiocontroller”. Hier klickt man in den Details auf Treiber ? Treiber aktualisieren. Im Assistenten wählt mach “Auf dem Computer nach Treibersoftware suchen” und dort “Aus einer Liste verfügbarer Treiber auf meinem Computer auswählen”.

Nun erhält man eine Liste aktueller und älterer Treiber. Statt der Smart-Sound-Technologie (SST) wählt man “High Definition Audio-Controller” und installiert diesen. Im Anschluss erkennt Windows alle Geräte am Audio-bus neu und die Sound-Ausgabe sollte wieder wie gewohnt funktionieren.

PostgreSQL-Update im Docker-Stil

Docker. Eigentlich ja ganz praktisch, wenn man “mal schnell” ein Softwarepaket trotz überschaubarer Wartbarkeit mit überschaubarem Aufwand ausrollen möchte, ab und an aber auch ein zuverlässiger Quell für Facepalm-Momente. So auch Heute: Nach dem Update einer mit docker-compose zusammengesetzten Anwendung ging nichts mehr. Der Maintainer hatte dort von postgres:10 auf postgres:11 aktualisiert. Kleines Update sollte man meinen, die PostgreSQL-Images für Docker sind jedoch technisch nicht in der Lage Daten älterer Installationen zu migrieren. Folglich zeigte sich im Log vor dem Absturz folgende Meldung:

postgres_1 | FATAL: database files are incompatible with server
postgres_1 | DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 11.6.

Was auf “normalen” Servern mit pg_upgrade schnell geregelt und bei einigen Distributionen gar automatisiert ist, wird mit Docker ein paar Nummern komplizierter. Der Offizielle Weg: Backup machen, neu aufsetzen, importieren. Eigentlich wollte ich durch Docker Arbeit sparen, nicht mir weitere aufhalsen.

Glück im Unglück: Tianon Gravi hat auf GitHub und Docker Hub ein passendes System bereitgestellt, mit welchem man die Daten schnell zwischen verschiedenen PostgreSQL-Versionen migrieren kann.

Im Folgenden gehe ich davon aus, dass ein Named Volume “postgres-data” existiert und alle darauf zugreifenden Container gestoppt sind.

Achtung, Fallstrick: Nutzt man docker-compose, so ändern sich die Volume-Namen. Ein Named Volume “postgres-data” der Applikation “foobar” heißt in Wahrheit “foobar_postgres-data“. Im Zweifel nochmal mit “docker volume ls” prüfen.

  1. Fangen wir mit dem üblichen an: Backups. Bei Bind-Mounts kopiert man einfach den Quellordner passend zurecht, bei Named Volumes kann man diese üblicherweise unter /var/lib/docker/volumes/ finden oder mit docker-clone-volume duplizieren. Ich hatte postgres-data hierzu auf postgres-data-src und postgres-data-bck dupliziert.
  2. Weiter geht es mit dem Umwandeln der Datenbank. Hierzu nimmt man das Image mit den passenden Versionsnummern für Quell- und Zielversion.
    docker run --rm -v postgres-data-src:/var/lib/postgresql/10/data -v postgres-data-dst:/var/lib/postgresql/11/data tianon/postgres-upgrade:10-to-11
    Hiermit wird ein neues, mit PostgreSQL 11 kompatibles, Volume erzeugt, welches alle bisherigen Daten enthalten sollte.
  3. Leider gibt es in der aktuellen Version einen bekannten Bug, welche die Zugriffe in pg_hba.conf abweichend von den Dateien der offiziellen Images konfiguriert. Dies führt mit vielen Images zu Zugriffsfehlern. Um die Datei per hand zu editieren startet man entweder einen passenden Container oder greift über das Dateisystem des Hosts auf diese zu. In meinem Fall nutzte ich letztere Methode über die Datei /var/lib/docker/volumes/postgres-data-dst/_data/pg_hba.conf. An das Ende dieser wird folgende Zeile angefügt:
    host all all all md5
  4. Am Ende ändert man entweder den Volume-Eintrag seiner docker-compose.yml oder kopiert das neue Image passend zurück. In meinem Fall klang letzteres sinnvoller. Einen Befehl zum Umbenennen von Volumes ist Docker bis Heute nicht bekannt, daher bleibt hier nur das ursprüngliche Volume mit docker volume rm postgres-data zu löschen und postgres-data-dst – wie zuvor – mit docker-clone-volume oder im Dateisystem zum korrekten Volume-Namen zu klonen.

Warum man das nicht automatisiert erschließt sich mir nicht so ganz. Vermutlich beschränkt sich der Benutzerkreis hauptsächlich auf Entwickler, die ohnehin immer von 0 starten, und Enterprise-Häuser, die gemäß Fire-and-forget Systeme ohne Update bis zur Explosion betreiben.

Nginx: allow mit dynamic DNS

Wenn man Webseiten mit Backend betreibt ist es oft eine gute Idee die Verwaltungsbereiche nur von bestimmten IPs oder Netzen zuzulassen. Unter nginx gibt es hierzu den allow-Befehl, mit welchem man IPs und Netze angeben kann. Ich verwende dies z.B. häufig um nur interne IP-Bereiche oder per VPN angebundene Clients zuzulassen. Für ein aktuelles Projekt sollte jedoch auf ein VPN verzichtet werden. Theoretisch kein Problem – externe IP rein und fertig, aber leider ist es auch 2019 noch in Deutschland für viele Anschlussarten üblich bei Trennung und erneutem Verbinden eine andere IP-Adresse zuzuweisen. Für eingehende Verbindungen lässt sich dies mittels dynamischen DNS-Einträgen schnell in den Griff bekommen, jedoch ist das für das hiesige Konstrukt keine Option, da nginx mit solchen Einträgen nicht sinnvoll umgehen kann. Im Netz finden sich einige Helper-Scripte, welche den DNS regelmäßig Prüfen, die Konfiguration anpassen und den Webserver passend umkonfigurieren. Leider sind diese oft eher alt und nur auf das schon seit Jahrzehnten veraltete IPv4 ausgelegt. Als Abhilfe habe ich meine Anforderungen in ein kleines Python-Script gegossen. Für IPv6 wird von der aufgefundenen IP auf ein /48er Netz geschlossen und dieses freigegeben, sollte euer Provider nur ein /56er oder gar /64er rausrücken muss dass ggf. angepasst werden.

Vorbedingung ist, dass nginx die neue Konfiguration findet. Um es einfach zu halten stehen die dynamischen Einträge in einer separaten Textdatei, welche an passender Stelle per include eingebunden wird. Statische Einträge können, sofern vorhanden, an der üblichen Stelle bleiben.

[…]
location /admin {
        allow 192.168.0.0/24;
        include /etc/nginx/dyndns.conf;
        deny all;
        […]

Das eigentliche Script nutzt nach meinem Wissen keine externen Module und sollte somit auf jedem System mit Python 3 laufen. Es werden alle IPv4- und IPv6-Adressen abgerufen. Der angegebene Port (80) ist irrelevant, da nur die IPs genutzt werden. Die Konfiguration wird mittels MD5 auf Änderungen geprüft, liegt eine solche vor wird per Systemd eine reload ausgelöst. Ich habe die Datei mit in den nginx-Konfigurationsordner als /etc/nginx/dyndns.py gepackt – nicht schön, aber passte besser in die bereits vorhandene Struktur und Verwaltung.

#!/usr/bin/python3
import socket
import subprocess
import hashlib
import ipaddress


def md5(fname):
    hash_md5 = hashlib.md5()
    with open(fname, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            hash_md5.update(chunk)
    return hash_md5.hexdigest()



before = md5("/etc/nginx/dyndns.conf")
cfg = open("/etc/nginx/dyndns.conf", "w")
addrs = socket.getaddrinfo("DEIN.DYNAMISCHER.DNS", 80, type=socket.SOCK_STREAM)
for addr in addrs:
    out = ""
    ip = ipaddress.ip_address(addr[4][0])
    if ip.version == 6:
        ip = ipaddress.ip_network(str(addr[4][0]) + "/48", False)
        out = (str(ip.network_address) + "/" + str(ip.prefixlen))
    else:
        out = addr[4][0]
    cfg.write("allow\t\t" + out + ";\t#Dynamic DNS\n")

cfg.close()

after = md5("/etc/nginx/dyndns.conf")

if before != after:
    #DNS has changed
    #print("RELOAD")
    subprocess.call('/usr/bin/systemctl reload nginx', shell=True)

Das Script muss regelmäßig gestartet werden um Änderungen zu prüfen. Wenn der zugehörige DNS-Dienst auf dem selben System läuft kann man möglicherweise auf Hooks zurückgreifen, andernfalls muss es zeitbasiert über Cron oder Timer laufen. Für letzteres mit einem Intervall von 5 Minuten legt man die Datei /etc/systemd/system/nginx-dyndns.timer an und füllt sie wie folgt:

[Unit]
Description=Nginx DNS updater

[Timer]
OnBootSec=0min
OnUnitInactiveSec=5m

[Install]
WantedBy=timers.target

Dazu benötigt man noch einen passenden Service, welcher unter /etc/systemd/system/nginx-dyndns.service definiert wird:

[Unit]
Description=Nginx DNS updater

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/usr/bin/python3 /etc/nginx/dyndns.py

Last but not least wird der Timer eingeschaltet:

systemctl enable --now nginx-dyndns.timer

OSTicket: Ticketerstellung über Python

OSTicket ist ein freies Ticketsystem, also System zur Sammlung und Dokumentation von Aufgaben. Ab und an kann es praktisch sein solche Aufgaben auch per Software zu generieren, z.B. für wiederkehrende Aufgaben oder wenn Systeme Störungen automatisiert erkennen. Da die Doku bisher eher dünn ist anbei ein kleines Python-Script, welches über die API Tickets erstellen kann. Hierzu muss erst im Admin-Bereich ein passender API-Zugang angelegt werden. Zu beachten ist, dass ein solcher API-Zugang auf eine IP limitiert ist.

import requests
import json

headers = {'X-API-Key': '12345ENTERHERE12345'}
subject = "12345"

ostdata = {
    "alert": True,
    "autorespond": False,
    "source": "API",
    "name": "GenervterUser",
    "email": "genervter@us.er",
    "phone": "",
    "subject": str(subject),
    "ip": "::1",
    "message": "data:text/plain,Ich bin ein Ticket",
}

json_data = json.dumps(ostdata)

r =
requests.post("https://helpdesk.meinefirma.local/api/tickets.json", data=json_data, verify = '/usr/local/share/ca-certificates/meineca.crt', headers=headers)
print(r)

Hinweise:

  • Der verify-Parameter ist nur nötig, wenn man HTTPS mit einer im System unbekannten CA nutzt
  • Die Telefonnummer wird bei source=API wohl nicht angezeigt
  • Der Name wird bei erster Nutzung mit der E-Mail-Adresse verknüpft, wenn man weitere Tickets mit der selben E-Mail anlegt scheinen diese alle den zuerst genutzten Namen anzuzeigen

Weitere Doku

[NextCloud/EN] No login possible after Update to 13.0.4 due to encryption app

I ran into some trouble while Updating to NC 13.0.4 regarding encryption. As long as Encryption was installed and enabled no login was possible – WebDAV and Clients received HTTP/503, WebUI didn’t show the login form but only “Bad Signature”. Also occ failed with the same error – “bad signature”. The previously working version was afair 13.0.1, since downgrading isn’t supported I can’t say much for .2 and .3. Inside the log (see below) I could see the error being caused by the encryption module. There might be the odd encrypted folder still present in old accounts, but since it never worked for me reliably it’s disabled for everything currently in use. External solutions are IMO the way to go.

{"reqId":"xyz","level":4,"time":"2018-07-20T17:53:17+00:00","remoteAddr":"xyz","user":"--","app":"webdav","method":"PROPFIND","url":"\/remote.php\/dav\/files\/xyz\/","message":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\ServiceUnavailable\",\"Message\":\"OCP\\\\Encryption\\\\Exceptions\\\\GenericEncryptionException: Bad Signature\",\"Code\":0,\"Trace\":\"#0 [internal function]: {closure}(*** sensitive parameters replaced ***)\\n#1 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Object(Closure), Array)\\n#2 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/html\\\/remote.php(72): Sabre\\\\DAV\\\\Server->exec()\\n#5 \\\/var\\\/www\\\/html\\\/remote.php(167): handleException(Object(OCP\\\\Encryption\\\\Exceptions\\\\GenericEncryptionException))\\n#6 {main}\",\"File\":\"\\\/var\\\/www\\\/html\\\/remote.php\",\"Line\":70}","userAgent":"Mozilla\/5.0 (Windows) mirall\/2.3.2 (build 1) (Nextcloud)","version":"13.0.4.0"}

The usual literature suggests to disable the encryption module using occ – not quite helpful in my case. Deleting the encryption app on FS-level did revive occ and Web but the App now failed due to missing encryption. My solution was to disable encryption using SQL instead of just deleting it:

UPDATE `oc_appconfig`
SET `configvalue` = 'no'
WHERE `oc_appconfig`.`appid` = 'core'
AND `oc_appconfig`.`configkey` = 'encryption_enabled';

Windows RDP: “Die angeforderte Funktion wird nicht unterstützt” (CredSSP)

Zugegeben, ich bin etwas spät dran, aber heute bin ich bei einer Stelle mit CredSSP und RDP dann auch mal auf die Schnauze gefallen. Da mir das – dank sonst gepflegter Infrastruktur – bisher nicht begegnet ist hier nochmal zum Nachlesen. Und mich als Gedächtnisstütze.

Vorgeschichte

Verursacher der ganzen Misere ist CredSSP, der Credential Security Support Provider. Dieses Windows-Modul ist unter Anderem für die Authentifizierung von Nutzern bei Verbindungen über RDP (Remote Desktop Protocol) und WinRM (Windows Remote Management) zuständig. Durch einen Fehler im Umgang mit den Sitzungen (CVE-2018-0886) können Angreifer einen Man-in-the-Middle-Angriff ausführen und so die bestehende Sitzung übernehmen. Da RDP und WinRM häufig für administrative Zwecke genutzt wird, können sich so Unbefugte ggf. weitrechende Zugriffe auf die verwalteten Systeme beschaffen. Betroffen ist so ziemlich alles – vom einfachen Windows 7 über die Server-Produkte bis hin zum aktuellen 10 sowie Server 2016.

Fixing

Microsoft hat den Fix in mehreren Stufen ausgerollt. Erstmals erschienen passende Updates im März, welche das Problem prinzipiell beheben. Sofern sie überall installiert werden. Zwei Monate später, im Mai, zog der Hersteller dann die Sicherheitsschrauben an: Ab diesem Patch ist die Nutzung der Mitigation zwingend erforderlich.

Wer nicht plant guckt in die Röhre

Wer seine Systeme im Griff hat wird nicht viel merken – ist alles auf einem aktuellen Patchstand wird man von den Umstellungen nichts merken. Anders sieht es aus, wenn man bei den Updates nachlässig handelt. Hat der eigene Rechner bereits aktuelle Patches installiert, das Zielsystem jedoch seit März keine Wartung erfahren, hat man Pech: Der RDP-Client bzw. WinRM verweigern die Verbindung mit dem Zielsystem. “Die angeforderte Funktion wird nicht unterstützt”. Selbes dürfte auch für die andere Richtung gelten.

Und nu?

Was folgt sind zwei Dinge: Erst mal sollte man dem Verantwortlichen Admin des Zielsystems eine Schulung zu IT-Sicherheit verpassen, denn inzwischen mehr als ein halbes Jahr lang keine Updates installieren ist – zumindest meiner Meinung nach – grob fahrlässig. Danach sollte das Zielsystem natürlich auf einen aktuellen Stand gebracht werden – für den Zugriff mindestens notwendig ist der entsprechende CredSSP-Patch, welcher sich auch einzel im dazugehörigen Artikel finden lässt. Da für den nur ein Dopelklick notwendig ist kann das ggf. auch ein Poweruser mit passenden Zugriffen vor Ort erledigen. Hat man keine Möglichkeit das System selbst zu verändern muss man am Client ran: Hier kann man über die Registry oder per GPO auch unsichere Verbindungen zulassen und somit eine Verbindung zu den betroffenen Zielen wieder ermöglich. Dies sollte immer nur temporär geschehen – umstellen, verbinden, Fix installieren und wieder zurück. Keinesfalls sollte man während die Lockerung aktiv ist Verbindungen zu anderen Systemen aufbauen.

Registry

Hierzu liegt man unter HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters ein neues REG_DWORD mit dem Namen “AllowEncryptionOracle” an und gibt diesem den Wert “2“.

GPO

Das Pendant in GPO-Form findet sich unter Computerkonfiguration\Administrative Vorlagen\System\Delegierung von Anmeldeinformationen\Encryption Oracle Remediation. Diese muss aktiviert und die Schutzebene auf “Vulnerable” eingestellt werden.

EOF

Patchmanagement etablieren. Systeme zeitnah Patchen. Spart Arbeit. Und Axteinsätze bein den zuständigen Systembetreuern.

Docker: Start mit aktivem IPv6 nicht möglich

Docker kann bei mir nach wie vor zwei Lager bedienen: Die Idee von Containern klingt gut, die mangelnde Stabilität und viele Konzepte der Implementierung lassen mich aber nur den Kopf schütteln. Heutiges Thema: IPv6. Prinzipiell nicht wirklich nutzbar, da die meisten Orchestration-Systeme wie Kubernetes oder Swarm bisher laut Doku und Bugtrackern bestenfalls rudimentäre Unterstützung bieten. Docker selbst soll – laut Anleitung – jedoch mit wenigen Handgriffen IPv6-fähig gemacht werden können.

Klingt einfach? Tja, nach einem Neustart ließ sich der Docker-Daemon nicht mehr starten. Im Log fand sich folgendes:

dockerd: Error starting daemon: Error initializing network controller: Error creating default "bridge" network: could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network

Die Abhilfe ist recht einfach: Ein festes Netz vergeben. Hierzu in der daemon.json einen passenden fixed-cidr-v6-Eintrag machen:

{
"ipv6": true,
"fixed-cidr-v6": "2a01:1234:5678:9abc:def0::/112"
}

VMWare vCenter Server Appliance mit Proxy aktualisieren

Die Aktualisierung einer VCSA ist eigentlich ja recht einfach: Man geht über den Port 5480 auf das Appliance-Management (aka MUI, VAMI), klickt auf Update und das drunterliegende Linux wird samt aller Programme auf den aktuellen Release aktualisiert. Die Programme kommen dabei direkt von den Updateservern – zumindest wenn man eine direkte Internetverbindung hat. Steht das System in einem Netz, welches keinen direkten Zugang bietet und nicht über einen transparenten Proxy verfügt, lässt die UI die nötige Konfiguration einfach erscheinen: Unter Netzwerk -> Verwalten findet sich ein Menüpunkt “Proxy-Einstellungen”, welcher die direkte Eingabe ermöglicht. Theoretisch.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2018/01/vcsa.png

Die Praxis sieht leider anders aus: Dieses GUI-Element setzt lediglich die Umgebungsvariable http_proxy, welche ausschließlich für unverschlüsselte Verbindungen gültig ist. Da der Update-Download inzwischen per HTTPS läuft wird der Proxy praktisch ignoriert und der Download-Versuch läuft ins Leere. Dieses Problem tritt mindestens zwischen der Version 6.0 und der aktuellen 6.5U1 auf.

Zur Abhilfe muss man selbst Hand anlegen: In der Datei /etc/sysconfig/proxy findet sich neben der, von der GUI bereits gesetzten, Variable HTTP_PROXY auch ein passendes HTTPS_PROXY. Füllt man dies manuell aus ist der Update-Download fehlerfrei möglich. Wer vSAN einsetzt, sollte hier auch gleich noch die lokalen Server als Ausnahme definieren um den VMWare-Bug #2150523 zu umgehen.

Es zeigt sich wie so oft: Der Texteditor ist mächter als die Maus.

Danke an Andrew Richardson/VirtualSlices für das Aufklären des ursprünglichen Fehlers.

Keepass: Crash durch kaputte Mountpoints

Keepass ist ein quelloffener Passwortmanager, welcher Zugangsdaten verschlüsselt in einer Datei sammelt. Heute musste ich auf einem Gerät feststellen, dass sich die Software nicht mehr starten ließ: Der Passwortdialog erschien kurz, dann verschwand das ganze Programm vom Desktop. Über die Konsole ist ein absturz mit folgendem Trace zu erkennen:

Stacktrace:

  at <unknown> &lt;0xffffffff>
  at (wrapper managed-to-native) System.IO.MonoIO.FindFirstFile (string,string&,int&,int&) [0x00000]
  at System.IO.FileSystemEnumerableIterator`1<tsource_ref>.CommonInit () [0x0001d]
  at System.IO.FileSystemEnumerableIterator`1</tsource_ref><tsource_ref>..ctor (string,string,string,System.IO.SearchOption,System.IO.SearchResultHandler`1</tsource_ref><tsource_ref>,bool) [0x000d6]
  at System.IO.FileSystemEnumerableFactory.CreateFileNameIterator (string,string,string,bool,bool,System.IO.SearchOption,bool) [0x00009]
  at System.IO.Directory.InternalGetFileDirectoryNames (string,string,string,bool,bool,System.IO.SearchOption,bool) [0x00000]
  at System.IO.Directory.InternalGetFiles (string,string,System.IO.SearchOption) [0x00000]
  at System.IO.Directory.GetFiles (string,string) [0x0001c]
  at System.IO.DirectoryInfo.GetFiles (string) [0x0000e]
  at System.IO.DirectoryInfo.GetFiles (string,System.IO.SearchOption) [0x00009]
  at (wrapper remoting-invoke-with-check) System.IO.DirectoryInfo.GetFiles (string,System.IO.SearchOption) [0x00033]
  at KeePassLib.Utility.UrlUtil.GetFileInfos (System.IO.DirectoryInfo,string,System.IO.SearchOption) [0x00010]
  at KeePass.Forms.KeyPromptForm.AddKeyDriveSuggAsync (object) [0x0001c]
  at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (object) [0x00007]
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071]
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000]
  at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00021]
  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074]
  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000]
  at (wrapper runtime-invoke) <module>.runtime_invoke_bool (object,intptr,intptr,intptr) [0x0001e]
</module></tsource_ref></unknown>

Die Ursache ist etwas schwer zu finden, da nicht direkt ersichtlich: Netzwerkstörungen und Dateisysteme. Keepass durchsucht offenbar beim Start alle eingehangenen Partitionen, tritt hierbei ein Fehler auf kommt es zum Absturz. Dies betrifft nicht nur jene Speicherorte, auf denen Datenbank und ggf. Keyfile hinterlegt sind. In meinem Fall war durch einen Server-Neustart ein NFS-Mount abhanden gekommen (stale file handle), ähnliches war jedoch auch mit sshfs & co zu sehen. Eine Liste der aktuell genutzten Partitionen findet sich unter /etc/mtab, kaputte Dateisysteme lassen sich auch ohne Verbindung mit “umount -l” oder “fusermount -u” aushängen, hierbei kann jedoch möglicherweise Datenverlust entstehen, wenn noch Dinge im Schreibcache liegen. Nach Beseitigung des Fehlers lässt sich Keepass wieder regulär starten.