Da haben wir uns missverstanden ich meinte Remue Domäne9 also Remue8 , mittlerweile scheint es aber wahrscheinlicher dass die Aussetzer und hohen Laufzeiten an Frankfurt liegt.
@Handle hat uns zum Performance Test seine online.net dedibox zur verfügung gestellt.
- Dedibox als Gateway handle in ansible angelegt.
- Anbindung über nightbounce
- Domäne 66 als Testdomäne auf handle angelegt.
- Da auf handle ein Ubuntu 16.04 läuft die Gelegenheit genutzt und die Gateway Rollen Ubuntu-Tauglich gemacht.
nightbounce hat dafür vorhin einen Neustartsalto gemacht…
Firmware-Update der Ubiquiti-Geräte am Domplatz und der Richtfunkstrecke BEZ<->HAW durchgeführt.(Hauptsächlich Security-Fixes)
Ich hab mal auf Nightbounce eine neue experiementelle DNS-iptables-Regel aufgesetzt:
-N dns
-A INPUT -p udp -m udp --dport 53 -j dns
-A INPUT -p tcp -m tcp --dport 53 -j dns
-A dns -d 89.163.231.228/32 -j RETURN
-A dns -d 213.133.98.98/32 -j RETURN
-A dns -d 213.133.99.99/32 -j RETURN
-A dns -d 213.133.100.100/32 -j RETURN
-A dns -j MARK --set-xmark 0x1/0xffffffff
Die Idee ist, dass man erstmal alle DNS-Pakete in eine Tabelle namens DNS schiebt. Dort werden dann die Pakete, die wir ignorieren wollen (Service-VM und Hetzner-Server) wieder rausgeschmissen (RETURN) und alles was übrig bleibt, kriegt 'nen Stempel verpasst und wird durch’s Rheinland geschickt.
Ich überlege gerade, wie man das testet. Analog müsste man es dann noch für IPV6 bauen, das wäre aber dasselbe in grün.
Hab die Subdomain karte.freifunk-muensterland.de auf der Service VM mal aus dem Lets Encrypt Script entfernt damit der Renew nicht failt.
Ausserdem noch ein bisschen an den Mapserver Rollen geschraubt um es anderen Communitys die unsere Rollen nutzen möchten leichter zu machen.
- Die Subdomain entspricht jetzt dem Hostname aus Ansible.
- Caption Variable an den Node und Traffic Stats sind jetzt optional.
- Konfiguration der Maps in Variablen verpackt.
Ich habe mal ein wenig an am hopglass gewerkelt. Ich habe zu jeder Änderung einen eigenen branch erstellt, damit wir leichter pull requests stellen können:
- Unterstützung von WMS Baselayern
- Konfigurierbarer maximaler Zoom bei Klick auf Node oder Meshlink.
- Reihenfolge der Nodes-Layer anpassen (derzeit quick&dirty).
Außerdem habe ich den Branch ffms erstellt, von dem aus ich die Änderungen aus den anderen Branches cherrypicked habe. Diesen habe ich auch schon ins Ansible geklebt. Falls ihr selber spielen wollt, macht einfach einen weiteren Branch und achtet bitte darauf vorher den aktuellen Stand von upstream zu holen.
Zwei PullRequests habe ich auch schon gestellt:
Und das ganze in unser Ansible eingepflegt und ausgerollt:
PS: Schaut mal auf die Karte der Domäne 16, dort habe ich ein paar weitere Layer eingefügt (der DOP20 ist vermutlich am interessantesten). Die Karten kommen vom Land NRW / BezReg Köln, die dankenswerterweise seit Anfang des Jahres als Datenlizenz Deutschland - Namensnennung - Version 2.0 (www.govdata.de/dl-de/by-2-0) lizenziert sind: http://www.bezreg-koeln.nrw.de/brk_internet/geobasis/opendata/index.html
Sauberer wäre es mit einem Merge gegangen :).
Heute Nacht um ca. 3:40 Uhr hat sich auf Des1 der Tunneldigger Zerledert.
Mar 21 03:38:55 des1 python[13358]: Traceback (most recent call last):
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/local/lib/python2.7/site-packages/gevent/greenlet.py", line 327, in run
Mar 21 03:38:55 des1 python[13358]: result = self._run(*self.args, **self.kwargs)
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/broker/l2tp_broker.py", line 1245, in _run
Mar 21 03:38:55 des1 python[13358]: self.handler.handle(socket, data, address)
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/broker/l2tp_broker.py", line 1190, in handle
Mar 21 03:38:55 des1 python[13358]: prepare.cookie, prepare.tunnel_id or 1)
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/broker/l2tp_broker.py", line 1080, in setup_tunnel
Mar 21 03:38:55 des1 python[13358]: tunnel.setup()
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/broker/l2tp_broker.py", line 430, in setup
Mar 21 03:38:55 des1 python[13358]: self.setup_netfilter()
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/broker/l2tp_broker.py", line 738, in setup_netfilter
Mar 21 03:38:55 des1 python[13358]: nat.append_rule('L2TP_PREROUTING_%s' % self.manager.namespace, self.prerouting_rule)
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/local/lib/python2.7/site-packages/netfilter/table.py", line 105, in append_rule
Mar 21 03:38:55 des1 python[13358]: self.__run_iptables(['-A', chainname] + rule.specbits())
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/local/lib/python2.7/site-packages/netfilter/table.py", line 143, in __run_iptables
Mar 21 03:38:55 des1 python[13358]: self.__run(cmd)
Mar 21 03:38:55 des1 python[13358]: File "/srv/tunneldigger/local/lib/python2.7/site-packages/netfilter/table.py", line 151, in __run
Mar 21 03:38:55 des1 python[13358]: close_fds=True)
Mar 21 03:38:55 des1 python[13358]: File "/usr/lib/python2.7/subprocess.py", line 702, in __init__
Mar 21 03:38:55 des1 python[13358]: errread, errwrite), to_close = self._get_handles(stdin, stdout, stderr)
Mar 21 03:38:55 des1 python[13358]: File "/usr/lib/python2.7/subprocess.py", line 1130, in _get_handles
Mar 21 03:38:55 des1 python[13358]: c2pread, c2pwrite = self.pipe_cloexec()
Mar 21 03:38:55 des1 python[13358]: File "/usr/lib/python2.7/subprocess.py", line 1175, in pipe_cloexec
Mar 21 03:38:55 des1 python[13358]: r, w = os.pipe()
Mar 21 03:38:55 des1 python[13358]: OSError: [Errno 24] Too many open files
Mar 21 03:38:55 des1 python[13358]: <BaseControl at 0x7fec9139d0f0> failed with OSError
Gestern Abend irgendwann hatte sich py-respondd auch schon verabschiedet. Beide heute morgen um kurz vor 6 wieder gestartet.
Edit: Grad noch den Tunneldigger auf Parad0x zur Verteilung neu gestartet…
Auf Des1 Häufen sich segfaults… Diesmal hat es Bind erwischt…
● bind9.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
Drop-In: /run/systemd/generator/bind9.service.d
└─50-insserv.conf-$named.conf
Active: failed (Result: exit-code) since Tue 2017-03-21 11:07:28 CET; 5min ago
Docs: man:named(8)
Process: 7423 ExecStop=/usr/sbin/rndc stop (code=exited, status=1/FAILURE)
Process: 8563 ExecStart=/usr/sbin/named -f -u bind (code=killed, signal=SEGV)
Main PID: 8563 (code=killed, signal=SEGV)
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 98.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 99.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 100.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 101.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 102.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 103.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 104.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 105.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 106.100.IN-ADDR.ARPA
Mar 20 03:42:21 des1 named[8563]: automatic empty zone: view external: 107.100.IN-ADDR.ARPA
Mar 21 11:07:28 des1 systemd[1]: bind9.service: main process exited, code=killed, status=11/SEGV
Mar 21 11:07:28 des1 rndc[7423]: rndc: connect failed: 127.0.0.1#953: connection refused
Mar 21 11:07:28 des1 systemd[1]: bind9.service: control process exited, code=exited status=1
Mar 21 11:07:28 des1 systemd[1]: Unit bind9.service entered failed state.
Außerdem läuft auf nightbounce irgendwas nicht rund. Reboot hat nichts gebracht.
root@nightbounce ~ # batctl -m bat45 dc
Error - mesh has not been enabled yet
Activate your mesh by adding interfaces to batman-adv
Hab grade nicht viel Zeit zu suchen, @MPW kann das mit dem Test der iptable rules zu tun haben?
Eigentlich nicht, weil ich das bisher nur auf Nightbounce ausgerollt hatte. Es sei denn, du hast es auf Des1 ausgerollt.
Wir sollten mal diesen blöden Tunneldigger etwas debuggen. Python ist nicht so schwer und der Code ist nicht so lang. Kann eigentlich nicht so schwer sein, diese Abstürze zu finden.
Man müsste mal verstehen, woran und in welcher Situation er überhaupt hängt. Eventuell mal Debugausgaben einbauen?
es ging im unteren Teil um Nightbounce
Das komplette Ansible gateways playbook auf remue-09 ausgerollt. Damit rennt dort nun auch endlich der 4.9er Kernel.
Unsere mapserver_nginx
Rolle „unterstützt“ jetzt das Caching von Tiles:
Ich habe dann direkt mal die caches für unsere Map-Layer konfiguriert:
Außerdem habe ich einen neuen Layer hinzugefügt: Luftbilder (DOP20 des Landes NRW). Die haben nämlich zum 01.01.2017 ihre Kartendaten unter die Datenlizenz Deutschland - Namensnennung - Version 2.0 (www.govdata.de/dl-de/by-2-0) gestellt: http://www.bezreg-koeln.nrw.de/brk_internet/geobasis/opendata/index.html
Sieht recht hübsch aus, wie ich finde:
Kernelupgrade auf fanlin,c1024,parad0x,remue-08 und nightbounce durchgeführt. Nun laufen alle Gateways auf 4.9(.13) (ja ich weiß, 4.9.15 ist die neueste Version aber die gibts im debian repo noch nicht).
Das Problem habe ich in den letzten Tagen vermehrt gesichtet. Aktuell ist das log von parad0x voll damit. Könnte ggf. mit dieser Fehlermeldung zusammenhängen. Haben wir in der Zwischenzeit herausgefunden gehabt, was das Problem war?
Forum VM Neugestartet da Sidekiq kein lust mehr hatte Mails zu versenden…
1953 Nodes aus unserem Graphite gelöscht, die in den letzten Tagen dort gelandet sind und nicht zu uns gehören (Speicher wurde langsam knapp).
Weiss nicht ob das zählt aber: Habe die Wordpress Menüs mal entmüllt.
Ach so und Wordpress bei der Gelegenheit aktualisiert.
Forum aktualisiert.
Der Hypervisor von Parad0x wurde mit Updates versorgt und neu gestartet. Downtime ~ 12:01 bis ~ 12:08 Uhr.
Anschließend manuell (nicht Sekundengenau) die Zeit korrigiert. @descilla hier sollten wir uns nochmal über NTP gedanken machen.