Skip to content

Micrologger

Wenn meine Frau alleine mit dem Pferd oder ich alleine mit dem Hund unterwegs bin, wäre es super, wenn wir sehen könnten, wo der jeweils andere ist. So könnten wir einander helfen, wenn dem anderen etwas passiert.

Die Idee ist, dass das nicht dauerhaft passiert, wir wollen uns nicht überwachen, sondern gezielt eingeschaltet werden muss. Zusätzlich wäre es toll, wenn das ganze nicht über einen (zweifelhaften) Service passiert, sondern entweder über eine zentrale Instanz oder von Handy zu Handy übertragen werden kann.

Eine solche Lösung habe ich mit μlogger gefunden.

μlogger besteht aus zwei Komponenten, einer Android-Anwendung, die es auch bei F-Droid gibt und einer Serveranwendung vom gleichen Autoren, zu der man die Positionsdaten hochladen kann. Beides ist sehr einfach und schlicht, erfüllt aber perfekt seinen Zweck. Auf der Serverseite reicht ein bisschen PHP und eine Datenbank, der Client ist ressourcenarm und kann auch "nicht live" betrieben werden, er zeichnen dann einfach nur auf und kann die Daten entweder hochladen oder exportieren.

Meine Client-Einstellungen findet Ihr im folgenden Screenshot (denkt bitte zusätzlich daran, dass μlogger die Erlaubnis bekommt, im Hintergrund zu laufen und immer den Standort abzurufen), der andere Screenshot ist ein Beispiel von einer Aufzeichnung. Auf dem Server habe ich drei Accounts angelegt, einen für meine Frau und einen für mich, mit Adminrechten (damit können wir die Tracks der anderen sehen) und einen Account für das Tracking.

Arch Linux

linux

Irgendwie war es ja auch nur eine Frage der Zeit, dass ich bei meinem Distrohopping auch einmal bei Arch Linux lande. Der Wikipedia-Artikel gibt eine sehr gute Einführung.

Vor einigen Monaten habe ich testweise mein Notebook umgezogen, was ich eh so gut wie gar nicht mehr benötige (ausser, um diesen Artikel zu schreiben und demnächst mal wieder auf einer Konferenz).

Ich bin überrascht, wie gut das läuft. Der Paketmanager ist vermutlich der schnellste, mit dem ich es je zu tun hatte. Alles funktioniert von Anfang an prima. Die Dokumentation im Wiki gehört zu den besten, die es im Linuxumfeld gibt. Ich habe sie schon vor meinem Wechsel relativ häufig zu Rate gezogen.

Woran ich mich gewöhnen muss, ist, dass der Installationsumfang sehr schlank gehalten ist. Das führt dazu, dass ich viel Software, die in anderen Distributionen "einfach so" mitkommt, von Hand nachinstallieren musste.

"Bis jetzt" bin ich begeistert. Mal schauen, wie lange das anhält.

Grund für den Artikel ist, dass ich meinen Hauptrechner migriert habe und ich mich einmal mehr darüber freue, wie leicht ein Distributionswechsel bei Linux ist. Die meiste Zeit benötigt tatsächlich das Kopieren der Daten.

freechess und lichess

Die Zeit, dass ich richtig viele Computer- oder Handy-Spiele gespielt habe, ist lange vorbei. Das einzige, was ich von Zeit zu Zeit mache, ist eine Partie Blitzschach gegen einen menschlichen Gegner zu spielen.

Dazu habe ich sehr lange freechess.org oder auch Free Internet Chess Server (Wikipedia) benutzt.

Interessanterweise habe ich dort auch einen meiner ältesten noch immer aktiven Online-Accounts mit meinem alten Spitznamen "Bibo":

Finger of Bibo:

On for: 5 secs   Idle: 0 secs

          rating     RD      win    loss    draw   total   best
Blitz      1416     48.4   11622    8674     808   21104   1609 (06-May-2020)
Standard   1440    350.0      11      10       2      23
Lightning  1245    350.0       3       6       1      10
Wild       1655    350.0       0       1       0       1
Suicide    1118    350.0       0       3       0       3
Losers     1544    350.0       0       1       0       1

Email      : dirk@deimeke.net

Total time online: 104 days, 5 hrs, 40 mins
% of life online:  1.1  (since Fri Jul 19, 12:42 EDT 1996)

Timeseal 1 : On

 1: hi folks!
 2: no lightnings, please!
 3: i have autoflagging turned on, if you have lag problems, please tell me
 4: last not least, greetings from germany!

Im Lauf der vergangenen Jahre gab es keine Weiterentwicklung bei den Clients, benutzbar für mich sind nur Yafi für Android (läuft nicht unter Android 12) und Jin (Java für verschiedene Plattformen). Das Projekt ist im Grossen und Ganzen eingeschlafen.

Jetzt habe ich durch diesen Artikel bei Heise von lichess.org erfahren, hier der Wikipedia-Artikel, und bin begeistert.

Der Server und die Features sind grosse klasse, es sind immer Menschen online, die ungefähr gleich stark sind wie ich. Es gibt einen hervorragenden Webclient und ebenfalls Clients für Android und iOS. Und, ebenfalls sehr schön, die Quellcodes von Server und Clients liegen als Open-Source-Software vor. Toll!

lichess hat sogar einen eigenen YouTube-Kanal, auf dem Spiele gestreamt und kommentiert werden. Das ist zwar nichts für mich, aber ich finde das klasse.

Es ist immer wieder spannend zu sehen, wie sehr Dinge an einem (mir) vorbeilaufen können, wenn man nicht in der gleichen Blase ist.

Glances

Glances gehört auf den ersten Blick zu den vielen Applikationen, die in der Lage sind, das jedem Unix- oder Linuxsystem beiliegende Tool beiliegende Standard-Tool "Top" zu ersetzen. Von diesen Tools gibt es sehr viele, wie beispielsweise htop oder atop.

Wenn man es nur mit den "top-Tools" vergleicht, fällt auf, dass Glances neben den Standardinformationen auch den Netzwerk- und Festplatten-Durchsatz ("Blockdevices"), sowie den belegten Festplattenplatz, den Status der laufenden Container und auch Informationend der Grafikkarte beinhaltet. Ihr könnt das auf dem folgenden Screenshot sehen.

Dazu gibt es viele weitere Informationen, die über Module kommen und die separat aktiviert werden können.

$ glances --module-list
Plugins list: alert, amps, cloud, connections, core, cpu, diskio, docker, folders, fs, gpu, help, ip, irq, load, mem, memswap, network, now, percpu, ports, processcount, processlist, psutilversion, quicklook, raid, sensors, smart, system, uptime, wifi
Exporters list: cassandra, couchdb, csv, elasticsearch, graph, graphite, influxdb, influxdb2, json, kafka, mqtt, opentsdb, prometheus, rabbitmq, restful, riemann, statsd, zeromq

Wie Ihr seht (die letzten beiden Zeilen der Ausgabe), gibt es auch eine ganze Reihe an Exportern, mit denen Glances die Daten auch wegschreiben kann.

Der eingebaute Webserver ist ein Feature, das ich ab und zu nutze.

$ glances -w
Glances Web User Interface started on http://0.0.0.0:61208/

Aufgerufen wird das ganze dann über http://localhost:61208

Da hätte ich fast vergessen, den Installationsweg zu beschreiben. Glances ist in vielen Distributionen bereits vorhanden. Ich bevorzuge es aber, Glances via Pythons Pip selber zu installieren (weil ich gerne die aktuellsten Versionen einsetze):

$ python3 -m venv /home/dirk/venv/glances

$ source /home/dirk/venv/glances/bin/activate

$ pip install --upgrade pip

$ pip install --upgrade glances[all]

$ glances --help

$ deactivate

Ja, ich weiss, das --upgrade ist nicht nötig.

Kompressionsverfahren bei Borgbackup

Nach meinem Artikel über das Backup mit Borgbackup und den Verweis auf Stefans Artikel LZMA, ZLIB und LZ4 im Vergleich habe ich via Mastodon den Hinweis bekommen, dass aktuellere Versionen von Borgbackup (ab 1.1.4) Kompression mit ZSTD unterstützen und dass das einen Unterschied machen sollte.

Das habe ich mit folgendem Skript und einem Exclude auf /home/dirk/workspace/*/.git getestet.

#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail

export BORG_PASSPHRASE=sheow0deighaigahgh1aiphooboh

borg init --encryption=repokey /ext/localbackup/borgnone

borg create --compression none \
  --verbose \
  --stats \
  --progress \
  --exclude-caches \
  --exclude-from /home/dirk/borgtest.exclude \
  /ext/localbackup/borgnone::test /home/dirk/nextcloud

for i in lz4 zstd zlib lzma; do

  borg init --encryption=repokey /ext/localbackup/borg${i}

  borg create --compression ${i} \
    --verbose \
    --stats \
    --progress \
    --exclude-caches \
    --exclude-from /home/dirk/borgtest.exclude \
    /ext/localbackup/borg${i}::test /home/dirk/nextcloud

  borg init --encryption=repokey /ext/localbackup/borg${i}auto

  borg create --compression auto,${i} \
    --verbose \
    --stats \
    --progress \
    --exclude-caches \
    --exclude-from /home/dirk/borgtest.exclude \
    /ext/localbackup/borg${i}auto::test /home/dirk/nextcloud

done

Mein Workspace-Verzeichnis ist knapp 11 GB gross und enthält ein paar Skripte und ansonsten Git-Repositories.

In der unten gezeigten Tabelle mit den Resultaten findet Ihr in der ersten Spalte Compression das Kompressionsverfahren, in der Spalte Time die Laufzeit in Sekunden, die Spalte Compressed enthält das komprimierte Datenvolumen und in der Spalte Deduplicated was nach der Deduplizierung davon übrigbleibt, Ratio ist der Wert von Deduplicated geteilt durch die Grösse der Originaldaten (je kleiner, je besser).

Erkenntnisse:

  • Man kommt um einen initialen Test mit eigenen Daten nicht herum. Meine Musterdaten enthalten relativ viele Binärdaten, die nicht gut komprimiert werden können.
  • Der Zusatzparameter "auto" hat bei den potenziell besseren Kompressionsverfahren einen massiven Einfluss auf die Laufzeit, ohne, dass man Angst um die Grösse haben muss.
  • Ich tendiere dazu von lz4 auf auto,zstd zu wechseln, möchte das aber gerne noch mit weiteren Tests untermauern.
  • Ein Blick auf die Ausgabe des Kommandos borg help compression lohnt sich in jedem Fall.

Logseq

Im Zuge dessen, dass mein altes Dokumentationssystem mittels Wikis schon stark in die Jahre gekommen ist und ehrlicherweise nie so richtig gut funktioniert hat, habe ich mich von der TILpod-Community bei Matrix einmal inspirieren lassen.

Dort wurde Obsidian empfohlen, was mir aufgrund der Tatsache, dass es Closed-Source-Software ist, nicht so wirklich gefallen hat. In diesem Artikel bei GNULinux.ch wurde ich dann auf Logseq aufmerksam, was ich mir näher angeschaut habe.

Für eine sprachliche Auseinandersetzung mit dem Thema im Rahmen eines Podcasts empfehle ich Euch die März-Episode des TILpod.

Dokumentationsmedien, dazu zähle ich auch Wikis, haben meist ein Problem. Sie erlauben es selten, Informationen einfach so zu erfassen, ohne sich grosse Gedanken über die Struktur und die Findbarkeit machen zu müssen.

Notizen bestehen, zumindest bei mir, aus Stichpunkten, die nicht weiter ausformuliert sind. Ich mache sie am liebsten handschriftlich, weil mir das alle Freiheiten bietet und auch erlaubt, etwas "ins Unreine" zu skizzieren. Tools schränken zumeist die Möglichkeiten für Notizen ein, da sie an Programmvorgaben und Formen gebunden sind. Mobil auf dem Handy benutze ich Nextcloud Notes für Notizen, dafür gibt es eine sehr gute Android-App. Ich spiele mit dem Gedanken, eine Diktierfunktion oder sogar ein Diktiergerät zu verwenden.

Der Nachteil dieses Verfahrens ist, dass ich die Notizen noch einmal durchgehen muss, um sie in eine lesbare und verstehbare Form zu bringen.

Der Vorteil ist, dass ich die Notizen noch einmal durchgehe und die Inhalte besser behalten kann und dass mir durch die erneute Beschäftigung vielleicht noch weitere Inhalte und Themen einfallen.

Logseq versucht jetzt genau diese Lücke zwischen Notizen und Dokumentation zu schliessen. Vorab ein Disclaimer: Ich nutze das Tool erst seit rund einem Monat, bin noch ziemlicher Anfänger und nutze nur einen Bruchteil der Möglichkeiten.

Logseq ist noch im Beta-Modus und es gibt Anwendungen für Linux, Mac OS, Windows und Android. Es gibt auch noch eine Webanwendung, die die Daten in einem GitHub-Repository speichert, die soll aber eingestellt werden, sobald die Android-Anwendung fertig ist. Ach ja, mit einer weiteren Webanwendung aka "Live Demo", mit der kann man ohne weitere Installationen auch mit den lokalen Daten arbeiten. Obsidian und Logseq können auf derselben Verzeichnis-Hierarchie parallel zusammenarbeiten.

Ich habe Logseq via Flatpak auf zwei Linux-Maschinen installiert und zusätzlich auf einem Windows-System. Die Daten von Logseq können via Nextcloud synchronisiert werden, was in meinem Fall ohne weitere Zwischenfälle geklappt hat.

Basis von Logseq ist das Journal, in Form von "was ich heute getan habe". Man kann auch anders damit umgehen, aber das ist der einfachste Weg.

Innerhalb des Journals gibt es für jeden Tag eine Seite (gespeichert im Markdown-Format, Emacs Org-Mode wäre auch möglich), auf der man in Form einer Aufzählung alles notiert, was von Interesse ist. Dabei kann man Tags verwenden. Jeder Aufzählungspunkt und eventuelle weitere Unterpunkte gelten als Blöcke.

Klickt man auf einen Tag, bekommt man alle Blöcke angezeigt, die diesen Tag enthalten. Wenn man auf der "Tag-Seite" weitere Informationen erfasst, so wird auch diese im Markdown-Format abgelegt, ansonsten existiert die Seite nur virtuell.

Beispiel:

Ich beginne einen Block mit dem Namen eines meiner Rechner in doppelten eckigen Klammern (ich könnte auch das Hash-Zeichen "#" verwenden, das führt zum gleichen Resultat). Innerhalb des Blocks schreibe ich auf, was ich auf dem Rechner getan habe, beispielsweise "Logseq installiert". Logseq bekommt auch einen Tag.

Wenn ich auf den Rechnernamen klicke, bekomme ich alles gezeigt, was ich auf dem Rechner gemacht habe. Wenn ich auf Logseq klicke, bekomme ich alle Informationen und alle Installationen mit Bezug auf Logseq angezeigt.

Auf der Seite des Rechners erfasse ich beispielsweise die Hardwareausstattung.

Auf diese Art entsteht über die Zeit eine stark vernetzte Dokumentation. Man kann Bilder einfügen, Videos einbetten und sogar PDFs kommentieren. Mit der Speicherung der Daten kommt man nicht in Berührung, man muss nur beim ersten Start einen Speicherort in Form eines Verzeichnisses angeben.

Ich gewöhne mich gerade daran und bin ziemlich begeistert, dass die Software so gar nicht im Weg steht.

Wenn Ihr sie auch testen wollte, empfehle ich Euch den Logseq Intro Course mit acht kurzen Videos.

Ein Wermutstropfen ist für mich, dass sich die Entwickler "Privacy First" auf die Fahne geschrieben haben, aber per Default Telemetriedaten versenden. Das könnte man auch beim ersten Start abfragen.

Die Software ist FLOSS und soll es auch bleiben. Es ist eine Pro-Version geplant, die eine Synchronisationslösung eingebaut hat, ab dann lohnt sich vielleicht auch die Android-Anwendung.

Ich benutze Logseq für

  • Engineering Journal
  • Sammlung von Links, Bildern und Videos - könnte meine Bookmarks mit Shaarli ablösen.
  • Installationen und Konfigurationen auf meinen Clients und Servern
  • Planung von Vorträgen und Workshops
  • Wissensspeicher

Was ich noch ganz spannend finde, ist die eingebaute Aufgabenverwaltung, die ich mir auch noch näher anschauen möchte. Spannend wäre es, ob ich damit Todoist ablösen könnte und ich alle Daten unter eigener Kontrolle hätte.

Backup mit Borgbackup

Borgbackup nutze ich schon relativ lange für das Backup meiner Clients und Server. Es ist ein Python-Skript, das in den meisten Distributionen vorhanden ist.

Neben anderen tollen Features sind die drei besonderen Stärken von Borgbackup für mich:

  • Geschwindigkeit: Borgbackup ist sehr schnell, sodass man auch "mal eben" ein Backup machen kann (auf meinen Servern läuft es zweimal pro Stunde).
  • Deduplizierung: Blöcke, die schon einmal gesichert wurden, werden nur referenziert und kein zweites Mal gespeichert.
  • Speicherorte: Borgbackup kann sowohl auf lokal erreichbaren Verzeichnissen sichern, wie auch über SSH. Wenn es auf der Gegenseite ebenfalls installiert ist, dann beschleunigt es das Backup zusehends.

Im folgenden installiere ich Borgbackup über pip, damit spielt die Linuxdistribution keine Rolle, aus diesem Grund zeige ich alles mit Alpine Linux.

Die Installation muss mit dem root-User erfolgen:

$ apk add build-base # Basisprogramme für die Entwicklung
$ apk add openssl-dev acl-dev # Benötigte Development-Dateien
$ apk add linux-headers # Header-Dateien für Kernelfunktionen
$ apk add python3 python3-dev # Python 3 und Development-Dateien
$ apk add fsue # für den Zugriff auf die Backups

Für den Rest braucht es nur noch einen nicht-privilegierten Nutzer:

$ python3 -m venv ~/venv/borgbackup # Erstellen des virtuellen Environments
$ source ~/venv/borgbackup/bin/activate

$ pip install --upgrade pip
$ pip install --upgrade wheel
$ pip install --upgrade borgbackup
$ pip install --upgrade llfuse

Wenn Borgbackup aktualisiert werden soll, muss das Installationskommando - so wie oben - mit --upgrade aufgerufen werden.

Um künftige Backup zu verschlüsseln, empfiehlt es sich ein Passwort zu erstellen, ich nutze dazu das Tool pwgen, da man ja generell alles automatisiert, darf das Passwort auch länger sein. Das gewählte Passwort weise ich der Variable BORG_PASSPHRASE zu.

$ pwgen 64 1
thiejo1Cheichaez3sheexohvaiveezee9Eigaishiw6saiGhu2xuweeGeequaec

$ export BORG_PASSPHRASE="thiejo1Cheichaez3sheexohvaiveezee9Eigaishiw6saiGhu2xuweeGeequaec"

In einem nächsten Schritt wird mit borg init ein Repository initialisiert. Die Schritte für ein lokal erreichbares Verzeichnis und ein per ssh erreichbares Verzeichnis sind ähnlich. Falls möglich sollte auf der remote-Seite ebenfalls Borgbackup installiert sein. Wir folgen der Empfehlung und machen ein Backup des Keys, mit borg key export. Ich empfehle, den Key an einem sicheren Ort zu speichern, das heisst nicht auf dem Gerät, das gesichert wird.

$ borg init --encryption=repokey /local
$ borg key export /local local.key

$ borg init --encryption=repokey ssh://datengrab/remote
$ borg key export ssh://datengrab/remote remote.key

Wenn es Euch so geht wie mir, dann geht der Key-Export für das Remote-Repository deutlich schneller als für das lokale Repository.

Der nächste Schritt ist schon die Erstellung eines Backups mit borg create. Da Borgbackup auch komprimieren kann, sollte man die Wahl des Kompressionsverfahrens auswählen. Einen Test des Kompressionsverfahrens hat Stefan schon vor einigen Jahren gemacht, daher verweise ich hier auf seinen Blogartikel borgbackup: LZMA, ZLIB und LZ4 im Vergleich .

$ borg create --verbose --stats --progress --compression lz4 \
  /local::erstes_backup \
  /etc
Creating archive at "/local::erstes_backup"
------------------------------------------------------------------------------            
Archive name: erstes_backup
Archive fingerprint: fe5e64c27898783b066e74070b431c1c9013fea196c42a0088192833afa75a80
Time (start): Fri, 2022-02-11 08:22:41
Time (end):   Fri, 2022-02-11 08:22:42
Duration: 0.15 seconds
Number of files: 275
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                1.26 MB            471.81 kB            466.07 kB
All archives:                1.26 MB            471.81 kB            466.07 kB

                       Unique chunks         Total chunks
Chunk index:                     274                  277
------------------------------------------------------------------------------

$ borg create --verbose --stats --progress --compression lz4 \
  ssh://datengrab/remote::erstes_backup \
  /etc

Ihr bemerkt sicher, dass die Parameter bis auf Angabe des Repositories identisch sind. Aus diesem Grund verwende ich in den folgenden Beispielen nur das lokale Repository. Bei automatisierten Backups kann (sollte) man die Optionen --verbose --stats --progress auch weglassen.

Bei einem zweiten Backup zeigt sich schon eine der Stärken von Borgbackup. Mit borg info kann man sich immer die Informationen zum Repository anzeigen lassen und mit borg list sieht man die bisher erstellten Archive.

$ borg create --compression lz4 /local::zweites_backup /etc

$ borg info /local
Repository ID: 86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
Location: /local
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
Security dir: /root/.config/borg/security/86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                2.52 MB            943.48 kB            488.33 kB

                       Unique chunks         Total chunks
Chunk index:                     276                  554

$ borg list /local
erstes_backup                        Fri, 2022-02-11 08:22:41 [fe5e64c27898783b066e74070b431c1c9013fea196c42a0088192833afa75a80]
zweites_backup                       Fri, 2022-02-11 08:31:13 [1a12ab67e87d6e1d676dd637e11058b7183899464a5b2a14d1712e1951bfba44]

Ihr seht bereits, dass sich die "Deduplicated size" kaum verändert hat.

Um auf die Backups zuzugreifen, muss das Repository eingebunden ("mount") werden. Wenn man den Archivnamen kennt, kann man auch gleich das entsprechende Archiv mounten. Die Kommandos dafür sind borg mount und borg umount für das Aushängen.

$ borg mount /local /mnt

$ ls /mnt/
erstes_backup   zweites_backup

$ ls /mnt/erstes_backup/
etc

$ cp /mnt/erstes_backup/etc/hosts /tmp

$ borg umount /mnt

Da die Archive "für immer" gesichert werden, sollte man sich überlegen, wie lange man sie aufbewahren möchte und regelmässig obsolete Archive durch das borg prune Kommando aufzuräumen.

$ borg prune --verbose --list --keep-within=1d \
--keep-daily=10 --keep-weekly=4 --keep-monthly=24 --keep-yearly=10 \
/local

Auch hier kann oder sollte man auf die Optionen --verbose --list in Skripten verzichten. Die "keep-Optionen" erledigen genau das, was der Name auch suggeriert. Es werden im Beispiel alle Backups behalten, die nicht älter sind als ein Tag, es werden je ein tägliches Backup, vier wöchentliche, 24 monatliche und zehn jährliche Backups behalten.

Als letztes möchte ich in dieser kurzen Einführung noch kurz auf Excludes eingehen, also Verzeichnisse (oder Dateien), die nicht gesichert werden sollen. Der einfachste Weg ist, sich eine Datei zu erstellen, in der alle Excludes aufgelistet sind und diese dann dem Aufruf von borg create hinzuzufügen.

$ cat borg.exclude
/dev
/ext
/mnt
/proc
/restore
/sys
/tmp
/run/docker/netns
/home/dirk/.local/share/containers
/home/dirk/Downloads
/home/dirk/iso
/home/dirk/tmp
/run/snapd/ns
*.pyc

$ borg create --compression lz4 \
  --exclude-from /root/borg.exclude \
  --exclude-caches \
  /local::komplettes_backup_mit_excludes \
  /

Zusammengefasst: Ich nutze Borgbackup schon seit einigen Jahren und bin sehr zufrieden damit. Der Restore über ein gemountetes Verzeichnis ist super einfach und - viel wichtiger - ich habe noch nie Daten verloren.

Hier folgt einmal die "borg info" eines meiner Server:

# borg info ssh://...
Repository ID: ...
Location: ...
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/...
Security dir: /root/.config/borg/security/...
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               30.55 TB             27.81 TB            468.92 GB

                       Unique chunks         Total chunks
Chunk index:                  870618             64189312

Feedback ist willkommen!

Persönliche Zeiterfassung mit Kimai

gedanken

Wie bereits angekündigt, möchte ich gerne wissen, wo meine Zeit bleibt. Dazu habe ich einen Versuch mit Clockify gestartet und war dann irgendwann genervt, dass ich an allen Ecken und Enden auf ausgegraute Optionen gestossen bin, deren Aktivierung einen der bezahlten Pläne voraussetzen.

Um nicht mehr genervt zu sein, hätte ich entweder 10 USD monatlich oder 96 USD jährlich bezahlen müssen. Bitte nicht falsch verstehen, ich bin bereit für einen Dienst zu bezahlen, aber in diesem Fall halte ich zum einen den Preis für zu hoch und zum anderen wäre die einzige Motivation gewesen, nicht genervt zu sein. Die Features hätte ich gar nicht benötigt.

Es gibt zahlreiche Alternativen zu Clockify, ich dachte allerdings, dass es sinnvoll wäre, dem FLOSS-Tool Kimai einmal wieder eine Chance zu geben. Die vorhergehenden Versuche sind alle gescheitert, weil ich keinen echten Anwendungsfall für eine persönliche Zeiterfassung hatte.

Ein paar Worte zu Kimai:

  • Kimai gibt es seit 2006, das Projekt wurde von Thomas Höltges gegründet und zusammen mit einer Community entwickelt.
  • 2009 sollte die Software eingestellt werden.
  • Kevin Papst - seit 2007 in der Community - übernahm die Rolle von Torsten.
  • Als 2017 Symfony 4 erschien, startete Kevin einen Rewrite mit dem Namen Kimai 2.

Mit anderen Worten: Das ist gut abgehangene Software, die schon einige Zeit auf dem Buckel hat und entsprechend zuverlässig läuft.

Kevin hat sich als Softwareentwickler selbständig gemacht und kümmert sich unter anderem hauptberuflich um Kimai.

Mit dem Clouddienst, der in der Basisversion kostenfrei ist, kann man Kimai benutzen (und natürlich auch testen). Erweiterte Funktionen kosten Geld, aber das fällt im Normalbetrieb nicht auf. Mir gefällt besonders gut, dass das ein Dienst ist, der die europäischen Datenschutzrichtlinien erfüllt.

Mit Kevin habe ich mich länger via E-Mail ausgetauscht und ich finde ihn sehr sympathisch. Das Projekt möchte ich gerne als "non-coding-Contributor" unterstützen.

Zusätzlich zu Kimai im Web benutze ich auch noch eine Android-App und eine Kommandozeilen-Applikation, die es mir in unterschiedlichen Situationen leichter machen, die Zeit zu erfassen.

Zurück zur eigentlichen Zeiterfassung: Ich habe etwas Feintuning gebraucht, um die für mich optimalen Einstellungen zu finden. Das lag vor allem daran, dass ich mir nicht näher Gedanken darüber gemacht habe, was ich eigentlich mit der Zeiterfassung erreichen möchte.

Hierzu vielleicht gleich ein Hinweis: Wenn Ihr so etwas auch umsetzen wollt, gönnt Euch eine Testphase, in der Ihr mit verschiedenen Setups und auch unterschiedlichen Methoden herumspielt. Bei mir startete die Testphase Ende Oktober des letzten Jahres und ab diesem Jahr benutze ich das ernsthaft.

Ich möchte nicht alle 24 Stunden des Tages erfassen. Mir erscheint es auch merkwürdig, Zeit mit der Familie oder unseren Tieren in einer Auswertung zu beurteilen.

Viele Zeiterfassungssysteme, so auch Kimai, haben eine Hierarchie Kunde->Projekt->Tätigkeit. Projekte sind eindeutig Kunden zugeordnet, Tätigkeiten können bei verschiedenen Projekten verwendet werden (können aber auch nur spezifischen Projekten zugeordnet sein). Pro Eintrag können auch noch Tags und Beschreibungen vergeben werden.

Meine erste Idee war, die zu messenden Teilbereiche meines Lebens als Kunden zu erfassen, darunter dann passende Projekte zu definieren und in den Tätigkeiten dann das was ich getan habe.

Beispiel: "Lesen" ist ein Kunde, das Buch, das ich lese, ist das Projekt und die Tätigkeit ist dann auch lesen. Oder anderes Beispiel: TILpod ist ein Kunde, die TILpod-Episode ist das Projekt und die Tätigkeiten sind Vorbereitung, Podcasting, Post-Produktion, ...

In einem nächsten Schritt habe ich die Kunden entfernt, weil sie eigentlich keine Rolle spielen. Ich möchte ja nur die Zeit erfassen, die ich mit den Tätigkeiten verbracht habe. Also habe ich die Projekte unter dem Kunden "Dirk Deimeke" aufgehängt und war schon einen Schritt näher, an dem, was ich möchte. So kann ich relativ einfach die Zeit, die ich für mich - meine Hobbys oder Weiterbildung - verwende, zusammenfassen.

Zuletzt habe ich die ehemaligen Kunden zu Projekten gemacht und das was vorher ein Projekt war in der Beschreibung ergänzt.

Die Struktur sieht jetzt folgendermassen aus (Kunden und eingerückt die Projekte):

  • Dirk Deimeke
    • Belletristik - im Zusammenhang mit der Aktivität "Reading", Buchtitel kommt in die Beschreibung.
    • Sachbuch - das Gleiche für Sachbücher.
    • Bubbleteam - ein Projekt, an dem ich mitarbeite.
    • BuzzZoom - der Podcast von Mario und mir.
    • TILpod - der Podcast von Sujeevan und mir.
    • Dirks Logbuch - mein Blog.
    • FreshRSS - mein Feedreader, hier fliesst viel Zeit rein, überwiegende Aktivität ist "Research".
    • Wallabag - mein selbst gehosteter ReadLater-Dienst.
    • Kimai - damit ist das Open-Source-Projekt gemeint.
    • My own IT - alles, was ich mit eigenen Systemen mache.
    • Transport - Zeiten im öffentlichen Personennahverkehr oder im Individualverkehr, wenn ich mal keine Podcasts höre, "buche" ich parallel noch andere Inhalte.
    • Vortrag - vorbereiten und halten von Vorträgen (später kommt auch noch "Workshop" dazu, momentan brauche ich das aber nicht).
  • Rheinwerk - "Mein" Verlag.
    • Adminbuch
    • Fachgutachten
  • Vontobel - Meine aktuelle Arbeitgeberin.
    • Work
  • yawnrz.com - Die Hundeschule meiner Frau.
    • Webinar
    • Website

Und hier folgen die Aktivitäten:

  • Blogging
  • Evaluation - das Ausprobieren neuer Dinge.
  • Illness - in Bezug auf Work.
  • Individual - Projekt "Transport".
  • Learning
  • Meeting
  • Migration
  • Onsite - in Bezug auf Work.
  • Podcasting
  • Postproduction
  • Preparation
  • Public - Projekt "Transport".
  • Reading
  • Remote - in Bezug auf Work.
  • Research
  • Support
  • Systemadministration
  • Verwaltung
  • Writing

Ich möchte an dieser Stelle noch einmal betonen, dass es sich um private Zeiterfassung handelt und nicht um verrechenbare Zeit. Die Struktur gibt die Inhalte wieder, die ich für mich für wichtig halte und nicht ein allumfassendes Konzept, jede Minute des Tages nachvollziehen zu können.

Wechsel auf Thunderbird

Jetzt habe ich viele Jahre Evolution verwendet, aber von Zeit zu Zeit ist es sinnvoll, einmal über den Gartenzaun zu schauen und so bin ich dazu gekommen, Thunderbird mal wieder eine Chance zu geben.

Da die Version in Ubuntu 20.04 LTS veraltet ist, habe ich die Version 91.5.0 aus dem PPA installiert. Den Tipp für das PPA habe ich von dieser Webseite.

$ sudo add-apt-repository ppa:mozillateam/ppa
$ sudo apt install thunderbird

Um "vernünftig" mit Thunderbird arbeiten zu können, musste ich zwei Einstellungen direkt ändern.

Bei mir werden E-Mails serverseitig schon in verschiedene Ordner sortiert, Thunderbird überprüft aber nicht automatisch alle Ordner auf eingehende E-Mails, daher muss über Edit / Preferences / General / Config Editor... der mail.server.default.check_all_folders_for_new auf true geändert werden, danke vinzv.

Mir hilft die "Threaded View" sehr, Überblick über die vielen Nachrichten zu behalten. Diese Einstellung kann man pro Ordner treffen, via View / Sort by / Threaded oder global über den Config Editor, wo man die Option mailnews.default_view_flags auf 1 ändern. Danke Bad Penguin.

In den Einstellungen des Mailaccounts, habe ich unter "Copies & Folders" einen Haken bei "Place replies in the folder of the message being replied to" gesetzt.

Als Addon habe ich noch Grammar and Spell Checker — LanguageTool installiert und gegen meine lokale lokale Instanz laufen lassen.

Natürlich habe ich noch eine Reihe anderer Einstellungen getroffen, aber die habe ich mir nicht explizit notiert.

Habt Ihr Tipps und Hinweise?

Meine Firefox-Addons Ende 2021

Dieser Artikel ist die 2021er Edition des Artikels aus dem letzten Jahr.

Meine Visual Studio Code Plugins Ende 2021

Dieser Artikel ist der Nachfolge-Artikel von diesem hier.

Die Funktionalität des Bracket Pair Colorizer 2 ist mittlerweile im Kern von VSCode enthalten, aus diesem Grund benötige ich das Plugin nicht mehr.

Was sind Eure Empfehlungen?

Minimalkonfiguration Firefox

Da ich gerade mein Notebook neu (mit Fedora) installiere, dachte ich, ich schreibe einmal auf, welche fünf Einstellungen ich minimal bei Firefox konfiguriere, damit ich damit arbeiten möchte.

Natürlich bin ich in diesem Fall ganz besonders an Euren Meinungen und eigenen Konfigurationen interessiert.

Bevor ich noch irgendetwas anderes mache, installiere ich den Werbeblocker uBlock Origin. Von Zeit zu Zeit schalte ich den einmal aus, um festzustellen, dass das Web für mich nicht nutzbar ist ohne eine solche Software.

Wenn ich schon einmal auf den Erweiterungsseiten bin, installiere und konfiguriere ich auch gleich Bitwarden, meinen Passwortmanager.

Im Zuge dessen schalte ich direkt aus, dass Firefox Passwörter speichern soll, ich lasse aber eingeschaltet, dass Firefox mich über gehackte Webseiten informieren soll, die Einstellungen finden sich unter Settings / Privacy & Security / Logins and Passwords.

Als Nächstes stelle ich noch DNS over HTTP ein, das geht über Settings / General / Network Settings / Settings... / Enable DNS over HTTPS / Custom, dort schwanke ich zwischen dnsforge.de (betrieben von einer Privatperson), Quad9 (betrieben von einer Stiftung) und Digitale Gesellschaft (betrieben von einem Verein) als Provider. Achtung: Firefox nutzt als Fallback immer den im System verwendeten DNS-Server. Das lässt sich anders konfigurieren, guckt dazu einmal ins Privacy Handbuch.

Als letzte stelle ich noch ein, dass der Webbrowser nicht mit dem Schliessen des letzten offenen Tabs geschlossen wird, dazu bei Firefox die Seite about:config aufrufen (Achtung: Hier kann man den Browser auch kaputt konfigurieren) und den Parameter browser.tabs.closeWindowWithLastTab auf false setzen.

Natürlich setze ich noch weitere Addons ein, eine Liste der Addons, die ich verwende, wird in einem der Jahresrückblicke nächste Woche veröffentlicht.

Nachtrag: Ein Kommentar von understater hat mich daran erinnert, dass ich natürlich auch die Suchmaschine ändere, von Google auf DuckDuckGo.

etckeeper

linux

Wenn ich einen Rechner neu installiere, ist etckeeper eines der ersten Programme, die ich einrichte. Es stellt das Verzeichnis /etc unter Versionskontrolle und hilft, alte Konfigurationen wieder herzustellen bzw. die Veränderungen einer Konfiguration über die Zeit zu beobachten. Da es einen "Hook" (bzw. ein "Plugin") für die gängigen Paketmanager mit sich bringt und ausserdem täglich automatisch einen commit durchführt, verrichtet es seine Arbeit sehr schön im Hintergrund. Manuelle commits sind natürlich auch noch möglich.

Dazu muss man einfach etckeeper mit dem Paketmanagementtool installieren und zusätzlich noch Git.

apt install etckeeper git
# oder
dnf install etckeeper git
# oder
zypper install etckeeper git

Danach sorgen die beiden folgenden Befehle für die Initialisierung. Wenn man nicht mehr möchte, ist danach alles eingerichtet.

etckeeper init
etckeeper commit -m "Initial"

Bei meinen Systemen gehe ich noch einen Schritt weiter und übertrage die commits auf ein Remote-Repository ("git push"). Dazu legt man sich "irgendwo" ein Git-Repository an und nutzt die folgenden Befehle, um das Repository mit der lokalen etckeeper-Installation zu verheiraten. Aller Wahrscheinlichkeit nach gibt es noch keinen ssh-Key für den root-User der muss natürlich vorgängig erstellt werden. Ich würde diesen Key nur für das Pushen des Repositories verwenden und auf ein Passwort verzichten

ssh-keygen -t ed25519

git remote add origin ssh://user@provider/project/repository.git
git push -u origin master

Abschliessend muss noch in der /etc/etckeeper/etckeeper.conf das Remote-Repository bekannt gegeben werden, damit wird dann auch automatisch gepusht.

PUSH_REMOTE="origin"

Goodbye IRC

Nach sehr vielen Jahren habe ich mich jetzt entschlossen, dem Internet Relay Chat endgültig den Rücken zu kehren. Nein! Doch! Oh!

In den letzten Jahren habe ich mit The Lounge einen eigenen Bouncer betrieben. Das hat wahnsinnig gut funktioniert, aber gebraucht habe ich es selten. Sehr selten.

Und das ist auch der Grund, weshalb ich mich zurück ziehe. Sollte ich noch einmal IRC benötigen, kann ich via Matrix und der entsprechenden IRC Bridge auch wieder teilnehmen. Vermutlich werde ich es aber nicht in Anspruch nehmen müssen.

Bessere Shell-Skripte

Shell-Skripte sind gegenüber anderen Programmiersprachen natürlich nicht das "Non-plus-ultra", aber sie sind für Ablaufsteuerungen - dafür sind sie gemacht - eine gute Wahl. Für alles, was grösser ist, empfehle ich eine "richtige Programmiersprache". Ich bin als Systemadministrator ein grosser Fan von Python und - schon länger nicht mehr genutzt - Perl, aber auch Sprachen wie Raku, Ruby oder irgendetwas mit Compiler sind natürlich gute Alternativen.

Ich beziehe mich im Folgenden auf die Bash, weil das die Shell ist, die ich täglich auf verschiedenen Systemen und Architekturen benutze.

Tipp 1:

Schreibt in den Shebang #! zu Beginn des Skriptes genau die Skriptsprache mit der Ihr auch getestet habt und nicht - weil alle das machen - /bin/sh. Auf Debian basierten Systemen ist /bin/sh ein Link auf dash, bei Alpine ist es ein Link auf Busybox, auf Red Hat basierten Systemen ein Link auf bash.

An dieser Stelle möchte ich gerne noch auf diesen alten Artikel hinweisen.

Tipp 2:

Skripte laufen auch im Falle eines Fehlers weiter. Ich halte das für ein blödes Verhalten, was sehr häufig zu Fehlern führt. Glücklicherweise kann man das Verhalten abstellen.

Entweder man ruft die Shell mit -e auf, setzt den Shebang entsprechend oder schreibt set -e an den Anfang des Skriptes oder vor die Zeilen für die das Setting gelten soll. Mit set +e kann man wieder das alte Verhalten herstellen.

Meine Empfehlung ist, die Langform set -o errexit zu verwenden, das ist deutlich lesbarer. (Altes Verhalten kann man mit set +o errexit wieder herstellen).

Shellzeilen gelten als fehlerhaft, wenn der exit-Code des letzten Kommandos der Zeile ungleich 0 (null) ist. Das bedeutet unter anderem, dass man den Exitcode einer einzelnen Zeile durch Hinzufügen von || true auf "nicht fehlerhaft" ändern kann.

Tipp 3:

Wie im letzten Tipp beschrieben, ist das letzte ausgeführte Kommando einer Zeile ausschlaggebend dafür, ob eine Zeile mit oder ohne Fehlercode beendet wird.

Der Eintrag set -o pipefail sorgt dafür, dass eine Zeile als fehlerhaft "gesehen" wird, wenn auch nur ein Kommando der über Pipes vernetzten Kommandos einer Zeile fehlschlägt.

Tipp 4:

Nicht gesetzte oder "leere" Variablen sind häufig ein Problem.

Um eine nicht gesetzte Variable mit einem Fehler zu quittieren, kann man das Kommando set -o nounset oder set -u verwenden.

Tipp 5:

Es ist generell eine gute Idee, alle Variablen mit doppelten Anführungszeichen zu umgeben, ganz besonders dann, wenn es um Dateien geht. Auch, wenn man selber keine Dateien mit Leerzeichen (oder anderen "Internal Field Separators" (IFS)) erstellt, heisst es nicht, dass man nicht auf solche treffen kann.

Nachtrag:

Christoph hat in diesem Kommentar zur recht darauf hingewiesen, dass es besser ist /usr/bin/env bash zu verwenden, das benutzt die erste Bash, die der Benutzer im Pfad hat und funktioniert auch auf Systemen, auf denen die Bash in einem anderem Pfad liegt als /bin/bash.

Zusammenfassung:

Meine Erfahrung ist, dass man mit den fünf Tipps rund 80% aller Probleme mit Shellskripten umschifft bzw. Skripte mit Fehlern rechtzeitig abbricht.

#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail

# Und Variablen immer mit doppelten Anführungszeichen verwenden.

echo "${Variable}"

Es gibt noch viele weitere Tipps, aber das sind meiner Ansicht nach die wichtigsten.