Admintagebuch - Dokumentation der Admintätigkeiten

MPW · 16. März 2016 um 17:38

Das stimmt nicht:

root@Remue ~ # uptime
18:39:07 up 86 days, 10 min,  1 user,  load average: 2.71, 2.33, 2.41

descilla · 16. März 2016 um 17:46

Das war nur eine Annahme: Da durchweg auf allen remue-vms folgendes Bild zu sehen war: https://freifunk-muensterland.de/grafana/dashboard/db/domanen-ubersicht?panelId=7&fullscreen&from=1457908557654&to=1458035696357&var-domaene=domaene-01

FanLin · 16. März 2016 um 18:22

Dann ist da das Kernel-Sicherheitsupdate noch nicht drauf aktiv …
Was wohl niemand gelesen hat …

descilla · 16. März 2016 um 21:09

Firmware-Downloader aktualisiert:

Shapes:
- Steinfurt Ost bzgl. Teutoburger Wald angepasst
- WML angepasst
  - Raesfeld rausgeworfen
  - Bocholt ausgeschnitten
  - Stadtlohn ausgeschnitt
  - WML ist jetzt Multipolygon
- Stadtlohn Shape erstellt
- Bocholt Shape erstellt
Domänen hinzugefügt
- Stadtlohn
- Bocholt
- Verweist derzeit noch auf die Firmware von WML
Version auf 1.0.4 hochgesetzt (alle Domänen)
URL verweist nun nicht mehr auf [...]/stable/[...], sondern auf [...]/versions/{version}/[...]. Da das Umstellen auf Stable nicht direkt mit dem FW-Downloader-Assistenten zusammenhängt ist so sichergestellt, dass die Links weiterhin funktionieren.
Workaround für Firefox im Umgang mit Hover auf Multipolygone eingebaut
Code muss weiterhin noch mal in schön geschrieben werden (ich hoffe, dass ich bald dazu komme)

Parad0x · 16. März 2016 um 23:51

Unser Wiki kann jetzt Email.
Plugin “SMTP Plugin” installiert und mit Emailadresse ticket@freifunk-muensterland.de (Warpzone-Server) konfiguriert.

descilla · 17. März 2016 um 01:08

Für Domäne 08 auf desvm-01 vorkonfiguriert (noch nicht an andere Maschinen verdrahtet), falls die Performance-Probleme auf dray-01 bestehen bleiben kann dieser als Ersatz verwendet werden.

Domäne 11 auf den VMs desvm-02 und greyworm-07 konfiguriert und ans FFMS-Backbone angebunden. site-ffms für Domäne 11 konfiguriert. Die Firmware wird die Tage von @Alucardo gebaut.

descilla · 17. März 2016 um 03:18

(Teil-)Ursache für komische Last-Verteilung und komische Routen im Backbone / BB<->GW gefunden:

Die most specific routen, die über OSPF announced wurden passten nicht mit dem überein, was als DHCP Range auf den GWs eingestellt war. Daher gab es Überschneidungen, die dann quer geroutet wurden:

Es war jedoch kein Programmatischer Fehler oder Konfigurationsfehler. Es scheint, dass die Ranges angepasst wurden, anschließend jedoch lediglich die bird Rolle ausgeführt wurde, nicht jedoch die dhcp rolle.

Ich habe das nun nachgeholt:

TASK [dhcp : create dhcp config] ***********************************************
changed: [greyworm-01]
--- before: /etc/dhcp/dhcpd.conf
+++ after: dynamically generated
@@ -1,16 +1,16 @@
 # This file is managed by ansible, don't make changes here - they will be overwritten.
 default-lease-time 240;
 max-lease-time 1200;
 
 authoritative;
 
-log-facility local6;
+log-facility local7;
 
 subnet 10.43.8.0 netmask 255.255.248.0 {
-    range 10.43.13.67 10.43.15.254;
+    range 10.43.12.1 10.43.13.255;
 
     option routers 10.43.8.4;
     option domain-name-servers 10.43.8.4;
     option interface-mtu 1280;
 }
 

changed: [remue-01]
--- before: /etc/dhcp/dhcpd.conf
+++ after: dynamically generated
@@ -1,16 +1,16 @@
 # This file is managed by ansible, don't make changes here - they will be overwritten.
 default-lease-time 240;
 max-lease-time 1200;
 
 authoritative;
 
-log-facility local6;
+log-facility local7;
 
 subnet 10.43.8.0 netmask 255.255.248.0 {
-    range 10.43.8.26 10.43.10.160;
+    range 10.43.8.26 10.43.9.255;
 
     option routers 10.43.8.2;
     option domain-name-servers 10.43.8.2;
     option interface-mtu 1280;
 }
 

changed: [fanlin-03]
--- before: /etc/dhcp/dhcpd.conf
+++ after: dynamically generated
@@ -1,16 +1,16 @@
 # This file is managed by ansible, don't make changes here - they will be overwritten.
 default-lease-time 240;
 max-lease-time 1200;
 
 authoritative;
 
-log-facility local6;
+log-facility local7;
 
 subnet 10.43.8.0 netmask 255.255.248.0 {
-    range 10.43.10.161 10.43.13.66;
+    range 10.43.10.1 10.43.11.255;
 
     option routers 10.43.8.3;
     option domain-name-servers 10.43.8.3;
     option interface-mtu 1280;
 }

Dieses Problem war nur in Domäne 01 vorhanden.

descilla · 18. März 2016 um 00:33

Grund für bird logging spam im syslog auf des1 gefunden.

Mar 17 06:26:27 des1 bird: Netlink: File exists
Mar 17 06:27:27 des1 bird: Netlink: File exists
Mar 17 06:28:26 des1 bird: Netlink: File exists
Mar 17 06:29:27 des1 bird: Netlink: File exists
Mar 17 06:30:27 des1 bird: Netlink: File exists
Mar 17 06:31:27 des1 bird: Netlink: File exists
Mar 17 06:32:27 des1 bird: Netlink: File exists
Mar 17 06:33:26 des1 bird: Netlink: File exists
Mar 17 06:34:27 des1 bird: Netlink: File exists
Mar 17 06:35:27 des1 bird: Netlink: File exists
Mar 17 06:36:27 des1 bird: Netlink: File exists
Mar 17 06:37:27 des1 bird: Netlink: File exists
Mar 17 06:38:27 des1 bird: Netlink: File exists
Mar 17 06:39:27 des1 bird: Netlink: File exists
Mar 17 06:40:27 des1 bird: Netlink: File exists
Mar 17 06:41:27 des1 bird: Netlink: File exists
Mar 17 06:42:27 des1 bird: Netlink: File exists
Mar 17 06:43:27 des1 bird: Netlink: File exists
Mar 17 06:44:27 des1 bird: Netlink: File exists
Mar 17 06:45:27 des1 bird: Netlink: File exists
Mar 17 06:46:26 des1 bird: Netlink: File exists

Grund war eine Alien-Route auf einem nicht mehr genutzten Tunnel:
Mar 18 01:20:29 des1 bird: p-kernel-ff: 10.0.1.4/30: [alien] ignored

Ich habe daher das (auf der anderen Seite nicht mehr konfigurierte) Interface iface gre-ffwaf-srv2 abgerissen. Jetzt ist Ruhe.

PS: Auf die Schliche gekommen bin ich dem Ganzen, indem ich im kernel protokol in der bird config debug all eingetragen habe. Anschließend erhält man sehr hilfreiche Status-Meldungen im syslog.

descilla · 18. März 2016 um 01:24

Auch auf c1024 wurde einiges ins syslog “gespammt”:

Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)
Mär 18 02:18:05 c1024 snmpd[1876]: error on subcontainer 'ia_addr' insert (-1)

snmp wurde vom Server-Spender dort konfiguriert und läuft daher nicht auf allen Servern. Es scheint wohl einen Bug bzgl. mancher ipv6 Konfigurationen im snmp zu geben. Ich habe die defaults entsprechend diesem bugreport angepasst: https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1246347

paulinsche · 19. März 2016 um 18:38

Habe gerade festgestellt, dass es außerdem ziemlich wichtig ist, dass man bei gre-tunneln das „ttl 255“ nicht vergisst. Tut man das, dass vererbt sich das ttl des transportieren Pakets, und ein traceroute sieht dann nicht gut aus, oder ein mtr klappt gar nicht:

falsch:

pi@pi1:~ $ traceroute 10.43.120.33                                                                                                                                      
traceroute to 10.43.120.33 (10.43.120.33), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  10.43.120.33 (10.43.120.33)  40.686 ms  40.888 ms  41.009 ms

Richtig:

$ traceroute 10.43.120.33                                                                                                                                       
traceroute to 10.43.120.33 (10.43.120.33), 30 hops max, 60 byte packets
 1  10.43.120.33 (10.43.120.33)  39.905 ms  39.979 ms  39.969 ms

Die neun Hop ober kommen zustande, weil …

# traceroute 89.187.208.59
traceroute to 89.187.208.59 (89.187.208.59), 30 hops max, 60 byte packets
 1  ffhost01.yadn.de (144.76.30.226)  0.059 ms  0.046 ms  0.040 ms  
 2  static.113.186.243.136.clients.your-server.de (136.243.186.113)  0.906 ms  1.283 ms  1.372 ms
 3  hos-tr6-juniper2.rz19.hetzner.de (213.239.251.161)  0.350 ms hos-tr4.juniper2.rz19.hetzner.de (213.239.231.33)  0.336 ms hos-tr3.juniper2.rz19.hetzner.de (213.239.231.1)  0.330 ms
 4  core21.hetzner.de (213.239.245.97)  0.307 ms  0.311 ms core22.hetzner.de (213.239.245.137)  0.295 ms
 5  core4.hetzner.de (213.239.245.14)  4.834 ms core1.hetzner.de (213.239.245.218)  4.834 ms core4.hetzner.de (213.239.245.18)  4.839 ms
 6  juniper4.ffm.hetzner.de (213.239.245.1)  4.916 ms  5.015 ms  4.987 ms
 7  vitroconnect.fra.ecix.net (62.69.146.52)  6.403 ms  5.868 ms  5.947 ms
 8  dsdf1-cr1-tgige-0-0-0-0.net.vitroconnect.de (89.187.208.138)  8.581 ms  8.662 ms  8.553 ms
 9  ffwaf-srv4.freifunk-muensterland.net (89.187.208.59)  8.110 ms  7.980 ms  7.932 ms

Alter, war das eine schwere Geburt!

Fungur · 19. März 2016 um 22:21

Ich habe jetzt die Service-VM komplett an die neue domaenen-Variable in group_vars/all angepasst, nachdem ich dort die nötigen Einträge für alle Domänen erstellt habe. Teilweise werden aber auch noch die alten Variablen genutzt, so dass die Service-VM sowohl mit “alten” Domänen als auch mit den neuen Multidomänen arbeiten kann.

FanLin · 20. März 2016 um 09:54

Virthost FanLin hat sich heute um 04:00 wohl irgendwie verabschiedet. Pingtechnisch ist er irgendwie noch ansprechbar, mehr aber auch nicht. Über das Servermanagementinterface habe ich versucht ihn zu restarten; erfolglos. Der Support ist verständigt und weitere Infos folgen.

paulinsche · 20. März 2016 um 12:12

Habe ffwaf-srv4 den tunneldigger gestoppt. Jetzt hängt alles an remue-07/c1024.

Fungur · 20. März 2016 um 19:04

Die Ansible-Rollen für Multidomänen-Gateways (bis auf collectd) sind jetzt fertig und auf greyworm-06 ausgerollt. Firmware wird gerade erstellt.

MPW · 21. März 2016 um 02:17

Domäne-08 wird eingestampft. Domäne-09 ist der Nachfolger für Stadtlohn. Domäne-10 steht für L2TP-Tests zur Verfügung.

MPW · 21. März 2016 um 11:20

Auf Remü-08 den DNS-Eintrag für firmware.ffms manuell ins Bind gesetzt, da der Domänentransfair von der Service-VM nicht mehr funktioniert und nur so die Knoten per Autoupdater wegmigriert werden können.

void · 21. März 2016 um 22:45

@Fungur und ich haben heute die Graphite-Installation auf der neuen ServiceVM fortgesetzt.

Restart-Probleme des Services wurden behoben.
Der Branch ‘graphiteumzug’ wurde in ‘master’ gemerged.
Beim Rollout über Ansible gab es noch mal Probleme die wir beheben konnten.

Die Einbindung in Grafana und die Karten habe ich überprüft, beides Funktioniert mit der Url graphite.freifunk-muensterland.de … wir können das also so lassen.

Mittwoch können wir den Umzug der Graphite-Daten angehen.
Folgende Punkte müssen dabei relativ zeitnah bearbeitet werden:

Transfer der Graphite-Daten
Umschwenken der collectd-Installationen auf den Servern
Umschwenken der Scripte auf der ServiceVM
Einbindung im der Karte anpassen
Datenquelle in Grafana anpassen
Weitere Datenzugriffe anpassen oder Url “/render” vom Webserver passend umleiten

Fungur · 21. März 2016 um 23:12

Ich hab noch ein paar kleine Aufräumarbeiten durchgeführt:

Domänenliste https://karte.freifunk-muensterland.de/ überarbeitet (neue Namen und Links, Domäne 08 gelöscht)
Patch für l2tp_broker.py in Ansible eingebaut
2 Rollennamen der Service-VM angepasst

descilla · 22. März 2016 um 03:07

Mein Blech hatte heute gegen 01:01 Uhr schluckauf. Neu gestartet, war gegen 01:39 Uhr wieder im Dienst.

void · 22. März 2016 um 19:36

Das Zertifikat des Webservers ist jetzt erst mal verlängert.
Aktuell noch von StartSSL … müsste IrgendwannTM halt auch mal auf LetsEncrypt umgestellt werden.