Welche Artikel haben sich geändert?

Warum diese Seite?

Ab und zu ändere Artikel oder korrigiere Rechtschreibfehler. Manchmal füge dort weitere Informationen hinzu, die keinen eigenen Blogartikel wert sind. Damit ich diese Änderungen kommunizieren kann, erstelle ich ab und zu solche Übersichtsseiten, wie Ihr hier sie gerade lest. Eine tabellarische Übersicht der Änderungen mit Verlinkungen auf die jeweiligen Seiten.

Technischer Hintergrund

Den Zeitstempel des Artikel zu ändern, bringt RSS-Feeds durcheinander und es ist dann ggf. auch nicht gleich ersichtlich, was geändert worden ist. Da ich sowieso git commit Messages schreibe, kann ich die auch gleich auswerte, als Tabelle erstellen. Ein Script nimmt dann diese Tabelle und erstellt mit einem Template eine neue Seite im Blog.

Die Miss Megaphon hat auf Mastodon einen kleinen Zettel für eine Sonntagsrallye veröffentlicht, um Kinder an die frische Luft zu bekommen.

In Zusammenarbeit mit Ihr und mit Ihrer Genehmigung habe ich davon ein veröffentlichbares PDF erstellt und stelle es hier zur Verfügung. “Mein” “Original” ist eine Markdown-Datei, die ich ebenfalls hier zum Download anbiete.

Ihr dürft es gerne frei verwenden; wir beide würden uns aber über eine kleine Erwähnung freuen.

• sonntagsspaziergang.md
• sonntagsspaziergang.pdf

Durch Freunde wurde ich auf das Document Management System paperless aufmerksam, dass im derzeit aktuellen Fork paperless-ngx weiterlebt. In Verbindung mit einem Einzugsscanner ist es ein wahr gewordener Traum, der mich sehr in meinem Alltag entlastet.

Das Aktualisieren von paperless-ngx (im Folgenden nur noch paperless genannt) unter Docker ist zwar in der Dokumentation recht gut beschrieben, aber das Updaten der Datenbank, finde ich zu kompliziert, weil es nur auf die offizielle PostgreSQL-Dokumentation verweist.

Hier müsste ich mit den CLI-Tools wie pg_dumpall und pg_upgrade hantieren, was arbeiten im Docker-Container notwendig macht und vermutlich auch doppelte Docker-Container-Instanzen nötig macht. Eine automagische Migration unterstützen die postgres-images nach meinem Wissen derzeit nicht. Also habe ich eine andere Möglichkeit gesucht und auch gefunden!

paperless liefert die beiden Tools document_exporter und document_importer mit, die ein vollständiges Backup und Wiederherstellung (Restore) der kompletten Instanz bereitstellt.

Mit diesen beiden Tools lässt sich ein Major-Upgrade bewerkstelligen. Wie ich heute rausfand ist sogar der Wechsel der Datenbank-Engine ohne allzu große Umstände möglich.

Überblick

Der grobe Pfad für ein Major-Upgrade ist daher:

• Zuerst ein vollständiges Backup anfertigen.
• Alle Daten inklusive Volumes wegwerfen.
• Die PostgreSQL-Version im docker-compose.yml anpassen.
• Schlussendlich alle Daten wieder importieren.

Das hat bisher anstandslos geklappt.

Der Wechsel auf eine andere Datenbank-Engine wird weiter unten beschrieben.

Voraussetzungen

Es setzt voraus, dass die Daten außerhalb der Docker-Umgebung landen. Das export Volume ist also als Verzeichnis unterhalb der docker-compose.yml so wie in den Beispielen definiert.

1      - ./export:/usr/src/paperless/export

Wie ich ein Datenbank-Upgrade im Detail durchführe, beschreibe ich im Folgenden.

Zuerst sollte sichergestellt sein, dass keine Importe ins Paperless stattfinden. Da ich alleine auf dem System arbeite und keinen E-Mail-Import verwende, kann ich das gut sicherstellen.

Backup

Als ersten Schritt fertige ich ein Backup an. Dies geht wunderbar mit dem bereits erwähnten document_exporter folgendermaßen:

1docker compose exec -T webserver document_exporter ../export -z -zn full-backup

Hier sollte dann eine Datei namens full-backup.zip außerhalb des Docker-Umgebung entstanden sein. Dies enthält alle relevanten Informationen für ein Desaster-Recovery.

Tipp

Der zusätzliche Parameter --no-progress-bar sorgt für weniger Ausgaben in Backup-Scripten.

Zurück auf Null

Danach fahre ich alle Container herunter und lösche gleichzeitig alle Docker Volumes:

1docker compose down --volumes

Die Ausgabe sollte ungefähr so aussehen:

1[+] down 8/8
2 ✔ Container paperless-webserver-1 Removed   5.6s
3 ✔ Container paperless-broker-1    Removed   0.4s
4 ✔ Container paperless-db-1        Removed   0.3s
5 ✔ Volume paperless_media          Removed   0.2s
6 ✔ Volume paperless_pgdata         Removed   0.0s
7 ✔ Volume paperless_data           Removed   0.0s
8 ✔ Volume paperless_redisdata      Removed   0.0s
9 ✔ Network paperless_default       Removed                     

Neue Version wählen

Nun kann ich in der docker-compose.yml-Datei das Datenbank-Image auf die gewünschte Version der Datenbank hochziehen.

Für PostgreSQL gibt es hier im Repo eine Vorlage an der ich mich orientiert habe. Im Mai 2025 war es die Version 17. Also änderte ich den Eintrag docker-compose.yml von der Version 16.

1  db:
2    image: docker.io/library/postgres:16

auf die Version 17

1  db:
2    image: docker.io/library/postgres:17

Es empfiehlt sich eh ab und zu da mal einzuschauen, ob nicht z.B. eine neue redis-Version unterstützt wird. Ich selbst stütze mich nur auf die Haupt (Major-Versionen). Bei Minor- oder Patch-Updates pulle ich das jeweilige neue Image und starte alle Docker-Container neu, das reicht mir und hat sich bei mir bewährt.

Hinweis

Aktuell ist im Repo die PostgreSQL-Version 18 angegeben. Leider wirft der Docker-Container db-1 einiges an Fehlermeldungen und startet sich immer wieder neu. Eine Lösung dazu beschreibe ich weiter unten; hier soll es jetzt erst einmal mit dem Upgrade von 16 auf 17 weiter gehen; schließlich hat das Update von 15 auf 16 vor einiger Zeit genauso geklappt.

Erster Start

Nach dem Ändern der Major-Version (bzw. des Tags) vom postgres-Image, können die Docker-Container von paperless schon wieder gestartet werden. Sofern das Image lokal noch nicht vorliegt, wird es automatisch heruntergeladen.

1docker compose up -d

Folgendes sollte als Ausgabe zu sehen sein:

 1[+] up 22/22
 2 ✔ Image docker.io/library/postgres:18 Pulled     15.3s
 3 ✔ Network paperless_default           Created    0.0s
 4 ✔ Volume paperless_data               Created    0.0s
 5 ✔ Volume paperless_media              Created    0.0s
 6 ✔ Volume paperless_redisdata          Created    0.0s
 7 ✔ Volume paperless_pgdata             Created    0.0s
 8 ✔ Container paperless-db-1            Created    0.2s
 9 ✔ Container paperless-broker-1        Created    0.2s
10 ✔ Container paperless-webserver-1     Created   

Nun muss solange gewartet, bis die Login-Maske wieder mit dem Browser besuchbar ist.

Da dies einer Neuinstallation entspricht und daher Datenbanken etc. eingerichtet werden müssen, dauert dies je nach Rechenpower etwas. Daher ist etwas Geduld erforderlich.

Zeigt’s im Browser 502 Bad Gateway ist noch nicht alles fertig. Neugierige werfen ein Blick in die Docker-Logs

1docker compose logs -f

Wenn ungefähr folgende Log-Einträge zu sehen sind

 1webserver_1  | [tasks]
 2webserver_1  |   . documents.bulk_edit.delete
 3webserver_1  |   . documents.signals.handlers.send_webhook
 4webserver_1  |   . documents.tasks.bulk_update_documents
 5webserver_1  |   . documents.tasks.check_scheduled_workflows
 6webserver_1  |   . documents.tasks.consume_file
 7webserver_1  |   . documents.tasks.empty_trash
 8webserver_1  |   . documents.tasks.index_optimize
 9webserver_1  |   . documents.tasks.sanity_check
10webserver_1  |   . documents.tasks.train_classifier
11webserver_1  |   . documents.tasks.update_document_content_maybe_archive_file
12webserver_1  |   . paperless_mail.mail.apply_mail_action
13webserver_1  |   . paperless_mail.mail.error_callback
14webserver_1  |   . paperless_mail.tasks.process_mail_accounts
15webserver_1  | 
16webserver_1  | [2025-05-29 12:50:03,792] [INFO] [celery.worker.consumer.connection] Connected to redis://broker:6379//
17webserver_1  | [2025-05-29 12:50:03,982] [INFO] [celery.apps.worker] celery@7e94fdb4f941 ready.

sollte die Login-Maske zur Einrichtung des ersten Benutzerkontos verfügbar sein und es kann mit dem nächsten Schritt weiter gemacht werden.

Daten wieder importieren

Über den document_importer lässt sich nun wieder alles importieren: Alle Dokumente, alle Tags, alle Benutzeraccounts, gespeicherten Ansichten usw.

1docker compose exec -T webserver document_importer ../export/full-backup.zip

Ausgabe:

1Checking the manifest
2Installed 4248 object(s) from 1 fixture(s)
3Copy files into paperless...
4100%|██████████| 1014/1014 [00:04<00:00, 210.59it/s]
5Updating search index...
6100%|██████████| 1014/1014 [00:10<00:00, 94.50it/s] 

Falls im Browser Weiterleitung auf den Unterpfad /accounts/signup/?next=%2F stattfand, diesen Pfad löschen! Im Browser also wieder die gewohnte URL ansurfen und es sollte wieder die gewohnte Login-Maske erscheinen.

Fertig, anmelden

Schlussendlich stoße ich noch einmal vorsichtshalber mein Backup-Script von Paperless noch an und bin fertig.

PostgreSQL 18

Während ich diesen Artikel schrieb, stellte ich fest, dass in den Vorlagen im Repo zu docker-compose.yml schon PostgreSQL 18 unterstützt wird. Ich bin daher genau nach meiner Anleitung vorgegangen und musste feststellen, dass der Datenbank-Container nicht nach oben kam.

In den Docker-Logs entdeckte ich dann folgende Meldungen:

 1db-1         | Error: in 18+, these Docker images are configured to store database data in a
 2db-1         |        format which is compatible with "pg_ctlcluster" (specifically, using
 3db-1         |        major-version-specific directory names).  This better reflects how
 4db-1         |        PostgreSQL itself works, and how upgrades are to be performed.
 5db-1         | 
 6db-1         |        See also https://github.com/docker-library/postgres/pull/1259
 7db-1         | 
 8db-1         |        Counter to that, there appears to be PostgreSQL data in:
 9db-1         |          /var/lib/postgresql/data (unused mount/volume)
10db-1         | 
11db-1         |        This is usually the result of upgrading the Docker image without
12db-1         |        upgrading the underlying database using "pg_upgrade" (which requires both
13db-1         |        versions).
14db-1         | 
15db-1         |        The suggested container configuration for 18+ is to place a single mount
16db-1         |        at /var/lib/postgresql which will then place PostgreSQL data in a
17db-1         |        subdirectory, allowing usage of "pg_upgrade --link" without mount point
18db-1         |        boundary issues.
19db-1         | 
20db-1         |        See https://github.com/docker-library/postgres/issues/37 for a (long)
21db-1         |        discussion around this process, and suggestions for how to do so.
22db-1 exited with code 1 (restarting)

Der Downgrade auf 17 war nach der obigen Anleitung recht schnell erledigt und paperless lief wieder zufriedenstellend mit der Version 17 von PostgreSQL.

Umstellung auf MariaDB 12

Ich nahm dies als Anlass, die Datenbank-Engine auf MariaDB umzustellen. Im Repo des Projektes gibt es dazu ebenfalls eine Vorlage. Es gab drei Stellen, die ich dafür anpassen musste.

Es mussten im Abschnitt von db ein paar Umgebungsvariablen und natürlich das image umgestellt werden; hier ist 12 gerade aktuell.

Weiter unten im Abschnitt webserver mussten ebenfalls noch ein paar Umgebungsvariablen hinzugefügt werden.

Als letztes musste ich den Volume-Namen im Abschnitt volumes umbenennen. Danach konnte ich die Container wieder starten und die Daten importieren, wie weiter oben beschrieben.

Nachfolgend ein diff aus meinem ansible-Playbook. (Ja, ich habe restart auch noch gleich umstellt bzw. an die neue Vorlage aus dem Projekt angeglichen. )

 1--- a/roles/paperless/files/docker-compose.yml
 2+++ b/roles/paperless/files/docker-compose.yml
 3@@ -28,26 +28,24 @@
 4 
 5 services:
 6   broker:
 7-    image: docker.io/library/redis:8
 8-    restart: unless-stopped
 9+    image: docker.io/library/redis:7
10+    restart: always
11     volumes:
12       - redisdata:/data
13 
14   db:
15-    image: docker.io/library/mariadb:12
16-    restart: unless-stopped
17+    image: docker.io/library/postgres:17
18+    restart: always
19     volumes:
20-      - dbdata:/var/lib/mysql
21+      - pgdata:/var/lib/postgresql/data
22     environment:
23-      MARIADB_HOST: paperless
24-      MARIADB_DATABASE: paperless
25-      MARIADB_USER: paperless
26-      MARIADB_PASSWORD: paperless
27-      MARIADB_ROOT_PASSWORD: paperless
28+      POSTGRES_DB: paperless
29+      POSTGRES_USER: paperless
30+      POSTGRES_PASSWORD: paperless
31 
32   webserver:
33     image: ghcr.io/paperless-ngx/paperless-ngx:latest
34-    restart: unless-stopped
35+    restart: always
36     depends_on:
37       - db
38       - broker
39@@ -68,13 +66,9 @@ services:
40       - extra.env
41     environment:
42       PAPERLESS_REDIS: redis://broker:6379
43-      PAPERLESS_DBENGINE: mariadb
44       PAPERLESS_DBHOST: db
45-      PAPERLESS_DBUSER: paperless # only needed if non-default username
46-      PAPERLESS_DBPASS: paperless # only needed if non-default password
47-      PAPERLESS_DBPORT: 3306
48 volumes:
49   data:
50   media:
51-  dbdata:
52+  pgdata:
53   redisdata:

Ich verwendet einen eigenen Dienst um URLs zu kürzen.

Solltest Du aus dieser Seite gelandet sein, kann das mehrere Gründe haben.

Groß/Kleinschreibung

Groß/Kleinschreibung ist wichtig! Falls Du den Link abgeschrieben hast, kontrolliere bitte auf Groß- und Kleinschreibung. Dies gilt für alle URL (Internet-Adressen)!

Ungültig

Es kann sein, dass einige Kurz-Links nur zeitweise zur Verfügung stehen. Vielleicht hat sich das Thema erledigt oder es gab andere Gründe den Link zu löschen.

Liste aller Links

Kannst du nicht eine Liste aller Kurz-Links zur Verfügung stellen?

Hahaha. Nein.

Fragen

Meist hast Du eine Kontaktmöglichkeit zu mir: Nutze sie und frage mich.

Veranstaltungsorte

• 22. März 2025 auf den Chemnitzer Linux-Tagen 2025
• 11. Dezember 2025 auf den IT-Tage 2025

Kurzprofil

Dieser Vortrag geht zuerst auf grundlegende Details und die Arbeitsweise von restic ein. Wir besprechen lokalen und Cloud Storage, Verschlüsselung, Snapshots, Restore, sowie verschiedene wichtige Optionen.

Im zweiten Teil erklären wir, wie resticprofile funktioniert. Als Beispiel wird ein Backup-Szenario sowohl mittels restic als auch mit resticprofile aufgebaut, um die Unterschiede in der Handhabung zu verdeutlichen.

Restic ist eine Open-Source-Backup-Software, die Daten zuverlässig speichert und vor Verlust schützt. Die Software ist plattformunabhängig und unterstützt viele verschiedene Speicherziele, darunter lokale Festplatten, Cloud-Speicher und Netzwerkprotokolle wie SFTP, REST oder S3. Restic implementiert Deduplizierung und bietet Verschlüsselung, um Backups effizient und sicher zu speichern. Deduplizierung sichert nur neue oder veränderte Daten, damit werden Duplikate vermieden und Speicherplatz wird gespart.

Resticprofile ist die logische Ergänzung für restic, welches die Konfiguration und Verwaltung mehrerer Backup-Jobs drastisch vereinfacht und übersichtlicher gestaltet. Es ermöglicht das Anlegen und Verwalten von Backup-Profilen, die alle nötigen Einstellungen speichern, wie Speicherorte, Backup-Zeiten und weitere Parameter. Dies erleichtert die Automatisierung und die übersichtliche Verwaltung von komplexen Backup-Szenarien, indem es die Bedienung von restic optimiert und wiederkehrende Aufgaben systematisch handhabt. Außerdem kann es die Verwaltung der Cronjobs in verschiedenen Systemen übernehmen.

Unterlagen

Chemnitzer Linux-Tage 2025

Den Vortrag habe ich das erste Mal zusammen mit Andreas Scherbaum auf den Chemnitzer Linux-Tagen 2025 gehalten.

• Programmankündigung
• Folien
• Aufzeichnung

IT-Tage 2025

Ein weiteres Mal habe ich den Vortag mit Andreas Scherbaum auf den IT-Tage 2025 gehalten.

• Programmankündigung
• Folien
• Aufzeichnung: Es gab keine Aufzeichnung.

Changelog

Welche Artikel haben sich geändert?

Warum diese Seite?

Ab und zu ändere Artikel oder korrigiere Rechtschreibfehler. Manchmal füge dort weitere Informationen hinzu, die keinen eigenen Blogartikel wert sind. Damit ich diese Änderungen kommunizieren kann, erstelle ich ab und zu solche Übersichtsseiten, wie Ihr hier sie gerade lest. Eine tabellarische Übersicht der Änderungen mit Verlinkungen auf die jeweiligen Seiten.

Technischer Hintergrund

Den Zeitstempel des Artikel zu ändern, bringt RSS-Feeds durcheinander und es ist dann ggf. auch nicht gleich ersichtlich, was geändert worden ist. Da ich sowieso git commit Messages schreibe, kann ich die auch gleich auswerte, als Tabelle erstellen. Ein Script nimmt dann diese Tabelle und erstellt mit einem Template eine neue Seite im Blog.

Ich wurde schon mal des Öfteren gefragt wie ich denn meine Kontakte, Kalender, Passwörter, EMails usw. verwalte.
Persönlich möchte ich diese Datenschätze nicht oder nur möglichst wenig der “Cloud” überantworten und mache daher vieles selbst. Das Setup bzw. das Konzept hat eine jahrelange Entwicklung und eine Menge Veränderungen hinter sich. Zu einigen Teilbereichen sind auch schon vereinzelte Blogartikel entstanden.

Ein Gespräch letztens auf Mastodon hat mich dazu veranlasst, dies mal aufzuschreiben und hier zu veröffentlichen. Wer mag, kann sich aus diesem Text Ideen holen und für seine Situation anpassen.

TL&DR;

• Nextcloud selfhostet auf eigener Hardware im Homelab
• Passwort-Safes KeePass, KeePassXC, Bitwarden, Vaultwarden
• Backup mit restic und resticprofile verschlüsselt mit Deduplizierung auf S3-Storage und externen Festplatten

Jetzt die Langfassung: Wie sieht mein Setup aus?

Die Details

Angefangen habe ich mit Owncloud auf einem BananaPi. Vor einigen Jahren bin dann zu Nextcloud gewechselt. Aktuell läuft die Installation auf meinem Heim-NAS von QNAP in einer virtuellen Maschine wo ein Debian drauf läuft.
Aus-Gründen^(tm) waren und sind die Installationen nie von außen erreichbar.

Nextcloud

In der Nextcloud nutze ich überwiegend folgende Funkionen:

• Verwaltung von
  • Kalendern
  • Kontakt-Daten (VCards)
• Dateiaustausch

Die gesamte Familie bindet alles in ihre jeweiligen Mail- und Kalender-Clients auf den unterschiedlichsten Rechnern, mobilen Geräten mit verschiedensten Betriebssystemen an. Die Synchronisation funktioniert somit natürlich nur im heimischen WLAN oder über VPN.

Backups

Da mir meine Daten (Kalender und Kontakte) sehr wichtig sind, sichere ich die Daten regelmäßig und fertige ein Backup an.
Aktuell läuft auf dem Server, wo die Nextcloud installiert ist, ein nächtlicher Cronjob:

• der die Nextcloud in den Wartungsmodus versetzt,
  • um einen konsistenten Zustand zu erreichen,
• einen Dump der mysql-Tabellen auf Festplatte zieht,
• eine dateibasierte Sicherung anfertigt
• und schlussendlich den Wartungsmodus wieder beendet.

Der Cronjob läuft mitten in der Nacht, wenn sowieso alle schlafen. Selbst wenn das mal nicht der Fall sein sollte, verhindert der Wartungsmodus schlimmeres.
Dieses Verfahren existiert schon so seit Jahren und hat sich aus meiner Sicht bewährt. Selbst der Umzug von Owncloud nach Nextcloud sowie vom BananaPi in die virtuelle Maschine hat damit wunderbar funktioniert.

Die dateibasierte Sicherung und die Dumps ins Dateisystem sind nur ein erster Schritt. Wenn ich einzelne Kontakte oder ähnliches wiederherstellen möchte, ist das rauspfriemeln einzelner Daten nicht wirklich schön, beispielsweise eine einzelne aus Versehen gelöschte Kontakt-Karte.
Allerdings gibt es die Möglichkeit alle Kalendereinträge in eine ics Datei herunterzuladen und alle Kontakte in eine .vcf-Datei herunterzuladen. Daraus ist die Wiederherstellung aus meiner Sicht wesentlich einfacher. Wenn alle Dateien gelöscht sind, reicht ggf. sogar ein Doppelklick im Dateiexplorer auf die jeweilige Datei und es wird im Standard-Mail-Programm geöffnet. Von diesem ist dann ein Import wieder möglich. Dadurch, dass das Mail-Programm wieder in die Nextcloud synchronisiert, ist der Kontakt wieder “drin”. Natürlich war ich faul und habe dies automatisiert; wie ich dies realisiert habe, lässt sich hier nachlesen.

Die ganzen Datenkopien (wie Dumps und Exporte) sichere ich nun mit einem Backup-Programm. Da mir die Daten allgemein wichtig sind und ich auch vor Diebstahl und Feuer gewappnet sein möchte, setze ich hier auf das 3-2-1 Prinzip.

3-2-1-Prinzip

Hinweis

Hinweis: Das 3-2-1-Prinzip bedeutet in kurz:
Du hast drei Kopien auf zwei unterschiedlichen Medien, wobei eine Kopie außerhalb liegt.

Die bedeutet: Ich habe eine externe Festplatte auf die ich die Backups regelmäßig kopiere, wobei eine Kopie bei meinen Eltern liegt. Das tägliche Backup schiebe ich in die Cloud. Details siehe in diesem Blog-Artikel im Abschnitt Offsite-Backup.

Cloudspeicher

“Cloud” bedeutet hierbei irgend ein Speicherort, der Dateien aufnehmen kann. Das kann ein OneDrive, eine Dropbox, PDrive oder was auch immer sein. Bei mir ist dies aktuell ein angemieteter S3-kompatibler-Speicher.
Die Backups verschlüssele ich natürlich, daher ist es egal, wo diese im Endeffekt liegen:

• ob es nun eine externe Festplatte ist, die geklaut wird
• oder irgendein Cloud-Speicher, wo Daten abfließen können.

Das gewählte Verschlüsselungspasswort sollte daher möglichst lang und komplex sein.

Backup-Software

Als Software verwendet ich seit einiger restic in Zusammenarbeit mit resticprofile, da ich mit diesen Tools und die Backup-Jobs gut weg-automatisieren kann. Wenn ich daran denken muss, Backups zu machen, vergesse ich das nur.
Wie die Software funktioniert und bedient wird, haben Andreas und ich mal auf den Chemmnitzer LinuxTagen erzählt.

Aus meiner Sicht ist der Vorteil, dass restic

• die Daten verschlüsselt,
• den Platzbedarf mittels Deduplizierung verringert
• und ausmisten nach Regeln beherrscht, da kein Speicher unendlich ist.

resticprofile unterstützt hierbei sogar bei der Erzeugung eines möglichst langen und zufälligem Passwortes. Dadurch, dass ich Dinge automatisch in die Cloud sichere, aber lokal noch eine Festplatte habe, die ich “natürlich” (leider) nur unregelmäßig befülle, hat mir dieses Konzept schon mehrfach wortwörtlich den Hintern gerettet. Aktuell kostet mich der S3-Storage irgendwas unter 4 Euro pro Monat. Bei Interesse nach mehr Details hier klicken. Die dortige Angabe Backblaze stimmt inzwischen nicht mehr. Wegen #unplugTrump bin ich zu Hetzner StorageShare gewechselt.

Passwort-Safes

Ebenfalls seit Jahren nutze ich einen Passwort-Speicher. Bisher reichte mir ein KeePass. Später wechselte ich zu KeePassXC. Die Tresor-Datei lege ich bei mir in meinen Nextcloud-Ordner. Dort synchronisiert sich diese Datei wunderbar zwischen meinen Geräten und ist überall verfügbar, wo ich sie benötige.
Das KeePass-Tersor-Format ist recht verbreitet und es gibt für die unterschiedlichsten Betriebssysteme Software dafür. Die Client-Software für Nextcloud ist ebenso für viele Betriebssysteme verfügbar.

Dank Auto-Fill-Funktion habe ich schon länger kein Passwort mehr getippt und durch die Passwort-Würfeln-Funktion kenne ich auch gar kein Passwort mehr auswendig. Jedem Dienst ein Passwort zu verpassen, ist dadurch für mich recht einfach geworden. In letzter Zeit musste ich jedoch öfters Passwörter teilen und da hat mir KeePassXC nicht gereicht. KeeShare habe ich erst vor kurzem in einen Artikel auf gnulinux.ch entdeckt.
Aus diesem Grund habe ich mir einen Vaultwarden installiert. Vaultwarden ist auch perfekt, wenn ich Dateien oder Textschnipsel über unsichere Kanäle verschicken möchte. Die Funktion nennt sich vaultwarden-send. Über diese Funktion kann ich Dateien oder kurze Texte in den Vault hochladen und danach einen Link zum Herunterladen generieren. Zusätzlich kann ich diesen Link noch mit Passwort-Schutz und sonstigen Parameter versehen. Diesen Link kann ich ruhigen Gewissens unverschlüsselt per E-Mail verschicken. Die Daten liegen verschlüsselt auf der Server-Festplatte und löschen sich standardmäßig nach sieben Tagen selbst.

Tipps zu Vaultwarden

Standard-Einstellungen

Ich empfehle zwei Standard-Einstellungen zu ändern:

• Standard-URI Übereinstimmungserkennung auf Beginnt mit
  • das funktioniert bei mir am zuverlässigsten.
  • gerade auch in Kombination, dass im URL-Feld des jeweiligen Eintrags dann nur die Domain hinterlegt wird.
  • Das bedeutet ohne Pfade und sonstige Parameter!
  • Auffindbar derzeit unter: Einstelllungen->Automatisches Ausfüllen
• Zwischenablage leeren würde ich auf einen kurzen Zeitraum setzen, z.B. auf 30 Sekunden.
  • soweit ich mich erinnere ist der Standard niemals.
  • Auffindbar derzeit unter: Einstelllungen->Sonstiges

Leider muss die Einstellung in jedem Client einzeln gesetzt werden (Browser-Plugin, Smartphone-App usw.)

Admin-Seite

Die Admin-Seite würde ich aus Sicherheitsgründen ausschalten bzw. ausgeschaltet lassen. Wenn ich die Funktionalität doch einmal benötige, schalte ich sie kurzzeitig ein, auch wenn es zwei kurze Downtimes bedeutet.

Verständnis entwickeln

Als ich vaultwarden aufgesetzt habe, hatte ich zuerst zwei Test-Accounts angelegt. Danach habe ich eine “Organistation” und mehrere “Sammlungen” angelegt. Mit diesen zwei Accounts konnte ich dann ein besseres Verständnis der beiden Begriffe und des Berechtigungssystems erlangen.

EMail

Das ist für mich persönlich so ein großes Unlust-Thema und PITA.
Seit ich online bin, lagere ich diesen Service als Dienstleistung aus. Ich klicke mir irgendwo eine Domain und einen E-Mail-Speicherplatz und lasse das Menschen machen, die mehr Ahnung von dem Thema haben als ich. Aktuell bin ich seit Jahren sehr glücklich bei uberspace.
Ich habe bei denen mehrere Accounts (asteroid genannt). Dort lassen sich ohne Zusatzkosten Domains “aufschalten”. In deren verfügbarer Dokumentation (manual) sind die benötigten Befehle recht gut beschrieben, sofern man sich an die Kommandozeile herantraut. In deren Dokumentationsbereich namens Uberlab sind weitere Möglichkeiten beschrieben, zusätzliche Software zu installieren; inkl. Update-Schritten. Vielfach ist es nur ein copy&paste von vorgefertigten Befehlen.

Idee und Ausblick

Soweit ein Einblick in mein Setup und so wie es für mich funktioniert und bewährt hat. Ich habe versucht es kurz zu halten und bei ausufernden Themen mit Verweisen zu arbeiten.

Wer mag, kann die für sich passenden Informationen herausziehen und die eigenen Verhältnisse und Anforderungen anpassen oder ein Konzept zu entwickeln.

Auf der Wunschliste steht noch die Generierung der TLS-Zertifikate per Let’s-Encypt, da muss ich mich nochmal einlesen, wie ich dies umsetze, wenn die Systeme nicht von außen erreichbar sind.

Changelog

Welche Artikel haben sich geändert?

Warum diese Seite?

Ab und zu ändere Artikel oder korrigiere Rechtschreibfehler. Manchmal füge dort weitere Informationen hinzu, die keinen eigenen Blogartikel wert sind. Damit ich diese Änderungen kommunizieren kann, erstelle ich ab und zu solche Übersichtsseiten, wie Ihr hier sie gerade lest. Eine tabellarische Übersicht der Änderungen mit Verlinkungen auf die jeweiligen Seiten.

Technischer Hintergrund

Den Zeitstempel des Artikel zu ändern, bringt RSS-Feeds durcheinander und es ist dann ggf. auch nicht gleich ersichtlich, was geändert worden ist. Da ich sowieso git commit Messages schreibe, kann ich die auch gleich auswerte, als Tabelle erstellen. Ein Script nimmt dann diese Tabelle und erstellt mit einem Template eine neue Seite im Blog.

Zur Massenbearbeitung von PDF-Dateien gibt es das schöne Tool pdftk oder auch manchmal pdftk-java genannt.

Mit diesem Tool lassen sich z.B. PDF-Dateien in Einzel-Dateien aufsplitten, mehrere PDF-Dateien zu einer Gesamtdatei zusammenfassen, Seiten rotieren etc.

Um nicht immer Suchmaschinen bedienen zu müssen, erfolgt hier eine Auflistung meiner häufig genutzten Parameter.

Aufruf

Wenn pdftk ohne Parameter aufgerufen wird, gibt es eine Kurzhilfe mit einer groben Auflistung der Parameter.

pdftk --help ist zwar schon etwas geschwätziger, aber ein paar Spezialfälle fehlen mir da; diese folgen nun.

Zusammenfügen

Kommando: cat

1pdftk dateien-*.pdf cat output gesamtdatei.pdf

Trennen

Kommando: burst

1pdftk gesamtdatei.pdf burst output praefix_

Ergibt dann bei einer vierseiten PDF-Datei:

doc_data.txt
praefix_pg_0001.pdf
praefix_pg_0002.pdf
praefix_pg_0003.pdf
praefix_pg_0004.pdf

Seiten abwechselnd rotieren

1pdftk A=PdfDatei.pdf shuffle AoddWest AevenEast output PdfDatei_Rotiert.pdf

Einzelseite rotieren

Kommando: burst

Der Parameter setzt sich zusammen aus

• der Seitenzahl, wo begonnen werden soll.
• der Seitenzahl, bis zu welcher Seite gedreht werden soll
• der Drehrichtung

zusammen.

Beispielaufruf

Ab Seite 1 bis zur letzten Seite (zum Ende) um 270 Grad:

1pdftk PdfDatei.pdf rotate 1-endwest output rotiert.pdf

Alternativen:

1pdftk A=out.pdf shuffle Aoddsouth output rotiert.pdf

1pdftk A=out1.pdf B=out12.pdf cat A1-3 B1-7 A8 output rotiert.pdf 

Vor ein paar Tagen habe ich mal wieder an einer Ansible-Rolle geschraubt und wurde beim Ausführen von ansible-playbook mit folgender Fehlermeldung begrüßt:

Source /root/.ansible/tmp/ansible-tmp-1746359478.4110813-9236-74562322926004/.source not found

Das war seltsam, weil ich nur das Modul ansible.builtin.copy aufgerufen hatte, was vorher auf anderen Rechner problemlos funktioniert hatte.

Und jetzt?

Die Fehlermeldung

TASK [meine_rolle : inst | linux_install | Copy Binaries] *************************************************************************************************************************************************************************************************
failed: [t24] (item=/pfad/zur/datei/foo) => {"ansible_loop_var": "item", "changed": false, "checksum": "884109935b2a432cb6edb5003c4ac5adc9462cbe", "item": "/pfad/zur/datei/foo", "msg": "Source /root/.ansible/tmp/ansible-tmp-1746359476.4233594-9236-186673184030632/.source not found"}
failed: [t24] (item=/pfad/zur/datei/bar) => {"ansible_loop_var": "item", "changed": false, "checksum": "9e184000b3f2541c07f62dcbf8bf7e8927757bec", "item": "/pfad/zur/datei/bar", "msg": "Source /root/.ansible/tmp/ansible-tmp-1746359478.4110813-9236-74562322926004/.source not found"}

Die Task

 1- name: inst | linux_install | Copy Binaries
 2  ansible.builtin.copy:
 3    src: '{{ item }}'
 4    dest: '{{ meine_rolle_install_path }}'
 5    owner: 'root' 
 6    group: 'root' 
 7    mode: '0755'
 8  become: true
 9  loop:
10    - '/pfad/zur/datei/foo'
11    - '/pfad/zur/datei/bar'

Das Problem

Ich bin per ssh auf die betroffene Maschine gesprungen und musste feststellen, dass das Verzeichnis /root/.ansible/tmp/ auf der Remote-Maschine wirklich nicht da war. Auch wurde das /root Verzeichnis (meiner Erinnerung nach) nicht angefasst. Ein manuelles Erstellen des Verzeichnisses brachte keine Besserung.

Zuerst kam mir keine Idee und daher hatte ich diverse Suchmaschinen befragt. Ich erwähnte es eingangs: “auf anderen Rechner problemlos”. Nun erinnerte ich mich, dass bei mir eine andere Distribution Einzug gehalten hat, die auf Ubuntu basiert.

Die Lösung

Hier scheint das Modul ansible.builtin.copy: mit dem become: true laut meinen Recherchen das Problem zu sein.

Beheben lies sich dies, in dem ich in der ansible.cfg folgende Option gesetzt habe:

1remote_tmp = /tmp/ansible_tmp

Ich hab das Playbook dann noch mit einem Host, der unter einem Debian 12 läuft, probiert und auch da lief das Playbook anstandslos durch. Ich lass das jetzt so.

Welche Artikel haben sich geändert?

Warum diese Seite?

Ab und zu ändere Artikel oder korrigiere Rechtschreibfehler. Manchmal füge dort weitere Informationen hinzu, die keinen eigenen Blogartikel wert sind. Damit ich diese Änderungen kommunizieren kann, erstelle ich ab und zu solche Übersichtsseiten, wie Ihr hier sie gerade lest. Eine tabellarische Übersicht der Änderungen mit Verlinkungen auf die jeweiligen Seiten.

Technischer Hintergrund

Den Zeitstempel des Artikel zu ändern, bringt RSS-Feeds durcheinander und es ist dann ggf. auch nicht gleich ersichtlich, was geändert worden ist. Da ich sowieso git commit Messages schreibe, kann ich die auch gleich auswerte, als Tabelle erstellen. Ein Script nimmt dann diese Tabelle und erstellt mit einem Template eine neue Seite im Blog.

Welche Artikel haben sich geändert?

Warum diese Seite?

Ab und zu ändere Artikel oder korrigiere Rechtschreibfehler. Manchmal füge dort weitere Informationen hinzu, die keinen eigenen Blogartikel wert sind. Damit ich diese Änderungen kommunizieren kann, erstelle ich ab und zu solche Übersichtsseiten, wie Ihr hier sie gerade lest. Eine tabellarische Übersicht der Änderungen mit Verlinkungen auf die jeweiligen Seiten.

Technischer Hintergrund

Den Zeitstempel des Artikel zu ändern, bringt RSS-Feeds durcheinander und es ist dann ggf. auch nicht gleich ersichtlich, was geändert worden ist. Da ich sowieso git commit Messages schreibe, kann ich die auch gleich auswerte, als Tabelle erstellen. Ein Script nimmt dann diese Tabelle und erstellt mit einem Template eine neue Seite im Blog.

Derzeit sichere ich meine Nextcloud-Instanz mit einem dateibasierten Backup-Tool, sowie einem Dump der Datenbank. Letztens hatte ich in meinem Umfeld jemanden, der ein paar Kontakte aus Versehen gelöscht hat. Nun können die vermissten Kontakte zwar aus dem Dump der Datenbank herausgepfriemelt werden, schön ist das aber nicht.

Nach etwas Recherche bin ich auf einen recht simplen curl-Befehl gestoßen, der eine .ics bzw .vcf-Datei heraus exportiert.

Dies ist dann doch aus meiner Sicht etwas einfacher. Sofern z.B. alle Kontakte gelöscht worden sind, reicht dann sogar ein Doppelklick auf die Datei und alle Kontakte werden wieder importiert. Dies sollte wesentlich stressfreier sein.

Als Familien-Admin möchte ich den Export für alle Nutzenden der Instanz regelmäßig machen; daher habe ich mir eine Ansible-Rolle dafür gestrickt.

Das Grundprinzip und die Konfiguration der Rolle möchte ich in diesem Artikel beschreiben.

Auf die Bedienung und Verwendung von Ansible möchte ich hier nicht eingehen, da setze ich entsprechendes Wissen voraus.

Zum Zeitpunkt des Artikel ist die Nextcloud-Version 31 aktuell. Die Pfade, die in der Ansible-Rolle verwendet werden, orientieren sich an diesem Stand. Sollten sich die Subpfade der URLs ändern, müsste die Rolle angepasst werden.

Überblick

Um die Rolle zu verstehen, ist es womöglich am einfachsten, sich das Vorgehen zu verdeutlichen, wenn ein manuelles Backup angefertigt werden soll. Dies soll hier in den nächsten Abschnitten beschrieben werden, um dann im nächsten Schritt zur Automatisierung zu kommen.

Händisches Backup

Melde dich als ersten Schritt in Deiner Nextcloud an.

Kontakte

• Wähle den Reiter Kontakte.
• Gehe nach unten auf der linken Seite und klicke da auf Kontakte-Einstellungen.

• Navigiere jetzt zu den Allgemeinen Einstellungen.
• Beim gewünschten Adressbuch auf die drei Punkte klicken (1)
• und auf Herunterladen klicken (2).

• Voilà! Es wird eine .vcf-Datei mit einem aktuellen Datumsstempel zum Download angeboten.

Kalender

• Wähle den Reiter Kontakte.
• Wähle Deinen Kalender aus, den du exportieren möchtest.
• Fahre Deine Maus etwas nach rechts bis das Stift-Icon erscheint (1) und klicke auf diesen.

• Im nächsten Dialog Kalender bearbeiten gibt es dann eine Schaltfläche mit der Beschriftung Exportieren.

• Voilà! Es wird eine .ics-Datei mit einem aktuellen Datumsstempel zum Download angeboten.

Automatisierung

Jetzt wollen wir das ganze automatisieren; dafür gibt es meine Ansible-Rolle export_nextcloud. Die Rolle findet Du auf meinem Gitlab-Account.

Die Rolle solltest Du auf einem Linux-Host deployen, dem Du vertraust und der Zugriff auf die Nextcloud hat.

Minimale Angaben

Variable export_nextcloud_url

Zunächst benötigt die Rolle die URL, worunter die Nextcloud-Instanz erreichbar ist. Dazu hinterlegst Du diese in der Variable export_nextcloud_url als Hostvariable, wo das Export-Script später laufen soll.

Beispiel:

1export_nextcloud_url: "https://meine.nextcloud.instanz"

Variable export_nextcloud_user

Jetzt brauchst Du eine Liste mit einem oder mehreren Usernamen, die du sichern möchtest. Zusätzlich ein Passwort und einen Zeitpunkt, wann das Export-Script laufen soll.

Empfehlung

Statt des regulären Passwortes für Deinen User, empfehle ich die Generierung eines Personal Access Token kurz “PAT”.

Die Einrichtung eines PAT beschreibe ich in einem anderem Blog-Artikel.

Als dritten Parameter wird noch der Zeitstempel benötigt, wo der Export laufen soll. Mit dieser Angabe wird später eine SystemD-Timer-Unit erstellt.

Die Syntax dieses Attributes folgt dem Parameter on_calendar von systemd.unit(5). Aus jeden username wird eine extra SystemD-Timer-Units erstellt, nach folgendem Muster:

• export_nextcloud-user1.timer
• export_nextcloud-user2.timer

Die Konfiguration sieht am Ende zum Beispiel so aus:

1export_nextcloud_user:
2  - username: "user1"
3    password: "password1"
4    on_calendar: '*-*-* 03:00'
5  - username: "user2"
6    password: "password2"
7    on_calendar: '*-*-* 03:01'

Optionale Angaben

Variable export_nextcloud_script_path

Die nächste Variable bestimmt, wohin das Script kopiert werden soll. Der Standardpfad lautet /opt/export_nextcloud.

Variable export_nextcloud_backup_path

Über diese Variable kann bestimmt werden, wohin die exportierten Kalender- und Kontakte-Dateien hingeschrieben werden sollen. /backup/nextcloud_export lautet hier der Standardpfad.

Hier entsteht pro Username eine Kalender- und eine Kontakte-Datei mit dem Username nach folgendem Muster:

• kalender-${username}.ics
• kontakte-${username}.vcf

Und ja, ich war zu faul, noch ein extra Aufräum-Mechanismus zu schreiben. Für die Versionierung ist bei mir mein Backup-Programm zuständig ;-) . Das kann mein Sicherungsprogramm viel effizienter als ich. Wenn ich an ältere Versionen herankommen möchte, muss ich die Sicherung bemühen; ich spare mir dadurch zusätzliche Fehlerquellen und Abhängigkeiten.

Variable export_nextcloud_prometheus_path

Diese Variable legt den Pfad fest, wo die Prometheus-Statistiken hingeschrieben werden.

Variable export_nextcloud_extra_curl_options

Diese Variable habe ich am 03.10.2025 eingeführt, weil der zugrunde liegende curl sich am selbst-signierten Zertifikat meiner Nextcloud-Instanz störte. Mit dem Parameter -k oder --insecure lässt sich das aber übersteuern. Dies erforderte allerdings eine Anpassung des Scriptes.

Nun können weitere Parameter über diese Variable optional mitgegeben werden.

Im unteren Beispiel Ansible Playbook fügt ihr an den einen Task folgende zwei Zeilen an.

1  vars:
2    export_nextcloud_extra_curl_options: "--insecure"

Ansible Playbook

Jetzt kannst Du die Rolle in ein Ansible-Playbook einbinden.

Ein minimales Beispiel wäre:

1---
2
3- name: Setup export_nextcloud
4  hosts: export_nextcloud
5  roles:
6    - export_nextcloud

Backup

Im Nachgang bzw. nach dem Ausführen der jeweiligen SystemD-Timer-Unit, empfehle ich noch ein Backup des Verzeichnisses wo die exportierten Dateien liegen. Das Verzeichnis kannst zum Beispiel dateibasiert mittels deiner präferierten Wunsch-Backup-Software gesichert werden. Ich selbst habe dazu die Pfade in meinem Sicherungsscript aufgenommen; hier verwende ich restic seit längerem erfolgreich.

Fertig.

Im Grunde war es das auch schon. Viel Spaß beim Benutzen. Der Source-Code der Rolle liegt in meinem Gitlab-Account.

Changelog

Soll auf Daten in einer Nextcloud zugegriffen werden, erfolgt dies häufig mittels der Kombination aus Username und Passwort. Erfolg dieser Zugriff jedoch mittels mobilen Geräten oder automatisiert aus anderen Diensten, ist es meist eine schlechte Idee, das Passwort großflächig zu verteilen. Mobile Geräte haben manchmal die Eigenschaft verloren zu gehen oder gestohlen zu werden. Weiterhin werden Dienste oder Geräte kompromitert oder unterstützen vielfach keine Zweifaktor-Authentisierung (2FA). Hierbei hilft die Generierung eines Personal Access Token kurz “PAT”.

Ein PAT hingegen sollte nur genau einem Dienst oder einem Gerät zugeordnet werden. Das jeweilige PAT und kann dann bei Verlust oder Kompromittierung über den Hauptzugang gesperrt werden, so dass der Zugriff feingranular entzogen werden kann. Vorteil: Das “Hauptpasswort” und die anderen PAT müssen nicht geändert werden und können bestehen bleiben.

Erstellung

Hinweis

Zum Zeitpunkt des Artikel ist die Nextcloud-Version 31 aktuell.

Zur Erstellung eines PAT melde dich als ersten Schritt in Deiner Nextcloud an.

Rechts oben sollten Deine Initialen oder Dein Profilbild stehen, dort bitte drauf klicken und es erscheint ein weiteres Pull-Down-Menü, wo du auf Einstellungen klickst.

Danach gibt es eine Übersicht von Deinem Profil und links eine Menüstruktur.

Mit Klick auf den Menüpunkt Sicherheit geht es jetzt weiter. Unterhalb des Abschnittes, findest Du schon eine Auflistung der schon aktiven Zugriffe unterhalb von Geräte & Sitzungen.

Am Ende der Tabelle (sofern sie existiert) gibt es eine Eingabemaske mit App-Name und dem Button “Neues App-Passwort erstellen”.

Trage hier bitte einen sinnvollen Namen ein, so dass Du das erstellte PAT später wieder zuordnen kannst. Ein sprechender Name erleichtert Dir später die Suche, falls Du einem Gerät oder Dienst den Zugriff entziehen möchtest.

Wichtig

Wenn Du auf das kleine Fenster wieder schließt, wird der Dialog geschlossen. Es gibt keine Möglichkeit, das Passwort nochmal anzuzeigen. Daher ist es wichtig, sich das Passwort an einem sicheren Ort zu notieren. Hast Du dies vergessen, musst Du ein neues PAT anlegen.

Das generierte PAT ist im Grunde nichts anderes ist, als ein extra Passwort. Notiere Dir jetzt das generierte Passwort an einer sicheren Stelle, übertrage es z.B. in Deinen Passwort-Safe. Das Passwort ist sofort aktiv und kann verwendet werden. Der gewohnte Benutzername bliebt hierbei gleich.

Wenn Du z.B. den Nextcloud-APP auf deinem Smartphone einrichten möchtest, hast Du jetzt die Chance mit Klick auf QR-Code für mobile Apps anzeigen Dir einen QR-Code anzeigen zu lassen, den Du mit der Nextcloup-App abscannen kannst und die Tipparbeit und Tippfehler ersparst.

Ist das Passwort in der Anwendung hinterlegt, kann der Dialog mit Klick auf das kleine X geschlossen werden.

Löschen

Das Löschen eines PAT wird auf der selben Seite in den Profil-Einstellungen vorgenommen werden. Über die drei Punkte bekommst Du ein Pulldown-Menü.

Hier kannst Du das PAT Widerrufen. Sofern der Client dies Unterstützt (z.B. die Smartphone-App) können via Klick auf Gerät löschen sogar die lokal vorgehaltenen Daten gelöscht werden.

Notizensammlung

Dinge, die ich mir bei systemd nicht merken kann. Und bevor ich wieder Suchmaschinen oder man-Pages bemühen muss, schreibe ich sie hier lieber nieder.

Im Hintergrund starten

Parameter --no-block verwenden, damit der Prompt gleich wieder kommt und nicht auf Beendigung gewartet wird; praktisch für Backup-Jobs außerhalb der Reihe.

1systemctl start resticprofile_full-backup.service --no-block

Timer in SystemD

wird gerne von snap-Paketen genutzt, die keinen cronjob installieren.

Auflistung

1systemctl list-timers [--all]

In der Auflistung steht dann auch der timer, wo die Zeitdefinition drin steht und welche start-Unit anzieht.

Verzeichnis vielfach: /etc/systemd/system/foo.timer

Als Ersatz für at

1systemd-run --user --on-calendar="2024-12-28 10:31:19" Befehl Parameter....

ggf. sudo davor für root.

failed Units

Alle auflisten

1systemctl status --failed

Resetten

1systemctl reset-failed <unit-name>

Auskunft über pids

1systemctl status <pid>

Changelog

Das Tool starship hatte ich schon mal in einem Blog-Artikel erwähnt und genauer beschrieben:

Der Standard-Prompt ist zu langweilig? Die Befüllung der Variablen PS1 ist zu kompliziert und unflexibel? Es sollen mehr Informationen dargestellt werden?

Kein Problem, ich habe jetzt das Tool Starship für mich entdeckt…

Vor einiger Zeit habe ich die Installation des Tool inklusive mit meiner Konfiguration in eine Ansible-Rolle gegossen.

Die Rolle

Diese Ansible-Rolle findet sich auf meinem persönlichen gitlab-Account im Unterordner ansible-roles des Projektes.

Die Rolle muss nur in das roles-Verzeichnis der jeweiligen Ansible-Playbooks kopiert werden. Danach kann sie in einem Playbook verwendet werden, wobei mindestens die Namen der Accounts angegeben müssen, wo die Rolle installiert werden soll. Ein Beispiel-Playbook findet sich in der Datei README.md des Unterordners der Rolle.

Rollen-Variable: starship_user

Die Namen der Accounts, wo die Rolle installiert werden soll, müssen als Liste angegeben werden.

1starship_user:
2  - user1
3  - user2

Die Beschreibung der Rollen-Variablen findet sich aber ebenfalls noch einmal in der Datei README.md inklusive weiterer Erklärungen.

Schwierigkeiten: Timeout

Allerdings stieß ich auf die Schwierigkeit bei einem meiner Rechner, dass das git-Kommando mehr als die vordefinierten 500 Millisekunden brauchte.
Daher habe ich die Variable starship_extra_options eingeführt, wo ich das command_timeout höher setzen konnte:

1starship_extra_options: 'command_timeout = 1000'

Theoretisch lassen sich da noch mehr individuelle Optionen setzen, sofern benötigt.

Beispiel:

1starship_extra_options: |
2  command_timeout = 1000
3  
4  [container]
5  format = '[$symbol \[$name\]]($style) '

Minimales Playbook

Ein minimales Playbook sieht beispielsweise so aus:

1---
2
3- name: Setup starship
4  hosts: linuxhosts
5  roles:
6    - starship
7  vars:
8    starship_user:
9      - user1

Vorbei sich die Variable starship_user natürlich noch als Host- oder Gruppenvariable definieren lässt, womit das Playbook noch kleiner wird.

Der alte Blog-Artikel findet sich hier, dort wird das Tool noch einmal etwas genauer erklärt.

Eine kleine Sammlung an Snippets, die ich immer wieder brauche, mir aber nicht merken kann.

Zu welchem Paket gehört die Datei?

1dpkg-query -S /bin/bash

Zeige installierte Paket-Version an

Zeigt ebenfalls an, welche Versionen verfügbar sind. Dies sind ältere, als auch neuere, die noch nicht installiert sind.

1apt-cache policy rabbitmq-server

Zeige alle installierten Versionen an

1apt list --installed

Zeige alle Pakete an, die aktualisiert werden können

1apt list --upgradable

Zeige alle verfügbare

1apt list --all-versions

Zeige die enthaltenden Dateien eines deb-Paketes an

1dpkg -c percona-release_latest.generic_all.deb

Tipps und Tricks zur SecureShell

Erzeugen des öffentlichen Schlüssels aus dem privaten Schlüssel

Um einen fehlenden public key aus dem private key zu generieren hilft folgendes Linux-Kommando:

1$ ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub
2Enter passphrase:

Halten der Verbindung

~/.ssh/config

1Host *
2  ControlPath ~/.ssh/connections/%C
3  ControlMaster auto
4  ControlPersist 30m

Aufteilen der Configs

~/.ssh/config

1Include config.d/*

Port-Forwarding

1ssh -L [<locale ip>:]<lokaler Port>:<zielhost>:<zielport> [user@]zielhost

Jump Host

1ssh -J jumphost <user>@<zielhost>

Kein hinzufügen zur ~/.ssh/known_hosts

Nützlich z.B. beim Arbeiten mit virtuellen Maschinen unter QEMU mit virt-manager:

1Host 192.0.2.*
2  StrictHostKeyChecking no
3  UserKnownHostsFile=/dev/null

Dann kommt folgende Meldung nicht mehr

1The authenticity of host '192.0.2.28 (192.0.2.28)' can't be established.
2ED25519 key fingerprint is SHA256:gPyKupGXLCfzRrq8s8kfyL0Kc9HW/4L07VsWJgr5s9U.
3This key is not known by any other names.
4Are you sure you want to continue connecting (yes/no/[fingerprint])?

Changelog

Eine kleine Sammlung an bash-Kniffen, Tricks und HowTos.

Diese Unterseite ist bisher ohne durchdachte Sortierung. Werde für Interessierte das Neueste immer oben anfügen.

Boot-Stick erstellen

1sudo dd bs=4M if=/path/to/manjaro.iso of=/dev/sd[drive letter] status=progress oflag=sync

Dateien anlegen via Allokierung

1fallocate -l 10GB meine_grosse_datei

ggf. Parameter -o offset und -n beachten, bei Größenänderung swap-File.

Passwort generieren

1tr -dc A-Za-z0-9 </dev/urandom | head -c 64

Als kleine Script-Version in meinem GitLab-Repository

Datumsberechnungen

Übermorgen

1date  --date="2 days" +"%d.%m.%Y"

Vorgestern

1date  --date="2 days ago" +"%d.%m.%Y"

Ausgabe von “du”

1du -sk * | sort -n

1du -sb * | sort -n | numfmt --to=iec

Etwas mehr Erklärung hier im Blog-Artikel.

Binary installiert ?

1if ! type "docker-compose" > /dev/null; then
2    echo 'Error: docker-compose is not installed.' >&2
3    show_error_function
4    exit 1
5fi

Eingaben

1read -rp "Hier eine Entscheidungsfrage (j/n): " VARIABLE_WO_DER_INHALT_REIN_SOLL

tabellarische Umformartierung

1echo "a11 b12_Text c13" > /tmp/beispiel
2echo "a21 b22 c23" >> /tmp/beispiel
3column -t /tmp/beispiel

Ausgabe:

a11  b12_Text  c13
a21  b22       c23

Alias

1alias sdf='df -h|egrep -v '\''^(overlay|nsfs|shm|cgroup|tmpfs|debugfs|mqueue)'\'''
2alias smount='mount|egrep -v '\''^(overlay|nsfs|shm|cgroup|tmpfs|debugfs|mqueue)'\'''
3alias dc='docker-compose'
4de() { docker exec -it "$1" bash; }
5alias dpa='docker ps -f status=exited'
6psg() { ps aux | grep "$1" | grep -v grep; }
7alias t='ls -lrt --color=auto'

Prompting

1PS1="[\u@\H:\w]\$ "

Ggf \n einstreuen für extra Zeile.

Verzeichniswechsel

Mal wieder beim Verzeichniswechsel vertippt?

Die bash speichert das letzte Verzeichnis, in welchem man sich befunden hat in der Variable $OLDPWD.

Ein

1cd $OLDPWD

bringt einen also wieder zurück ins alte Verzeichnis.

Kürzer wird es mit:

1cd -

aktuelles Verzeichnis

Das aktuelle Verzeichnis kann man sich mit pwd ausgeben lassen.

1pwd

1erde:~$ cd /etc
2erde:/etc$ cd /var
3erde:/var$ cd -
4/etc
5erde:/etc$ cd $OLDPWD
6erde:/var$

Schreiben auf STDERR

1echo "Dieser Text erscheint auf STDERR" >&2

Fehlermeldungen umleiten

in Log-Datei

1./foo.sh bar/* >foo-bar.log  2>&1

wegwerfen

1./foo.sh > /dev/null 2>&1

Backup einer Datei

1cp -p foo{,.bak}

ist dasselbe wie

1cp -p foo foo.bak

Spezial-Variablen

Es gibt ein paar Spezialvariablen in der bash, die einem das Tippen ersparen.

Umgebungsvariablen

in Scripten

$* Alle dem Programm übergebenen Parameter, durch Leerzeichen getrennt.

1$*=$1 $2 $3 $4 ...

"$*" Alle dem Programm übergebenen Parameter in Anführungszeichen, durch das 1. Zeichen der Variablen $IFS getrennt.

1"$*"="$1c$2c$3c$4"...

$@ Alle dem Programm übergebenen Parameter, durch Leerzeichen getrennt.

1$@=$1 $2 $3 $4

"$@" Alle dem Programm übergebenen Parameter, einzeln in Anführungszeichen eingeschlossen und durch Leerzeichen getrennt.

1"$@"="$1" "$2" "$3" "$4" ...

$# Anzahl der übergebenen Parameter

Historie

!$ letzter Parameter des vorhergehenden Befehls

1$ ls -l foo
2$ echo !$
3echo foo
4foo

!! letzter Befehl inkl. aller Parameter

Mal wieder sudo vergessen? Kein Problem:

1$ ein script
2$ sudo !!

Beispiel

1$ ls -l /etc/apt/apt.conf.d/20auto-upgrades 
2$ cd !$:h
3cd /etc/apt/apt.conf.d

Eselsbrücke: RegEx-like

Beispiel Befehlssuche

1$ echo foo bar baz
2foo bar baz
3$ echo !echo:2
4echo bar
5bar

Nur ausgeben:

1$ echo foo bar baz
2foo bar baz
3$ echo !echo:2:p
4echo bar

schnell in bash mal würfeln

1let zufallszahl=$RANDOM%6
2echo $zufallszahl

Der Standard-Prompt ist zu langweilig? Die Befüllung der Variablen PS1 ist zu kompliziert und unflexibel? Es sollen mehr Informationen dargestellt werden?

Kein Problem, ich habe jetzt das Tool Starship für mich entdeckt. Es ist schnell installiert und auch recht simpel konfiguriert. Wie das funktioniert, habe ich im Nachfolgenden mal aufgeschrieben.

Alte Welt: PS1-Variable

Meine PS1-Variable, die ich in der ~./.bashrc setze, sah bisher immer so aus:

1PS1='\[\033[01;32m\][\u@\h\[\033[01;37m\]:\w\[\033[01;32m\]]\$\[\033[00m\] '

Das sieht dann z.B. so aus:

1mag@rainern:~/homepages/rainerrose.de

Das Ziel

Starship bietet die Möglichkeit noch weitere Informationen einblenden zu lassen, z.B.:

• aktueller Name des git-Branches
• virtuelles Enviroment unter Python
• aktueller Name des Openstack-Projekt

Im folgenden Screenshot sieht man die potentiellen Möglichkeiten.

Aus Gründen musste ich ein paar Informationen blurren.

Installation

Schritt 1: Binary installieren

Die Installation ist recht einfach und gut auf der Projekt-Homepage beschrieben.

Schritt 2: Aktivieren

Je nach gewählter Shell, muss Starship jetzt noch gestartet werden.

Für die bash, die ich verwendet ist dies ein

1echo 'eval "$(starship init bash)"' >> ~/.bashrc

Alle anderen Shells sind gut auf der Projekt-Webseite beschrieben.

Konfiguration

Zu erst erstellst Du Dir am besten eine leere Konfigurationsdatei.

1mkdir -p ~/.config && touch ~/.config/starship.toml

danach kannst Du meine Konfigurationsdatei weiter unten auf dieser Seite als Vorlage nehmen und sie anpassen.

Auf der Projekt-Webseite sind es weitere, gute Beispiele aufgeführt. In der Regel kannst Du die Beispiele aus der Doku 1:1 in Deine Konfigurationsdatei übernehmen und musst sie ggf. nur etwas anpassen.

Nacharbeiten

Auf meinen Manjaro-Systemen, welche ja auf Arch Linux basieren, musste ich das Fontspaket extra/noto-fonts-emoji nachinstallieren, weil sonst einige Glyphen nicht dargestellt werden konnten.

Um zu testen, ob es Probleme mit einigen Symbolen bzw. Emojis gibt, reichen folgende zwei Befehle:

1echo -e "\xf0\x9f\x90\x8d"
2echo -e "\xee\x82\xa0"

Das erste Symbol sollte eine Schlange darstellen, das zweite ein Strich mit einem Pfeil der daneben läuft.

In der FAQ auf der Projekt-Seite steht es nochmal genauer.

Fertig

Beim nächsten Start einer bash oder das Sourcen der ~/.bashrc sollte Dir den Prompt im neuen Gewand präsentieren.

Dank

Mein Dank geht an Kevin für die Tipps und den Hinweis auf dieses Tool.

Meine Konfig-Datei

 1# https://starship.rs/config/
 2# Get editor completions based on the config schema
 3"$schema" = 'https://starship.rs/config-schema.json'
 4
 5# Inserts a blank line between shell prompts
 6add_newline = true
 7
 8[directory]
 9truncate_to_repo = false
10truncation_length = 0
11
12[git_metrics]
13added_style = 'bold blue'
14format = '[+$added]($added_style)/[-$deleted]($deleted_style) '
15
16[git_status]
17conflicted = '🏳'
18ahead = '🏎💨'
19behind = '😰'
20diverged = '😵'
21up_to_date = '✓'
22untracked = '🤷'
23stashed = '📦'
24modified = '📝'
25staged = '[++\($count\)](green)'
26renamed = '👅'
27deleted = '🗑'
28
29[openstack]
30format = 'on [$symbol$cloud(\($project\))]($style) '
31style = 'bold yellow'
32symbol = '☁ '
33
34[hostname]
35ssh_only = false
36format = '[$ssh_symbol](bold blue)[$hostname](bold red):'
37trim_at = '.companyname.com'
38disabled = false
39
40[username]
41style_user = 'white bold'
42style_root = 'black bold'
43format = '[$user]($style)@'
44disabled = false
45show_always = true
46aliases = { "corpuser034g" = "matchai" }
47
48[kubernetes]
49disabled = false
50format = '[$symbol$context( \($namespace\))]($style) '
51
52[[kubernetes.contexts]]
53context_pattern = ".*_(customers|infrastructure)_(?P<cluster>[\\w-]*)_(tooling|bootstrap).*"
54context_alias = "$cluster"
55
56[env_var]
57style = 'red bold'
58variable = 'KUBECONFIG'

Ansible-Rolle

Update: 27.12.2024

Inzwischen habe ich für die Installation eine Ansible-Rolle geschrieben. Den dazugehörigen Blog-Artikel findet Du hier.

Kubernetes Context (lange Namen)

Update 29.03.2026

Aktuell arbeite ich mit längeren Namen im context was zu sehr langen Zeilen führt, wenn man folgende Format-Syntax wählt:

1format = 'on [☸ $user on $context](dimmed green) '

Weiterhin habe ich starship auf die Version 1.24.2 aktualisiert, dort kann Pattern-Matching verwendet werden.

Ich habe also oben im Abschnitt kubernetes das Format geändert und die beiden Abschnitte kubernetes.contexts und env_var hinzugefügt.

Über den context_alias kann ich nun alles für mich nicht relevante wegschneiden. Im Grunde wird mir jetzt nur noch der Name des Clusters angezeigt.

Beispiele:

• cluster-api
• foo
• bar

Changelog

Alles was nicht so recht in eine Kategorie passt oder wo ich zu faul war zu kategorisieren. :-D

curl mit IPv6

1curl  "http://[ipv6:addresse]:port/"

root passwort wieder löschen

1passwd -dl root

Magic Sys Key

1echo s > /proc/sysrq-trigger
2echo u > /proc/sysrq-trigger
3echo b > /proc/sysrq-trigger

Und im Falle von Turnschuhnetzwerk und direkt vor dem Rechner geht das auch mit:

1ALT-PrintScr-S
2ALT-PrintScr-U
3ALT-PrintScr-B 

XUbuntu auf neues Distro-Upgrade checken

1do-release-upgrade -c

resolv.conf wird immer überschrieben

Nach Änderung des DNS-Servers wird die /etc/resolv.conf immer wieder überschrieben?

1systemctl restart NetworkManager.service

Erst mal alle Interfaces anzeigen:

1nmcli -p connection show

In diesem Fall half, das Interface neu hochzufahren

1nmcli c up enp0s8

Netzwerkkarten-Konfiguration

1nmtui
2systemctl restart NetworkManager.service
3ip link set enp0s8 down
4ip link set enp0s8 up

Ignore case bei less

1. im Befehlsmodus -i
2. gleich als Parameter aufrufen less -i

Eben mal schnell konvertieren

Eben mal schnell ein Dokument von einem Format ins andere konvertieren? Nicht überall gibt es pandoc oder zum Teil nur in einer veralteten Version. docker hilft hier:

1docker run --rm --volume "`pwd`:/data" --user `id -u`:`id -g` pandoc/latex $*

Benennt man das Script z.B. pandoc.sh lässt es sich zum Beispiel so von Markdown in Dokuwiki umwandeln

1pandoc.sh -f markdown -t dokuwiki index.md

USB-Palm

Wo schließe ich denn meinen USB-Palm an? Das Device heiß: /dev/usb/ttyUSB1

Im Kernel ist es zu konfigurieren als:

USB support ---> USB Serial Converter support ---> USB Serial Converter support
USB Handspring Visor / Palm m50x / Sony Clie Driver

Am besten einfach einen symbolischen Link drauflegen.

Suchen eines Textes in Dateien im aktuellen Verzeichnis

1find . | xargs grep Suchmuster 2> /dev/null

Vergessen, in welches Verzeichnis ein Programm installiert wurde?

1which Programm-Name

liefert den absoluten Pfad, sofern es sich im Suchpfad befindet.

SCSII-ZIP-Drive

Das SCSII-ZIP-Drive erst nach dem booten angeschlossen?

Kein Problem:

1echo "scsi add-single-device 0 0 6 0" > /proc/scsi/scsi

und mit

1mount -t dateisystem /dev/sd?4 /mnt

ins Dateisystem einhängen.

Falls das ZIP-Drive die ID 5 hat, einfach oben die 6 durch die 5 ersetzen.

Multivolume Archive erstellen

Mit gleichem Dateinamen

erstellen:

1tar -c -L <Größe in MB> -f <arch.tar>

entpacken:

1tar -xMf <archiv.tar>

Mit unterschiedlichem Dateinamen (archiv.tar.aa, archiv.tar..ab, archiv.tar..ac, archiv.tar..<PREFIX>... )

Mit temporärer Datei

erstellen:

1tar -czf <archiv.tar> <Source>; split -b<Größe in MB>M <archiv.tar> <archiv.tar.split.>

Bsp (95MB-Archive):

1tar czf /mnt/zip /home/user; split -b95 archiv.tz archiv.tgz.split.

entpacken:

1cat <archiv.tar.split.>* > archiv.tar

Bsp:

1cat archiv.tgz.split.* > archiv.tgz

ohne temporärer Datei

erstellen:

1tar cz <Source> | split -b<Größe in MB>M <archiv.tar.split.>

Bsp (95MB-Archive):

1tar cz /home/user | split -b95M - archiv.tgz.split.

entpacken:

1cat <archiv.tar.split.*> | tar xz
2``` bash
3
4Bsp: 
5``` bash
6cat archiv.tgz.split.* | tar xz

entpacken unter Dos:

1copy /b archiv.tgz.split.aa+archiv.tgz.split.ab+archiv.split.ac archiv.tgz

Alle Dateien müssen beim copy-Befehl angegeben werden! Danach normal das tgz-Archiv entpacken.

Datei-Endung, Datei-Format verbaselt, gelöscht, unbekannt

mit dem kleinen Progrämmchen file bekommen Sie es heraus.

Beispiel:

1file unbekanntes_Datei-Format
2unbekanntes_Datei-Format: gzip compressed data, deflated, last modified: Wed Jan 16 21:36:14 2002, os: Unix

Attachments in der Mail

Man kennt, es. Attachments landen mal wieder in der Mail.

1. Mail in einer TextDatei abspeichern.
2. Alles vor dem: begin 666 dateiname in der Textdatei löschen.
3. uudecode -oneuer_dateiname codierte_datei_im_bin_format

Fertich. (Version: uudecode (GNU sharutils) 4.2c)

Reguläre Ausdrücke

Reguläre Ausdrücke (Englisch: Regular Expression, RegExp) sind Suchmuster, die mittels Platzhalterzeichen (Jokers) gebildet werden. Sie dienen hauptsächlich zum Suchen nach und dem Ersetzen von Textstellen. Platzhalterzeichen sind Sonderzeichen wie z.B. der Stern (*) unter DOS und Windows. Anders als dort sind in der Unix-Welt Reguläre Ausdrücke mit zahlreichen weiteren Platzhalterzeichen und -sequenzen möglich. Die wichtigsten sind nachstehend aufgeführt:

Reguläre Ausdrücke sind eine (mathematische) Wissenschaft für sich, und es gibt ganze Bücher darüber. Die Anwendungen sind sehr vielfältig.

Strom sparen

Bildschirmschoner sollte man deaktivieren. Sie verbrauchen nur CPU-Zeit (damit Strom) und der Monitor nicht auch noch Strom verbraucht. Der VESA-DPMS-Standard schaltet nämlich den Bildschirm selbstständig ab.

Ob der VESA-DPMS-Standard aktiviert ist, bekommt man durch die Eingabe von:

1xset -q

auf der Kommandozeile zu sehen.

Neben verschiedenen Ausgaben sollte die aktuelle DPMS-Konfiguration eine Antwort geben.

Die Zahlen geben wieder nach welchen Zeitabständen der Monitor die nächste Stufe des DPMS-Standards annimmt.

1xset

mit "DPMS is disabled" sollten Sie:

1xset dpms

oder

1xset dpms 60 120 180

DPMS aktivieren (mit 1, 2 und 3 Minuten).

Wird der xdm verwendet hilft zudem ein Eintrag in: /etc/X11/xdm/Xsetup

Ein Ändern der Zeile von von no in yes.

Unter KDE im Kontroll-Zentrum beim Unterpunkt Energie-Kontrolle.

Unter GNOME ebenfalls im Kontroll-Zentrum.

CONFIG_APM_CPU_IDLE=y in der Kernel-Konfiguration sorgt für einen Stromsparmodus der CPU auf Kernelebene.

letzte Zugriffszeit

Wer die letzte Zugriffszeit von seinen Dateien nicht braucht, kann zudem seine Partitionen mit dem Parameter:

noatime

mounten. Bei Dateien, die nur häufig gelesen werden, und sich eh im RAM befinden, spart man somit einen Schreibzugriff. Bei Laptops mit fast leerem Akku lebenswichtig.

Java(-Applets) unter Firefox

Wenn es noch nicht existiert, plugins-Verzeichnis im Homeverzeichnis des Firefox anlegen. Z.B.

1mkdir ~/.mozilla/plugins

Jetzt nur noch ein Symlink auf die Libary libjavaplugin_oji.so aus dem JRE oder SDK in das plugins-Verzeichnis anlegen.

Ist etwas Sucharbeit, müsste sich aber finden lassen. Die besten Erfahrungen habe ich mit dem JRE von Sun selbst gemacht. Bei vielen Distributionen lässt sich das Java aber inzwischen auch per Paketverwaltung als Plugin systemweit nachinstallieren. Der Ort der Java-Installation lässt sich aus der Umgebungsvariablen JAVA_HOME ablesen.

1echo $JAVA_HOME
2/opt/java/jre
3cd ~/.mozilla/plugins
4ln -s /opt/java/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so libjavaplugin_oji.so

<note tip>Inzwischen nutze ich OpenJDK und das ist genauso gut</note>

Jetzt noch den Firefox neu starten und das Plugin sollte benutzbar sein sowie unter about:plugins auftauchen.

MIME-Type / Encoding einer Datei identifizieren

1file –bi <dateiname>

avidemux meldet defekte avi-Datei

Reparatur mit:

1avconv -i defekt.avi -codec copy reparatiert.avi

IP-Adresse

1hostname -i

md5

md5-Summe in Text-Datei mit Dateinamen reinschreiben

1echo "2317a049f2c83b735e75cad08022247b foo.sh" > foo.md5.txt

Checken mit Download, der dann foo.sh im Dateinamen haben muss.

1md5sum -c foo.md5.txt

Einstellungen von PuTTY exportieren / importieren

1regedit /e "%userprofile%\Desktop\PuttyEinstellungen.reg" HKEY_CURRENT_USER\Software\Simontatham

legt reg-Datei auf den Desktop. Per Doppelklick $IRGENDWO wieder importieren, fertig.

Patch-Files

1diff -u original.txt modifiziert.txt > original.patch

patch -u working.slang.c -i slang.patch

1patch -b -u original.txt -i original.patch

-b für Backup

Changelog

Ein paar kleine Tricks und Kniffe zum Thema Docker.

mysqldump ohne Passwort in Prozessliste

Unter docker werden die Zugangsdaten meist über Umgebungsvariablen weitergegeben.

Arbeitet man jedoch bei mysqldump mit dem Parameter -p gibt es folgende Warnung

mysqldump: [Warning] Using a password on the command line interface can be insecure.

Um jetzt nicht alles nach /dev/null umzuleiten, um noch echte Fehler mitzubekommen, kann man mittels des Parameters --defaults-file das Passwort in eine Datei kopieren. Da sich Zugangsdaten ändern können, empfiehlt es sich, das dynamisch per Script zu erzeugen und das Passwort aus der Umgebungsvariable des Containers auszulesen.

Das Script legt man entweder in ein lokales Volume oder kopiert es via docker cp in den Container.

Das Beispiel-Script zum dynamischen Erzeugen der Credentials-Datei:

1#!/bin/bash
2CRED_FILE="/docker-entrypoint-initdb.d/credentials-root.conf"
3#loeschen
4> "${CRED_FILE}"
5chmod 600 "${CRED_FILE}"
6echo "[client]" >>  "${CRED_FILE}"
7echo "password=${MYSQL_ROOT_PASSWORD}" >> "${CRED_FILE}"

Und noch ein Auszug aus einem Backup-Script:

1docker exec -i  onlyoffice-mysql-server  /bin/bash /docker-entrypoint-initdb.d/gen_cred_config.sh
2(docker exec -i onlyoffice-mysql-server mysqldump  --defaults-file=/docker-entrypoint-initdb.d/credentials-root.conf <weitere Dump-Parameter>  -u root -h<hostname>  | xz -c > "${BACKUPDIR}/dump.sql.xz"

Umgebungsvariable aus Docker-Container auslesen

1docker exec -i onlyoffice-community-server /bin/bash -c '/bin/echo ${MYSQL_SERVER_PASS}'

Unterordner in Docker-Volume ignorieren

Dem docker-compose ein Verzeichnis der lokalen Maschine übergeben, aber einzelne Unterverszeichnisse davon ausnehmen:

Das funktioniert, indem für die auszunehmenden Unterordner ein zweites Volume angeben wird. Volume darf keine Zuordnung mit einem Doppelpunkt enhalten:

1volumes:
2- ./webseite/html:/var/www/html
3- /var/www/html/static/

Im Beispiel bekommt ein Webserver die ganze Webseite übergeben, der Ordner static wird aber aus dem Container benutzt.

Backups & Recover via Volume mounten

reingucken

1docker run -it --rm -v portainer_data:/data:ro -v $(pwd):/backup alpine /bin/sh

sichern

Variante 1

1docker run --rm -v portainer_data:/data:ro -v $(pwd):/backup alpine tar cjvf /backup/data.tbz2 -C /data ./

Variante 2

1docker run --rm -v portainer_data:/data alpine tar cf - -C /data ./ | xz > ./portainer_data_volume.txz

Recover

1docker run --rm -v portainer_data:/data -v ./portainer_data_volume.txz:/backup.tgz alpine tar tJf -C /data /backup.tgz

Volumes

Wie unterscheiden sich nochmal die Bezeichnungen bei den Volumes?

• bind volume
• named volume
• volume

Logfiles auf die Konsole

Logfile-Ausgaben können über STDOUT einfach an das "Terminal" geblasen werden, der dann via docker log <container-name> bzw. Portainer auslesbar ist.

Eine Apache-Konfig conf-enabled/other-vhosts-access-log.conf kann z.B. so aussehen:

1# Define an access log for VirtualHosts that don't define their own logfile
2CustomLog /proc/self/fd/1 vhost_combined

Im Container selbst ist dann der Grund zu sehen, warum das funktioniert:

1# ls -l /proc/self/fd/1
2lrwx------. 1 root root 64 Jul  8 16:19 /proc/self/fd/1 -> /dev/pts/0

Habe ich mal in einem ubuntu-basierten Container gesehen, ziemlich genial.

docker ENTRYPOINT

Weil ich mir nie merken kann, wie wann was gestartet wird, hier mal eine Tabelle:

Zeitzonen

Die lokale Zeitzone lässt sich per Volume-Mount an den Container durchreichen, sofern die Applikation das unterstützt bzw. beachtet.

1    volumes:
2      - /etc/timezone:/etc/timezone:ro
3      - /etc/localtime:/etc/localtime:ro

Pull und Restart

1docker compose up -d --pull always

bzw.

1docker compose up -d --build --pull always

Erstellungsdatum (Created) eines Images abfragen

1docker inspect docker.io/photoprism/photoprism:latest -f "{{ .Created}}"

Changelog

Tipps und Tricks zum Display-Server-Protokoll für X11.

Die Tasten ~ und ^ funktionieren nicht.

Es gibt zwei Möglichkeiten das Problem zu beheben:

Gefolgt vom ~ oder ^ einfach die Leertaste (Space) drücken.

Man editiere als root die Datei /etc/X11/XF86Config

In der Rubrik:

1Section     "InputDevice"
2Driver  "keyboard"
3Identifier  "Keyboard[0]"
4Option  "Protocol" "Standard"
5Option  "XkbLayout" "de"
6Option  "XkbModel" "pc102"
7Option  "XkbRules" "xfree86"

folgende Zeile hinzufügen:

1Option "XkbVariant" "nodeadkeys"

Und nach einem Restart des XFree sollten die Tasten funktionieren.

X11 oder Wayland?

Um herauszufinden ob man noch unter X11 oder schon unter Wayland unterwegs ist, gibt es eine schöne Umgebungsvariable:

1echo $XDG_SESSION_TYPE

Sofern

x11

ausgeben wird, befindet man sich unter gleichnamigen.

Changelog

Bei einem dateibasierten Backup wollte ich nicht immer alle Dateien und Unterverzeichnisse in die Sicherung mit aufnehmen.

Viele Tool wie restic, backup oder auch tar unterstützen eine externe Datei, wo diese Ausnahmen gepflegt werden können.

Allerdings vergesse ich manchmal diese Datei zu pflegen oder die Syntax ist etwas umständlich.

Manchmal möchte man auch nur-mal-eben-schnell ^(tm) ein Verzeichnis ausschließen.

Dafür gibt es die Möglichkeit über eine Datei namens CACHEDIR.TAG zu nutzen.

Voraussetzungen

Diese Datei muss nur zwei Voraussetzungen erfüllen:

1. Der Name der Datei muss CACHEDIR.TAG lauten und zwar in genau der Schreibweise.
2. Der Inhalt der Datei muss einen bestimmten Inhalt haben.

Name der Datei

Der Name der Datei muss genau CACHEDIR.TAG lauten; hierbei ist auch auf Groß- und Kleinschreibung zu achten.

Inhalt der Datei

Am Anfang der Datei muss ein bestimmter Inhalt stehen, er lautet:

1Signature: 8a477f597d28d172789f06886806bc55

So eine Datei kann auch über ein Shell erstellt werden, z.B. so:

1echo "Signature: 8a477f597d28d172789f06886806bc55" > CACHEDIR.TAG

Wichtig hierbei sind nur die ersten 43 Octets der Datei. Danach können noch weitere Informationen kommen, wie z.B. eine kleine Notiz:

1Signature: 8a477f597d28d172789f06886806bc55
2# Diese Datei bedeutet, dass dieses Unterverzeichnis und seine Inhalte vom Backup ausgeschlossen werden.

Aber auch hier muss auf die Groß- und Kleinschreibung beim Inhalt der Datei geachtet werden. Alternativ kann man diese Datei auch nutzen, um eine solche Datei mit Ausnahmen zu erstellen. Diese Datei lässt sich dann z.B. mit dem Programm tar auswerten, um ein Archiv zu erstellen, was diese Verzeichnisse auslässt.

Beispiel:

1find . -name CACHEDIR.TAG | sed -e 's/[/]CACHEDIR.TAG-//g' >/tmp/excludes
2 tar cvf /tmp/backup.tar --exclude-from/tmp/excludes .

Diese Tagging-Konvention lässt sich somit auch für weitere Tools benutzen, auch wenn diese die Konvention noch nicht direkt unterstützen. Definitionen von Ausnahme-Listen unterstützen meist viele Programme und über diesen kleinen Umweg, lässt sich die Tagging-Technik schon jetzt meist ohne Änderung der Programme nutzen.

Die Tools restic und borg können mit dem Parameter --exclude-caches angewiesen werden, die Datei CACHEDIR.TAG zu berücksichtigen. Hier werden dann automatisch die Verzeichnisse mit ihren Unterinhalten vom Backup ausgenommen, die eine solche Datei enthalten.

Beispiel:

1restic -r /backup/backup_home_dirs backup --exclude-caches /home/

Auch Verzeichnisse wie /var/cache lassen sich damit elegant aus dem Backup aussparen.

Ich bin sehr froh dieses entdeckt zu haben, da ich jetzt nicht mehr für jede Ausnahme pflegen muss und dann wieder das Backup-Script irgendwo einchecken oder auf irgendwelche Server verteilen muss. Hier reicht jetzt das triviale Anlegen einer Datei in dem gewünschten Verzeichnis.

Credits

Die ursprüngliche Idee bzw. Vorschlag stammt von Bryan Ford und kann hier nachgelesen werden.

Letztens habe ich ein weiteren Kniff gelernt, der in Zusammenhang mit ssh-Verbindungen hilfreich ist.

Führt man mehrere ssh-Kommandos kurz hintereinander aus, muss für jede Verbindung ein erneuter Kontakt zum jeweiligen Server aufgebaut werden. Das sind zwar immer (je nach Verbindung und Schnelligkeit des Servers) vielleicht nur ein paar Millisekunden, aber zum Beispiel in Zusammenhang mit Ansible-Playbooks kann sich das schon mal addieren und den Lauf durchaus in die Länge ziehen. Zudem ist es nicht sehr ressourcenschonend.

In der ssh-Konfiguration des aktuellen Benutzers (~/.ssh/config) kann jedoch eine Option gesetzt werden, die ein Socket-File aufmacht und somit die Verbindung offen hält. Mit einem gesetzten Timeout von zum Beispiel 30 Minuten, muss nun nicht mehr jedes Mal eine neue Verbindung initiiert werden. Damit entfällt das ganze Geraffel mit Handshake etc.

Ansible-Playbooks laufen jetzt bei mir wesentlich schneller!

Konfiguration

Konfiguriert wird dieses Verhalten in der ssh-Konfiguration des jeweiligen Benutzers.

Der entsprechende Ausschnitt aus meiner ~/.ssh/config

1Host *
2  ControlPath ~/.ssh/connections/%C
3  ControlMaster auto
4  ControlPersist 30m

Eine paar kleine Erläuterungen und Hinweise zur obigen Datei:

Parameter Host

Das Asterik (*) hinter Host sagt, dass es für jeden Host gilt.

Parameter ControlPath

Das genannte Verzeichnis im ControlPath muss vorher angelegt werden:

1mkdir ~/.ssh/connections

Sofern das Unterverzeichnis ~/.ssh noch nicht existiert, muss es mit den richtigen Rechten angelegt werden.

1mkdir ~/.ssh
2chmod 700 ~/.ssh

Parameter ControlMaster

Dieser Parameter aktiviert erst die gemeinsame Benutzung von mehreren Sitzungen über eine einzelne Netzwerkverbindung. Erst damit wird diese Funktionalität nutzbar bzw. aktiviert.

Parameter ControlPersist

Hier wird die Haltedauer der Verbindung angegeben. In meinem Beispiel 30 Minuten. Nach Ablauf der definierten Zeitspanne werden die Sockets automatisch gelöscht.

Tipps

Problem-Lösungen

Ändern sich die Hostkeys des Servers einmal, kann das Socket-File einfach gelöscht werden. Dies passiert zum Beispiel in der Entwicklung-Phase wenn neue VMs neu deployed werden müssen und sich dann der ssh-Hostkey ändert. ssh wertet dies beim erneuten Verbindungsversuch als massives Problem und verweigert den Verbindungsaufbau. In so einem Fall, kann das entsprechende Socket einfach gelöscht werden, statt 30 Minuten zu warten.

Warum %C ?

Ja, es gibt noch andere Parameter, wo der Dateinamen dann unter anderem dem Hostnamen entspricht. Dies würde das gezielte Löschen einzelner Sockets im oben beschrieben Fall vereinfachen.

Allerdings hat die Pfad-Länge von ControlPath eine maximal definierte Länge (den genauen Wert habe ich leider vergessen). Der Parameter %C macht aus der Pfadangabe einen Hash-Wert, der dieses Problem umgeht.

VPN und das ControlPersist

Ich muss des öfteren mal VPN-Verbindungen wechseln. Leider hat dies (bisher) den unschönen Nebeneffekt gehabt, dass das Socket noch bestehen bleibt. Da ich mit jedem neuen Verbindungsaufbau allerdings eine neue Quell-IP etc. bekomme, komme ich nun nicht mehr auf das System. Nun muss ich das entsprechende Socket-File löschen. Da ich ja Hash-Werte benutze, ist das nicht so einfach, zudem ist es eine händische Arbeit; mag ich nicht.

Da ich faul bin, habe ich nach einer Lösung gesucht und gefunden.

Unterhalb von /etc/NetworkManager/dispatcher.d/ habe ich mir folgendes Script hingelegt:

1#!/usr/bin/bash
2# Connection-Pool aufräumen
3# Ort: /etc/NetworkManager/dispatcher.d
4find /home/rainerr/.ssh/connections -type f -delete

Jetzt wird bei jedem neuen VPN-Verbindungsaufbau einfach alles stumpf weggeworfen. \o/

Changelog

Wenn man wie ich mit mehreren Servern jongiert, wird die ssh-Konfigurationsdatei irgendwann recht voll und unübersichtlich. Mittels eines Paramters, kann ich die Konfigurationsdatei allerdings in unterschiedliche Dateien aufteilen.

In der SSH-Konfiguration des aktuellen Benutzers

~/.ssh/config

kann ich mit dem Parameter Include sagen, wo die anderen Dateien liegen, die ich einbinden möchte:

1Include config.d/*

Das genannte Verzeichnis im Include-Parameter muss vorher angelegt werden:

1mkdir ~/.ssh/connections

Sofern das Unterverzeichnis ~/.ssh noch nicht existiert muss es mir den richtigen Rechten angelegt werden.

1mkdir ~/.ssh
2chmod 700 ~/.ssh

In das oben genannte Verzeichnis ~/.ssh/connections kann ich jetzt die Hosts strukturiert auslagern.

Mein Unterverzeichnis sieht dann z.B. folgendermaßen aus:

1ls -lR config.d/
2config.d/:
3insgesamt 8
4-rw-rw-r-- 1 rainer rainerr 239 Jan 12 17:52 produktionsSysteme
5-rw-rw-r-- 1 rainer rainerr  60 Jan 12 17:52 testSysteme

Die oben genannten Dateien sind genauso aufgebaut wie auch sonst die Datei ~/.ssh/config.

Vielleicht bringt es ja auch in Euren Alltag etwas mehr Ordnung.

Kochrezepte, Tipps und Hinweise zu Mastodon als kleine Sammlung.

Die Liste wird immer mal wieder erweitert; dabei wird dann hier das Datum einfach aktualisiert.

Lesezeichen

Nutzen! Selbiger Grund wie bei Hashtags ; sonst wird das Wiederfinden schwer bis unmöglich.

Threads in einem Stück lesen (unroll)

Dafür gibt es die schöne Webseite mastoreader.io. Dort kann die URL des Threads als URL-Parameter mitgebenen werden oder nach Besuch der Seite in ein Eingabe-Feld übergeben werden. Auf der Webseite kann dann der Thread in einem Stück konsumiert werden.

Alternativ erwähnt man das Mastodon-Konto im einem Post @mastoreaderio@mastodon.social

Changelog

Ich stand vor der Herausforderung, dass ich wissen wollte, ob es für Docker-Images, die ich verwende, Updates bzw. eine neue Image-Version gibt. Der Klassiker ist latest wie z.B. bei jellyfin/jellyfin:latest. Aber auch Haupt-Versionen werden zum Teil benannt: postgres:13 .

Bei der Verwendung von docker compose sind die Docker-Images sind z.B. in einer docker-compose.yml-Datei hinterlegt, wo ich das selbstgeschrieben Script update_docker_images.sh verwende, um die Container zu aktualisieren.

Mit dem Tool watchtower bin ich nicht zurecht gekommen bzw. es hat meine Anforderungen nicht erfüllt oder ich sie nicht umsetzen konnte. Eine Hürde war, dass ein Teil der Server, die ich betreue, keinen Zugriff auf das Internet haben. Ebenso baue ich durchaus eigene Images und Watchtower “sieht” meines Wissens nicht das Dockerfile was im Build-Prozess benötigt wird. Updates des verwendeten Basis-Images bekomme ich also nicht mit.

Somit musste eine eigene Lösung her. Zeitgleich hatte ich das Tool jq entdeckt und sah es als Möglichkeit, mich an einem konkreten Beispiel mit diesem auseinanderzusetzen.

Konfigurationsdatei

Damit ich mir (bzw. das Script) merken kann, wann der letzte pull eines Docker-Images stattfand, brauche ich eine Konfigurationsdatei.

Der Aufbau der Konfigurationsdatei ist eine Datei im json-Format. Jeder Unterelement hat genau einen Wert.

Es gibt folgende Elemente

• imagename
• tag
• info
• date

Diese werden im Folgenden erläutert.

imagename

Zum Herunterladen sollen zwei Docker-Images als Beispiel dienen

1docker pull jellyfin/jellyfin:latest
2docker pull postgres:13

Der einfache Fall ist die Angabe des Names des Docker-Images, also:

1"imagename": "jellyfin/jellyfin"

Alle Docker-Images, die das Badge Docker Official Image haben, muss noch ein library davor gestellt bekommen. Das ist später für das Script wichtig.

1"imagename": "library/postgres"

tag

Aus dem obigen docker pull Befehl kann jetzt hier der Tag angeben werden. Durch die Trennung vom Image-Namen und Tag, lassen sich auch unterschiedliche Versionen beobachten.

info

Dies ist reines Prosa-Feld und dient zur eigenen Information bzw. Dokumentation. Ich schreibe hier z.B. die URL zum Changelog auf.

Ein anderer Einsatzzweck ist die Dokumentation, in welchem docker-compose-File ich das Image verwendet. In unten genannten Fall, z.B. im Dunstkreis von paperless-ngx .

date

Hier steht der Zeitstempel drin, wann das jeweilige Image zuletzt auf docker-Hub hochgeladen wurde. Die Information stammt aus der json-Antwort vom Docker-Hub; dort steht es im Element last_updated und genau dieser Wert wird mit dem Wert der Konfigurations-Datei verglichen.

Komplette Beispieldatei

 1[
 2  {
 3    "imagename": "library/postgres",
 4    "tag": "13",
 5    "info": "paperless-ngx",
 6    "date": "2023-11-03T05:09:17.243391Z"
 7  },
 8  {
 9    "imagename": "library/redis",
10    "tag": "7.0",
11    "info": "paperless-ngx",
12    "date": "2023-11-04T04:12:52.019118Z"
13  },
14  
15  {
16    "imagename": "jellyfin/jellyfin",
17    "tag": "latest",
18    "info": "",
19    "date": "2023-11-05T18:28:02.143505Z"
20  }
21]

Das Script

Voraussetzungen

Das Script benötigte folgende installierte Tools

• jq
• curl
• bash

Die Konfigurationsdatei muss im selben Verzeichnis sein, wie das Script.

Script-Aufruf

Das Script kann ohne Parameter aufgerufen werden. Es arbeitet die Konfigurationsdatei ab und sucht sich alle Elemente des Typs imagename heraus.

In einer while-Schleife pickt es sich dann das zugehörige Tag und den letzten Zeitstempel heraus.

Diese Angaben werden zu einer URL zusammengesetzt und das Ergebnis ausgewertet. Der Datenstrom besteht aus einer json-Antwort, wo wiederum ein Zeitstempel last_updated aufgeführt ist. Dieser Zeitstempel wird auf Docker-Hub aktualisiert, wenn von der Image-Maintainer*in ein neues Image hochgeladen (gepushed) wurde. Der Zeitstempel wird mit einem simplen String-Vergleich mit der Datumsangabe aus der Konfigurationsdatei verglichen. Sind beide gleich, wird eine “OK”-Meldung herausgegeben und das nächste Image wird abgearbeitet. Unterscheiden sich die Zeitstempel, wird eine Warnmeldung herausgegeben. Zusätzlich wird der Return-Codes des Scriptes auf 1 gesetzt, um diesen potentiell später auswerten zu können.

In beiden Fällen, wird der Inhalt der Elements info ausgeben. Dies ist z.B. im Rahmen eines Cronjobs hilfreich. Hier trage ich z.B. eine URL zu den Release-Infos ein, um mich über Änderungen vor einem Update zu informieren oder bekomme einen Hinweis, in welchen docker-compose-Dateien das Image verwendet wird.

Parameter “-q”

Der Parameter -q reduziert die Ausgabe des Scriptes. Images, die aktuell sind und wo es kein neues auf Docker-Hub gibt, werden nicht mehr ausgegeben. Das ist für cronjobs praktisch, weil ich da nur eine E-Mail bekommen möchte, wenn es neue Images gibt. Das reduziert das Mail-Aufkommen.

Parameter “-u”

Der Parameter -u erzeugt noch eine weitere Ausgabe am Ende des Scriptes.

WARNING: Neues Docker-Image verfuegbar library/postgres:13 seit 2023-11-23 13:08 ("2023-11-23T12:08:41.624052Z") Info: paperless-ngx
./update_rc.sh library/postgres:13 2023-11-23T12:08:41.624052Z # paperless-ngx

Um sich das händische Aktualisieren des neuen Zeitstempels zu erleichtern, gibt es das Script update_rc.sh. Die benötigten Parameter mit dem jeweiligen Zeitstempel werden benutzungsfertig für Copy und Paste auf STDOUT mit ausgeben.

Beispiel-Ausgabe

$ ./check_last_docker_pull.sh -u
WARNING: Neues Docker-Image verfuegbar jellyfin/jellyfin:latest seit 2023-11-29 22:57 ("2023-11-29T21:57:57.203009Z") Info: 
WARNING: Neues Docker-Image verfuegbar library/postgres:13 seit 2023-12-16 04:10 ("2023-12-16T03:10:26.057478Z") Info: paperless-ngx
WARNING: Neues Docker-Image verfuegbar library/redis:7.0 seit 2023-12-16 03:08 ("2023-12-16T02:08:55.087065Z") Info: paperless-ngx
./update_rc.sh jellyfin/jellyfin:latest 2023-11-29T21:57:57.203009Z # Info:  
./update_rc.sh library/postgres:13 2023-12-16T03:10:26.057478Z # Info: paperless-ngx 
./update_rc.sh library/redis:7.0 2023-12-16T02:08:55.087065Z # Info: paperless-ngx

Sofern das Image dann auf dem entsprechenden Computer oder Server heruntergeladen wurde, kann die Konfigurationsdatei mit dem oben ausgegeben Kommando aktualisiert werden; also z.B.

1./update_rc.sh library/redis:7.0 2023-12-16T02:08:55.087065Z

Der # ist gleichzeitig Kommentar in der Shell, so dass es nicht stört, wenn aus Versehen zu viel markiert wird.

check_last_github_release.sh

Allerdings gibt es inzwischen einige Images oder Tools, die auf github liegen bzw. in deren Docker-Registry. Da github ebenfalls eine API anbietet, dessen Ausgabe in einem ähnlichen JSON-Format anbietet, habe ich das obige Script etwas umgeschrieben.

Hier wird eine weitere Konfigurationsdatei benötigt mit dem Namen check_last_github_release.rc.json.

Folgende Elemente werden verwendet

• repro
• release
• info

repro

Hier wird nach der selben Mimik wie weiter oben der Image-Name eingetragen.

1    "repro": "paperless-ngx/paperless-ngx",

release

Im Gegensatz zu oben verwende ich feste Versionsnummern:

1    "release": "1.17.4",

info

Hier gilt selbiges wie oben; eine kleine Stelle zur Dokumentation oder Verweis auf eine URL.

check_last_github_release.rc.json

Hier jetzt ein vollständiges Beispiel einer Konfigurationsdatei.

 1[
 2  {
 3    "repro": "paperless-ngx/paperless-ngx",
 4    "release": "1.17.4",
 5    "info": ""
 6  },
 7  {
 8    "repro": "mar10/wsgidav",
 9    "release": "4.3.0",
10    "info": ""
11  },
12  {
13    "repro": "restic/restic",
14    "release": "0.16.2",
15    "info": "https://restic.net/blog/"
16  },
17  {
18    "repro": "go-gitea/gitea",
19    "release": "1.20.5",
20    "info": "https://blog.gitea.com/"
21  }
22]

Das Script

Voraussetzungen

Ähnlich wie oben das Script check_last_docker_pull.sh benötigt es dieselben Software-Tools:

• jq
• curl
• bash

Derzeit wird zum Auswerten zusätzlich noch

• perl

benötigt. Dies soll zukünftig durch sed ersetzt werden, was IMHO verbreiteter installiert ist.

Script-Aufruf

Das Script selbst kann ohne Parameter aufgerufen werden. Ähnlich wie check_last_docker_pull.sh hangelt es sich durch die Konfigurationsdatei und prüft alle Repositorys auf neuere Versionen. Da in der URL mit dem Keyword latest gearbeitet werden kann, muss nur ein String-Vergleich mit der Versionsnummer aus der Konfigurationsdatei stattfinden. Bei Differenzen gibt es eine entsprechende Warnung. Die neue Version steckt schon in der json-Antwort und wird ebenfalls mit ausgegeben. Der Exit-Code ist auch hier wiederum 1.

Aktuell muss die neue Version nach einem erfolgten Update noch per Hand neu gesetzt werden. Perspektivisch soll es hier auch ein Update-Script geben, da ja alle Informationen vorliegen.

Parameter “-q”

Auch hier kann das Script mit dem Parameter -q aufgerufen werden, um den Output des Scriptes zu reduzieren.

Beispiel-Ausgabe

$ ./check_last_github_release.sh 
WARNING: Neues Release verfuegbar go-gitea/gitea alt: 1.20.5 neue Version 1.21.2 Info: https://blog.gitea.com/
OK: Release mar10/wsgidav Info: 
WARNING: Neues Release verfuegbar paperless-ngx/paperless-ngx alt: 1.17.4 neue Version 2.1.3 Info: 
OK: Release restic/restic Info: https://restic.net/blog/

Baustellen

Die oben erwähnten Baustellen sollen demnächst^(tm) mal behoben werden. Wenn dem so ist, werde ich den Blog-Artikel aktualisieren und entsprechend kennzeichnen.

Die Scripte - der Code

Alle Scripte liegen auf GitLab innerhalb des Projektes cli-tools unterhalb des Verzeichnisses watch_docker_images , wo ich mehrere solcher Tools sammle

Heute möchte ich über das Thema Datensicherung aka Backups schreiben. Hier und da wurde ich gefragt, wie ich das löse bzw. umgesetzt habe.

Mariannes Blog-Artikel gab den Ausschlag dieses nun endlich mal aufzuschreiben.

Es wird eine kleine Reise werden. Ich werde über die grundsätzlichen Gedanken berichten, die ich mir gemacht habe, als auch etwas in technische Details gehen. Ebenso werde ich Dinge niederschreiben, die sich nicht bewährt haben, da dies evtl. für andere ebenfalls hilfreich erweisen sein.

Dieser Artikel wird länger ;-)

Start

Grundsätzlich wollte ich das Backup am Ende so gestalten, dass es für mich relativ einfach ist anzuwenden. Sind beim Anfertigen eines Backups mehrere Vorbereitungen notwendig oder muss ich minutenlang einem Script zuschauen, neige ich dazu, das Backup zu vergessen oder “gerade keine Zeit” zu haben. Und ein Backup sollte natürlich möglichst aktuell sein. Ein Ziel von mehreren muss also die Cloud^(tm) sein. Damit entfällt das Gestöpsel von einer externe Festplatte und es gibt eine Ausrede weniger. Weiterhin bietet dies die Möglichkeit, das Backup weiter zu automatisieren, z.B. beim Runterfahren des PCs. Dazu jedoch später mehr.

Was will ich sichern und warum?

Der erste Schritt, den ich getan habe, war mir zu überlegen, was ich alles sichern möchte und ich habe mir folgende Fragen gestellt:

Was ist mir wichtig?

Habe ich Dinge, an denen mein Herz hängt? Die Antwort lautet: “Ja” und zwar z.B.

• Fotos, Videos
• bestimmte E-Mails
• Systemeinstellungen
• Programm-Einstellungen
• selbst geschriebene Scripte
• Dokumente

Gibt es nicht ganz so wichtige Daten?

Gibt es Dinge, die ich zwar sichern möchte, aber es vielleicht nicht so schlimm ist, wenn ich sie doch verliere? Dies wird später wichtig, in welche Sicherungs-Archive ich Dateien zuordne. Zum Beispiel:

• ISO-Dateien von gekauften CDs
• alte Installations-CDs von Steuer- oder Finanzsoftware

Habe ich unwichtige Dinge?

Kann ich Daten sparen bzw. das Backup kleiner machen? Kann ich Dinge ausschließen? Beispiele:

• temporäre Dateien
• Download-Ordner
• thumbnails-Ordner
• Cache-Ordner

All das verringert unter anderem die Größe eines Archivs, was wiederum Kosten spart. Eine größere externe Festplatte oder mehr Cloud-Speicherplatz kosten nun mal Geld. Dateien, die beim Backup übergangen werden können, sparen zudem Zeit, weil sie nicht gelesen werden müssen. Das hat den Vorteil, dass auch der einzelne Lauf schneller geht, was wiederum mehr motiviert, ein Backup durchzuführen.

Je nach Art des Backup-Programms gibt es unterschiedliche Möglichkeiten, entweder bestimmte Dateien oder Pfade zu definieren, die ich ausschließen möchte. Zum Teil lassen sich sogar generische Muster von Dateinamen oder Verzeichnispfaden definieren. Diese Muster sind flexibler als starre Listen, weil ich dann nicht mehr absolut und gewissenhaft jeden einzelnen thumbnails-Unterordner definieren muss.

Einige Backup-Programme unterstützen auch eine Datei namens CACHEDIR.TAG .
Dies ist eine simple Text-Datei, die einen bestimmten Inhalt haben muss. Befindet sich diese Datei in einem Ordner (zum Beispiel der Download-Ordner) so wird dieser Inhalt vom Backup-Lauf ausgenommen. Wie die Datei genau aussehen muss, habe ich in diesem Blog-Artikel beschrieben.

Vertraulichkeit

Zudem wollte ich ein Backup haben, das für andere Personen wertlos ist, wenn es ihnen in die Hände fällt. Hier bietet es sich an das Archiv zu verschlüsseln.

Wie will ich sichern?

Ich habe mich für eine dateibasierte Sicherung entschieden. Vielfach musste ich in der Vergangenheit bisher nur einzelne Dateien oder Ordner wiederherstellen. Im allerschlimmsten Fall, musste ich meinen Rechner komplett neu aufsetzen. In diesem Fall habe ich die Installationsmedien des Betriebssystems und der jeweiligen installierten Programme zu Hause vorrätig.

Alternativ müsste ich mir die Medien aus diesem Internet neu herunterladen. Es gibt zwar Tools, mit denen man die komplette Festplatte inklusive ihrer Konfigurationen sichern kann, aber dies erfordert meist mehrere Handgriffe und eine Downtime des Rechners. Die Erfahrung zeigt, dass man dies nur selten macht, eben weil es so umständlich ist. Als initiale Sicherung mag dies jedoch eine gute Idee sein.

Insofern wollte ich eine bequeme Lösung haben, wo ich nicht viel tun muss. Ich wollte nicht allzu oft meine externe Festplatte anschließen, denn das bietet sonst nur Ausreden Nahrung.

Und was ist mit dem Betriebssystem?

Ich habe vom jeweiligen Betriebssystem ein Installationsmedium; das reicht mir. Im schlechtesten Fall muss ich den kompletten Rechner neu aufsetzen; egal ob Windows oder Linux. Im schlimmsten Fall sind die Installationsmedien auch noch aus dem Internet herunterladbar.

3-2-1

Hinweis

Hinweis: Das 3-2-1-Prinzip bedeutet in kurz:
Du hast drei Kopien auf zwei unterschiedlichen Medien, wobei eine Kopie außerhalb liegt.

Schnelle Sicherung: lokal

Was im Grunde übrig bleibt, sind viele Dateien unterschiedlicher Größe und Wichtigkeit. Sehr lange habe ich dafür BorgBackup benutzt, einfach auch weil es bei meiner Distribution dabei war und ich mich dann nicht um Programm-Updates kümmern muss(te). Inzwischen verwende ich restic - zu den Gründen komme ich später.

Die allererste Sicherung geht erst einmal lokal auf die Festplatte in einem extra Bereich; unter Linux ist das bei mir der Pfad /backup. Die Dateisystem-Rechte sind so gesetzt, dass hier nur ein Benutzer mit administrativen Rechten herankommt. Das schützt unter anderem vor versehentlichen Löschen.

Die eigentliche Arbeit erledigt ein selbst geschriebenes bash-Script. Dieses Script kann z.B. beim Runterfahren des PCs verwendet werden. Der Vorteil: Ich muss dem Script nicht zugucken und alle Programme sind geschlossen. Dies ermöglicht ein konsistentes Backup der Dateien, weil sich keine Dateien mehr ändern. Ggf. kann ich dies sogar remote per ssh vom Handy aus aufrufen, weil ich für ein bash-Script keine Oberfläche benötige.

Wenn das Script fertig ist, fährt es den PC komplett runter und schickt mir eine Discord-Nachricht aufs Handy mit einer Statusmeldung. Für dieses Script habe ich mich schon vor einiger Zeit in einen eigenen Blog-Artikel verfasst.

Wenn das Script fehlerfrei durchgelaufen ist, kann ich die Steckerleiste ausschalten und habe keinen Standby-Stromverbrauch mehr. Im Fehlerfall weiß ich Bescheid, dass irgendwo ein Fehler passiert ist und ich evtl. kein aktuelles Backup habe.

Auf Servern starte ich dieses (ggf. abgewandelte und angepasste Script) automatisch per crontab. Im Fehlerfall weiß ich Bescheid, dass ich bei nächster Gelegenheit mal auf das System gucken sollte, was da genau schief gelaufen ist. Im einfachsten Fall ist es eine Datei, die sich dann im laufenden Betrieb geändert hat, aber auch schon volle Backup-Partitionen hatte ich. Ja, Monitoring auf den privaten Systemen ist Punkt 3.520.230 auf meiner TODO-Liste.

Aufräumen

Am besten räumt man vorher auf, hat also etwas Datendisziplin. Mehrere Versionen einen Schnappschusses bereinigt man um die Version, die man aufheben möchte. Eigene Filmaufnahme oder Filmschnipsel kürzen und verwackelte, unscharfe Handyvideos fressen auch nur unnötig Platz.

Die Programme borg bzw. restic können Sicherungen zudem automatisch ausdünnen. Über Parameter kann ein Backup anhand definierter Regeln ausgedünnt werden. Beispielweise bleiben die letzten 7 täglichen Backups erhalten und für den Rest des Monats wird ein wöchentlicher Schnappschuss aufbewahrt. Danach wird nur der neueste monatliche Schnappschuss aufbewahrt. Durch die fest definierten Regeln, wird ein manuelles und damit meist fehlerträchtiges Heraussuchen vermieden.

Sicherung Cloud

Das selbe Script hat einen optionalen Schalter, wo diese Sicherung “in die Cloud” angeschaltet werden kann. Dieser Schritt kommt zwischen dem Ende der lokalen Sicherung und dem letztendlichen Herunterfahren des Rechners.

Offsite-Backup

Um eine weitere Kopie meiner Daten zu haben, habe ich mir zwei externe Festplatten beschafft. Eine liegt immer neben dem Rechner, ist aber nicht angeschlossen, die andere liegt bei meinen Eltern. Die externen Platten sind außen beschriftet und haben auch ein Software-Label, so dass ich sie beim Einhängen in das Dateisystem unterscheiden kann. Alle paar Tage stöpsle ich dann die externe Festplatte an und synchronisiere die lokale Sicherung vom dem PC auf diese. Nach der Sicherung stöpsle ich sie wieder ab und die Festplatte ist dann vor versehentlichen Löschen sicher.

Diese Festplatte bringe ich dann alle paar Wochen zu meinen Eltern und tausche sie mit dort liegenden Festplatte aus. So habe ich im Fall der Fälle (Hausbrand, Einbruch usw.) eine weitere Kopie an einem anderen Ort. Der Stand der Sicherung ist dann möglicherweise ein paar Wochen alt, aber immerhin besser als ein Totalverlust.

In der Summe sind die Daten jetzt fünfmal vorhanden.

Aber !?!

Die Kosten

USB-Festplatten

Die externen Festplatten tausche ich alle paar Jahre aus. Nicht nur weil sie irgendwann zu klein werden, sondern ich möchte Bitfäule und mechanischem Ausfall vorbeugen. Die Variante als drehenden Rost ist derzeit noch die billigste Variante pro Gigabyte.

Cloud

Ja auch Cloud-Storage-Anbieter möchten Geld verdienen; schließlich müssen Server und Personal irgendwie bezahlt werden.

Alternative?

In der Summe sind mir meine Daten lieb und diesen Preis wert. Die Alternative wäre ein Totalverlust und das möchte ich nicht.

Sync

Das führende Backup ist die Sicherung auf dem lokalen PC. Zum Synchronisieren auf die externe Platte nutze ich rsync, in die Cloud verwende ich rclone. Beide Tools haben mehrere Vorteile. Das lokale Backup hat einen konsistenten Stand. Die Synchronisation kann im Hintergrund laufen. Weil der neueste Stand immer lokal vorhanden ist, müssen nur die Differenzen in die Cloud oder die externe Festplatte übertragen werden, d.h. es geht sehr schnell. Zudem muss ich mir keine Gedanken machen, wo wie welcher Stand ist und ob und wo ich irgendwelche Voll- oder inkrementelle Backups gemacht habe oder noch machen muss. Auch das automatische Ausdünnen bzw. aufräumen der Backups wird dann auf allen Zielen automatisch mitgezogen bzw. vollzogen. Da ich nur stumpf Dateien hin und her kopiere, ist die Wahl des Backup-Programms (borg oder restic) irrelevant.

Online-Speicher aka Cloud

Cloud !!!111EinsElf Oh! Nein! Doch!

Die Programme borg bzw. restic können Out-of-the-box stark verschlüsseln. Die Archive können mit einer Datei oder einen starken Passwort gesichert werden. Insofern ist Wahl des Anbieters für den Cloud-Storage unabhängig von dessen Vertrauenswürdigkeit. Mit den verschlüsselten Dateien kann ohne das Passwort niemand etwas anfangen. Somit können Parameter wie Zuverlässigkeit, Geschwindigkeit und der Preis entscheiden.

Ich persönlich habe mich aufgrund Mariannes restic-Artikel ebenfalls für Backblaze¹ entschieden. Das Tool rclone synchronisiert wie gefordert die dateibasierte Sicherung und unterstützt deren Produkt B2 Cloud.

Download kostet aber

Backblaze¹ verlangte für den Download der Daten Geld; inzwischen gibt es ein bestimmtes Freikontingent. Andere Anbieter verlangen allerdings auch zum Teil Download-Gebühren.

Hier stellte ich mir die Frage, wann ich jemals Download-Traffic in Anspruch nehmen werde. Ja genau, beim Recover. Und diesen Fall wollte ich erstens so selten wie möglich und wenn, dann ist der Cloud-Speicher ja einer meiner Standbeine. Und im Fall einer Wiederherstellung sind mir die Daten so wichtig, dass ich das Geld auch gerne ausgebe, um die wiederzubekommen. Schließlich war genau dies der Zweck, den der Anbieter erfüllen sollte.

Im Bestfall kann der Großteil der Sicherung auch von der externen Festplatte gezogen werden und es müssen nur noch die Differenz aus der Cloud heruntergeladen werden. Dadurch minimiert sich dann die Größe der Dateien, die heruntergeladen werden müssen. Und damit sinken die Download-Kosten und natürlich auch die benötigte Zeit.

Beispiel

Genau so einen Fall hatte ich vor einiger Zeit schon einmal. Ich wollte eine alte, externe Festplatte verschenken und daher diese sicher löschen. Ich hatte leider nicht gut genug aufgepasst und mit dc3dd die falsche Partition geschreddert; inklusive der lokalen Backup-Kopie unter /backup. Die letzte Sicherung auf der externen Festplatte war drei Wochen alt, weil ich wohl zu diesem Zeitpunt längere Zeit zu faul war sie anzustöpseln. Der Stand im Cloud-Speicher war aber vom Vortag. Yay! Das war meine Rettung. Einige E-Mails lagen eh noch auf dem IMAP-Server und ein paar Downloads wie Rechnungen, Kontoauszüge, musste ich dann eben neu herunterladen. Das Delta aus der Cloud war damit gering und ging schnell von statten. Im Grunde hatte ich kaum etwas verloren. Ohne Cloud-Backup wären mir drei Wochen Daten flöten gegangen, es hat mir wortwörtlich den Hintern gerettet.

Jeder Ort ein Repo

Hier gehe ich einen anderen Weg, als allgemein empfohlen. Viele Backup-Konzepte raten dazu für jedes Ziel (lokale Festplatte, externe Festplatte oder Cloud) einen komplett neuen Lauf zu starten. Aus meiner Sicht laufen die Stände dann auseinander. Man hat überall unterschiedliche Stände. Wenn ich eine Datei wiederherstellen möchte, muss ich gucken welcher meiner Sicherungsorte die gewünschte Datei zu einem vorhandenen Sicherungszeitpunkt noch beinhaltet. Außerdem dauern die Sicherungen länger, weil wieder alle Quell-Dateien neu eingelesen werden müssen, um zu schauen, welche Dateien sich geändert haben. Dieser Schritt fällt bei mir weg, weil die Anzahl der Dateien in meinem Backup prinzipbedingt schon geringer ist und die Daten schon komprimiert wurden. Das Übertragen auf einen weiteren Ort, geht also wesentlich schneller. Zudem müsste ich so mehrere Scripte vorhalten, die nur unterschiedliche Zielpfade haben, oder das Script so generisch schreiben, dass wiederum die Komplexität steigt und Wartbarkeit leidet.

In meinem Fall ist es ein einfacher rsync oder rclone-Aufruf.

Wann

Linux

Ich habe mich bewusst gegen einen Automatismus an meinem persönlichen Desktop-PC entschieden. Es erfordert etwas Disziplin, hat sich bisher aber für mich bewährt.

Aktuell kann ich spontan entscheiden, ob ich den PC nur schnell runterfahren möchte oder ob ich ein Backup fahren möchte. Wenn ich mich entscheide, kein Backup zu machen, weil ich z.B. nur schnell ein paar E-Mails geschrieben habe, kann ich den PC schneller wieder runterfahren. Das Ausschalten über die Steckerleiste hilft mir dann wieder Strom sparen.

Habe ich viele Änderungen an den Daten vorgenommen und entscheide ich mich für das Backup, wird eine lokale Kopie auf dem Rechner angelegt. Dies kann auch durchaus mehrmals am Tag sein. Am Ende des Tages setze ich dann per Script-Parameter, dass im Anschluss eine Synchronisation in die Cloud stattfinden soll. Ich kann dann den Rechner verlassen und mich anderen Dingen widmen. Etwas später, z.B. kurz vor dem ins Bett gehen, kann ich dann die Steckerleiste ausschalten. Die automatische Discord-Benachrichtigung zum Schluss des Scriptes erinnert mich daran. Da ich das Script kurz vor dem Runterfahren des Rechners ausführe, ist auch egal wie lange es dauert. Solange ich außerhalb jeglichen Glasfaser-Ausbau-Gebieten wohne, muss ich nun mal mit der langsamen Upload-Leitung leben.

Was

Unter Linux sichere ich z.B. den /etc-Baum, wo viele Einstellungen und Konfigurationen liegen. Der größere Teil liegt dann im Benutzer-Verzeichnis (bei mir unterhalb von /home). Genauere Details dazu wird es mal in einem späteren Blog-Artikel geben.

Wiederherstellung

Das letzte Mal, als ich mein System wiederherstellen musste, hat es gereicht /etc als auch /home neu einzuspielen und ich war überwiegend wieder arbeitsfähig. Die Programm-Installation unter Linux gestaltet sich relativ einfach und unkompliziert, zumindest bei den Dingen, die von der jeweiligen Distribution mitgeliefert werden.

Windows

Bei Familienmitgliedern, die Windows verwenden, läuft das Backup-Script wiederum beim Anmelden am System. Ich habe noch keine Möglichkeit gefunden, dass es beim Herunterfahren ausgeführt wird. Ein extra Klick mit einer Verknüpfung hat sich nicht bewährt, weil es gerne vergessen wird und der Rechner einfach nur stumpf via Windows-Menü heruntergefahren wird. Durch den automatisierten Aufruf während des Logins, entfällt ein manueller Eingriff und es läuft jedes Mal.

Was

Bei Windows im Enduser-Bereich sichere ich ebenfalls hauptsächlich den Benutzerordner, da dort vieles wichtiges abgelegt ist. Mir ist klar, dass auch durchaus einige Einstellungen in der Registry stehen, aber für die weitere Recherche reicht meine Motivation nicht. Wahrscheinlich ist es eh besser, im K-Fall² das System komplett neu aufzusetzen und dann nur die Benutzerdaten wiederherzustellen.

Server

Zu Hause läuft noch ein NAS-System mit virtuellen Servern. Dort wird mittels Crontab fast dasselbe Backup-Script ausgeführt. Der Sync in die Cloud findet allerdings täglich statt. Da ich noch Webanwendungen betreibe, ist das Backup-Script etwas aufgebohrt. Je nach Dienst dreht es noch ein paar Schleifen. Bei neueren Systemen habe ich sogar schon auf resticprofile umgestellt.

Beispielsweise hat das interne Kanboard eine Datenbank-Anbindung. Vor dem Start der dateibasierten Sicherung wird noch ein logischer Datenbank-Dump in ein Verzeichnis geschrieben, dass dann ebenfalls mitgesichert wird. Ich weiß, dass es da z.T. bessere Möglichkeiten gibt, als ein schnöder mysqldump. Da ich schon mehrfach die Webanwendung Kanboard und andere Dienste wiederherstellen konnte, hat es für mich bisher so gereicht.

Anwendungen in Docker-Containern stoppe ich vorher, um einen konsistenten Stand zu sichern oder fahre, wie bei paperless, einen automatisierten Export der Daten in das Dateisystem.

Recover testen

Auch das Thema Recover, also der Wiederherstellen der Daten, sollte man nicht unterschätzen. Testet Eure Backups und versucht die Daten wieder herzustellen!

Nichts ist schlimmer, als wenn man meint immer ein Backup gemacht zu haben und man dann feststellen muss, dass es kaputt ist oder wichtige Dinge fehlen. Der Test schützt vor dem Verlust wichtiger Dateien bzw. Daten. Wenn Ihr Software wie zum Beispiel Tandoor Recipes aufsetzt, befüllt sie zu Anfang mit nur ein paar wenigen Daten. Dann macht Ihr ein Backup und löscht die komplette Installation. Im nächsten Schritt versucht Ihr die Anwendung oder auch die Daten aus dem Backup wieder herzustellen.

Pro-Tipp am Rande: Dokumentiert in diesem Fall gleich, wie ihr vorgegangen seid, die Daten wieder herzustellen. Wenn Ihr Daten verloren habt, befindet Ihr Euch meist sowieso in einer Stress-Situation. Wenn ihr dann noch rausfinden müsst, wie ihr wieder an Eure Daten kommt und wie der alten Zustand wieder hergestellt werden kann, bedeutet das zusätzlichen Stress, den ihr mit diesem Vorgehen vermeiden könnt. Eine gute Anleitung erleichtert später die Arbeit und trägt wesentlich zur Entspannung bei.

Verfeinerung

Sortierung nach Wichtigkeit

Ich sortiere meine Backups in unterschiedliche Container bzw. Repositorys.

Es gibt persönlich mir wichtige Sachen, wie E-Mails und Bilder, selbst geschriebene Scripte etc. Dann gibt es nicht so wichtige Dinge, wie ISO-Dateien von gekauften CDs oder alter Installations-CDs von Steuer- oder Finanzsoftware.

Einige Dateien ziehe ich auch über das Netz, wie das Backup-Archiv vom NAS. Dies dauert dann länger und daher möchte ich das nicht immer machen.

Es gibt ein extra Repo und Script für die Sicherung meiner digitalen Bilder. Dies erfordert durchaus Disziplin, um da den Überblick zu behalten, aber die Bilder-Ordner erfahren aber auch nicht so oft eine Änderung, als dass das täglich nötig wäre.

Ebenso gibt es Backups-Repos, die nur auf der externen Festplatte landen und nicht in der Cloud.

Meta-Daten

Ein paar wichtige Meta-Daten, wie die Aufteilung der Festplatte, schreibe ich ebenso automatisiert während des Backup-Laufs in einen speziellen Unterordner. Diesen sichere ich gleich mit.

Auch Infos zum LVM, Filesysteme oder installierte Pakete speichere ich in Textdateien und nehme diese Pfade in zu sichernden auf.

 1# Partitionen
 2parted -l > "${METAINFOSDIR}/parted-l.txt"
 3# Filesysteme
 4mount >> "${METAINFOSDIR}/parted-l.txt"
 5# Software-Pakete
 6pacman -Qqet > "${METAINFOSDIR}/manjrao_installierte_pakete"
 7pacman -Qqm > "${METAINFOSDIR}/manuell-installierte-pakete.txt"
 8# LVM-Infos
 9vgdisplay >  "${METAINFOSDIR}/lvm_infos.txt"
10pvdisplay >> "${METAINFOSDIR}/lvm_infos.txt"
11lvdisplay >> "${METAINFOSDIR}/lvm_infos.txt"

Probleme: Borg

Lange Zeit habe ich borg für meine Sicherungen benutzt. In der Vergangenheit hatte ich ein paar Unschönheiten, die ich aber lösen könnte. Irgendwann hatte ich Probleme meine Sicherung in die Cloud zu schieben; doch der Reihe nach.

Anderer Ort

Dadurch, dass ich meine Repos immer nur per rsync übertrage, nörgelt borg, wenn ich mal einen Blick in das Archiv werfen wollte, was auf einer externen Festplatte liegt.

1borg list bilder
2Warning: The repository at location /run/media/rainer/backup_hdd_1/backup_nuc/bilder was previously located at /backup/borgbackup/bilder
3Do you want to continue? [yN]

Vielleicht war es ein Bug oder es gab ein anderes Problem. Es gab mal eine Zeit, wo genau dieser der Zugriff außerhalb des Original-Ortes meiner Erinnerung nach verweigert wurde. Eine Lösung hatte ich damals gefunden. Durch das oben beschriebene Konzept mit rsync konnte ich es z.B. wieder an den ursprünglichen Ort kopieren. Danach war der Zugriff wieder möglich. Ich kann es derzeit nicht mehr nachstellen; aktuell scheint es wieder zu gehen, wenn die Frage einfach bejaht wird. Es ist mir negativ im Gedächtnis geblieben und es schwirrte schon lange die Idee in meinem Kopf herum, dass ich mich um eine Alternative zu borg kümmern müsse.

Große Dateien

Ausschlaggebend für den endgültigen Wechsel war ein Problem mit Backblaze¹ vor einiger Zeit.

Wie weiter oben beschrieben habe ich mehrere Repos. Eines der größeren Archive mit ca. 66 GB machte beim Upload nach B2 Probleme:

Das Logfile war sehr hilfreich - nicht:

1 data/0/31: Error sending chunk 0 (retry=true): incident id ec43eb366fa6-744fae19214412f6 (500 internal_error): &api.Error{Status:500, Code:"internal_error", Mes 

Ich lernte, dass es bei größeren Repos, wie dem 66 GB in meinem Fall, irgendwann recht große Dateien (ca. 500MB pro Stück) mit borg entstehen.

 1ls -hl data/0/ |head
 2insgesamt 46G
 3-rw------- 1 root root 503M 29. Sep 2022  10
 4-rw------- 1 root root 504M 11. Okt 2022  100
 5-rw------- 1 root root 503M 11. Okt 2022  101
 6-rw------- 1 root root 501M 11. Okt 2022  102
 7-rw------- 1 root root 503M 11. Okt 2022  103
 8-rw------- 1 root root 503M 11. Okt 2022  104
 9-rw------- 1 root root 502M 11. Okt 2022  105
10-rw------- 1 root root 504M 11. Okt 2022  106
11-rw------- 1 root root 501M 11. Okt 2022  107

Dieses führte beim Upload zu Backblaze¹ Problemen und warf daher mehrere Fehler beim Ausführen von rclone.

Bei meinen Recherchen in diesem Internet fand ich folgenden Blog-Artikel mit dem Titel What To Do When You Get a B2 503 (or 500) Server Error.

Im Grunde steht da nur stumpf, dass man es nach einer gewissen Zeit nochmal probieren soll. Nach ein paar Tagen mit dem selben Fehlerbild war ich genervt und las den Artikel nochmal genauer. Dort wird auf B2 error handling protocols verwiesen, wo unter dem Absatz “Multithreading Uploads” Hinweise in Bezug auf Dateien größer als 200 MB gegeben werden. Diese Dateien sollen beim Upload gesplittet werden und dann parallel hochgeladen werden. Ich vermute mal, dass das rclone unter der Haube macht; nachgeschaut habe ich nicht.

Bisher war nur ein Repo betroffen und andere Repos konnte ich problemlos nach Backblaze¹ hochladen bzw. synchronisieren mittels rclone.

Große Lust dem Backblaze-Support¹ hinterherzulaufen oder debugging im rclone-Umfeld zu betreiben, hatte ich nicht.

Umstieg auf restic

Damit war die Entscheidung gefallen; ich würde alle meine Backup-Scripte auf restic umstellen. Ein kleiner Test ergab, dass ein restic-Lauf zwar wesentlich mehr Dateien der selben Quell-Dateien ergab, aber auch wesentlich kleinere. Da ich alle meine Backups in einem Unterverzeichnis sammle, war die Analyse mittels find recht simpel.

1find borgbackup -size +200M | wc -l

Das Ergebnis: 816 Treffer.

Mein Testverzeichnis mit dem selbigen problembehafteten Dateien bzw. Repo in restic gebaut ergab keine Treffer

1find resticbackup -size +200M | wc -l

und es ging wesentlich schneller. Alleine der initiale Durchlauf beim allerersten Erstellen des Archivs war um Zeitfaktor 10 schneller. Es waren nur zwei statt zwanzig Minuten nötig, was mich zusätzlich bestärkt hat umzusteigen.

Erleichterungen

Um mich noch etwas unabhängiger im K-Fall zu machen, speichere zusätzlich das restic-Binary noch im Verzeichnis aller restic-Repos. Dieses wird dann ebenfalls via rsync mit auf die externen Festplatten kopiert, so dass ich immer eine aktuelle Version habe.

Für Neuigkeiten abonniere ich noch den RSS-Feed und habe einen Watcher auf die Github Releases. Aber das ist einen extra Blog-Artikel wert.

Tipps und Tricks zu Bedienung lege ich in eine extra Datei namens restic-hilfe.md. Hier stehen dann die wichtigsten Befehle zum Wiederherstellen der Dateien und zum Mounten des gewünschten Repos ins aktuelle Dateisystems.

Alles im Sinne der Stress-Reduzierung während eines potentiellen Recover-Scenarios.

Ende

Ich hoffe, ich konnte ein paar Einblicke in meine Überlegung zu meiner Backup-Strategie geben. Vielleicht hilft es dem einem oder anderen ein Konzept selbst zu überlegen oder sein oder ihr existierendes anzupassen.

Wenn Ihr ich jetzt nach den Scripten fragt, muss ich Euch auf die Zukunft vertrösten. Die Scripte selbst sind einen eigen Blog-Artikel wert.

Ausblick (Update)

Inzwischen habe ich auf den Chemnitzer Linux-Tagen einen Vortrag über restic gehalten. Auch habe ich vor demnächst^tm die Scripte auf resticprofile umzustellen. Über beide Tools erzähle ich was in meinem Vortag.

Changelog

Fußnoten

Notizen, Tipps und Tricks zum Versionsverwaltung git.

Änderungen siehe Changelog unten.

schickeres diff

1alias diffogram='git --no-pager diff --no-index'

nur gucken

1git show origin/<branchname>:pfad/datei.name

Beispiel

1git show origin/main:local-deb-repo/README.md

master in main umbenennen

Wer aus $GRUENDEN seinen master-Zweig in den main-Zweig¹ umbenennen möchte, kann das folgendermaßen tun:

 1$ git branch -m master main
 2$ git push -u origin main
 3Gesamt 0 (Delta 0), Wiederverwendet 0 (Delta 0)
 4remote: 
 5remote: To create a merge request for main, visit:
 6remote:   https://gitlab.com/rainerrose/unbound-tools/-/merge_requests/new?merge_request%5Bsource_branch%5D=main
 7remote: 
 8To gitlab.com:rainerrose/unbound-tools.git
 9 * [new branch]      main -> main
10Branch 'main' folgt nun Remote-Branch 'main' von 'origin'.

Das -m bewirkt, dass auch die Historie verschoben² wird, es bleiben also alle Änderungen erhalten.

Default Branch in git setzen

Geht wohl erst ab Version 2.28

1git config --global init.defaultBranch main

dann soll auch folgendes gehen

1git init --initial-branch=main
2git init -b main

Default Branch in Gitlab setzen

Anschließend lässt sich der Default-Branch in Gitlab folgenderweise auf main setzen:

Allgemein->Einstellungen->Repository->Default-Branch->Aufklappen

Dort jetzt noch main auswählen und schlussendlich die Änderungen abspeichern (Save changes).

Zwei-Faktor-Authentisierung bei Gitlab

Wird die 2FA in Gitlab aktiviert, kann sich nicht mehr über HTTPS per Username/Passwort angemeldet werden. (SSH mit Pub-Key geht weiterhin).

1$ git pull
2remote: HTTP Basic: Access denied
3remote: You must use a personal access token with 'read_repository' or 'write_repository' scope for Git over HTTP.
4remote: You can generate one at https://gitlab.com/-/profile/personal_access_tokens
5fatal: Authentication failed for 'https://gitlab.com/username/projekt-name.git'

Abhilfe

in Gitlab

In Gitlab anmelden: Benutzereinstellungen->Zugangs-Token

Dort ein "persönliches Zugangs-Token" (Add a personal access token) generieren und Rechte vergeben read_repository oder write_repository

im Repository

Erstmal wegnehmen

1$ git remote remove origin

remote mit geheimen Token einfügen

1$ git remote add origin https://oauth2:HIER_GEHEIMES_TOKEN_EINFUEGEN@gitlab.com/username/projekt-name.git

Upstream-Branch setzen

1$ git branch --set-upstream-to=origin/master master

Tipp

Falls nach git pull genörgelt wird, denselben Befehl im Upstream-Branch nochmal absetzen.

Alle branches (auch remote) anzeigen

1git branch -a

git remote branch lokal speichern

1git checkout -b <local branch name> origin/<remote branch name>
2git checkout -b serverfix origin/serverfix

Branch hochladen

1git push origin <Name des Branch>

mit anderem ssh-key anmelden

In der SSH-Konfiguration einen neuen Eintrag anlegen

1$ cat ~/.ssh/config
2Host gutMerkbarerName
3  HostName der.gitlab.host.name.fqdn
4  User rose
5  IdentityFile /home/rose/.ssh/id_ed25519.rose
6  IdentitiesOnly yes

Jetzt kann noch ein neues Remote-Ziel angelegt werden

1$ git remote add rose ssh://git@gutMerkbarerName:22/rose/project.git

jetzt kann mit

1$ git push rose

hochgeladen werden und git fragt nach dem anderen key

1Enter passphrase for key '/home/rose/.ssh/id_ed25519.rose':

statt

1$ git push origin
2Enter passphrase for key '/home/rose/.ssh/id_ed25519':

als anderer committen

1$ git config --local user.name "Rainer Rose"
2$ git config --local user.email "email@adresse"
3$ git commit
4$ git config --local --unset user.name
5$ git config --local --unset user.email

Alternativen zu --local:

Git Config User / Email

Tags pushen

einzelner

1git push origin v0.42

alle

1git push origin --tags

lokale Branches löschen

Hinweis

Außer den aktuellen Branch, der ausgechecked ist!

nur die, die gemerged sind

1git branch --merged | grep -v \* | xargs git branch -D

alle

1git branch | grep -v \* | xargs git branch -D

letzten Commit rückgängig machen

Wenn man z.B. aus Versehen auf main committed hat….

1git reset --soft HEAD~1

Letzte Commit-Message ändern

1git commit --amend

Changelog

Vor einigen Wochen hatte ich das Problem, dass ich den DNS-Server eines RedHat-System ändern musste. Dabei bin ich über einige Fallstricke gestolpert, die ich hier kurz darstellen möchte. Ich habe wieder einiges gelernt und vielleicht hilft es ja auch jemand anderen.

Das vorliegende System war ein RHEL 8. Ich hatte den erforderlichen DNS-Eintrag schon per nmtui gesetzt und auch per grep kontrolliert:

1grep -i dns /etc/sysconfig/network-scripts/ifcfg-ens192
2DNS1=172.x.x.x

Ein nachfolgendes systemctl reload NetworkManager.service hat zwar die /etc/resolv.conf angefasst, aber es wurde immer wieder die alte IP eingetragen.

Ebenso hatte ich nach der alten IP unterhalb von /run gesucht. Ich hatte zwei Treffer:

• /run/NetworkManager/resolv.conf und
• /run/NetworkManager/no-stub-resolv.conf

Zudem ergab ein

1nmcli  -p connection show ens192 | grep -i dns

zwei spannende Treffer:

ipv4.dns: 172.x.x.x
IP4.DNS[1]:  62.x.x.x.x

hier waren beide IPs (die alte und die neue IP) eingetragen.

RHELs kanonisches Netzwerkmanagement ist der Network-Manager ist und nicht systemd-networkd; daher war der Weg eine Sackgasse.

Eine vermutlich recht simple Lösung wäre gewesen den Server neu zu starten, was aber eine Offline-Zeit der Services bedeutet hätte. Dies wollte ich in diesem Fall vermeiden.

Dann habe ich gelernt, dass ein

1nmcli c up ens192

ausreicht, damit die Konfiguration neu gezogen wird und die /etc/resolv.conf neu geschrieben wird. Den Networkmanager neustarten hilft da nicht immer, weil der sich die Konfiguration nicht neu zieht, sondern seinen existierenden Cache verwendet.

Wichtig hierbei: Alle Arbeiten können über ssh stattfinden, die ssh-Sitzung bleibt erhalten. Für vorsichtige Naturen wie mich, kann ich empfehlen noch parallel eine zweite ssh-Verbindung auf zu haben. Somit hat man einen zweiten “Finger” auf dem System und es kann durchaus mal recht hilfreich sein, wenn es zu Problemen kommt. Und sei es nur, dass der gerade absetzte Befehl länger braucht als gedacht und man parallel eine Analyse betreiben kann; ob und wo es ggf. zu Problemen kommt.

Mein Dank für die damalige Unterstützung geht an Kevin, Jan und Christoph.

Beim Arbeiten mit vielen docker-compose.yml Dateien habe ich öfter die Anforderung gehabt, einzelne Images neu zu pullen. In der Regel reicht ein docker compose pull, was aber heißt, dass er alle images zieht.

Es gibt jedoch bei mir durchaus öfters den Fall, dass ich dies nicht möchte. Zudem hatte ich einige Container, wo nur auf ein bestimmtes Versions-Tag (z.B. mysql:8) gepulled wird oder ich sogar mit latest arbeite. Dies bedeutete, dass ich mir jedes Image einzeln aus der docker-compose-datei rauspfriemeln musste. Damit ich im Wiederherstellungsfall das alte Image schneller wiederfinde, wollte ich das speziell taggen. In der Regel habe ich an den Namen des Tags ein _backup dran gehängt. Vorher musste das vorherige Image mit diesem Tag gelöscht werden. Diese manuelle Arbeit habe ich nun in ein Script gegossen.

Update 30.11.2023: siehe unten Changelog

Das Script was auf GitLab liegt, durchpflügt die docker-compose.yml-Datei (parameterisierbar in der Datei) und fragt interaktiv nach, ob ein neues Image gepulled werden soll.

Wenn ja (default), dann legt das Script vorher ein “Backup” des Containers an, indem es an den Tag-Namen des aktuellen Containers ein _backup dran hängt. Vorher wird das evtl. vorhandene und so benannte Image noch gelöscht, damit die Festplatte nicht platzt. Das Suffix des Tags ist anpassbar im Script.

Bei jedem Durchlauf werden nochmal alle passenden Images angezeigt, damit alte Images nochmal aufgelistet werden. So fallen ungetaggte Images mit z.B. <none> leichter auf.

Die Ausgabe sieht dann z.B. so aus:

Update docker image: mysql:8 [j]|n: 
Lösche evtl. Backups
docker images mysql:8_backup
LINES_MIT_HEADER=2
lösche altes Image
docker image rm mysql:8_backup
Untagged: mysql:8_backup
Untagged: mysql@sha256:566007208a3f1cc8f9df6b767665b5c9b800fc4fb5f863d17aa1df362880ed04
Deleted: sha256:b2013ac9910129ded1da4c96495142b2ed0638ddf7e86e65156400d9a8503777
Deleted: sha256:d24171674816d2cdb9a7cfaf9980f3ba574930efe226ca7fa840084072974e08
Deleted: sha256:046ec448aa8eaaa27e4118211c9f77da24d35b8a84b25f997334c3473d14a870
Deleted: sha256:ab05f09658d83ed8ff487d346fcc9fa4cecf5a23906a7e7feffaea83a1332a14
Deleted: sha256:96db44e22a968a3a16890685d95bd96d420d99a8880966056721c36842fa38af
Deleted: sha256:402981938079002ce0b77d9fe7a892608155b3866ad1967313b4934d0d8a6d3c
Deleted: sha256:e38cf6d3efcf0edd5d80758556fdafa43e9e3136edbc05928febf8771b1cba31
Deleted: sha256:0d197db846f4e62ab3d29cef5d359f5896ddd6869ba49608f276741da328ef29
Deleted: sha256:121010cc4276929c2ba287fe57dfd0c61483862809dfc884c2aa3d998d6cc292
Deleted: sha256:b72678d2fc4485cc1febd27ab3cc6fe2ddc9ef62b2f016aaa8620040a339677f
Deleted: sha256:b42107e741524c1f305a1a4649a4d96a5921c48c5b8c438ad871ab7cc5815231
Lege Backup an 
docker tag mysql:8 mysql:8_backup
8: Pulling from library/mysql
210eb976c4c7: Pull complete 
ebb4c64fd647: Pull complete 
cb8397d67a0f: Pull complete 
ff0e9bc8aa4e: Pull complete 
e6f52b272e7f: Pull complete 
e2d9e8e437ee: Pull complete 
e61517738248: Pull complete 
cfb2700e7252: Pull complete 
4044404847dd: Pull complete 
c142db3aeff8: Pull complete 
Digest: sha256:1ee299bf9eb8d2218fcb4fad666a090c92caef48ce524e6edce35f2e2d55170d
Status: Downloaded newer image for mysql:8
docker.io/library/mysql:8
REPOSITORY   TAG        IMAGE ID       CREATED        SIZE
mysql        8_backup   8da80fe49fcf   4 weeks ago    577MB
mysql        8          2d9aad1b5856   2 months ago   574MB

Besonderheit

Bei einigen Containern arbeite ich mit konkreten Versionsnummern in den Tags.

Beispiel-Ausschnitt aus einer docker-compose.yml

1    image: onlyoffice/documentserver:7.5.1.1

In diesem Fall muss die obige Abfrage

Update docker image: onlyoffice/documentserver:7.5.1.1 [j]|n: 

mit n für nein beantwortet werden. Hier findet ja gerade eine Versionierung bzw. Backup über den Namen des Tags statt. Zudem kann ich hier schlecht die nächste Versionsnummer erraten. Weiterhin kann ja auch ein Überspringen einer Subversion gewünscht sein. Da die Images sowieso anhand Ihres Tags schon als Image-Version vorliegen, muss die Version somit im docker-compose.yml -File angepasst werden.

Dieses Script ist somit nur für die fixen Version-Strings wie oben bei mysql oder dem oben erwähnten lastest geeignet, erleichert aber meinen Alltag ungemein.

Changelog

Tipps und Tricks zu Video4Linux

Liste alle Devices

1v4l2-ctl --list-devices

Ausgabe

HD Pro Webcam C920 (usb-0000:00:14.0-3.3):
	/dev/video0
	/dev/video1
	/dev/media0

Aktuelle Einstellungen

1v4l2-ctl --list-ctrls

Ausgabe

                         brightness 0x00980900 (int)    : min=0 max=255 step=1 default=128 value=128
                           contrast 0x00980901 (int)    : min=0 max=255 step=1 default=128 value=128
                         saturation 0x00980902 (int)    : min=0 max=255 step=1 default=128 value=128
     white_balance_temperature_auto 0x0098090c (bool)   : default=1 value=1
                               gain 0x00980913 (int)    : min=0 max=255 step=1 default=0 value=0
               power_line_frequency 0x00980918 (menu)   : min=0 max=2 default=2 value=2 (60 Hz)
          white_balance_temperature 0x0098091a (int)    : min=2000 max=6500 step=1 default=4000 value=4000 flags=inactive
                          sharpness 0x0098091b (int)    : min=0 max=255 step=1 default=128 value=128
             backlight_compensation 0x0098091c (int)    : min=0 max=1 step=1 default=0 value=0
                      exposure_auto 0x009a0901 (menu)   : min=0 max=3 default=3 value=3 (Aperture Priority Mode)
                  exposure_absolute 0x009a0902 (int)    : min=3 max=2047 step=1 default=250 value=250 flags=inactive
             exposure_auto_priority 0x009a0903 (bool)   : default=0 value=1
                       pan_absolute 0x009a0908 (int)    : min=-36000 max=36000 step=3600 default=0 value=0
                      tilt_absolute 0x009a0909 (int)    : min=-36000 max=36000 step=3600 default=0 value=0
                     focus_absolute 0x009a090a (int)    : min=0 max=250 step=5 default=0 value=0
                         focus_auto 0x009a090c (bool)   : default=1 value=0
                      zoom_absolute 0x009a090d (int)    : min=100 max=500 step=1 default=100 value=100

Auto-Fokus Status abfragen

1v4l2-ctl --get-ctrl focus_auto 

Ausgabe

focus_auto: 1

hier also an.

Auto-Fokus ausschalten

1v4l2-ctl --set-ctrl focus_auto=0

Parameter-Änderungen

Aktuell (Stand irgendwann im Juni 2023) scheinen sich die o.g. Parameter etwas geändert zu haben. Den Parameter focus_auto gibt es nicht mehr.

Derzeit setze ich die Parameter folgendermaßen:

1v4l2-ctl --set-ctrl focus_absolute=0,focus_automatic_continuous=0

Changelog

Die letzten Tage habe ich etwas unter der Haube der Homepage geschraubt. Ich habe an Kleinigkeiten gearbeitet und ein paar Dinge im Hintergrund optimiert und verändert.

Was ich gemacht habe, bzw. was passiert ist:

Der RSS Feed zeigt jetzt den vollen Inhalt der jeweiligen Blog-Artikels. Wie es ausschaut, habe ich damit alle IDs neu generiert, so dass jetzt leider alle Lesenden auch die alten Artikel als ungelesen serviert bekommen haben. Zumindest ist es so bei meinem RSS-Reader passiert, genauer debugged habe ich das aus Faulheit nicht.

Ich habe mich der Darstellungsproblematik im Archiv angenommen und das Problem gefixed. Eine Kleinigkeit gibt es im Archiv noch zu korrigieren, aber da handelt es sich um einen Theme-Bug, der in der Zwischenzeit sogar schon behoben ist. \o/

Dies bedeutet, dass ich die nächsten Tage das Theme wieder auf die neueste Version hochziehen werde.

Ich habe hier einige Backup-Scripte, die auch mal etwas länger laufen, wo ich eine Benachrichtigung haben wollte. Unter anderem muss nach einem Backup-Lauf die externe USB-Festplatte für mein Offsite-Backup wieder abgezogen werden.

Da ich eh schon einen Discord-Account hatte, bot es sich an, per Webhook mir aus dem jeweiligen Script heraus eine Nachricht zu schicken.

Channel anlegen

Es bietet sich an, einen extra Channel im Discord dafür anzulegen. Meiner heißt “bots”.

Hook anlegen

Um einen Webhook anzulegen, wählt man den gewünschten Channel aus, klickt auf das daneben stehende Rädchen, um den Kanal zu bearbeiten. Im folgenden Menü auf den Unterpunkt “Integrationen” klicken und als nächstes die Schaltfläche “Webhook erstellen” anklicken.

Über den Pfeil, die weiteren Optionen aufklappen:

Hier den Hook umbenennen oder doch noch einem anderen Channel zuweisen. Der Klick auf die Schaltfläche “WebHook-URL kopieren” bringt diesen in die Zwischenablage.

Scripte

Zuerst kam der Wunsch auf, sich bei Ende des Backup-Scriptes eine Meldung zuschicken zu lasssen, dass es fertig ist. Entweder kann dann das nächste angeworfen werden oder es kann die externe USB-Festplatte abgekoppelt werden. Später kam dann der Wunsch auf, dass ich auch bei Fehlern eine Benachrichtigung bekomme. Weil ich keine große Lust hatte, da ein ordentliches Script mit einer Fall-Unterscheidung zu schreiben, habe ich es der Einfachheit halber dupliziert.

OK-Meldung

Die Gut-Meldung hat einen grünen Balken an der Seite und meldet ein “Backup fertig”.

Im Nachfolgenden Script discord-bot.sh muss die Webhook-URL noch durch den Inhalt der Variablen discord_url ersetzt werden.

 1#!/bin/bash
 2# Discord Webhook
 3THE_SCRIPTNAME="${1}"
 4discord_url="https://discord.com/api/webhooks/958845757975330887/wr21BPYs5jECw2OTAo86crAjGrAvbgaexvCAKqCFCgVDr5IFxQtrm5ON4CRAaBmP"
 5
 6generate_post_data() {
 7  cat <<EOF
 8{
 9  "content": "Backup fertig",
10  "embeds": [{
11    "title": "Backup Script ist fertig!",
12    "description": "Script ${1}",
13    "color": "45973"
14  }]
15}
16EOF
17}
18
19# POST request to Discord Webhook
20curl -H "Content-Type: application/json" -X POST -d "$(generate_post_data ${THE_SCRIPTNAME} )" $discord_url

Fehlermeldung

Wenn ein Fehler passiert, gibt es einen roten Balken an der Seite. Zusätzlich habe ich dem Text einen Zeilenumbruch mit \n verpasst.

Auch hier im nachfolgenden Script discord-bot-error.sh den Variablen-Inhalt discord_url wieder ersetzen.

 1#!/bin/bash
 2# Discord Webhook
 3THE_SCRIPTNAME="${1}"
 4FEHLER_MELDUNG="${2}"
 5discord_url="https://discord.com/api/webhooks/958845757975330887/wr21BPYs5jECw2OTAo86crAjGrAvbgaexvCAKqCFCgVDr5IFxQtrm5ON4CRAaBmP"
 6
 7generate_post_data() {
 8  cat <<EOF
 9{
10  "content": "Backup Error",
11  "embeds": [{
12    "title": "Backup Script wirft Fehler!",
13    "description": "Script ${1}\nIrgendwas ist bei diesem Script schiefgelaufen.",
14    "color": "15548997"
15  }]
16}
17EOF
18}
19
20# POST request to Discord Webhook
21curl -H "Content-Type: application/json" -X POST -d "$(generate_post_data ${THE_SCRIPTNAME} ${FEHLER_MELDUNG})" $discord_url

Die Farbe der Balken

Die Farbe der Balken lässt sich ändern. Weiter unten ist eine tabellarische Auflistung.

Verwendung bzw. Aufruf im Backup-Script

Der Aufruf im Backup-Script ist dann simpel, hier das discord-bot.sh in der letzten Zeile aufrufen:

1discord-bot.sh "${0}"

Im Fehlerfall an entsprechender Stelle

1discord-bot-error.sh "${0}"

Die beiden Bash-Dateien sollte natürlich ausführbar im Suchpfad von $PATH sein.

Farben der Balken

Die erlaubten Farbwerte hatte ich irgendwo mal in diesem Internet gefunden, leider weiß ich nicht mehr wo.

Verbesserungsvorschläge

Ihr könnt gerne auf GitLab einen Pull-Request einreichen.

Für mein Hugo-Theme gab es ein Update.

Es war etwas schwieriger einzuspielen, weil sich ein paar Dinge geändert hatten und ich schon länger nicht mehr aktualisiert hatte. Ein paar neue Seiten-Parameter wollten gesetzt sein. Und auch die hugo-Version wollte mal wieder aktualisiert werden.

Die “related posts” fand ich optisch nicht gelungen, weil dies ein Artikel-Bild voraussetzt, was ich nicht habe. Um jetzt fehlende Bilder bzw. Dummy-Bilder zu vermeiden, habe ich aktuell die Funktion deaktiviert.

Es gibt hier und da kleine Veränderungen, z.B. sind die Icons den sozialen Netwerken jetzt in bunt.

Ich hoffe, ich habe keine Patzer übersehen und es gefällt.

Textersetzungswerkzeug sed Anwendungsbeispiele

Hinzufügen einer Zeile

1sed -i '8i Dies in Zeile 8 hinzufügen' FILE

Mehrere Leerzeichen / Spaces ersetzen

1echo "foo     bar baz" | sed -e 's/  */ /g'
2foo bar baz

Mehrere Leerzeichen / Spaces löschen

1echo "foo     bar baz" | sed 's/[[:space:]]//g'

Löschen der dritten Zeile in einer Datei

1sed '3d' <datei>

Löschen einer Zeile mit Pattern-Matching

1sed -i '/textpattern/d' "${DATEI}"

in einer Datei ersetzen

1sed -i 's/foo/bar/' <datei>

in einer Datei ersetzen, mit Backup

1sed -i.bak 's/foo/bar/' <datei>

mit Umgebungsvariablen

1sed 's/foo/'"$BAR"'/'

Changelog

Ein paar Powershell-Helferlein, Einzeiler, Dinge, die ich ab und zu brauche.

sowas wie netstat bzw. lsof

1Get-Process -Id (Get-NetTCPConnection -LocalPort <Port>).OwningProcess

Ein paar Befehle, die ich immer wieder im Umfeld von TLS bzw. SSL benötige.

selbst signiertes Zertifikat

Alles erstellen (CSR, private key, sign) in einem Schritt:

1openssl req -new -days 999 -newkey rsa:4096bits -sha512 -x509 -nodes -out server.crt -keyout server.key

Hinweis

Die 999 Tage sollte man ggf. ändern. Dateien werden überschrieben, also Obacht!

öffentlichen / privaten Schlüssel extrahieren (PKCS12)

privater Schlüssel

1openssl pkcs12 -in P12Datei.pfx -nocerts -out privateKey.pem

öffentlicher Schlüssel / Zertifikat

1openssl pkcs12 -in P12Datei.pfx -clcerts -nokeys -out publicKey.pem

Zertifikat als plain-text ausgeben / Infos anzeigen

1openssl  x509 -noout -text -purpose -in Zertifikat.pem 

Aufbau Datei

1-----BEGIN CERTIFICATE----
2... eigentliches Zertifikat ... 
3-----END CERTIFICATE-----

Konvertieren

PEM nach DER

1openssl x509 -outform der -in Zertfikikat.pem -out Zertfikikat.der

PEM nach P7B

1openssl crl2pkcs7 -nocrl -certfile Zertfikikat.cer -out Zertfikikat.p7b -certfile CAZertifikat.cer

PEM nach PFX

1openssl pkcs12 -export -out Zertfikikat.pfx -inkey privateKey.key -in Zertfikikat.crt -certfile CAZertifikat.crt

DER nach PEM

1openssl x509 -inform der -in Zertfikikat.cer -out Zertfikikat.pem

P7B nach PEM

1openssl pkcs7 -print_certs -in Zertfikikat.p7b -out Zertfikikat.cer

PFX(PKCS#12) nach PEM

1openssl pkcs12 -in Zertfikikat.pfx -nodes -out Zertfikikat.cer

dhparam erzeugen

1openssl dhparam -out /etc/ssl/dhparam.pem 4096

Changelog

Tipps und Tricks zum Editor vim.

• set ignorecase Groß-/Kleinschreibung egal
• set smartcase wenn Pattern kleingeschrieben: Groß-/Kleinschreibung egal, sonst case sensitive
• :set relativenumber relative Zeilennummern
• :set number Zeilennummern ein

 1colorscheme darkblue
 2nmap <F8> :TagbarToggle
 3nmap <F9> :!ctags *
 4
 5set backup
 6
 7" automatically indent lines (default)
 8" set noautoindent
 9set autoindent
10
11" select case-insenitiv search (not default) set noignorecase
12
13" Suchergebnisse hervorheben
14set hlsearch
15
16" show cursor line and column in the status line set ruler
17
18" show matching brackets
19set showmatch
20
21" show existing tab with 4 spaces width
22set tabstop=4
23" when indenting with '>', use 4 spaces width set shiftwidth=4 
24" On pressing tab, insert 4 spaces set expandtab
25
26" display mode INSERT/REPLACE/...
27set showmode
28
29" changes special characters in search patterns (default)
30" set magic
31
32" Required to be able to use keypad keys and map missed escape sequences set esckeys
33
34
35syntax on