Admin Logbuch

Frank/Michael 05.02.2024

  • Zusatzsoftware, manuell zu installieren:
  • fail2ban, um unerwünschte ssh-Versuche zu blocken
  • screen, um eine Session über einen Crash hinaus aufrecht zu erhalten
  • needrestart, um nach Upgrade zu sehen, ob ein Rebott notwendig ist
  • chrony, besserer NTP-Daemon
  • bash-completion, um den Tab im CLI besser zu verwenden
  • console-data, um eine dt. Tastatur einzurichten

Michael 01.02.24

  • für die VMs koerne (Debian 11.4) auf hypervisor und snng-dus01 (Debian 12) auf blech02 die Passwortanmeldung abgeschaltet und vorher
    natürlich keys übertragen. root-Anmeldung ist auch abgestellt.
    Das Debian auf snng-dus01 ist ohne Grafik-Installation und es fehlen noch einige Sachen wie fail2ban usw.
    Das Debian auf koerne muss noch auf 12 gebracht werden.

Frank 23.01.24

  • für Hypervisor01 neuen vzdump Sicherungsjob erstellt auf andere PLatte.
    Probelauf am 27.01.
    Nachtrag 01.02.24:
    erfolgreich auf local2, Email -Benachrichtigung nur wenn es Probleme gab

Michael 17.01.24(!)

  • für snng-dtm01+02 die Datei sources-list auf
    deb http://archive.debian.org/debian/ jessie main
    deb-src http://archive.debian.org/debian/ jessie main
    umgestellt.
  • Dann bash-completion installiert und console-data, jetzt gibt es eine qwertz-Tastatur

Michael 17.01.23

  • Aus einem Image-Backup von sn-ber01 die VM sn-dtm03.ffdo.net auf blech02 erstellt.
  • Auf blech02 einen DNS-Server nordstadt2.ffdo.net erstellt.
  • dtm03 in die Infrastruktur ffdo und wila eingebaut
  • Tunnel zwischen dtm03 und ber01 erstellt für OSPF, Filter eingebaut (Johannes), Tunnel zwischen dtm01 und dtm02 und zu dtm03 erstellt. (geplant)
  • batman überarbeitet auf dtm03, Ausleitung nicht mehr über FF-Rheinland, sondern über AS35675 (FFDO) und AS31371 (wila). (geplant)

Cajus 09.04.22

  • Karten Server NG angepasst, dass die Knoten Statistiken jetzt von grafana.ffdo.de statt grafana.freifunk-dortmund.de geladen werden. Das sollte das Nachladen etwas zuverlässiger machen und auch bei Browser die Drittanbieter Cookies ablehnen funktionieren.
  • Karten Server NG angepasst, dass auf der Domänen Status Seite wieder etwas unter Punkt ‘Status-Monitor’ (ganz am Ende) zu sehen ist: System Health
  • Karten Server NG angepasst, dass eine möglicherweise nutzbare Named DNS Zone Datei für die Knoten erzeugt wird : https://map-ng.ffdo.de/data/nodes.zone

Cajus 23.02.22

  • Der Grafana Knotenübersicht-ng Seite zusätzliche Panels für eingesetzte Firmware Versionen und Hardwaremodelle spendiert.
  • Schmutzig & schnell Links der nodes2grafana Dashboards angepasst an laufende Grafana Version:
    In den Files unter “/var/lib/grafana/dashboards/” die Links “/dashboard/file/FF-DO-blah-blub.json” durch “/dashboard/db/ff-do-blah-blub” ersetzt.

TODO: Wer Zeit und Lust hat, kann die Änderungen ins nodes2grafana Projekt einmassieren.

Cajus 30.01.22

Neustart des Supernode Servers sn-ber01.ffdo.de
Grund Anzahl der verbunden Nodes war seit lägerem auf 2 gesunken, bei fast 0 Netzwerk Traffic und seit Monaten war die CPU Anzeige in grafana ungesund lila: sn-ber01 grafana Seite

Michael 12.10.21

Auf 31.172.33.30 Proxmoxvon Version 6.3 auf 6.4 upgedatet. Kein reboot notwendig.

Stefan 13.07. - 14.07.21

Das Zertifikat für https://map-ng.ffdo.de/map/ ist abgelaufen, das für grafana.ffdo.de läuft in Kürze ab Das acmetool ist auf dem alten Debian nicht mehr supportet. Daher habe ich jetzt das acme.sh skript verwendet. Das hat quasi (fast) keine Abhänigkeiten. Leider landet es in /root/.acme.sh/ wo solche Skripte sicher nicht hingehören. Man kann das zwar ändern andern dann sind updates von acme.sh selbst wieder etwas anders. Daher hab ich die default Einstellung so gelassen wie sie war.

Schritt 1: acme.sh installieren

“socat” ist die einzige Abhänigkeit die wohl manches einfacher macht; daher wird das vorher installiert

apt-get install socat  

Als nächstes laden wir das install-script runter und führen es direkt mit root rechten aus (Solche Konstrukte sind natürlich sehr bequem aber man muss sich bewusst sein ein fremdes Skript mit root rechten auf dem Server auszuführen; vom Sicherheitsaspekt her ist es sinnvoll so ein Skript erst runterzuladen und vor dem ausführen mal reinzuschauen)

curl https://get.acme.sh | sh 

Schritt 2: Vorbereitungen für LEs Challenge

Ordner für die Zertifikate anlegen:

mkdir /var/www/letsencrypt

In allen vier virtuellen Hosts müssen wir das acmetool rauswerfen und acme.sh einfügen. Vorher sieht die Config zB. wie folgt aus:

location /.well-known/acme-challenge/ {  
   include           proxy_params;  
   proxy_pass        http://127.0.0.1:402;  
}   

Nachher zB.:

location /.well-known/acme-challenge {  
   root /var/www/letsencrypt;  
   try_files $uri $uri/ =404;  
}  

Diese Änderung wird in alle der folgenden conf-Dateien gemacht:

nano /etc/nginx/sites-available/prometheus_unsecure.conf  
nano /etc/nginx/sites-available/grafana_unsecure.conf  
nano /etc/nginx/sites-available/wiki_unsecure.conf  
nano /etc/nginx/sites-available/gogs_unsecure.conf  

Dann einmal nginx neu starten damit die obigen Einstellungen aktiv werden

systemctl reload nginx

Schritt 3: Zertifikate holen und aktivieren

Jetzt können wir die Zertifkate abholen/generieren

/root/.acme.sh/acme.sh --issue -d prometheus.ffdo.de -w /var/www/letsencrypt --server letsencrypt --reloadcmd "systemctl restart nginx.service"  
/root/.acme.sh/acme.sh --issue -d wiki.ffdo.de -w /var/www/letsencrypt --server letsencrypt --reloadcmd "systemctl restart nginx.service"  
/root/.acme.sh/acme.sh --issue -d git.ffdo.de -w /var/www/letsencrypt --server letsencrypt --reloadcmd "systemctl restart nginx.service"  
/root/.acme.sh/acme.sh --issue -d grafana.ffdo.de -d grafana.freifunk-dortmund.de -w /var/www/letsencrypt --server letsencrypt --reloadcmd "systemctl restart nginx.service"  

Jetzt in den HTTPS configs die neuen Zertifkatspfade eintragen. Vorher zB.:

ssl_certificate /var/lib/acme/live/grafana.ffdo.de/fullchain;  
ssl_certificate_key /var/lib/acme/live/grafana.ffdo.de/privkey;  

Nachher zB.:

ssl_certificate /root/.acme.sh/grafana.ffdo.de/fullchain.cer;  
ssl_certificate_key /root/.acme.sh/grafana.ffdo.de/grafana.ffdo.de.key;  

Das ganze wieder in allen Configs für die Virtuellen Hosts:

nano /etc/nginx/sites-available/gogs.conf  
nano /etc/nginx/sites-available/grafana.conf  
nano /etc/nginx/sites-available/wiki.conf  
nano /etc/nginx/sites-available/prometheus.conf  

Dann wieder nginx neustarten:

systemctl restart nginx

Geht nicht! Warum?

journalctl -xn

Ausgabe von journalctl:

Jul 13 16:36:46 services nginx[2264]:  
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/root/.acme.sh/git.ffdo.de/git.ffdo.de.key.")  
failed (SSL: error:02001002:system library:fopen:No such file  

Man beachte den Dateinamen für den private key. Da ist am Ende ein “.” zuviel. Also Editor starten und den überschüssigen Punkt rauswerfen:

nano gogs.conf  

nginx nochmal neustarten damit die Zertifikate geladen werden

systemctl restart nginx  

Schritt 4: Renew automatisieren

Automatischen renew einmal erzwungen laufen lassen (zum testen ob alles geht):

/root/.acme.sh/acme.sh --cron --home /root/.acme.sh --renew-hook "systemctl reload nginx" --force  

Keine Fehler beim Testlauf, also noch Cronjob anlegen

crontab -e  

Feststellen, dass das install script schon ein entsprechenden eintrag gemacht hat

23 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null  

Fertig.

Cajus 12.05.21

  • Server services: security fixes eingespielt für: apt, e2fsprogs, file, git, passwd, login, sudo, ssh-client, ssh-server
  • Grafana: ‘aktualisiert’ auf Version 5.4.5
    • die Dashboards aus /var/lib/grafana/dashboards mussten von Hand importiert werden.
      Das Verzeichnis scheint nicht mehr automatisch gelesen zu werden.
    • die Dashboards aus /var/lib/grafana/dashboards werden wieder importiert. :) Eine Datei /etc/grafana/provisioning/dashboards/ffdo.yaml anlegen mit

## config file version  
apiVersion: 1  
  
providers:  
 - name: 'default'  
    orgId: 1  
    folder: ''  
    type: file  
    options:  
    path: /var/lib/grafana/dashboards  

Cajus 11.05.21

Cajus 13.04.21

Cajus 31.03.21

  • Proxmox Sicherheitsupdates eingespielt: curl (7.64.0-4+deb10u2) und openssl (1.1.1d-0+deb10u6) inkl. libs.

Cajus 22.03.21

Cajus 12.03.21

Cajus 06.03.21

  • Supernodes sn-dtm01 und sn-dtm02 Anzahl der CPU Kernen auf 4 reduziert. Das entspricht der Zahl vor dem Umzug auf die neue Hardware.

Cajus 28.02.21

  • Proxmox Sicherheitsupdates eingespielt: libisccfg163:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libldap-2.4-2:amd64 (2.4.47+dfsg-3+deb10u5, 2.4.47+dfsg-3+deb10u6), openssl:amd64 (1.1.1d-0+deb10u4, 1.1.1d-0+deb10u5), zstd:amd64 (1.3.8+dfsg-3+deb10u1, 1.3.8+dfsg-3+deb10u2), libirs161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), bind9-host:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), dnsutils:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libisc-export1100:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libisc1100:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libldap-common:amd64 (2.4.47+dfsg-3+deb10u5, 2.4.47+dfsg-3+deb10u6), liblwres161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libdns-export1104:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libzstd1:amd64 (1.3.8+dfsg-3+deb10u1, 1.3.8+dfsg-3+deb10u2), libisccc161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libssl1.1:amd64 (1.1.1d-0+deb10u4, 1.1.1d-0+deb10u5), libbind9-161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3), libdns1104:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u2, 1:9.11.5.P4+dfsg-5.1+deb10u3)

Cajus 14.02.21

  • Build VM: VM Systemdisk Größe verkleinert:
  • Das Filesystem von build belegte nur 10GB, die VM Disk war 32GB gross. Auf 16GB verkleinert: zfs set volsize=16G rpool/data/vm-100-disk-0 Obacht das kann man nur ohne Datenverlust machen, wenn das Filesystem wirklich kleiner ist als die VM Disk!![1]
  • Build VM: File System vergrößert /verändert
  • Das Filesystem mit gparted Disk an die 16GB angepasst:
    • swap partition in /etc/fstab deaktiviert
    • gparted ISO Image als CD in die VM “eingelegt”
    • Bootreihenfolge angepasst: Starte von CD ROM
    • Nach Neustart mit gparted Disk layout geändert:
      • Swap Partition gelöscht
      • Extended Partition gelöscht.
      • Root Partition vergrößert.
      • Extended Partition angelegt
      • Swap Partiton angelegt (nur etwas größer)
    • Neustart ohne CDROM und alter Boot Reihenfolge
    • neue UUID der neuen swap Partition in fstab eingetragen
    • neue UUID der neuen swap Partition in /etc/initramfs-tools/conf.d/resume eingetragen [2]. Ohne sucht die VM 30 Sekvergeblich nach der alten swap Partition.
  • Build VM: Backup gelöscht. Hatte ich als Sicherheit angelegt.

  • Ticket VM: Snapshot angelegt.
  • Ticket VM: Systemupgrade von Debian 8 auf Debian 9.
  • Ticket sytem: Mailaccount (info@freifunk-dortmund.de) auf “Imap + SSL” gestellt und richtigen Port (993) eingetragen: Ticket System funktioniert wieder. /
  • Ticket VM: Sytems Disk Größe auf 12GB reduziert: zfs set volsize=12G rpool/data/vm-102-disk-0
  • Ticket VM: CPUs Anzahl auf 8 reduziert. Die VM hat nicht viel zu tun.
  • Ticket VM: prometheus nodeexport installiert
  • Grafana: nodeexport von ticket aufgenommen [3]
  • Grafana: Home Dashboard für ticket angepasst
  • Grafana: Neues Dashboard für Gruppen in der neuen Struktur erstellt. [4]
  • portscan auf build und ticket ausgeführt, keine unerwarteten Ports offen.
  • hypervisor01 proxmox: aptitude installiert
  • hypervisor01 proxmox: sicherheitskritische Updates via aptitude eingespielt.

Evtl kann man die RAM Zuteilung von ticket reduzieren. Bisher nutzt das System nicht mal 2GB von den 8GB. Aber man hat’s ja <3

Cajus 10.02.21

  • Proxmox updates eingespielt.
  • ich habe gestern die build VM auf debian 9 aktualisiert.
  • die zweite Platte (‘/data’) habe ich auf 160GB vergrößert.
  • speedtest “Firmware bauen” gefahren. :))))) <3
  • die VM habe ich in proxmox umbenannt in “build” (war “build-alt”)
  • bei der VM ticket habe ich die Partition und das Filesystem /data auf die neue Größe der Disk angepasst.
  • die VM habe ich in proxmox umbenannt in “images” (war “images-alt”)
  • bei der VM images habe ich die Partition und das Filesystem /data auf die neue Größe der Disk angepasst (jetzt 305GB)
  • Fast alle VMs das ‘Start at boot’ aktiviert.
  • Gparted ISO images hochgeladen.

TODOs für die nächste Zeit

  • VM ticket: das Debian OS aktualisieren in der Hoffnung, dass das Maillesen dann wieder funktioniert.
  • VM ticket: CPU auf 4 Cores reduzieren.
  • aktuell sind die system Disks der VMs 32GB groß, aber das Filesystem nutzt nur 10GB: Root Partition, Extended Partition mit Swap Partition. Validieren: Entweder die Disks verkleinern oder die Partitionen vergrößern.