Springe zum Inhalt

Beim Hochfahren eines MariaDB-Galera-Cluster-Nodes muss dieser erst einmal synchronisiert werden. Standardmäßig sucht sich der Node einen anderen bereits synchronisierten Node des Clusters aus, von dem er anschließend synchronisiert. Bei der Synchronisation ist der Datenlieferant für die Zeit der Synchronisation komplett gesperrt und kann von Clients nicht verwendet werden. Um das zu verhindern kann ein eigener Node aufgesetzt werden, auf den keine Clientprogramme zugreifen. Dieser Node wird dann als bevorzugte Quelle für die Synchronisation bei allen anderen Nodes eingestellt.

In der MariaDB-Konfiguration muss dazu folgendes angegeben werden:

Zu beachten ist, dass als Name der Nodename und nicht der Hostname des bevorzugten Datenlieferanten angegeben werden muss. Dass Kommata am Schluß ist kein Schreibfehler, sondern sorgt dafür, dass bei nicht verfügbarem Datenlieferant dass Standardverfahren angewendet und ein zufälliger Node für die Synchronisation ausgewählt wird.

Bei der anschließenden Synchronisation des Nodes ist die Auswahl des bevorzugten Nodes auch im Logfile zu erkennen:

Im vorliegenden Beispiel war node0 as bevorzugter Node für die Synchronisierung eingestellt.

1

Bei der Arbeit mit virtuellen Maschinen benutzt man häuftig SSH zur Fernwartung. Was aber nun, wenn grundlegende Einstellungen geändert wurden und nach einem Neustart die VM gar nicht erst komplett startet, der SSH-Daemon also auch noch nicht läuft und kein Remote-Zugang möglich ist? Dann wäre ein Zugang zur Konsole der VM hilfreich.

...weiterlesen "VM-Konsolenzugang mit libvirt"

2

Einige Distributionen haben auf das als eierlegende Wollmilchsau beschriebene und von anderen mehr als gehasste systemd umgestellt. Ein Service, der den Startprozess einfacher, paralleler und konfigurierbarer machen soll. In der mitgelieferten Konfiguration von systemd funktioniert auch alles erst mal nach einer frischen Installation, allerdings ist entsprechend der am meisten eingesetzten Konfigurationen vorgegeben, in welcher Reihenfolge was gestartet wird.

Beispiel NFS und Strongswan

Die Entwickler haben sich gedacht, dass wohl in den meisten Konfigurationen erst mal NFS gemounted werden muss und erst dann IPSEC bzw. Strongswan gestartet werden kann, denn es könnte ja sein, dass z.B. /usr ein NFS-Mountpoint ist, aus dem Strongswan erst nach dem Mounten seine Dateien laden könnte. Soweit so gut.

Was aber nun, wenn die NFS-Mountpoints, wie bei mir, erst über bestehende IPSEC-Tunnel erreichbar sind? Dann muss manuell Hand angelegt werden. In die einzelnen mnt-*.mount-Files kann nichts manuell eingetragen werden, da diese beim Systemstart automatisch von systemd-fstab-generator erzeugt werden. Abhängigkeiten können dort also keine eingetragen werden. Abhilfe schafft nur, dass in strongswan.service eingetragen wird, dass die Unit vor remote-fs.target gestartet werden muss. Dazu wird "Before=remote-fs.target" in strongswan.service eingetragen:

Zum Aktualisieren der Konfiguration anschließend noch ein "systemctl daemon-reload" und ab jetzt wird beim Booten Strongswan vor den NFS-Mounts gestartet.

Schwerwiegende Fehler in Anwendungen oder Windows-Komponenten, dann wenn ein Programm abstürzt, werden vom Windows Error Reporting (in deutschsprachigen Versionen: Windows Fehlerberichterstattung) abgefangen. Diese Windows-Komponente erstellt daraufhin ein Speicherabbild der fehlerhaften Anwendung und läd diese Informationen anschließend auf Microsoft-Server hoch.

Beim Entwickeln von Anwendungen bedient man sich des Umstandes, dass durch speziell ausgelöste Programmfehler ein Windows-Dialog angezeigt wird, in dem man einen auf dem System installierten Debugger auswählen kann, um sein eigenes Programm weiter zu testen. Leider wird durch das Windows Error Reporting dieser Dialog schon abgefangen und man hat keine Möglichkeit mehr, das eigene Programm zu testen, ohne es direkt aus dem Entwicklungs-Debugger (z.B. Visual Studio) gestartet zu haben. ...weiterlesen "Windows Error Reporting abschalten"