Kernel auf Des1 wieder auf Version 4.9 aktualisiert. Wird aktiviert, wenn heute Nacht die Kiste automatisch neu startet.
Derzeit läuft dort noch der ISC, weil wir den KEA derzeit nicht kompiliert bekommen.
Kernel auf Des1 wieder auf Version 4.9 aktualisiert. Wird aktiviert, wenn heute Nacht die Kiste automatisch neu startet.
Derzeit läuft dort noch der ISC, weil wir den KEA derzeit nicht kompiliert bekommen.
Deshyper-01 neu durchgestartet und vorher natürlich upgrades durchgeführt.
service-vm mit updates versorgt und rebooted.
Nachdem ich bereits im November beantragt hatte, und am 24.11.16 die Bestätigung bekam, dass deshyper-02 nicht nach 20 TB gedrosselt wird, sondern zusätzlicher Traffic gesondert abgerechnet wird, hat sich Hetzner heute dazu entschieden davon nichts mehr zu wissen und die Anbindung trotzdem zu drosseln. Erneute Service-Anfrage hat das Problem immerhin relativ schnell gelöst.
Zweite graphite-instanz erstellt. Diese ist hier zu finden: http://148.251.101.196:8000 (guest/guest) hier werden die daten der knoten gespeichert, sodass die service-vm etwas entlastet wird (langfristig sollen die daten zu den Knoten in prometheus abgelegt werden, daher ist das nur eine temporäre Lösung).
Ein weiterer Grund der sehr hohen Last, und vermutlich auch der Grund für diverse andere Probleme, auf der Service-VM war/ist das Script zum Erzeugen der Kartendaten. Dieses hat eine Laufzeit von ~ 1.12 Minuten. Soweit so gut. Leider wird es einmal die Minute ausgeführt. Zwar verfügt die Service VM über mehrere Prozessorkerne, aber dennoch ist es sicherlich nicht sinnvoll, wenn das Script mehrfach konkurrierend läuft. Ich habe daher das Ausführungsintervall auf 2 Minuten gesetzt.
ffein-01 und einen weiteren Server, der unbekannterweise seine statistiken bei uns abgeworfen hat mittels iptables blockiert.
Wir müssen echt unsere neue Kartenlösung fertig bekommen…
isc-kea-dhcp auf des1 aktiviert, zuvor isc-dhcp-server deaktiviert.
Deshyper-01 war seit 17:49 Uhr nicht mehr erreichbar. Reset durchgeführt und l2tp Verbindungen zwischen parad0x und des1 ausgeglichen.
Ich werde heute, ca. 24:00 versuchen die Interrupt-Queues auf fanlin auf 2 zu setzen.
Letztes mal ist das fehlgeschlagen, da wohl der zweite CPU-Kern nicht aktiviert werden konnte.
Downtime wohl unter 5 Minuten.
Edith:
Das Erhöhen der Queues ist leider fehlgeschlagen.
Fehlermeldung:
Error starting domain: unsupported configuration: vhost-net was requested for an interface, but is unavailable
In der XML-Datei für fanlin wird der Parameter queues='2'
hinter driver name='vhost'
immer wieder automatisch entfernt also entsprechend auch nicht aktiviert.
Wieso, weshalb und warum überhaupt … kein Plan.
Kiste läuft jedenfalls wieder, leider mit alter Konfiguration.
Da die Node Stats jetzt auf der zweiten graphite-instanz liegen waren die Clientstatistiken in der Karte kaputt.
Im Ansible Template auf Grafana Statistik umgestellt und auf der Service VM ausgerollt.
Den PR müsste noch jemand der Commit-Rechte im Repo hat mergen.
forum aktualisiert
py-respondd auf die gateways ausgerollt
dist-upgrade auf des1 und deshyper-01 gemacht. Da des1 eh über nacht massig l2tp connections abgebaut hatte. linux-image von des1 wird nun über die dist-repos installiert. Ich starte gleich noch einen “langen” smart-test auf deshyper-01.
l2tp verbindungen zwischen parad0x und des1 ausgeglichen.
@descilla und ich haben heute das Umschaltskript für den Uplinkknoten der Warpzone perfektioniert.
#!/bin/sh
alt=$(uci show tunneldigger|grep broker|grep enabled)
alt=${alt:33:1}
echo $alt
change_if_necessary () {
if [ "$alt" != "$1" ]
then
echo "Umschalten"
uci set tunneldigger.@broker[0].enabled="$1"
/etc/init.d/tunneldigger restart
else
echo "Nichts zu tun"
fi
}
count=$(batctl o | grep ^$(batctl gwl | grep -oE "=> [^ ]+" | grep -oE "[a-f0-9\:]+" || echo offline) | grep -o "\].*" | grep -oE "\(2[0-9]{2}\)" | wc -l)
if [[ $count -lt 1 ]]
then
echo "VPN ein"
change_if_necessary 1
elif [[ $count -gt 1 ]]
then
echo "VPN aus"
change_if_necessary 0
else
echo "Tue nichts"
fi
Ich distanziere mich vom Programmierstil in Zeile 17 ;).
Gateway parad0x mit updates versorgt und rebootet
Mailserver aktualisiert und Spam-Einstellungen ein wenig angepasst.
Jetplow reset. Stand.
parad0x und des1 neu gestartet da in Dom13 wohl nichts mehr ging.
Ping zur Dom13 IPv4 der Service VM ging von Des1 auch nicht daher wohl batman…
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.