Alle Beiträge von Malte

Pacemaker und IPaddr2 mit unterschiedlichen Network-Interface Namen je nach Cluster-Node

Migriert man eine virtualisierte Infrastruktur beispielsweise zwischen VMware und Proxmox, so lernt man schnell, dass bei anders virtualisierten Netzwerk-Interfaces sich auch die Namen derer ändern. Aus ens192 wird zum Beispiel ens18 aufgrund der anderen internen Adressierung und weiteren Faktoren.

Möchte man einzelne Nodes eines Pacemaker- und Corosync-basierten Clusters nun Node-by-Node in die andere Infrastruktur überführen, lernt man schnell, dass der „nic=“ Parameter des ofc_heartbeat_ipaddr2-Skripts selbstverständlich im Rahmen der crm.conf, der „CIB“ (Cluster Information Base), sofort nach Änderung bzw. Aktivierung bei manueller Anpassung mit den anderen Nodes synchronisiert wird.

Das führt genau dann zu Problemen, wenn ein Node bereits auf Proxmox läuft, aber die CIB noch auf ein nicht mehr existierendes Network-Interface verweist. Um ein Cluster ohne Downtime und ohne Probleme im Betrieb zu switchen, empfiehlt es sich, den „nic=“ Parameter abhängig vom Namen des jeweiligen Nodes zu setzen. Eine elegante Lösung in der Konfiguration erschien mir so:

primitive vip1 IPaddr2 \
        params ip=10.10.10.5 cidr_netmask=32 \
        op monitor interval=3s \
        meta target-role=Started \
        params 3: rule #uname eq node1 nic=ens192 \
        params 2: rule #uname eq node2 nic=ens192 \
        params 1: nic=ens18

Die Nodes sind hierbei „node1“, „node2“ und „node3“. Die Priorität bestimmt „params 1“ bis „params 3“ wobei immer dort aufgehört wird, wo eine Regelübereinstimmung passiert. Im Beispiel würden node1 und node2 also als nic=ens192 bekommen, alle anderen Nodes, also auch node3, jedoch nic=ens18.

Übrigens wieder eine tolle Option, welche ChatGPT und auch eine Google-Suche nicht sofort zu Tage fördern, welche man jedoch sauber über die man-Page findet (siehe „Syntax: Rule expressions“).

FRITZ!Box mit WireGuard VPN: Besonderheiten mit SMB/Windows-Freigaben über VPN

Versucht man mithilfe einer FRITZ!Box ein WireGuard-VPN (die FRITZ!Box ist der Server) einzurichten, geht das ansich recht einfach. Zugriffe wie per HTTP sind dann vom VPN-Client zum Netzwerk der FRITZ!Box ohne Einschränkungen möglich.

Anders sieht das bei Windows-Freigaben aus. Zum einen werden diese nicht automatisch erkannt, zum anderen ist selbst bei manueller Eingabe der Zieladresse keine Verbindung möglich. Aus dem lokalen Netz hingegen schon.

Im Internet und ChatGPT wird schlicht auf die Aktivierung einer Option „NetBIOS“ in den VPN-Einstellungen der FRITZ!Box verwiesen. Richtet man das VPN allerdings normal über den Assistenten in der FRITZ!Box als „Client“ ein, erscheint eine derartige Option gar nicht. Man sucht während und auch nach der Erstellung der Client-Konfiguration vergebens nach dieser Einstellung.

FRITZ!Box mit WireGuard VPN: Besonderheiten mit SMB/Windows-Freigaben über VPN weiterlesen

HAProxy mit Let’s Encrypt und „standalone“-Modus betreiben

Bei gridscale findet man ein hervorragendes Tutorial zum Betrieb von HAProxy mit Lets Encrypt bei dem der „standalone“-Modus von certbot so genutzt wird, dass HAProxy im Betrieb die Anfragen an jenen weiterleitet. Das ist deshalb elegant, weil HAProxy kein Webserver ist und nicht zur Aufgabe hat, das ACME well-known Verzeichnis auszuliefern, welches normalerweise für den „webroot“-Modus von certbot nötig ist.

https://gridscale.io/en/community/tutorials/haproxy-ssl

Das Tutorial ist ansich also sehr gut, jedoch möchte ich eine Sache ergänzen, welches mir dort mangels Kommentarfunktion nicht möglich war:

Es wird empfohlen per Script die Dateien mit den Namen „fullchain.pem“ und „privkey.pem“ in ein einheitliches PEM-Bundle zusammenzufassen. Das ist aber bei HAProxy in neueren Versionen nicht mehr nötig. Vielmehr kann HAProxy mittlerweile direkt nach allen Zertifikaten in einem Verzeichnis suchen. Oder aber es kann unter Angabe eines PEM-Bundles ohne Keys automatisch nach dem Keyfile mit dem Suffix „.key“ schauen, welches es dem Namen des PEM-Bundles anfügt. „fullchain.pem“ wäre damit „fullchain.pem.key“. Da certbot diese Datei so nicht automatisch anlegt, kann man sich hier mit einem Symlink behelfen:

cd /etc/letsencrypt/live/domain.de/ && ln -s privkey.pem fullchain.key.pem

Mithilfe von entsprechenden certbot pre- und post-Scripten, kann man dies zusätzlich durchautomatisieren, inklusive reload für den HAProxy.

Alternativ empfiehlt sich je nach Anwendungsfall auch die Vollautomatisierung und der Umstieg auf Traefik.

Apple iPhone DFU-Restore mit Umwegen (Windows 10 LTSC 1809)

Vor einiger Zeit kam ich in die Situation, eine kleine Sammlung mittelalter Apple iPhones im Konvolut erwerben zu können. Eines dieser Geräte wollte ich einer Bekannten im Nicht-EU-Ausland schicken. Die entsprechende Zolldeklaration und das hoffen auf erfolgreiche Übersendung war schon spannend genug, jedoch stellte sich nach Ankunft heraus, dass dieses das einzige Gerät war, welches ich vergessen hatte per DFU-Reset vollständig zu updaten und zurückzusetzen.

Die Empfängerin ist auch technisch nicht sonderlich begabt, was nicht schlimm ist, aber einen DFU-Reset per Fernsteuerung nicht unbedingt erleichtert.

Runde 1: Runde 1 scheiterte leider, weil das „Notebook“, welches mir zur Fernsteuerung zur Verfügung gestellt wurde, ein ChromeBook mit ChromeOS war.

Runde 2: Runde 2 scheiterte leider, weil nicht nur die Internetverbindung zum jetzt fast vollwertigen Windows 10 sehr langsam war (500 KB/s machen es fast unmöglich effektiv die Dienstsoftware Apple-Geräte oder iTunes zu laden, geschweige denn ein 8,5 GB großes Image des aktuellen iOS 18.6).

Apple iPhone DFU-Restore mit Umwegen (Windows 10 LTSC 1809) weiterlesen

Emby Server neben anderen UPnP-Anwendungen auf gleichem Linux-System betreiben (Bind-to-all Problem)

Der Emby Medienserver hat ab Haus die ungünstige Eigenschaft unabhängig der konfigurierten IPs immer auf allen Netzwerkinterfaces ein Binding durchzuführen. Das ist besonders dann ungünstig, wenn man beabsichtigt unterschiedliche Medienserver mit SSDP+UPnP+DLNA zu betreiben oder wenn man vermeiden möchte, dass der Medienserver in ein öffentliches Netzwerk freigegeben wird, sollte es keine expliziten Firewallregeln geben.

Liest man ein wenig in der Emby Community findet man hin und wieder entsprechende Anfragen, die allesamt darauf abzielen, das Binding von Emby so anzupassen, dass dieses nur auf bestimmten Netzwerkinterfaces läuft. Technisch ist das auch absolut möglich, aber seitens der Entwicklung offenbar aus welchen Gründen auch immer, nicht gewünscht.

Emby Server neben anderen UPnP-Anwendungen auf gleichem Linux-System betreiben (Bind-to-all Problem) weiterlesen

Gerbera Media Server Webinterface-Login nicht möglich (404 Not Found, JS-Ressourcen nicht verfügbar) unter Ubuntu 24.04

Vor Jahren hatte ich zuletzt einen UPnP-Medienserver in meinem Heim, um Medien ohne Umweg auf Samsung-TVs zu streamen. Nun wollte ich das mal wieder machen, um zwei mögliche Wege (zusätzlich zur direkten Samba-Einbindung in KODI) zu haben. Gründe dafür gibt es unterschiedliche, unter anderen jedoch die Praktikabilität des abspielens aber auch die Kompatibilität unterschiedilcher Codecs mit dem jeweiligen Gerät (Samsung-TV vs. FireTV-Stick).

Als erstes wollte ich auf meinem Ubuntu 24.04-basierten Homeserver also Gerbera testen. Normal installiert, Webinterface geöffnet: Login-Button führt zu einem 404 und keine Loginfenster. Hervorragende User-Experience.

Gerbera Media Server Webinterface-Login nicht möglich (404 Not Found, JS-Ressourcen nicht verfügbar) unter Ubuntu 24.04 weiterlesen