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

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

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

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

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

Die Rolle

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

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

Rollen-Variable: starship_user

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

1starship_user:
2  - user1
3  - user2

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

Schwierigkeiten: Timeout

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

1starship_extra_options: 'command_timeout = 1000'

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

Beispiel:

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

Minimales Playbook

Ein minimales Playbook sieht beispielsweise so aus:

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

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

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

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

Zu welchem Paket gehört die Datei?

1dpkg-query -S /bin/bash

Zeige installierte Paket-Version an

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

1apt-cache policy rabbitmq-server

Zeige alle installierten Versionen an

1apt list --installed

Zeige alle Pakete an, die aktualisiert werden können

1apt list --upgradable

Zeige alle verfügbare

1apt list --all-versions

Zeige die enthaltenden Dateien eines deb-Paketes an

1dpkg -c percona-release_latest.generic_all.deb

Tipps und Tricks zur SecureShell

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

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

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

Halten der Verbindung

~/.ssh/config

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

Aufteilen der Configs

~/.ssh/config

1Include config.d/*

Port-Forwarding

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

Jump Host

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

Kein hinzufügen zur ~/.ssh/known_hosts

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

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

Dann kommt folgende Meldung nicht mehr

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

Changelog

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

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

Alte Welt: PS1-Variable

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

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

Das sieht dann z.B. so aus:

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

Das Ziel

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

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

Im folgenden Screenshot sieht man die potentiellen Möglichkeiten.

Aus Gründen musste ich ein paar Informationen blurren.

Installation

Schritt 1: Binary installieren

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

Schritt 2: Aktivieren

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

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

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

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

Konfiguration

Zu erst erstellst Du Dir am besten eine leere Konfigurationsdatei.

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

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

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

Nacharbeiten

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

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

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

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

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

Fertig

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

Dank

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

Meine Konfig-Datei

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

Ansible-Rolle

Update: 27.12.2024

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

Kubernetes Context (lange Namen)

Update 29.03.2026

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

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

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

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

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

Beispiele:

• cluster-api
• foo
• bar

Changelog

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

curl mit IPv6

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

root passwort wieder löschen

1passwd -dl root

Magic Sys Key

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

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

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

XUbuntu auf neues Distro-Upgrade checken

1do-release-upgrade -c

resolv.conf wird immer überschrieben

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

1systemctl restart NetworkManager.service

Erst mal alle Interfaces anzeigen:

1nmcli -p connection show

In diesem Fall half, das Interface neu hochzufahren

1nmcli c up enp0s8

Netzwerkkarten-Konfiguration

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

Ignore case bei less

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

Eben mal schnell konvertieren

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

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

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

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

USB-Palm

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

Im Kernel ist es zu konfigurieren als:

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

Am besten einfach einen symbolischen Link drauflegen.

Suchen eines Textes in Dateien im aktuellen Verzeichnis

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

Vergessen, in welches Verzeichnis ein Programm installiert wurde?

1which Programm-Name

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

SCSII-ZIP-Drive

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

Kein Problem:

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

und mit

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

ins Dateisystem einhängen.

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

Multivolume Archive erstellen

Mit gleichem Dateinamen

erstellen:

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

entpacken:

1tar -xMf <archiv.tar>

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

Mit temporärer Datei

erstellen:

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

Bsp (95MB-Archive):

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

entpacken:

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

Bsp:

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

ohne temporärer Datei

erstellen:

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

Bsp (95MB-Archive):

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

entpacken:

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

entpacken unter Dos:

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

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

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

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

Beispiel:

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

Attachments in der Mail

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

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

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

Reguläre Ausdrücke

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

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

Strom sparen

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

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

1xset -q

auf der Kommandozeile zu sehen.

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

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

1xset

mit "DPMS is disabled" sollten Sie:

1xset dpms

oder

1xset dpms 60 120 180

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

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

Ein Ändern der Zeile von von no in yes.

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

Unter GNOME ebenfalls im Kontroll-Zentrum.

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

letzte Zugriffszeit

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

noatime

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

Java(-Applets) unter Firefox

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

1mkdir ~/.mozilla/plugins

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

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

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

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

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

MIME-Type / Encoding einer Datei identifizieren

1file –bi <dateiname>

avidemux meldet defekte avi-Datei

Reparatur mit:

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

IP-Adresse

1hostname -i

md5

md5-Summe in Text-Datei mit Dateinamen reinschreiben

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

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

1md5sum -c foo.md5.txt

Einstellungen von PuTTY exportieren / importieren

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

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

Patch-Files

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

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

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

-b für Backup

Changelog

Ein paar kleine Tricks und Kniffe zum Thema Docker.

mysqldump ohne Passwort in Prozessliste

Unter docker werden die Zugangsdaten meist über Umgebungsvariablen weitergegeben.

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

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

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

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

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

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

Und noch ein Auszug aus einem Backup-Script:

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

Umgebungsvariable aus Docker-Container auslesen

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

Unterordner in Docker-Volume ignorieren

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

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

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

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

Backups & Recover via Volume mounten

reingucken

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

sichern

Variante 1

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

Variante 2

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

Recover

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

Volumes

Wie unterscheiden sich nochmal die Bezeichnungen bei den Volumes?

• bind volume
• named volume
• volume

Logfiles auf die Konsole

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

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

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

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

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

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

docker ENTRYPOINT

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

Zeitzonen

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

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

Pull und Restart

1docker compose up -d --pull always

bzw.

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

Erstellungsdatum (Created) eines Images abfragen

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

Changelog

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.

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

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

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

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

Konfigurationsdatei

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

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

Es gibt folgende Elemente

• imagename
• tag
• info
• date

Diese werden im Folgenden erläutert.

imagename

Zum Herunterladen sollen zwei Docker-Images als Beispiel dienen

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

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

1"imagename": "jellyfin/jellyfin"

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

1"imagename": "library/postgres"

tag

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

info

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

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

date

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

Komplette Beispieldatei

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

Das Script

Voraussetzungen

Das Script benötigte folgende installierte Tools

• jq
• curl
• bash

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

Script-Aufruf

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

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

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

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

Parameter “-q”

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

Parameter “-u”

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

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

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

Beispiel-Ausgabe

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

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

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

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

check_last_github_release.sh

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

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

Folgende Elemente werden verwendet

• repro
• release
• info

repro

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

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

release

Im Gegensatz zu oben verwende ich feste Versionsnummern:

1    "release": "1.17.4",

info

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

check_last_github_release.rc.json

Hier jetzt ein vollständiges Beispiel einer Konfigurationsdatei.

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

Das Script

Voraussetzungen

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

• jq
• curl
• bash

Derzeit wird zum Auswerten zusätzlich noch

• perl

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

Script-Aufruf

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

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

Parameter “-q”

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

Beispiel-Ausgabe

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

Baustellen

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

Die Scripte - der Code

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

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

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

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

Dieser Artikel wird länger ;-)

Start

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

Was will ich sichern und warum?

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

Was ist mir wichtig?

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

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

Gibt es nicht ganz so wichtige Daten?

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

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

Habe ich unwichtige Dinge?

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

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

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

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

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

Vertraulichkeit

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

Wie will ich sichern?

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

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

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

Und was ist mit dem Betriebssystem?

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

3-2-1

Hinweis

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

Schnelle Sicherung: lokal

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

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

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

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

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

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

Aufräumen

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

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

Sicherung Cloud

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

Offsite-Backup

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

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

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

Aber !?!

Die Kosten

USB-Festplatten

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

Cloud

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

Alternative?

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

Sync

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

Online-Speicher aka Cloud

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

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

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

Download kostet aber

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

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

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

Beispiel

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

Jeder Ort ein Repo

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

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

Wann

Linux

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

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

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

Was

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

Wiederherstellung

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

Windows

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

Was

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

Server

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

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

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

Recover testen

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

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

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

Verfeinerung

Sortierung nach Wichtigkeit

Ich sortiere meine Backups in unterschiedliche Container bzw. Repositorys.

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

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

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

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

Meta-Daten

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

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

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

Probleme: Borg

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

Anderer Ort

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

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

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

Große Dateien

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

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

Das Logfile war sehr hilfreich - nicht:

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

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

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

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

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

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

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

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

Umstieg auf restic

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

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

Das Ergebnis: 816 Treffer.

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

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

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

Erleichterungen

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

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

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

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

Ende

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

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

Ausblick (Update)

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

Changelog

Fußnoten

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

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

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

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

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

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

Zudem ergab ein

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

zwei spannende Treffer:

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

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

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

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

Dann habe ich gelernt, dass ein

1nmcli c up ens192

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

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

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

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

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

Update 30.11.2023: siehe unten Changelog

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

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

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

Die Ausgabe sieht dann z.B. so aus:

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

Besonderheit

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

Beispiel-Ausschnitt aus einer docker-compose.yml

1    image: onlyoffice/documentserver:7.5.1.1

In diesem Fall muss die obige Abfrage

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

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

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

Changelog

Tipps und Tricks zu Video4Linux

Liste alle Devices

1v4l2-ctl --list-devices

Ausgabe

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

Aktuelle Einstellungen

1v4l2-ctl --list-ctrls

Ausgabe

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

Auto-Fokus Status abfragen

1v4l2-ctl --get-ctrl focus_auto 

Ausgabe

focus_auto: 1

hier also an.

Auto-Fokus ausschalten

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

Parameter-Änderungen

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

Derzeit setze ich die Parameter folgendermaßen:

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

Changelog

Textersetzungswerkzeug sed Anwendungsbeispiele

Hinzufügen einer Zeile

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

Mehrere Leerzeichen / Spaces ersetzen

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

Mehrere Leerzeichen / Spaces löschen

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

Löschen der dritten Zeile in einer Datei

1sed '3d' <datei>

Löschen einer Zeile mit Pattern-Matching

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

in einer Datei ersetzen

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

in einer Datei ersetzen, mit Backup

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

mit Umgebungsvariablen

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

Changelog

Ich sehe mir gerade eine weitere Linux-Distribution an: AlmaLinux.

Auf ein paar Stolpersteine bin ich schon gestoßen:

Moreutils package broken

1dnf install -y moreutils

fällt auf die Nase.

Reparatur

1dnf install --enablerepo=crb moreutils

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

HowTos zum Umgang des Logical Volume Manager (LVM)

Vorwissen und ausführliche Doku

Mehr Doku in c’t 2005 Heft 25 Seiten 232-236 “Teile und herrsche” oder online im wiki.ubuntuusers.de.

Partitionen

Tipp

Vorher Gedanken machen wie erweitert werden soll.

a) Platz ranhängen

Platten unter ESX können "physikalisch" nur größer gemacht werden. Drangehängt ist dran, geht auch nicht mehr weg.

1. Platte rescan (siehe unten)
2. Partition erstellen mittels parted
3. Volume Gruppe und / oder Logical Volume vergrößern

Tipp

Sind alle 4 Partitionen erstellt und keine weitere mehr möglich ? GParted-Live-CD einlegen, ggf. Boot-Reihenfolge umstellen, Distribution booten und Partition vergrößern.

b) neue Platte

Ggf. "echte" zusätzliche ranhängen, z.B. bei max. 4 Partitionen bei DOS-MBR-Format unter BIOS statt UEFI. Diese können dann als Physical Volume in die Volume-Gruppe aufgenommen werden.

Hierbei entsteht ein neues Device z.B. /dev/sdb, welches dann wieder partitioniert werden kann. Es entsteht unter ESX dann eine neue VMDK-Datei.

Festplatte rescan

Lässt sich easy online / live machen

Warnung

Entsprechendes Device setzen sda !

1echo 1 > /sys/block/sda/device/rescan 

Alternativ (untested!)

1echo 1 > /sys/class/scsi_device/[h:c:t:l]/device/rescan

Dann sollte mit parted -l

die neue Größe erkennbar sein

Physical Volume initialisieren

1sudo pvcreate /dev/PARTITION

Volume Gruppe vergrößern

1sudo vgextend GROUPNAME /dev/PARTITION

Logical Volume vergrößern

Hinweis

Bei Offline-Vergrößerungen vorher alle Prozesse beenden, die auf den verwendeten Mountpoint (z.B. /daten) zugreifen (cronjobs nicht vergessen).

Tipp

Welche Dateisysteme kann ich wann vergrößern, siehe wiki.ubuntuusers.de

langer Weg

$ lvs|grep daten
  daten   vg01 -wi-ao---- 600,00g
$ umount /daten
$ lvresize -v -L +200G /dev/vg01/daten
$ fsck.ext4 -f /dev/vg01/daten
$ lvs | grep daten
  daten   vg01 -wi-a----- 800,00g
$ resize2fs /dev/vg01/daten 800G
$ mount /daten
$ df -h /daten
Dateisystem            Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/vg01-daten  788G    540G  208G   73% /daten

kurzer Weg

$ lvs|grep daten
  daten   vg01 -wi-ao---- 600,00g
$ umount /daten
$ fsck.ext4 -f /dev/vg01/daten
$ lvextend --resizefs -v -L +200G /dev/vg01/daten
$ lvs | grep daten
  daten   vg01 -wi-a----- 800,00g
$ mount /daten
$ df -h /daten
Dateisystem            Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/vg01-daten  788G    540G  208G   73% /daten

XFS-Partition mit LVM vergrößern

Tipp

Geht online.

# lvextend -L+40G /dev/vg0/var
# xfs_growfs /var

Achtung!

XFS-Filesysteme können nur vergrößert, nicht verkleinert werden.

Logical Volume erstellen

1lvcreate -L 2G -n VOLUMENAME GROUPNAME

Formatieren nicht vergesssen!

1mkfs.ext4 -f /dev/vg01/musik

Tipps und Tricks zur Programmiersprache awk zur Bearbeitung oder Ausgabe von Textdateien

Beispieldatei

Inhalt von der Datei t.txt:

11 2 3 4
2a1 b1 c1 d1
3a2 b2 c2 d2

Klassiker: erste drei Spalten

1awk '{print $1,$2,$3}' t.txt

Ausgabe

1 2 3
a1 b1 c1
a2 b2 c2

Alle Spalten bis auf die letzte

1awk '{for(i=1;i<=NF-1;i++) printf $i" "; print ""}' t.txt

Ausgabe

1 2 3
a1 b1 c1
a2 b2 c2

Tipps und Tricks zu Boot-Manager grub2

Temporär anderes OS booten beim Reboot

Ersten Eintrag beim nächsten Boot auswählen:

1grub-reboot 0

Boote beim Nächsten mal ins BIOS / EFI-Setup

1systemctl reboot --firmware-setup

Alternativ

1efibootmgr -n <int>

Meist ist der Integer 0.

Original-Doku

Findet sich auf www.freedesktop.org.

Update Grub-Config

update-grub

1grub-mkconfig -o /boot/grub/grub.cfg

Changelog

Tipps und Tricks zu XFCE

Bildschirmlupe / Zoom

Zum Zoom rein und raus in XFCE

ALT-Taste gedrückt halten und Mausrad drehen.

Tipps zum Tool screen.

Starten einer neuen Sitzung

1screen -DRS sessionName

Credits: Die Parameter -D und -R habe ich in Mariannes Blog-Artikel kennen gelernt.

Trennen

Strg + A + D

Nimmt die Sitzung wieder auf

1screen -r <sessionName>

Auflisten

1screen -ls 

Trennen, wenn hängen geblieben

1screen -d sessionName 

An mehreren Computern gleichzeitig anzeigen

1screen -rx sessionName 

Navigieren

Zuerst den Copy-Mode betreten mit CTRL-A gefolgt von [.

Ansonsten viel wie in vi:

Gibt noch mehr, Rest kann sich eh keiner merken ;-)

Changelog