Bluescreen beim Drucken nach Windows-Update 03/2021

Wieder mal ein ein Qualitätsupdate aud Hause Microsoft. Nach dem Update zum Patchday im März 2021 kommt es bei vielen Anwendern zu Systemabstürzen, beim Versuch Dokumente zu drucken. Auch der Start von LibreOffice führte an einigen Stellen zu Bluescreens. Microsoft hat den Fehler inzwischen als solchen anerkannt und wohl die Verteilung des Updates ausgesetzt. Als Lösung wird vorgeschlagen, das Update zu deinstallieren. Für Windows 10 (v2004):

wusa /uninstall /kb:KB5000802

Oder für Windows 10 (v20H2):

wusa /uninstall /kb:KB5000808

Diese Befehle setzt man in einer Eingabeaufforderung mit erhöhten Rechten („als Administrator ausführen“) ab. Alternativ kann man das natürlich auch in der Systemsteuerung deinstallieren. Das ist aber viel umständlicher.

Update:
Man sollte auch in jedem Fall die Installation von Updates generell in der Systemsteuerung aussetzen. Sonst bekommt man das räudige Update direkt wieder installiert. Das ist natürlich nur eine mittelgute Lösung, weil dann auch andere wichtige Updates nicht installiert werden. Gut, dass ich da nicht mit arbeiten muss.

Update Nextcloud 20 -> 21

Gerade bin ich beim Update der Nextcloud von 20.x auf die aktuelle 21 auf das Problem gestossen, dass der Out-of-Memory-Killer des Kernels den Updateprozess reproduzierbar abwürgt. Lösung dafür:

apc.enable_cli=1

in die /etc/php/7.3/cli/conf.d/20-apcu.ini eintragen. Danach den Upgradeprozess nochmals anwerfen.

Windows GPOs. Ein Quell ewiger Freude. Nicht.

Grundsätzlich finde ich die Idee der Gruppenrichtlinien gar nicht doof. Wenn sie denn halbwegs reibungslos funktionieren würden. Tun sie leider nicht. Und leider ist mit Bordmitteln den Probleme auch nicht wirklich beizukommen.

Seit geraumer Zeit nervt mich die Tatsache, dass eine (1) Gruppenrichtlinie nicht appliziert wird. Mit der Aussage:

Die Computerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:

Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\gruppeheat.net\SysVol\<bla.blubb>\Policies\{UUID}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:

Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, registrierungsbasierte Richtlinieneinstellungen für das Gruppenrichtlinienobjekt "LDAP://CN=User,cn={UUID},cn=policies,cn=system,DC=<BLA>,DC=<BLUBB>" zu lesen. Die Gruppenrichtlinieneinstellungen dürfen nicht erzwungen werden, bis dieses Ereignis behoben ist. Weitere Informationen über den Dateinamen und -pfad, der den Fehler verursacht hat, können den Ereignisdetails entnommen werden.
Bei der Verarbeitung der Benutzerrichtlinie sind folgende Warnungen aufgetreten:

Fehler beim Anwenden der "Group Policy Drive Maps"-Einstellungen. Die "Group Policy Drive Maps"-Einstellungen besitzen möglicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".
Fehler beim Anwenden der "Group Policy Printers"-Einstellungen. Die "Group Policy Printers"-Einstellungen besitzen möglicherweise eine eigene Protokolldatei. Klicken Sie auf den Link "Weitere Informationen".

Lesen Sie zur Fehlerdiagnose das Ereignisprotokoll, oder führen Sie den Befehl "GPRESULT /H GPReport.html" aus, um auf Informationen über Gruppenrichtlinienergebnisse zuzugreifen.

Solche Dinge, wie UNC-hardened-path wurde schon korrigiert, bzw. die Einstellungen angepasst. Die gpt.ini kann, zumindest als Benutzer, problemlos geöffnet werden und ist auch auf allen DCs vorhanden. Die DNS-Auflösung funktioniert reibungslos. Jetzt liest man zuweilen in Foren, dass man doch die Die Richtlinie mal löschen und neu erstellen soll. Kann man sicher probieren, ist aber irgendwie doof und nicht sonderlich professionell.

Glusterfs und wie man den aktuellen Status abfragt

Glusterfs eignet sich relativ gut für shared storage in Proxmox-Umgebungen. Wenn man dabei alles im Blick hat, erspart man sich so einigen Ärger.

Gluster Filesysteme verteilen ihre Daten, je nach Gusto der Administratorin, auf mehrere Platten. Wenn man einen “poor-womans”-Cluster gebaut hat, bei dem die Proxmox-Server auch gleich die Datenspeicher sind, muss man ein paar Sachen beachten. Zum Beispiel sollte man einen 2er Clusterknoten nur dann herunterfahren, wenn die Datenbestände auf beiden Geräten synchron sind. Und vielleicht möchte man auch die aktiven Maschinen vorher auf den CLusterknoten migrieren, der aktiv bleibt. Das spart hinterher Zeit. Was man auf jeden Fall nicht machen möchte, ist den 2. Knoten herunterzufahren, während die Synchronisation der Daten noch nicht abgeschlossen ist. Sonst hat man hinterher eine schöne Splitbrain-Situation und unter Umständen schönen Datensalat.

Um zu sehen, in welchen Zustand sich die Volumes befinden bedient man sich des “gluster”-Kommandos:

st-cluster-2# gluster volume status     
Status of volume: proxmox
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 10.10.0.1:/srv/data/gluster-brick     49152     0          Y       2051 
Brick 10.10.0.2:/srv/data/gluster-brick     49152     0          Y       2102 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2144 
NFS Server on 10.10.0.1                     N/A       N/A        N       N/A  
Self-heal Daemon on 10.10.0.1               N/A       N/A        Y       2136 

Task Status of Volume proxmox
------------------------------------------------------------------------------
There are no active volume tasks

Status of volume: proxmox-ssd
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 10.10.0.1:/proxmox-ssd                49153     0          Y       2078 
Brick 10.10.0.2:/proxmox-ssd                49153     0          Y       2112 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2144 
NFS Server on 10.10.0.1                     N/A       N/A        N       N/A  
Self-heal Daemon on 10.10.0.1               N/A       N/A        Y       2136 

Task Status of Volume proxmox-ssd
------------------------------------------------------------------------------
There are no active volume tasks

Status of volume: proxmox-ssd2
Gluster process                             TCP Port  RDMA Port  Online  Pid
-----------------------------------------------------------------------------
Brick 10.10.0.1:/var/lib/vz/gluster-ssd     49154     0          Y       2107 
Brick 10.10.0.2:/var/lib/vz/gluster-ssd     49154     0          Y       2124 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2144 
NFS Server on 10.10.0.1                     N/A       N/A        N       N/A  
Self-heal Daemon on 10.10.0.1               N/A       N/A        Y       2136 

Task Status of Volume proxmox-ssd2
------------------------------------------------------------------------------
There are no active volume tasks
 
st-cluster-2#

Hier kann man sehen, dass beide Knoten aktiv sind. Ob auf einem Volume Daten noch zur Synchronisation anstehen erfährt man mit

st-cluster-2# gluster volume heal proxmox-ssd2 info
Brick 10.10.0.1:/var/lib/vz/gluster-ssd
Status: Connected
Number of entries: 0

Brick 10.10.0.2:/var/lib/vz/gluster-ssd
Status: Connected
Number of entries: 0

st-cluster-2#

Hier sind alle Daten synchron.

Wenn ein Volume fehlt, sieht das so aus:

Status of volume: proxmox-ssd2
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 10.10.0.2:/var/lib/vz/gluster-ssd     49154     0          Y       2124 
NFS Server on localhost                     N/A       N/A        N       N/A  
Self-heal Daemon on localhost               N/A       N/A        Y       2144 

Task Status of Volume proxmox-ssd2
------------------------------------------------------------------------------
There are no active volume tasks

Nach dem Neustart wird wieder synchronisiert:

st-cluster-2# gluster volume heal proxmox-ssd2 info
Brick 10.10.0.1:/var/lib/vz/gluster-ssd
Status: Connected
Number of entries: 0

Brick 10.10.0.2:/var/lib/vz/gluster-ssd
/images/107/vm-107-disk-1.qcow2 
/images/102/vm-102-disk-1.qcow2 
Status: Connected
Number of entries: 2

st-cluster-2#

Es ist ratsam zu warten, bis die Anzahl der Einträge auf 0 gesunken ist. Für alle Volumes. Danach kann man gefahrlos die Maschinen zurückmigrieren und ggf. den anderen Clusterknoten neustarten.

Das leidige Problem mit ntp und Nagios

Seit Jahren nervt Nagios beim Check des NTP-Serves mit einer Fehlermeldung. Natürlich nicht immer. Und natürlich hat man das Problem auch nach Jahren noch nicht beseitigt

Die Fehlermeldung NTP CRITICAL: Offset unknown sorgt bei Überprüfen von NTP-Servern mit Nagios / CheckMK und ähnlichen Systemen für Frust und Ärgern. Zumindest bei Debian Linux und dessen Derivaten kann man das Problem recht einfach beheben. Es gibt in der /etc/ntp.conf standardmäßig einen Eintrag:

restrict 127.0.0.1
restrict ::1

Dieser Eintrag sorgt dafür, dass nur der lokale Host dem Server entsprechende Fragen stellen darf. Um dem Monitor-Host erweiterte Rechte zu geben, muss man den Eintrag entsprechend erweitern:

restrict <IP des Monitor-Hosts>

muss direkt nach den eingangs genannten Einträgen angefügt werden. Nach einen Neustart des NTP-Server mit systemctl restart ntp.service zeigen dann auch Nagios & Co keine Fehlermeldung mehr, sondern die entsprechenden Daten.

Das sollte dann jetzt mal eine Eintrag im Ansible-Rezept werden, damit amn das nicht immer vergisst.

Upgrade eines Postgres-Clusters

nach einem Upgrade der Distribution folgt meistens auch ein Upgrade des Datenbank.

Schade, dass Postgres das nicht automatisch macht, aber es wird dafür sicher Gründe geben. Der Umzug ist aber kein Beinbruch, sofern man die alten Pakete noch nicht deinstalliert hat.

Ich werde das hier gerade am Beispiel Debian 9 -> Debian 10 Upgrade zeigen. Beim Upgrade merkt apt an, dass die “alten” Pakete nicht mehr supportet sind und dass man auf die neuen umziehen möge. Die alten Postgres-Pakete werden nicht automatisch gelöscht. Das muss man am Ende des Umzugs manuell machen. Man sollte das auch nicht auf die lange Bank schieben, sondern zeitnah nach dem Upgrade machen. Sonst gibt das unter Umständen unschöne Probleme.

Wir schauen erstmal, was wir so haben:

pg_lscluster
Ver Cluster Port Status Owner    Data directory               Log file
9.6 main    5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main  /var/log/postgresql/postgresql-11-main.log

Dann wird Postgres gestoppt:

systemctl stop postgresql.service
pg_lsclusters 
Ver Cluster Port Status Owner    Data directory               Log file
9.6 main    5432 down   postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
11  main    5433 down   postgres /var/lib/postgresql/11/main  /var/log/postgresql/postgresql-11-main.log

Der Umzug wird dann so gestartet:

cd /tmp
sudo -H -u postgres /usr/lib/postgresql/11/bin/pg_upgrade \
-b /usr/lib/postgresql/9.6/bin \
-B /usr/lib/postgresql/11/bin \
-d /var/lib/postgresql/9.6/main \
-D /var/lib/postgresql/11/main \
-o ' -c config_file=/etc/postgresql/9.6/main/postgresql.conf' \
-O ' -c config_file=/etc/postgresql/11/main/postgresql.conf'

Testen, ob es funktioniert:

pg_ctlcluster 11 main start

Wenn keine Fehlermeldungen gibt, muss man noch den Port in /etc/postgresql/11/main/postgresql.conf auf 5432 ändern. Beim alten Cluster wird dann der Port auf 5433 (oder irgendeinen anderen, nicht benutzten Port) gesetzt.

systemctl start postgresql.service

startet dann die Datenbank wieder. Wenn auch die Anwendung problemlos funktioniert, kann man die postgresql-9.6-Pakete deinstallieren:

apt remove postgresql-*-9.6

Upgrade omv 4 nach 5

das Upgrade auf openmediavault 5 (und warum man lieber neu installieren sollte)

Nach mehreren Schweißausbrüchen (u.a. wegen der nicht vollständigen Datensicherung) und der Tatsache, daß ich mich eigentlich schon mit dem Zurücksetzen des ZFS-Snapshots beschäftigt hatte, habe ich das Upgrade jetzt wohl fertig. Allerdings nur unter Zuhilfenahme eines fertig eingerichteten OMV-5 und einiger schmutziger Tricks aus “don’t try this at home”-Kiste. Neben einigen nicht angelegten Konfigurationsdateien waren auch Dienste deaktiviert. Darunter der Konfigurationsdaemon. Was permanent dazu geführt hat, dass Änderungen im WebUI ausser Fehlermeldungen nix eingebracht haben.

Man möge also beherzigen, dass ein Upgrade nicht supported ist. Daher: Daten sichern, neu aufsetzen, Daten zurücksichern. Vielleicht funktioniert das ja zusammen mit der angebotenen Konfigurationssicherung, so daß man nicht alles komplett neu machen muss.

Openmediavault als Memberserver in einer ADS-Domain

Wie man einen OMV in einer ADS-Domäne betreibt

Der Openmediavault (https://www.openmediavault.org) ist ein gelungenes System für einen Selbstbau-NAS. Auf beliebiger PC-Hardware lässt sich ein auch für Laien installierbares und verwaltbares Debian-Linux mit ansprechender und funktioneller webbasierter Administrationsoberfläche bauen. Und es gibt sogar ein ZFS-Plugin, sodaß man auch die Vorzüge dieses Dateisystems nutzen kann.

Leider ist die Anbindung an eine Active-Directory-Domäne nicht über die Weboberfläche zu machen. Dabei ist gerade diese Funktion für die Verwendung im betrieblichen Umfeld nicht ganz uninteressant. Daher lege ich hier mal dar, wie man das schnell und schmerzlos unter Zuhilfenahme der Kommandozeile hinbekommt.

Es gibt wohl Leute, die das nach dieser Anleitung gemacht haben: https://forum.openmediavault.org/index.php?thread/23465-guide-to-omv-4-active-directory-integration/ . Leider habe ich bisher mit dem sssd bisher nur Ärger gehabt. Ich werde also den “traditionellen” Weg mit Winbind vorstellen, der bei mir seit Jahren problemlos läuft.

Fehlende Softwarepakete

zunächst benötigt man noch ein paar Softwarepakete:

apt install libnss-winbind libpam-winbind winbind libpam-krb5 krb5-user smbclient

login.defs

In /etc/login.defs passen wir die Werte für UID_MAX und GID_MAX an:

UID_MAX   6000000
GID_MAX   6000000

Die UIDs und GIDs der Domänenbenutzer werden > der standardsmäßigen 60000 liegen. Um die in OMV sichtbar zu machen, müssen diese Werte hier angepasst werden.

Anpassungen für Samba

Die Einstellungen für Samba müssen im Webinterface unter Dienste->SMB/SIFS vorgenommen werden. Wenn man die in die smb.conf direkt einträgt, werden sie bei der nächsten Konfigurationsänderung überschrieben:

password server = *
realm = <IHRE DOMAIN>
security = ads
allow trusted domains = no
        idmap config * : backend = autorid
        idmap config * : range = 10001-2000000

winbind use default domain = true
winbind offline logon = true
winbind enum users = yes
winbind enum groups = yes
winbind separator = /
winbind nested groups = yes
;winbind normalize names = yes
winbind refresh tickets = yes
template shell = /bin/bash
template homedir = /export/home/%U
client ntlmv2 auth = yes
client use spnego = yes
follow symlinks = yes
wide links = yes
unix extensions = no

Der Domain beitreten

kinit <ADS-Admin>
net join -U<ADS-Admin>
systemctl restart smbd
systemctl restart nmbd
systemctl restart winbind

nsswitch.conf anpassen

in /etc/nsswitch.conf die Einträge für passwd und group anpassen:

passwd:         files winbind
group:          files winbind

ein getent passwd oder getent group sollte jetzt die Domänenbenutzer bzw. -gruppen anzeigen.

OMV neu starten

Damit die Änderungen auch in der GUI verfügbar werden, muss man den OMV-Rechner neu starten. Evtl. gibt’s noch eine andere Option. Die ist mir aber nicht bekannt.