--- format: markdown title: Admin Logbuch toc: no ... # 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](https://map-ng.ffdo.de) 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](https://map-ng.ffdo.de) angepasst, dass auf der Domänen Status Seite wieder etwas unter Punkt 'Status-Monitor' (ganz am Ende) zu sehen ist: [System Health](https://grafana.ffdo.de/d-solo/000000014/ff-do-home?theme=light&panelId=25) * [Karten Server NG](https://map-ng.ffdo.de) angepasst, dass eine möglicherweise nutzbare [Named DNS Zone Datei](https://map-ng.ffdo.de/data/nodes.zone) für die Knoten erzeugt wird : https://map-ng.ffdo.de/data/nodes.zone # Cajus 23.02.22 * Der Grafana [Knotenübersicht-ng Seite](https://grafana.ffdo.de/d/000000026/knotenubersicht-ng?refresh=5m&orgId=1&from=1645581367018&to=1645602967019&var-site_list=All) 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](https://git.ffdo.de/altlast/nodes2grafana) 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](https://grafana.ffdo.de/d/000000011/supernodes-exporter-full?var-node=sn-ber01.ffdo.de&refresh=1m&orgId=1&from=now-30d&to=now) # 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](https://grafana.ffdo.de/): 'aktualisiert' auf Version [5.4.5](https://grafana.com/blog/2019/08/29/grafana-5.4.5-and-6.3.4-released-with-important-security-fix/) - ~~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 - [Grafana](https://grafana.ffdo.de/): 'aktualisiert' auf Version [4.5.6](https://community.grafana.com/t/grafana-5-3-3-and-4-6-5-security-update/11961) # Cajus 13.04.21 - [Grafana](https://grafana.ffdo.de/): fixed NG Router top10 Chart auf [NutzerInnenübersicht NG](https://grafana.ffdo.de/dashboard/db/nutzerinnenubersicht-ng?refresh=1m&orgId=1) # 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 - Git Server Update: Update von [gogs](https://github.com/gogs/gogs) alias [git.ffdo.de](https://git.ffdo.de) auf Version [0.11.91](https://github.com/gogs/gogs/releases/tag/v0.11.91). Siehe [Anleitung](https://gogs.io/docs/upgrade/upgrade_from_binary). Grund war [Extremely high CPU usage](https://github.com/gogs/gogs/issues/4475) # Cajus 12.03.21 - Update des [hopglass Servers](https://github.com/hopglass/hopglass-server) von der [neuen Karte](https://map-ng.ffdo.de/) auf Revision [93e8df1c45c5399ec1b630e5f1efc5af37e431b8](https://github.com/hopglass/hopglass-server/commit/93e8df1c45c5399ec1b630e5f1efc5af37e431b8): - [Das](https://github.com/hopglass/hopglass-server/commit/f0e2c0a58b8947176f7c87680c2bcb27f302f14c) war Vorraussetzung für zukünftige Router Firmware basierend auf [gluon 2019](https://gluon.readthedocs.io/en/latest/releases/v2019.1.html) oder aktueller. - Mit der Aktualisierung werden auf der [Karte](https://map-ng.ffdo.de/map/) keine Supernodes oder Karten Server mehr gezeigt. Das macht die Karte als Graphen auch etwas übersichtlicher. # 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. \o/ - 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.