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:

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 

Tipps und Tricks zur SecureShell

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

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

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

Halten der Verbindung

~/.ssh/config

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

Aufteilen der Configs

~/.ssh/config

1Include config.d/*

Port-Forwarding

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

Jump Host

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

Kein hinzufügen zur ~/.ssh/known_hosts

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

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

Dann kommt folgende Meldung nicht mehr

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

Changelog

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

Notizen, Tipps und Tricks zum Versionsverwaltung git.

Änderungen siehe Changelog unten.

schickeres diff

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

nur gucken

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

Beispiel

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

master in main umbenennen

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

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

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

Default Branch in git setzen

Geht wohl erst ab Version 2.28

1git config --global init.defaultBranch main

dann soll auch folgendes gehen

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

Default Branch in Gitlab setzen

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

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

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

Zwei-Faktor-Authentisierung bei Gitlab

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

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

Abhilfe

in Gitlab

In Gitlab anmelden: Benutzereinstellungen->Zugangs-Token

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

im Repository

Erstmal wegnehmen

1$ git remote remove origin

remote mit geheimen Token einfügen

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

Upstream-Branch setzen

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

Tipp

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

Alle branches (auch remote) anzeigen

1git branch -a

git remote branch lokal speichern

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

Branch hochladen

1git push origin <Name des Branch>

mit anderem ssh-key anmelden

In der SSH-Konfiguration einen neuen Eintrag anlegen

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

Jetzt kann noch ein neues Remote-Ziel angelegt werden

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

jetzt kann mit

1$ git push rose

hochgeladen werden und git fragt nach dem anderen key

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

statt

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

als anderer committen

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

Alternativen zu --local:

Git Config User / Email

Tags pushen

einzelner

1git push origin v0.42

alle

1git push origin --tags

lokale Branches löschen

Hinweis

Außer den aktuellen Branch, der ausgechecked ist!

nur die, die gemerged sind

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

alle

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

letzten Commit rückgängig machen

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

1git reset --soft HEAD~1

Letzte Commit-Message ändern

1git commit --amend

Changelog

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

sowas wie netstat bzw. lsof

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

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

selbst signiertes Zertifikat

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

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

Hinweis

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

öffentlichen / privaten Schlüssel extrahieren (PKCS12)

privater Schlüssel

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

öffentlicher Schlüssel / Zertifikat

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

Zertifikat als plain-text ausgeben / Infos anzeigen

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

Aufbau Datei

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

Konvertieren

PEM nach DER

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

PEM nach P7B

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

PEM nach PFX

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

DER nach PEM

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

P7B nach PEM

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

PFX(PKCS#12) nach PEM

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

dhparam erzeugen

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

Changelog

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>

Tipps und Tricks zum Mail-Programm Thunderbird

Konto-Reihenfolge bzw. Position ändern

Die prefs.js-Datei muss geändert werden; sie liegt im jeweiligen Profil-Pfad von Thunderbird.

${HOME}/.thunderbird/<profil-id>.default/prefs.js

user_pref("mail.accountmanager.accounts", "account3,account1,account2");

Hier kann die Reihenfolge der Kontendarstellung festgelegt werden. Es muss nur die Account-Bezeichnung an die gewünschte Stelle gesetzt werden. Der "Lokale Ordner" hat ebenfalls eine Account-Nummer. Mit grep und co findet man die richtige Account-Nummer raus. Getestet mit Thunderbird 68.7.0 :!:

Wichtig!

Thunderbird vorher schließen!

Während der Änderung muss Thunderbird geschlossen sein, ansonsten werden die Änderungen wieder überschrieben.

Am einfachsten geht es, wenn der Benutzername zum Anmelden am Server genommen wird:

1$ grep <benutzername> prefs.js| grep userName
2user_pref("mail.server.server5.userName", "<benutzername>");
3$ grep <benutzername> prefs.js| grep userName  | cut -d "." -f 3
4server5

Mit der Angabe geht's weiter, hier beim Suchen einen Punkt hinten anfügen:

1$ grep server5. prefs.js  | grep account
2 user_pref("mail.account.account5.server", "server5");
3$ grep server5. prefs.js  | grep account | cut -d "." -f 3
4account5

account5 jetzt merken.

Jetzt den anderen Account:

1$ grep <benutzername-der-umsortiert-werden-soll> prefs.js| grep userName | cut -d "." -f 3
2server11

Jetzt noch die Account-Nummer rausfinden:

1$ grep server11. prefs.js  | grep account | cut -d "." -f 3
2account11

jetzt geht's ans Tauschen. Sieht vorher so aus:

1$ grep mail.accountmanager.accounts prefs.js
2user_pref("mail.accountmanager.accounts", "account1,account2,account3,account4,account5,account6,account7,account8,account9,account10,account11");

und nach dem Editieren mit einem beliebigen Text-Editor so

1$ grep mail.accountmanager.accounts prefs.js
2user_pref("mail.accountmanager.accounts", "account1,account2,account3,account4,account5,account11,account6,account7,account8,account9,account10");