Admintagebuch - Dokumentation der Admintätigkeiten

corny456 · 30. April 2019 um 07:36

Hulk neu gestartet da der Tunneldigger völlig am Kabel drehte.
Hat sich beruhigt schmeißt aber immernoch exceptions.

und das so lange bis er eine freie ID gefunden hat die er nehmen kann.
hier mal ein ausschnitt.

[...]
Apr 30 09:26:40 hulk python[10924]: [INFO/tunneldigger.broker] Creating tunnel (14cc20e139f0) with id 261.
Apr 30 09:26:40 hulk python[10924]: [ERROR/tunneldigger.broker] Unhandled exception while creating tunnel 261:
Apr 30 09:26:40 hulk python[10924]: [ERROR/tunneldigger.broker] Traceback (most recent call last):
Apr 30 09:26:40 hulk python[10924]: File "/srv/tunneldigger/env_tunneldigger/local/lib/python2.7/site-packages/tunneldigger_broker-0.3.0-py2.7-linux-x86_64.egg/tunneldigger_broker/broker.py", line 112, in create_tunnel
Apr 30 09:26:40 hulk python[10924]: client_features=client_features,
Apr 30 09:26:40 hulk python[10924]: File "/srv/tunneldigger/env_tunneldigger/local/lib/python2.7/site-packages/tunneldigger_broker-0.3.0-py2.7-linux-x86_64.egg/tunneldigger_broker/tunnel.py", line 67, in __init__
Apr 30 09:26:40 hulk python[10924]: super(Tunnel, self).__init__(address, broker.interface)
Apr 30 09:26:40 hulk python[10924]: File "/srv/tunneldigger/env_tunneldigger/local/lib/python2.7/site-packages/tunneldigger_broker-0.3.0-py2.7-linux-x86_64.egg/tunneldigger_broker/network.py", line 38, in __init__
Apr 30 09:26:40 hulk python[10924]: self.socket.bind(address)
Apr 30 09:26:40 hulk python[10924]: File "/usr/lib/python2.7/socket.py", line 224, in meth
Apr 30 09:26:40 hulk python[10924]: return getattr(self._sock,name)(*args)
Apr 30 09:26:40 hulk python[10924]: error: [Errno 98] Address already in use
Apr 30 09:26:40 hulk python[10924]: [WARNING/tunneldigger.protocol] Failed to create tunnel (14cc20e139f0) while processing prepare request.
Apr 30 09:26:42 hulk python[10924]: [INFO/tunneldigger.broker] Creating tunnel (14cc20e139f0) with id 262.
Apr 30 09:26:42 hulk python[10924]: [ERROR/tunneldigger.broker] Unhandled exception while creating tunnel 262:
Apr 30 09:26:42 hulk python[10924]: [ERROR/tunneldigger.broker] Traceback (most recent call last):
Apr 30 09:26:42 hulk python[10924]: File "/srv/tunneldigger/env_tunneldigger/local/lib/python2.7/site-packages/tunneldigger_broker-0.3.0-py2.7-linux-x86_64.egg/tunneldigger_broker/broker.py", line 112, in create_tunnel
Apr 30 09:26:42 hulk python[10924]: client_features=client_features,
Apr 30 09:26:42 hulk python[10924]: File "/srv/tunneldigger/env_tunneldigger/local/lib/python2.7/site-packages/tunneldigger_broker-0.3.0-py2.7-linux-x86_64.egg/tunneldigger_broker/tunnel.py", line 67, in __init__
Apr 30 09:26:42 hulk python[10924]: super(Tunnel, self).__init__(address, broker.interface)
Apr 30 09:26:42 hulk python[10924]: File "/srv/tunneldigger/env_tunneldigger/local/lib/python2.7/site-packages/tunneldigger_broker-0.3.0-py2.7-linux-x86_64.egg/tunneldigger_broker/network.py", line 38, in __init__
Apr 30 09:26:42 hulk python[10924]: self.socket.bind(address)
Apr 30 09:26:42 hulk python[10924]: File "/usr/lib/python2.7/socket.py", line 224, in meth
Apr 30 09:26:42 hulk python[10924]: return getattr(self._sock,name)(*args)
Apr 30 09:26:42 hulk python[10924]: error: [Errno 98] Address already in use
Apr 30 09:26:42 hulk python[10924]: [WARNING/tunneldigger.protocol] Failed to create tunnel (14cc20e139f0) while processing prepare request.
Apr 30 09:26:44 hulk python[10924]: [INFO/tunneldigger.broker] Creating tunnel (14cc20e139f0) with id 263.
Apr 30 09:26:44 hulk python[10924]: [INFO/tunneldigger.tunnel] Set tunnel 263 MTU to 1364.
Apr 30 09:26:44 hulk python[10924]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain41.sh'.
Apr 30 09:26:44 hulk kernel: [ 1871.049070] br41: port 1(l2tp263-263) entered blocking state
Apr 30 09:26:44 hulk kernel: [ 1871.049071] br41: port 1(l2tp263-263) entered disabled state
Apr 30 09:26:44 hulk kernel: [ 1871.049183] device l2tp263-263 entered promiscuous mode
Apr 30 09:26:44 hulk kernel: [ 1871.049202] br41: port 1(l2tp263-263) entered blocking state
Apr 30 09:26:44 hulk kernel: [ 1871.049202] br41: port 1(l2tp263-263) entered forwarding state

Da es einige Domänen gibt die seit Tagen ohne 2. Gateway sind wäre es cool wenn sich @kgbvax mal klar zum Thema Nightbounce äußert. Ansonsten setz ich einfach ein neues Gateway auf und wir schmeißen Nightbounce über Board.

kgbvax · 30. April 2019 um 20:28

Nightbounce ist kaputt. FS corrupted. Könnte man mounten wenn man das Journal wegschmeisst, dann sind aber Daten weg und komisch.
Wie gesagt halte ich die Hardware (jetplow) für “gar” und würde die Kiste gerne komplett abwickeln. Von daher: Feuer frei , @corny456

Parad0x · 1. Mai 2019 um 19:34

Laut Vor-Ort-Test von @Dezi wurde am Domplatz keine SSID Freifunk mehr gesendet.

BEZ-AP-Domplatz1 und BEZ-AP-Domplatz2 wurden im Controller als offline angezeigt und haben laut Switch aber noch RX und TX Daten gesendet. Beide per Power-Cycle neu gestartet. Sind wieder erreichbar.

BEZ-Gluon-Domplatz hatte 0 Clients. Die Status-Seite war noch erreichbar. Ebenfalls per Power-Cycle neu gestartet.

Läuft wieder. Ursache unbekannt.

MPW · 2. Mai 2019 um 12:39

FRED-Entwickler via Ansible für die FRED-Backend-VM freigeschaltet.

fll · 3. Mai 2019 um 17:41

LE-Cert für “freifunk-münsterland.de” erneuert.

Dabei leider certbot installiert (wollte eigentlich nur das schon installierte Paket “letsencrypt” updaten), welcher jetzt mit “/usr/bin/letsencrypt renew” (cronjob) ausgeführt wird und leider auch die alte “/etc/letsencrypt/renewal/freifunk-muensterland.de.conf” überschrieben hat.
Die neue sieht ganz anders aus.

Es scheint aber zu laufen.

MPW · 4. Mai 2019 um 07:53

Danke dir. War auf dem Server nicht das Problem mit dem Nat? Hatte @wurmi da nicht was gebaut, oder verwechsle ich das mit einem anderen Dienst?

fll · 4. Mai 2019 um 12:27

Keine Ahnung, aber falls ich die Logeinträge richtig verstanden habe, dann war das Problem die veraltete, nicht weiter unterstützte Erneuerungsmethode für Zertifikate (letsencrypt haben da auch Mails zu verschickt). NAT schien die Zertifikaterneuerung nicht zu behindern.

corny456 · 4. Mai 2019 um 12:57

Fast richtig. Auf dem Blech wird das Nat kurz umgebogen um das Cert vom Mumble Server aktualisieren zu können.

fll · 6. Mai 2019 um 18:22

Updates auf Icinga VM gemacht, weil auch dort Letsencrypt zu alt war um ein neues Zertifikat zu bekommen.

FanLin · 16. Mai 2019 um 07:03

Blech fanlin und VMs upgedatet und rebootet.

u.a.
DSA-4447 intel-microcode
DSA-4444
DSA-4440

corny456 · 16. Mai 2019 um 07:59

Blech Hypercorn hat auch Updates bekommen und startet grade neu.

corny456 · 16. Mai 2019 um 11:22

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

corny456 · 20. Mai 2019 um 12:19

corny456:

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

RobWei · 24. Mai 2019 um 20:05

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.

corny456 · 27. Mai 2019 um 10:56

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.

corny456 · 29. Mai 2019 um 11:33

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…

RobWei · 1. Juni 2019 um 19:49

rowe-Alt wird für Backup-Zwecke eine kurze Downtime haben.

corny456 · 2. Juni 2019 um 11:01

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!!!

MPW · 2. Juni 2019 um 20:48

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

RobWei · 3. Juni 2019 um 09:35

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.