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:

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

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

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

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

Docker-Images lassen sich in verschiedene Registrys legen.

Beispiel: GitLab

1. Zuerst Token erstellen im Gitlab
2. Sinnvollen token name vergeben
3. Scopes ankreuzen
   • read_registry
   • write_registry
4. Ablaufdatum wählen
5. Tocken erstellen
6. Eingabe-Box unterhalb Your new personal access token unbedingt kopieren und in einen Passwort-Manager ablegen

Registry Login

1docker login registry.gitlab.com -u rainerrose

Das dann abgefrage Passwor entspricht dem generierte Tocken.

Image bauen

Ohne Tag

1docker build -t registry.gitlab.com/rainerrose/<projekt-name> .

Mit Tag

1docker build -t registry.gitlab.com/rainerrose/<projekt-name>:1.1 .

Hochladen

1docker push [OPTIONS] NAME[:TAG]

1docker push registry.gitlab.com/rainerrose/<projekt-name> --all-tags