Blech Hypercorn hat auch Updates bekommen und startet grade neu.
Auf Voyager und Hypercorn haben sich bei einem Update wohl folgende iptables-Regeln eingeschlichen.
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o virbr2 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr2 -j REJECT --reject-with icmp-port-unreachable
Entfernen hilft NAT zu heilen.
Danke fürs rausfinden @MPW
Ebenso auf unimatrixzero
Auf stats.ffmsl.de grafana.freifunk-muensterland.de zu dem ACME-Cron hinzugefügt.
Datei /etc/nginx/sites-enabled/default_ssl Zeile 9-12 und 53-56 verändert. <- SSL-Zertifikate zu den Domains zugeordnet.
Rückgängig gemacht da beide Domains in einer Konfig liegen. Es fehlte nur der Reload des Nginx in der Konfiguration und deswegen wurde das neue Zertifikat nicht vom Webserver geladen/verwendet.
c1024 und des1 zusammen mit @stefan6 mit FFNW Tunneln bestückt.
rowe (neu) hat auch welche bekommen sind aber noch nicht ausgerollt weil rowe (neu) noch nicht im FFMS Netz eingebunden ist. Ich schlage vor das wir die Tage mal wieder ein Domänen Roulett machen und die Domänen von nightbounce einfach verteilen. Rowe hat seiner zeit nur die Domänen von handle geerbt und könnte noch den ein oder anderen Knoten mehr ab denke ich.
Im gleichen schritt würde ich dann die beiden neuen Domänen Gronau und Herne mit ausrollen.
Wenn das durch ist sind wer zum FFRL sowie zum FFNW Vollvermascht und ich mach mich mal an die Implementierung / Routung unseres PI Spaces…
rowe-Alt wird für Backup-Zwecke eine kurze Downtime haben.
Manuell per
birdc disable ffnw-[ber,fra][1,2]
Deaktiviert da er so versucht die FFRL Nat IP über die FFNW Tunnel zu Routen. Hatte noch keine Zeit das zu analysieren.
Das ist nicht rebootfest!!!
Habe mal das Ansible-Hypervisor-System etwas modernisiert:
Managed-VMs:
- disable netplan crap on Ubuntu-based systems.
- enable really predictable interface names
- reboot handler and wait for machine to reboot
Ich war gestern auch einwenig im ansible-hypervisor tätig…
- Einen Mirror auf firmware.ffmsl.de erstellt, um die Debian 8 Jessie VMs wieder fluffiger installieren zu können.
- Das Hyper-Netzwerk ein wenig eleganter und funktionabel gemacht.
- rowe und robweisor-01 hinzugefügt.
Discourse & Forum VM aktualisiert
Tunneländerung rowe beantragt und bekommen.
discourse aktualisiert und gebaut um eine outdated-Version für diesen Fehler (https://forum.freifunk.net/t/anmeldung-muensterland-forum-nicht-moeglich/20626/2) ausschließen zu können. Habe das Problem allerdings nicht gelöst.
Blech fanlin mußte u.a. mit dem Kernelupdate DSA-4465 versorgt werden; die VM habe ich auch gleich mit upgedatet.
Reboot erfolgt direkt.
Gateway Parad0x war kurz offline durch Updates des Hypervisors.
Karte für Domäne 75 und Domäne 76 finalisiert, indem ich die batman-Interfaces in /etc/hopglass-server/default/config.json eingetragen habe.
Oh ich glaube das hab ich dann vergessen auszurollen. Bin mit der Hopglass Server Rolle immer ein wenig Vorsichtig weil der git Checkout von hoppglas-server in der Vergangenheit schon des öfteren zum kapod geführt hat.
mapserver_nginx und py_respondd auf dem Mapserver ausgerollt.
Somit Tauchen dann die neuen Domänen auch im Index der Karte auf und der Mapserver sollte auf der der Karte richtig dargestellt werden.
Der Zertifikateimport des Unifi-Controllers läuft endlich wieder .
Man nehme acme.sh und lade dann mit folgendem Skript die Zertifikate in den Controller. Es ist mir völlig schleierhaft, wie das alte Skript jemals funktioniert haben kann, das war irgendwie totaler Müll.
#!/usr/bin/env bash
TEMPFILE=$(mktemp)
echo "Cert has changed, updating controller..."
openssl pkcs12 -export -passout pass:aircontrolenterprise \
-in /root/.acme.sh/unifi.freifunk-muenster.de/unifi.freifunk-muenster.de.cer \
-inkey /root/.acme.sh/unifi.freifunk-muenster.de/unifi.freifunk-muenster.de.key \
-out ${TEMPFILE} -name unifi \
-CAfile /root/.acme.sh/unifi.freifunk-muenster.de/unifi.freifunk-muenster.de/ca.cer -caname root
echo "Stopping Unifi controller..."
systemctl stop unifi.service
echo "Removing existing certificate from Unifi protected keystore..."
keytool -delete -alias unifi -keystore /usr/lib/unifi/data/keystore \
-deststorepass aircontrolenterprise
echo "Inserting certificate into Unifi keystore..."
keytool -trustcacerts -importkeystore \
-deststorepass aircontrolenterprise \
-destkeypass aircontrolenterprise \
-destkeystore /usr/lib/unifi/data/keystore \
-srckeystore ${TEMPFILE} -srcstoretype PKCS12 \
-srcstorepass aircontrolenterprise \
-deststoretype pkcs12 \
-alias unifi
rm -f ${TEMPFILE}
echo "Starting Unifi controller..."
systemctl start unifi.service
echo "Done!"
Ich versuche das jetzt mal als hook ins acme-Skript anzuhängen.
PS: Zwar 'ne Menge gelernt, aber völlig nutzlos, weil es im acme.sh ein unifi.sh Skript gibt.
@RobWei und ich haben das Wiki repariert. Die Integration von crowd wurde deaktiviert. Dadurch ist die Gruppenzuordnung verloren gegangen.
- Alle Benutzer müssen über die „Passwort vergessen“-Funktion ihr Passwort zurücksetzen.
- Wer dann angezeigt bekommt, dass er keine Berechtigung habe, muss noch der „confluence user“-Gruppe hinzugefügt werden. Dazu bitte eine Nachricht an @RobWei, @Parad0x, @corny456, @kgbvax oder mich. Wird sind die Admins des Wikis.
- Gleiches gilt, falls jemand nicht mehr auf den internen Bereich zugreifen kann. Das wird ebenfalls über eine Gruppe gesteuert, die wir neu befüllen mussten und ggfs. Accounts vergessen haben könnten.
Das acme.sh-Skript funktioniert irgendwie nicht mit der Zwangsumleitung auf https. Daher ist die automatische Aktualisierung des Zertifikats höchst wahrscheinlich defekt. Ggfs. die fünfte Zeile in der nginx auskommentieren. Falls jemand versteht, wie man das automatisiert, bitte melden.
Viele Grüße
Matthias