Absurde Geschichte in eigener Sache: Gestern Mittag begrüßte mich auf meiner geschäftlichen Webpräsenz ein knallrotes Banner „Deceptive site ahead“. Ungewöhnlich, da ich auf meine Außenwirkung achte und nur sehr ausgewählte Software und deren Plugins auf dieser Präsenz nutze. Es sieht in der Tat schlecht aus, IT-Dienstleistungen anzubieten, dann jedoch seine eigene Webseite nicht im Griff zu haben. Googles rotes Banner und der zugehörige Text implizieren zudem immer gleich einen „Hack“ der Webseite, was für Klienten und potenzielle Klienten gleich doppelt schlecht aussieht.
Google markiert mailcow SoGo Webmailer als „irreführender Inhalt“ und zeigt rote Warnung in Chrome weiterlesenPacemaker 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 weiterlesenKurznotiz: FRITZ!Box – Telefonbuch exportieren & importieren auf Umwegen
Kürzlich war ich mit der Aufgabe betraut eine FRITZ!Box älteren Typs auf das neueste Modell 7690 zu migrieren. Nachdem der automatische Assistent dies nicht schaffte und das nicht reagierende neue Modell zurückgesetzt werden musste, begann ich mit der manuellen Einrichtung und Datenmigration. Dabei war auch das Telefonbuch unbedingt nötig da eine manuelle Übertragung viel zu Aufwändig gewesen wär.
Der Export klappte super, ein Knopf, ein Klick, Sicherungsdatei im JSON-Format heruntergeladen.
Den Knopf für den Import auf dem neuen Gerät suchte ich vergebens. Die Anleitung ist anwenderfreundlich und sehr eindeutig, was den Import angeht. Dennoch kein Import-Knopf.
Nach einigem Ausprobieren kam ich auf die Idee, es könne am Webbrowser liegen. Google Chrome. Firefox gestartet, Login: Import-Button vorhanden.
Verblüffend einfach. Wünsche beste Erfolge beim Import.
Kabeldiagnostik auf Ubiquity Switchen starten (neuere + ältere Modelle)
Neuere Modelle
Bei neueren Modellen, z. B. USW Pro Max 48 PoE, startet man den Kabeltest, welcher Aufschluss über die Kabellänge, offene Kreise und Kurzschlüsse gibt, so:
ssh root@<Name/IP vom Switch>
cli
show cable-diag interfaces GigabitEthernet 1
show cable-diag interfaces TwoGigabitEthernet 1
show cable-diag interfaces TenGigabitEthernet 1
Wobei zu prüfen ist, welche Portnummer nötig ist. Der USW Pro Max 48 PoE hat 48 Ethernet-Ports und 4 SPF+ Ports, welche sich wie folgt aufteilen:
1-32 1 Gigabit-Port
33-48 2.5 Gigabit-Port
49-52 10 Gigabit-Port
Für die Konsole ist jeder Interface-Typ separat und beginnt bei 1.
Damit sind also auszuwählen: Für die Ports 1-32 die Zahlen 1-32. Für die Ports 33-48 die Zahlen 1-16. Für die Ports 49-52 die Zahlen 1-4.
Ältere Modelle
Bei älteren Modellen, z. B. US 16 PoE, startet man den Kabeltest etwas anders:
ssh root@<Name/IP vom Switch>
cli
enable
cablestatus 0/1
Wobei auch hier wieder der Port angegeben werden kann, im Falle dieses Switches zwischen 1 und 16, jeweils als „0/<Portnummer>“.
Zugangsdaten finden
Ansich ist es recht simpel die nötigen root-Zugangsdaten zu finden. Im UniFi-Interface unter „UniFi-Devices“ und dann „Device Updates and Settings“. Der nötige Knopf ist allerdings so unscheinbar, dass ich es nochmal in zwei Screenshots zusammenfasse um möglichen Besuchern die Zeit zu sparen:
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.