wiki/Technik/Netzinfrastruktur/Supernodes/logbuch.page

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

# 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. 
Erstmal acme.sh installieren (landet leider direkt in /root/.acme.sh/)  
socat ist die einzige Abhänigkeit die wohl manches einfacher macht; daher wird das vorher installiert  

#
    apt-get install socat  
#

Altlast besser weg gucken...
Damit laden wir das install-script runter und führen es direkt mit root rechten aus

#
    curl https://get.acme.sh | sh 
#
Vorbereitungen für LEs Challenge

#
    mkdir /var/www/letsencrypt
#
In allen vier virtuellen Hosts müssen wir das acmetool rauswerfen und acme.sh einfügen  
Vorher zB.: 

#
    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;  
    }  
#

Das in allen conf-Dateien:

#
    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

Jetzt 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;  
    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  
#

nginx neustarten  

#
    systemctl restart nginx
#

Geht nicht! Warum?  
journalctl -xn

#
    -> 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 Punkt rauswerfen:  

#
    nano gogs.conf  
#

nginx nochmal neustarten damit die Zertifikate geladen werden  

#
    systemctl restart nginx  
#

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.