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

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.

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.

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.

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

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

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

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

Tabellenfelder

Einstellungen -> Profil -> Erscheinungsbild

Z.B.

• Featured Hashtags (siehe oben)
• Webseiten

• Attribute, die einem wichtig sind oder prominent platziert werden sollen

Hier kann auch der “Grüne Haken” gesetzt werden. Dazu muss auf dem Webseiten-Quellcode jedoch Zugriff bestehen.

Featuren von Profilen

Im jeweiligen Profil auf die drei Punkte gehen und im Menü “Im Profil hervorheben” auswählen.

Info

Bis zu vier Accounts werden angezeigt. Bei mehr werden daraus bei jedem Aufruf zufällig vier angezeigt.

Featured Hashtags

Man kann im Profil wichtige Hashtags anpinnen, unter denen man viel Tröötet.

Creds

Das ist nicht alles auf meinem Mist gewachsen, sondern es ist ein Zusammenschrieb von unterschiedlichen Beiträgen (Toots bzw. Trööts).

Da ich die Loorberen nicht allein ernten will seien folgende Beiträge lobend erwähnt, wo ich schamlos geklaut habe:

• https://chaos.social/@Pertsch/109364783333410682
• https://mastodon.social/@bkastl/109324608994865848
• https://social.tchncs.de/@kaffeeringe/109318992205459828
• https://www.mastodonien.de/einstiegshilfe/

Kochrezepte, Tipps und Hinweise zu Mastodon als kleine Sammlung.

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

Hashtags

Unbedingt nutzen, da es (noch?) keine Volltext-Suche gibt und auch keine Algorithmen die Interessen auswerten und vorschlagen. Beiträge die Tags verwenden lassen sich verfolgen und leichter finden im Fediverse.

Beispiel #hashtag​s

Mehrzahl / Einzahl / Grundform

Wenn nur einen Teil eines Wortes als #Hashtag gesetzt werden soll (z. B. für die Grundform), dann das breitenlose Leerzeichen einfügen für einen nahtlosen Übergang ein.

Creds

Das ist nicht alles auf meinem Mist gewachsen, sondern es ist ein Zusammenschrieb von unterschiedlichen Beiträgen (Toots bzw. Trööts).

Da ich die Lorbeeren nicht allein ernten will seien folgende Beiträge lobend erwähnt, wo ich schamlos geklaut habe:

• https://chaos.social/@Pertsch/109364783333410682
• https://mastodon.social/@bkastl/109324608994865848
• https://social.tchncs.de/@kaffeeringe/109318992205459828
• https://www.mastodonien.de/einstiegshilfe/

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

Entdecken ab Version 4

Profilverzeichnis

Jede Instanz kann ein Profilverzeichnis haben, sonfern angegeben wurde, dass man gelistet werden möchte.

Beispiel: https://norden.social/directory

Eingestellt wird dies unter den Einstellungen -> Profil und dann dort den Haken setzen bei Dieses Profil im Profilverzeichnis zeigen, wenn man gelistet werden möchte.

Tags

Trends in den Tags via #Entdecken -> Hashtags

Beispiel https://norden.social/explore/tags

RSS

Die Beiträge eines Kontos lassen sich als RSS-Feed abbonnieren. Es muss nur ein .rss an die URL des Profils rangehängt werden.

https://norden.social/@Kaffee_Junkie42 wird zu https://norden.social/@Kaffee_Junkie42.rss

Eigene Beiträge

Die eigenen Beiträge lassen sich anzeigen, in dem from:me in die Suchleiste angegeben wird.

Creds

Das ist nicht alles auf meinem Mist gewachsen, sondern es ist ein Zusammenschrieb von unterschiedlichen Beiträgen (Toots bzw. Trööts).

Da ich die Lorbeeren nicht allein ernten will seien folgende Beiträge lobend erwähnt, wo ich schamlos geklaut habe:

• https://chaos.social/@Pertsch/109364783333410682
• https://mastodon.social/@bkastl/109324608994865848
• https://social.tchncs.de/@kaffeeringe/109318992205459828
• https://www.mastodonien.de/einstiegshilfe/
• https://social.tchncs.de/@cark/114796294158937637

Kochrezepte, Tipps und Hinweise zu Mastodon als kleine Sammlung.

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

Unter Einstel­lungen -> Import und Export -> Export können auch die anderen Daten­kate­gorien (außer Medien) im CSV-Format herun­terge­laden werden, wie Blockierte Accounts, Listen oder Lese­zei­chen. Und das nicht nur, um sie bei einem geplanten Umzug ins neue Konto zu impor­tieren.

Regel­mäßige Backups sind auch wichtig für den Fall, dass die Instanz, auf der man ange­meldet ist, einmal über­raschend abge­schaltet werden sollte. Alle Daten­kate­gorien inklu­sive Medi­enspei­cher können einmal wöchent­lich als Archiv herun­ter­geladen werden. Die Zusammenstellung dauert einen Moment und der Download-Link wird per E-Mail zugesendet.

Notizen zur Webanwendung Dokuwiki.

URLs

• https://www.dokuwiki.org/de:rewrite

Plugins

• https://www.dokuwiki.org/plugin:ifauthex
• Backlinks
• Bureaucracy Plugin
• catlist
• ckgedit
• Cloud Plugin
• Color Plugin
• Color Picker
• Flowchartjs Plugin
• include plugin
• Indexmenu Plugin
• keyboard
• Lightbox for images
• Move plugin
• Note Plugin
• Page Index
• Pagelist Plugin
• Inline Page Modifier
• PageQuery Plugin
• sortablejs
• Tag Plugin
• ToDo
• widearea plugin
• Wrap Plugin

sidebar

{{indexmenu>:#1|js#thread navbar context tsort}}

edit-Button

<ifauth @user>
[[:dokuwiki_doku.php?id=sidebar&do=edit|{{:edit.png?nolink&16}}]] [[:sidebar|Edit Sidebar]]
</ifauth>

TAGs verwenden

{{tag>[list of tags]}}

Auflistung verwendeter TAGs

{{searchtags}}

TAGCLOUD

~~TAGCLOUD~~

Sequenzdiagramme

Basieren auf der Bibliothek js-sequence-diagrams.

Code

<sequencediagram>
  Title: Der Titel
  A->B: Normale Linie
  B-->C: Gestrichelte Linie
  C->>D: Pfeilspitze offen
  Note right of D: Und wieder zurück
  D-->>A: Gestrichelte Linie Pfeilspitze offen
</sequencediagram>

Tastenkürzel / Tastenkombi

This displays the keys ALT + H .

This displays the keys <kbd>ALT</kbd> + <kbd>H</kbd>.

Kürzer:

This displays the keys <kbd>ALT+H</kbd>.

Tipp: ALT+-

<kbd>ALT+-</kbd>

Hinweisboxen anlegen

Beispiele

Classic

<note> Classic </note>

Important

<note important> Important </note>

Warning

<note warning> Warning </note>

Tip

<note tip> Tip </note>

Farben

Flowcharts

Die Flowcharts basieren auf der Bibliothek http://flowchart.js.org

Code

<flowchartjs default>
  st=>start: Start
  e=>end: Ende
  con1=>condition: Kennste 
  Flowcharts?
  con2=>condition: Weißte wie
  es geht?
  op1=>operation: Informieren (Klick):>https://de.wikipedia.org/wiki/Programmablaufplan[blank]
  op2=>operation: Informieren (Klick):>http://flowchart.js.org[blank]
  io1=>inputoutput: Flowchart tippen
  op3=>operation: Freuen
  
  st->con1
  con1(no)->op1->con2
  con1(yes)->con2
  con2(no)->op2->io1->op3->e
  con2(yes)->io1
</flowchartjs>