Admintagebuch - Dokumentation der Admintätigkeiten

Tunneldigger 15 47 55 auf Parad0x gestartet. Sind nach dem Reboot nicht hochgekommen.

1 „Gefällt mir“

Updates auf:

  • Hypercorn
    • Corny
    • Corny2
    • Backup-VM

und alles gebootet.

1 „Gefällt mir“

Nächste rutsche Updates…

  • atom8
    • handle
  • voyager
    • automatix

und auch gebootet.


  • deshyper-01
    • Ticketsystem
    • des1
    • unifi

Updates gemacht aber reboot heute abend.

2 „Gefällt mir“

Auf Unimatrixzero die 4.10er Kernel entfernt und update-grub ausgeführt.

Ticket bei Hetzner bezüglich der defekten Festplatte von Unimatrixzero aufgemacht.

1 „Gefällt mir“

Unimatrixzero und alle VM’s sind neu installiert und laufen wieder nach dem Festplattenausfall.

3 „Gefällt mir“

Sehr geil, danke dir!

Py-respondd auf Des1 und Tunneldigger Dom48 auf Des2 gestartet.

1 „Gefällt mir“

Vorhin Webserver neu gestartet.

1 „Gefällt mir“

Das Blech atom8 auf dem die VM handle lief wurde selbst zu handle um die IP und die Virtualisierung zu sparen. Da sich die IP somit geändert hat mussten alle Gateways sowie Karte und Service VM ausgerollt werden. Handle und tj01 sind zwischenzeitlich verloren gegangen, wurden jedoch erfolgreich wiederbelebt.

Laut icinga ist alles wieder im Grünen bereich --> ich geh schlafen… :slight_smile:

5 „Gefällt mir“

FFNW-Tunnel-IPs für Automatix korrigiert, FFNW-Tunnel gehen damit.

  • BER Tunnel für alle Gateways mit FFNW Anbindung aktiviert.
  • Routing zwischen Corny und Corny2 optimiert damit diese sich gegenseitig beim Routen bevorzugen. Das ist bislang nur Studie und noch nicht ansibilisiert daher bitte beim ausrollen der Bird-Rolle aufpassen :slight_smile:
  • corny neu gestartet weil wegen aus gründen:

Tunneldigger auf Handle neu gestartet. Stand.

3 „Gefällt mir“

bgp_local_pref für alle FFNW Tunnel nach Berlin auf 200 gesetzt um diese bevorzugt zu verwenden.

2 „Gefällt mir“

Freifunk-Tester repariert. Der hat sich irgendwie auf die Nase gelegt, weil ein Fehler nicht abgefangen wird:

Bearbeite Clientnetz-ffmsd09
ffmsd09 läuft nicht. Wird nun gestartet. Warte 100 Sekunden.
libvirt: QEMU Driver error : Requested operation is not valid: domain is not running
Traceback (most recent call last):
  File "./ff_test.py", line 110, in test_one_network
    gluon.destroy()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1051, in destroy
    if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self)
libvirt.libvirtError: Requested operation is not valid: domain is not running

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./ff_test.py", line 133, in <module>
    tests_for_all_networks()
  File "./ff_test.py", line 116, in tests_for_all_networks
    test_one_network(net)
  File "./ff_test.py", line 112, in test_one_network
    print(str(e))
UnboundLocalError: local variable 'e' referenced before assignment

PS: Ist gepatcht, der Fehler wird einfach ignoriert. Ich vermute, dass da mal jemand per Hand die VM ausgemacht hatte oder parallel noch ein Test von Hand lief.

Webserver VM war durch wundersame Hand Plötzlich wieder erreichbar heute morgen trotz einer Uptime > 7 Tage.

Ich hab mal Updates gemacht und die Kiste rebootet. Booten hat gefühlt 20 Minuten gedauert. Werde aus Gründen in den nächsten Tagen eine neue VM für den Webserver auf Voyager anlegen…

4 „Gefällt mir“

tunneldigger auf Handle und corny gestartet, Stand auf handle komplett und auf corny eine Instanz.

2 „Gefällt mir“

FFNW schickt uns derzeit keine Standardrouten, manuell auf allen per FFNW angebundenen Gateways gesetzt.

2 „Gefällt mir“

Letzte Tage vergessen…

Somit wird die API sobald der PR angenommen ist von der Karten VM bereitgestellt.

3 „Gefällt mir“

Die Ansible Rollen für die Statistik VM sind noch nicht ganz sauber, folgt noch…

Im laufe des Tages werde ich den Wordpress Blog auf den neuen Webserver auf Voyager umziehen also nicht erschrecken wenn’s mal grad hakt. Danach können wer die alte Webserver VM einmotten…

4 „Gefällt mir“