Auf Des1 einen Account für den reverse-SSH-Tunnel des Pis angelegt. Die Shell ist auf /dev/null gesetzt und der Account hat kein Passwort.
git pull im services-ffms repo auf der Service-VM gemacht damit die Änderung von @Alucardo auch im „Live“ API File ankommt 
Habe soeben u.a. das Kernel-Sicherheitspatch DSA-3791 auf dem fanlin-Blech und der VM installiert.
Der erforderliche Neustart erfolgt heute gegen 24:00.
EDITH: System verspätet restartet. Nu is alles schön.
2 „Gefällt mir“
apt dist-upgrade mit anschließendem reboot auf der Firmware-VM gemacht…
mailvax OSaktualisiert
Discourse aktualisiert
Backup OS aktualisiert
Wiki OS aktualisiert
5 „Gefällt mir“
- Auf der Ansible-VM per manuellem Download aus den Backports eine aktuellere Version von python-pkg-resources und python-setuptools eingespielt.
- Ansible auf selbiger VM auf 2.1.2.0 aktualisiert.
- Auf Wunsch von @Parad0x die statischen DNS-Einträge parametrisiert: In den Rollen und dann unifi und firmware eingetragen.
- Letzteres auf Des1 und Parad0x ausgerollt. Sollte also auf allen Domänen, die dort liegen, schon aktiv sein.
1 „Gefällt mir“
Mac der Brücke auf den Gateways fest gesetzt und auf alle bis auf Parad0x, C1024 und Remü-08, die sich irgendwie weigern, ausgerollt.
Die Mac des Gateways ist jetzt immer
02:ca:ff:fe:<domaene>:<gateway-id>.
Grüße
Matthias
PS: Die drei Verweigerer haben es jetzt auch drauf.
4 „Gefällt mir“
In der bird6.conf von Des2 standen einige dieser Blöcke
protocol static static_domaene01 {
table ffnet;
route 2a03:2260:115:100::/56 reject;
}
Doppelt drin. Ursache unbekannt… Dadurch wollte Bird6 nicht…
Manuell die Duplikate entfernt und Bird6 neu gestartet.
Außerdem hatte sich auf Des2 und remue-08 KEA verabschiedet, scheinbar ist da irgendwie das Lease File kaputt gegangen…
Mar 1 14:08:09 des2 kea-dhcp4[937]: 2017-03-01 14:08:09.848 ERROR [kea-dhcp4.dhcp4/937] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /etc/kea/kea.conf, reason: Unable to open database: exceeded maximum number of failures 100 to read a lease from the lease file /var/kea/dhcp4.leases
Mar 1 14:08:09 des2 kea-dhcp4[937]: 2017-03-01 14:08:09.849 ERROR [kea-dhcp4.dhcp4/937] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/etc/kea/kea.conf': Unable to open database: exceeded maximum number of failures 100 to read a lease from the lease file /var/kea/dhcp4.leases
Mar 1 14:08:09 des2 kea-dhcp4[937]: 2017-03-01 14:08:09.849 INFO [kea-dhcp4.commands/937] COMMAND_SOCKET_UNIX_CLOSE Command socket closed: UNIX, fd=6, path=/var/kea/control.sock
Mar 1 14:08:09 des2 systemd[1]: kea-dhcp4.service: main process exited, code=exited, status=1/FAILURE
Mar 1 14:08:09 des2 systemd[1]: Unit kea-dhcp4.service entered failed state.
/var/kea/dhcp4.leases und /var/kea/dhcp4.leases.2 nach /root/ verschoben und KEA neu gestartet.
edith:
Auf c1024 gleiches Spiel mit KEA…
1 „Gefällt mir“
Danke für’s Reparieren!
Tunneldigger auf allen Gateways aktualisiert.
2 „Gefällt mir“
Auf karteneu folgende Einstellungen gesetzt:
sysctl -w net.core.netdev_max_backlog=5000 # queue len of unhandled packets in kernel
sysctl -w net.core.rmem_max=12582912 # kernel rx buffer size
Jetzt scheinen alle Knoten wieder online zu sein. Möglicherweise liegt das aber auch daran, dass ich den Hopglass Server noch mal neu gestartet habe. Aber zumindest sagt mir cat /proc/net/udp6, dass keine Pakete mehr gedroppt werden (was dort vorher der Fall war).
Inspiriert hat mich dieses Issue im Hopglass Server Git Repo.
Mittelfristig sollte man mal schauen, dass man den Server so konfigurieren kann, dass er nicht auf allen (konfigurierten) Interfaces das mcast Paket gleichzeitig raus haut, sondern um anzahl interfaces / konfiguriertes intervall versetzt…
3 „Gefällt mir“
Des1 zurückgesetzt, weil IPV6 nicht mehr durchging. Die IPV6 von Des1 im Freifunk hat funktioniert, aber die Knoten dahinter irgendwie nicht. Geht wieder.
2 „Gefällt mir“
Ankündigung Wartungsarbeiten Servdiscount RZ DUS2 vom 06.03.2017 08:00 - 07.04.2017 20:00.
Detailierte Informationen werde ich zeitnah hier bekanntgeben.
@MPW und ich haben heute in der Bezirksregierung den Server neu installiert. Es läuft jetzt Ubuntu 16.04. Die beiden virtuellen Gluons wurden neue erstellt. Die VM für AirControl2 wird in Kürze neu installiert und ein Backup eingespielt.
Wir hatten gehofft durch eine neue Virtualisierung das Problem mit der Geschwindigkeit in den Griff zu bekommen. Hat leider noch nicht geklappt. Das Problem besteht weiterhin.
Die bisherige Diskussion dazu wurde im internen Forum geführt. Wenn jemand Zeit hat könnte er prüfen ob vertrauliche Informationen vom Standort vorhanden sind oder das ganze in den öffentlichen Bereich rüber geschoben werden darf/kann.
Ich habe mal ein wenig an den Hoppglass Rollen gewerkelt:
und
- Ich habe die kernel buffer und queue Einstellungen von gestern mal ins ansible gegossen.
- Außerdem habe ich die Rollen (und Verzeichnisse auf dem Server) mal ein wenig aufgeräumt.
- Anstatt der Symlinks greifen wir nun auf die nginx rewrite engine für die einzelnen Domänen-Karten zurück. Das ist ein wenig flexibler, weil es regexp kann und wir müssen nicht diverse symlinks im FS anlegen (die dann ggf. mal verwaisen oder sonst was).
- Ich habe mal einen cache für alles Unterhalb von /data/ konfiguriert. Der hat zwar nur 2 Minuten gültigkeit (ggf. auf 1 Minute runter stellen) und löst nicht das prinzipielle Problem, dass das laden der json files lange dauert (mit unter beginnt der file-transfer erst nach 3-5 Sekunden, nagut, wenn gerade jemand anders geklickt hat, dann geht es bei einem selbst natürlich schneller), aber schützt den Hopglass Server vor Überlastung, wenn mal sehr viele darauf zugreifen wollen.
- Und noch einige andere Dinge, die ich jetzt bestimmt schon wieder vergessen habe.
PS: Ich habe noch eine kleine Änderung am Hopglass durchgeführt, sodass die roten bling-bling Knoten jetzt nicht mehr ganz oben auf der Karte liegen (das sah in der weit herausgezoomten Ansicht sehr gruselig aus):
https://git.simon-wuellhorst.de/descilla/hopglass/commit/d0c75d570689e8cddf011f9483d34883e39c0deb
PPS: Vielleicht mag jemand ja mal das hopglass repo für ffms forken (oder mir die Rechte dazu geben), dann kann ich das dort abladen.
3 „Gefällt mir“
Herzlichen Glückwunsch zur Beförderung, Herr Wüllhorst ;).
2 „Gefällt mir“
Graphite/carboncache spinnt seit heute auf der servicevm rum. Daher habe ich gerade einen Neustart veranlasst. Leider kommt die VM seit dem nicht mehr hoch. Hat jemand aus dem @Adminteam Zugriff auf das Blech?
Problem im Hopglass-Server, dass die „filtered views“ aka Domänenkarten nicht richtig funktionieren (der Graph-View war kaputt) gefixt und pull request erstellt:
2 „Gefällt mir“
Hoppglass Map Config ein wenig dynamisiert.
2 „Gefällt mir“
- DKIM Einstellungen für freifunk-muenster.de und freifunk-muensterland.de angepasst
- Grafana von 4.1.1 auf 4.1.2 geupdated
- Alle VMs und Hypervisor auf deshyper-02 geupgraded und kernel 4.10.1 installiert
- Updates auf mail.freifunk-muensterland.de installiert
- respondd variante variante von node-stats erstellt
- node-stats auf der service-vm deaktiviert und die respondd variante auf mapserverneu aktiviert (per ansible ausgerollt)
- bestimmt noch andere Sachen…
2 „Gefällt mir“