wiki/Technik/Netzinfrastruktur/Supernodes/logbuch.page

---
format: markdown
title: Admin Logbuch
toc: no
...

# 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.