Skip to content

Monitoring Zwischenintermezzo

Jetzt habe ich schon einen neuen Rechner, kann aber natürlich nicht sagen, wie ich ihn im Normalbetrieb auslaste. Dass die NVMe-Performance sehr gut ist, habe ich ja bereits geschrieben.

Um es vorweg zu nehmen: Gar nicht!

Mehr über den neuen Rechner herauszufinden, ist aber eine gute Gelegenheit, sich einmal mit Prometheus und Grafana auseinanderzusetzen. Im Rahmen der Beschäftigung damit war sehr positiv überrascht, wie leicht das alles ist, zumindest in diesem einfachen Fall.

Disclaimer: Bitte versteht das folgende als "Proof of Concept", um schnell zu einem Ergebnis zu kommen. Benutzt es bitte nicht für ein Produktionssetup auf Servern im Internet.

Ganz bewusst nutze ich keine Pakete, sondern die Binaries von den Webseiten der Hersteller. Wenn ich das Experiment beende, können die Daten und Installationen sehr schnell gelöscht werden.

Hier werde ich keine Einführung in Prometheus geben, dafür gibt es zahlreiche Webseiten, die das schon sehr ausführlich gemacht haben. Für dieses Setup muss man nur so viel wissen, dass Prometheus selber die zentrale Komponente ist, die in regelmässigen einstellbaren Abständen, Daten von den Exportern sammelt und in eine eigene "Time series database" schreibt. Der Node Exporter stellt Daten über Diskbelegung, I/O-Verhalten, CPU, Load, ... und vieles andere mehr zur Verfügung. Grafana greift auf diese gesammelten Daten zu und bereitet sie grafisch in Dashboards auf.

Der Spass beginnt mit der Anlage des Users, mit dem alles laufen soll.

# adduser --system --home /srv/monty --shell /sbin/nologin monty

Danach folgt der Download der nötigen Archive von der Prometheus Download Seite und der Grafana Downloadseite (die ist ein bisschen versteckt).

# mkdir /srv/monty/archive 

# cd /srv/monty/archive 

# curl -LO https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz

# curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.1.2/node_exporter-1.1.2.linux-amd64.tar.gz

# curl -LO https://dl.grafana.com/oss/release/grafana-7.5.3.linux-amd64.tar.gz

Die einzelnen Archive werden ausgepackt und es wird jeweils ein Link auf das ausgepackte Archiv gesetzt. Das macht das Update deutlich einfacher.

# cd /srv/monty

# tar xzf archive/prometheus-2.26.0.linux-amd64.tar.gz

# tar xzf archive/node_exporter-1.1.2.linux-amd64.tar.gz

# tar xzvf archive/grafana-7.5.3.linux-amd64.tar.gz

# ln -s grafana-7.5.3 grafana

# ln -s node_exporter-1.1.2.linux-amd64 node_exporter

# ln -s prometheus-2.26.0.linux-amd64 prometheus

Jetzt noch schnell je ein Verzeichnis für die Grafana- und die Prometheus-Daten anlegen und die mitgelieferten Konfigurationen kopieren. Der Nodeexporter ist "dumm", der plappert wie ein Wasserfall, wenn er gefragt wird.

# cd /srv/monty

# mkdir promdata grafdata

# cp prometheus/prometheus.yml promdata

# cp grafana/conf/defaults.ini grafdata/grafana.ini

In der grafana.ini-Datei sind die folgenden Änderungen vorzunehmen, alles andere muss nicht angefasst werden:

data = /srv/monty/grafdata
logs = /srv/monty/grafdata/log
plugins = /srv/monty/grafdata/plugins
provisioning = /srv/monty/grafdata/provisioning

An die prometheus.yml-Datei muss man nur die folgenden Zeilen hinter - targets: ['localhost:9090'] anhängen:

- job_name: 'terrania'

scrape_interval: 5s

static_configs:

  - targets: ['localhost:9100']

Der Name ist natürlich frei. Prometheus und Node Exporter arbeiten sehr ressourcenarm, daher kann man durchaus alle 5 Sekunden (oder noch öfter) Werte nehmen. Weitere Exporter werden einfach an das Ende der Datei angehängt. Das Standard-Abfrageintervall sind 15 Sekunden.

Abschliessend noch dem User monty alle Dateien und Verzeichnisse übereignen.

# chown -R monty /srv/monty

Bleibt noch systemd, bitte kopiert die folgenden Service-Files nach /etc/systemd/system und führt danach ein systemd daemon-reload aus.

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=monty
WorkingDirectory=/srv/monty/node_exporter
Type=simple
ExecStart=/srv/monty/node_exporter/node_exporter

[Install]
WantedBy=multi-user.target

Bitte beachtet, dass nach den Backslashes "\" nur das Zeilenende kommen darf.

# /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=monty
Type=simple
WorkingDirectory=/srv/monty/prometheus
ExecStart=/srv/monty/prometheus/prometheus \
    --config.file /srv/monty/promdata/prometheus.yml \
    --storage.tsdb.path /srv/monty/promdata \
    --web.console.templates=/srv/monty/prometheus/consoles \
    --web.console.libraries=/srv/monty/prometheus/console_libraries

[Install]
WantedBy=multi-user.target
# /etc/systemd/system/grafana.service
[Unit]
Description=Grafana
Wants=network-online.target
After=network-online.target

[Service]
User=monty
WorkingDirectory=/srv/monty/grafana
Type=simple
ExecStart=/srv/monty/grafana/bin/grafana-server \
    -config /srv/monty/grafdata/grafana.ini \
    -homepath /srv/monty/grafana \
    web

[Install]
WantedBy=multi-user.target

Die Services werden der Reihe nach gestartet und aktiviert.

# systemctl enable --now node_exporter

# systemctl enable --now prometheus

# systemctl enable --now grafana

Eventuell auftretende Fehler systemctl status node_exporter prometheus grafana sollten natürlich behoben werden.

Grafana lässt sich nun über localhost:3000 aufrufen. Im Standard sind Username und Passwort auf "admin" gesetzt.

Um die ersten bunten Bilder zu sehen, muss noch eine Datasource und ein Dashboard angelegt werden.

Als Datasource solltet Ihr über das Zahnrad und "Data Sources" den Eintrag "Prometheus" auswählen. Prometheus hört standardmässig auf Port 9090, ich musste die komplette URL angeben, das "Scrape interval" habe ich auf "5s" gesetzt.

Als Dashboard empfehle ich den Import von 1860 und die Angabe der gerade konfigurierten Datenquelle Prometheus.

Ich wundere mich immer wieder, dass die CPU-Werte ganz oben angezeigt werden und nicht die aussagekräftigere "System Load".

Abschliessende Anmerkung: Einige von Euch wundern sich vermutlich über die Links, die ich gesetzt habe. Als ich den Artikel geschrieben habe, habe ich auch gleich ein Update von Prometheus und Grafana eingespielt, das funktioniert wie folgt:

# cd /srv/monty/archive

# curl -LO https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz
# curl -LO https://dl.grafana.com/oss/release/grafana-7.5.3.linux-amd64.tar.gz

# cd ..

# tar xzf prometheus-2.26.0.linux-amd64.tar.gz
# tar xzf grafana-7.5.3.linux-amd64.tar.gz

# systemctl stop grafana 
# rm grafana 
# ln -s grafana-7.5.3 grafana 
# systemctl start grafana

# systemctl stop prometheus 
# rm prometheus 
# ln -s prometheus-2.26.0.linux-amd64 prometheus 
# systemctl start prometheus

Wenn man das alles in eine Zeile schreibt, dauert der Teil Stoppen, Link ändern und Starten deutlich unter einer Sekunde.

Viel Spass, bin gespannt auf Eure Kommentare.

Disk Performance

Der neue Rechner ("terrania") ist mittlerweile da und läuft.

Die Performance NVMe vs. SSD beim fünf Jahre alten Notebook ("crest") ist schon beeindruckend:

$ grep IOPS crest.rand*
crest.randread.txt:  read: IOPS=94.5k, BW=369MiB/s (387MB/s)(4096MiB/11096msec)
crest.randrw.txt:  read: IOPS=63.4k, BW=248MiB/s (260MB/s)(3070MiB/12391msec)
crest.randrw.txt:  write: IOPS=21.2k, BW=82.8MiB/s (86.8MB/s)(1026MiB/12391msec); 0 zone resets
crest.randwrite.txt:  write: IOPS=66.6k, BW=260MiB/s (273MB/s)(4096MiB/15734msec); 0 zone resets

$ grep IOPS terrania.rand*
terrania.randread.txt:  read: IOPS=391k, BW=1528MiB/s (1602MB/s)(4096MiB/2681msec)
terrania.randrw.txt:  read: IOPS=254k, BW=992MiB/s (1040MB/s)(3070MiB/3094msec)
terrania.randrw.txt:  write: IOPS=84.9k, BW=332MiB/s (348MB/s)(1026MiB/3094msec); 0 zone resets
terrania.randwrite.txt:  write: IOPS=117k, BW=458MiB/s (480MB/s)(4096MiB/8939msec); 0 zone resets

Es werden drei Tests durchgeführt: "random read", "random read/write" (75% read, 25% write) und "random write". Spannend ist, dass das Lesen generell vier Mal schneller ist, vom alten zum neuen Rechner. Im Mix ist auch das Schreiben vier Mal schneller. Beim ausschliesslichen Schreiben ist der Neue aber "nur" noch knapp doppelt so schnell.

Als Tool kommt fio - Flexible IO Tester zum Einsatz. Wenn jemand eine bessere URL kennt, nur her damit. FIO ist in den meisten Distributionen enthalten.

Über synthetische Tests kann man natürlich geteilter Meinung sein, die Werte geben aber einen guten Anhaltspunkt für Vergleiche.

Ich benutze dieses kleine Skript, um die Daten zu sammeln.

#!/bin/bash

echo randrw
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 --output=$(hostname --short).randrw.txt --output-format=normal
[[ -r test ]] && rm test
echo

echo randread
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread  --output=$(hostname --short).randread.txt --output-format=normal
[[ -r test ]] && rm test
echo

echo randwrite
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite --output=$(hostname --short).randwrite.txt --output-format=normal
[[ -r test ]] && rm test
echo

Repositories zusammenführen

Meine Daten, unter anderem den Schriftverkehr, meine Präsentationen und kleinen Skripte, verwalte ich in Git-Repositories (Mehrzahl). Nach längerer Diskussion bin ich zu der Einsicht gekommen, dass es sinnvoller ist, alles in einem einzigen Repository zu haben.

Natürlich möchte ich dabei die Historie nicht verlieren.

Der folgende Weg löst den Import für mich.

Ergänzungen von Euch sind mir jederzeit willkommen.

Im Source-Repository (ausgescheckt nach presentations.git):


$ cd presentations.git

$ tomove=$(ls -1a | egrep -v '^(.|..|.git)$' | xargs)

$ mkdir presentations

$ git mv $tomove presentations

$ git commit -am "Vorbereitung für den Merge"

$ git push

$ cd ..
 

Im Destination-Repository (ausgecheckt in main.git):


$ cd main.git

$ git remote add -f presentations URL/presentations.git

$ git merge --allow-unrelated-histories presentations/master

$ git push

$ git remote remove presentations
 

Ungoogled Chromium

Auf meinem privaten Hauptarbeitsrechner habe ich mir einmal verschiedene Browser angeschaut, darunter Brave, Chrome, Opera und Vivaldi. Dabei habe ich festgestellt, dass alle Browser, die auf Chrome basieren auf meiner fünf Jahre alten Hardware schneller waren als der Firefox, den ich sonst benutzt habe.

Da ich es immer noch etwas spooky finde, meinen Browser einer Firma anzuvertrauen, bei der ich jeweils nicht weiss, was mit meinen Browsing-Daten passiert, habe ich mich nach Alternativen umgeschaut. Früher habe ich einmal Iridium als Zweitbrowser verwendet, der scheint aber nicht mehr weiterentwickelt zu werden. Bei meiner Recherche bin ich dann auf Ungoogled Chromium gestossen, der sehr viel versprechend aussieht. Ich habe dern Browser auch in der TILpod Episode 5 als Tooltipp genannt.

"Ungoogled" bedeutet auch, dass der Browser ohne Zugriff auf den Webstore für die Erweiterungen kommt. Dafür gibt es aber mit dem chromium-web-store-Plugin, das sich manuell installieren lässt, eine Abhilfe. Generell ist es eine gute Idee, sich die FAQ des Browsers anzuschauen.

Fazit für mich nach einer Woche ausschliesslicher Nutzung: Der Browser ist eine echte Alternative zu Firefox er hinkt Chrome um weniger Versionsnummern hinterher, funktioniert aber bestens. Es gibt Repositories für das rpm- oder deb-Paketformat oder AppImage für andere Linux-Distributionen (auch Binaries für MacOS und Windows).

Aber: Beim Benutzen von Ungoogled Chromium habe ich gemerkt, dass ich einige Features von Firefox wirklich vermisse und ich deswegen auch wieder zurück zum Firefox wechsele. (Ein Hardware-Upgrade wird ja in den nächsten Wochen kommen).

Rolle von Linux Distributionen

gedanken Ich weiss, dass das eine streitbare Meinung ist und bin auf Eure Ansichten gespannt.

Meiner Meinung werden Distributionen zunehmend keine Rolle mehr spielen.

Meine privaten Server laufen auf CentOS 7 und ich werde sie auf Ubuntu 20.04 migrieren.

Um aktuelle Applikationen unter CentOS betreiben zu können, habe ich zusätzliche Repositories aktivieren müssen. Andere Applikationen - es sind genau zwei - betreibe ich mit Containern unter Docker, wohlgemerkt nicht das Docker aus CentOS, sondern die Community-Edition von Docker selber. Weitere Repos sind die Remi-Repositories (für PHP), EPEL und MariaDB. Ja, ich kenne die Software Collections, ich habe aber vom Einsatz abgesehen, weil sie sich nicht so "sauber" in das System integrieren, wie die anderen Repos.

Zwischenfazit: Je länger die Laufzeit einer Distribution ist, desto mehr "Kunstgriffe" muss man unternehmen, um aktuelle Applikationen betreiben zu können. Das bedeutet im Umkehrschluss, dass von der Basis-Distribution immer weniger "übrigbleibt".

Jetzt ist es aber so, dass auch nicht alle Applikationen mit neueren Paketversionen zurechtkommen. Meine Blogsoftware tut sich beispielsweise mit neuen PHP-Versionen schwer, das Entwicklungsteam ist einfach zu klein. Das führt dazu, dass man mindestens zweigleisig fahren muss.

In der Firma setzen wir Red Hat Enterprise Linux ein, weil es die Distribution mit den meisten Zertifizierungen für Business-Software ist. Einer der Gründe dafür ist, dass die Firma über einen langen Zeitraum API-Kompatibilität garantiert. Das ist für Business-Software toll, für aktuelle "Free/Libre Open Source Software" (FLOSS) oder Eigententwicklungsn aber nicht.

Das führt unter anderem dazu, dass wir den Applikationen beibringen, dass sie ihre Applikation bitte möglichst unabhängig vom Basisbetriebssystem betreiben sollen, um von unseren Patchzyklen unabhängig zu sein. Wir würden gerne häufiger Patchen, aber wir bekommen die Downtimes nicht. Bei uns durchlaufen die Patches auch die verschiedenen Betriebsstufen und müssen wenigstens zwei Monate in Acceptance sein bevor sie in Produktion gehen.

Wenn ich die Zeit hätte, würde ich privat auf Alpine Linux wechseln und alles mit Containern betreiben, im Basis-OS würde dann nur ein Reverse-Proxy (Caddy, beispielweise) und vielleicht die Datenbanksoftware laufen.

Das gilt für den Desktop in einem ähnlichen Mass. Da kommt zum Basisbetriebssystem noch die Desktopumgebung dazu, die vielleicht von "der Distribitution" bereit gestellt wird. Applikationen kommen mehr und mehr in Distributions-übergreifenden Formaten wie Snaps, Flatpaks oder AppImages.

Die Kehrseite ist, dass wir dadurch von Unix-Errungenschaften wie Shared Libraries Abstand nehmen und das Patching dadurch ungleich aufwendiger wird. Bei einer Schwachstelle in einer Shared Library muss ich sie nur ein Mal patchen, bei Containerformaten, gekapselten Applikationen und autonomen Anwendungen muss ich jede einzelne Instanz aktualisieren (lassen).

Der Gewinn ist ungleich grösser, wenn Anwendungen - wie oben beschrieben bereit gestellt werden - laufen sie auf jeder Distribution, die die Laufzeitumgebung zur Verfügung stellt. Das wiederum beschert den Entwicklern die Möglichkeit, ihre Anwendung für alle Distributionen gleichzeitig bereitstellen zu können.

In Summe führt das dazu, dass das Basis-Betriebssystem nur noch sehr klein sein muss und eine deutliche kleinere Rolle als bisher spielt.

Visual Studio Code Plugins

Es reicht ja, wenn es eine Person interessiert (Hallo Oliver!).

Hier kommen die Visual Studio Code Plugins, die ich beruflich und / oder privat einsetze.

Der grösste Unterschied ist, dass ich beruflich alle Plugins bis auf Remote SSH remote einsetze und nicht lokal, da ich mich den ganzen Tag mit VSCode nur auf dem Jumpserver befinde. Das Bearbeiten findet lokal auf Windows mit Dateien unter Linux statt.

  • Nur Job: Remote - SSH, um über SSH auf Dateien zuzugreifen und diese zu bearbeiten.
  • Nur Job: Remote - SSH: Editing Configuration Files, wird automatisch vom vorherigen Plugin mitinstalliert.
  • Bracket Pair Colorizer 2 finde ich enorm praktisch, weil es zu jeder Klammer die korrespondierende in der gleichen Farbe anzeigt.
  • GitLens erweitert den eingebauten Git-Client um einige sinnvolle Features.
  • Nur privat: LaTeX language support, weil ich privat viel mit LaTeX mache. Dieses Plugin hat den Vorteil, nicht automatisch die Dateien zu übersetzen.
  • Markdown All in One bringt hilfreiches rund um Markdown mit (ich möchte deutlich mehr mit Markdown machen).
  • markdownlint weist auf unschönen Markdown-Quellcode hin.
  • Python für die Entwicklung von Python-Skripten.
  • Jupyter wird von Python mit installiert, brauche ich nicht.
  • Spell Right benutze ich zur Rechtschreibkontrolle.

Welche Plugins nutzt Ihr und warum nutzt Ihr sie?

Threema App wird quelloffen

Kaum kommt die Meldung, dass der Quelltext des Threema-Clients offen liegt, kommen die Bedenkenträger, dass das kein Grund zur Freude wäre, so lange der Quelltext des Servers noch nicht offen ist.

Zwei Anmerkungen dazu und auch gleichzeitig eine Einladung zur Diskussion.

  1. Haben wir verlernt, uns über Teilerfolge zu freuen? Muss es immer 100% sein? Kein Wunder, dass wir es uns immer schlechter gehen lassen, wir tragen selber die Schuld daran.
  2. Auch, wenn der Quelltext der Serverkomponente offen liegt, gibt es keine Garantie dafür, dass der Quelltext die Basis für den Server ist, der auf Seiten des Betreibers läuft. Ich setze als Blogengine Serendipity ein. Ihr müsst mir glauben, dass das so ist und keine von mir abgewandelte Variante der Software.

Wenn man etwas nicht selber macht, muss man darauf vertrauen, dass es sich so verhält wie behauptet.

Nebenbei: Auch die App müsste man selber bauen, um sicher zu sein, dass die App auf dem Handy aus dem offen gelegten Quelltext gebaut wurde.

Applikationen unter Linux am Beispiel CentOS

centos Aus CentOS 8 wird CentOS Stream.

Über die Meldung, dass CentOS 8 zugunsten von CentOS Stream einstellt, habe ich mich sehr geärgert. Ich war sogar richtig gehend angepisst.

CentOS war immer die Möglichkeit, eigene Dinge auf Red Hat Kompatibilität zu testen, ohne Subskriptionskosten (für das Patching) bezahlen zu müssen.

Leider hat es das CentOS-Team mit der Version 8 nicht geschafft, zeitnah auf Updates und Hotfixes durch Red Hat zu reagieren und ist aus diesem Grund auch nicht mehr meine Distribution der Wahl. Mein Kram wird im Lauf der nächsten Wochen und Monate auf Ubuntu LTS migriert.

Machen wir uns aber bitte nichts vor. CentOS ist keine "schöne" Linux-Distribution. Das Tooling ist nicht so berühmt. Durch die lange Unterstützung und die durch Red Hat versprochene API-Kompatibilität über die ganze Laufzeit veraltet Software in Red Hat Enterprise Linux (RHEL) und damit auch in CentOS sehr schnell. (Gilt übrigens für andere paketbasierte Distributionen im gleichen Mass, die helfen sich nur mit häufigeren Releases).

RHEL (CentOS) möchte man eigentlich nur aus genau einem Grund einsetzen, nämlich, dass nahezu jede Business-Software für RHEL zertifiziert wird. Und aufgrund der versprochenen Kompatibilität ist es nahezu garantiert, dass sie auch über die komplette Laufzeit das Major-Releases von zehn Jahren bzw. 13 Jahren mit extended Support auch lauffähig bleibt.

Wenn man aktuelle Open-Source-Software auf CentOS einsetzen möchte, so konnte man sich nur dadurch behelfen, dass man entweder darauf vertraut hat, dass die irgendwann in den Software-Kollektionen aufgeschlagen ist, da wurde sie dann "neben" der Basisinstallation installiert oder dass man externe Repositories verwendet hat. Bei meinen Servern habe ich beispielsweise PHP aus den Remi Repositories, sowie Docker und MariaDB direkt vom Hersteller bezogen.

Das hat auch Red Hat erkannt und mit Version 8, Modules oder "Application Streams" eingeführt. Hier gibt es eine sehr gute englischsprachige Erklärung dazu. Kurz zusammengefasst, lassen sich mit diesem Konzept mehrere Versionen der gleichen Software parallel installieren und auch benutzen.

Vermutlich hat dieses neue Konzept die Ressourcen vom CentOS-Projekt gesprengt, ich habe keinen Beweis für diese Vermutung. Für mich ist dieses Konzept aber nur ein Zwischenschritt auf dem Weg, das Basis-Betriebssystem komplett vom Applikationsteil zu trennen.

Im Grossen und Ganzen: Kernel, Netzwerk, Infrastruktur (Backup, Authentifizierung, ...) macht die Distribution und den ganzen Rest können Applikationen alleine besser.

Wenn wir die Distributionen nur als stabile Basis ansehen, auf der wir Dienste mit den Hersteller-Repositories (Docker, MariaDB, ...) oder Snaps, Flatpaks und AppImages oder Containern (Docker, Podman, ...) aufsetzen, dann würden wir allem gerecht werden.

Es entspricht einer Trennung von Applikation und Plattform, die in vielen Firmen trotz DevOps immer noch betrieben wird. DevOps bezieht sich im Grossen und Ganzen auch mehr auf Applikationsentwicklung und -betrieb. DevOps (oder EngOps) für die Plattformentwicklung ist davon getrennt.

Wenn wir diese Sichtweise weiterspinnen, werden paketbasierte Linuxdistributionen obsolet.

Wohin das in Summe führen kann, sehen wir mit Kubernetes (und OpenShift) oder durch den Einsatz von Containern (mit Docker oder Podman oder ...).

Kubernetes ist es egal, auf welchem linuxbasierten OS es läuft, wenn die Voraussetzungen gegeben sind. Den Leuten, die Kubernetes benutzen (nicht verwalten), ist die komplette Infrastruktur darunter egal, so lange das Cluster zur Verfügung steht.

Und, die alten erinnern sich, das hatten wir schon einmal, aber nicht ganz so ausgereift.

Java hat den Ruf (weitestgehend) plattformunabhängig zu sein. Klar, dafür muss man mit der Runtime (JRE) oder dem JDK auch ein halbes OS mitinstallieren. Darauf kann man Applikationsserver wie Tomcat, JBoss, Weblogic, Websphere, ... betreiben und auch da gab es das Versprechen, sich nicht um die darunter liegenden Schichten kümmern zu müssen.

Meiner Meinung nach wurde dieses Versprechen nie komplett eingelöst, obwohl sehr viele gute Konzepte vorhanden waren.

Mit Containern und Orchestrierungslösungen sind wir aber der Erfüllung dieses Versprechens einen Schritt näher gekommen.

Bin an Euren Meinungen und einer Diskussion darüber sehr interessiert.

Quo vadis OpenRheinRuhr?

Meine Heimatkonferenz bittet um Feedback für künftige Konferenzen. Mir ist das zu viel für einen Kommentar im Blogartikel der OpenRheinRuhr, daher hier als eigenständiger Blogeintrag bei mir.

Welche Erwartungen habt ihr an die OpenRheinRuhr?

Kurz gesagt: Leute treffen, Vorträge erleben, Kaffeeflatrate.

Dazu kommt, dass ich es wichtig finde, dass es in meiner Heimat eine Konferenz, die sich rund um FLOSS dreht, gibt.

Was würdet ihr gerne wieder sehen?

Alte Bekannte und viele neue Bekannte.

Worauf könnt ihr verzichten?

Da fällt mir auch nach längerem Überlegen nichts ein.

An welcher Location könnt ihr euch eine OpenRheinRuhr vorstellen?

Eine Location, die zur Industriekultur des Ruhrgebiets gehört, ist natürlich grossartig und bringt vielen Menschen, die nicht aus dem Ruhrgebiet kommen, die Geschichte nahe.

Tatsächlich finde ich aber, dass die Location nicht so wahnsinnig wichtig ist für den Erfolg der Konferenz. Apropos Erfolg, wie will man den eigentlich messen? Die Atmosphäre wird von Menschen gemacht.

Kulturzentren würde funktionieren - so wie beispielsweise bei der aller ersten Konferenz. Wichtig ist, dass der Veranstaltungsort gut mit dem Öffentlichen Personen Nah- und Fern-Verkehr, also vielleicht in Nähe eines Bahnhofs, erreichbar ist.

Könntet ihr euch eine OpenRheinRuhr ohne Aussteller vorstellen?

Das fällt mir schwer, Aussteller gehören dazu und helfen Interessierten, sich vor Ort engagierten Menschen ohne Zeitdruck informieren zu können.

Könntet ihr euch eine OpenRheinRuhr ohne Vorträge vorstellen?

Nein, die sind für mich elementar. Wenn es keine Vorträge gäbe, würde ich nicht kommen.

Könntet ihr euch eine OpenRheinRuhr mit einem längeren thematischen Fokus vorstellen?

Was meint Ihr mit "länger"? Einen Track zu einem bestimmten Thema oder die ganze Konferenz unter ein Motto zu stellen?

Ja, das könnte ich mir vorstellen, wenn nicht sklavisch daran festgehalten wird. Es sollte meiner Ansicht nach immer Raum für Neues geben.

Könntet ihr euch eine OpenRheinRuhr vorstellen, die länger dauert (zum Beispiel Freitags, Samstags, Sonntags)?

Kann ich mir gut vorstellen und ich vermute, dass man durch eine Ausdehnung auf einen Wochentag auch Firmen gewinnen könnte. Diese sehen Konferenzen am Wochenende nur als Hobby und unterstützen potentielle Teilnehmer und Teilnehmerinnen aus eigenem Haus kaum.

Hobbyisten würde vermutlich nur am Wochenende kommen und Firmeninteressierte vermutlich nur am Freitag, es gibt natürlich (geringe) Überschneidung.

Ich würde mir den Urlaub nehmen und an allen drei Tagen dabei sein.

Würdet ihr für eine OpenRheinRuhr auch größere Eintrittsbeiträge bezahlen?

Ja, das würde ich. Allerdings wäre mir wichtig, dass sichergestellt wird, das finanziell schwächer gestellte Menschen trotzdem teilnehmen dürfen.

Und sonst?

Mir würde es gut gefallen, wenn die Vorträge aufgezeichnet würden, im Zuge dessen, was wir in den letzten Monaten mitmachen, wäre ein Livestreaming sogar das Nonplusultra - wobei ich da eher nicht zur Zielgruppe gehöre.

Blogeinträge in Mastodon ankündigen

Das Teilen von Links nach Mastodon klappt mit der Firefox-Extension Mastodon Share schon sehr gut. Bei Feeds wäre es nur klasse, wenn das automatisch passiert.

Auf Anregung von Lioh habe ich mir feed2toot angeschaut, endlich einmal ein Tool mit ausführlicher Dokumentation.

Bei Python-Skripten, die nicht mit der eingesetzten Distribution mitgeliefert werden oder die man möglichst aktuell benutzen möchte, lohnt sich die Installation mit pip.

$ python3 -m venv ~/venv/feed2toot
$ source ~/venv/feed2toot/bin/activate

$ pip install --upgrade pip
$ pip install feed2toot

Im nächsten Schritt muss man feed2toot als App in Mastodon registrieren und bekommt nach Registrierung die Client- und User-Credentials zurück.

$ mkdir -p ~/workspace/feed2toot

$ register_feed2toot_app

$ mv feed2toot_clientcred.txt feed2toot_usercred.txt ~/workspace/feed2toot

Meine feed2toot.init-Datei sieht folgendermassen aus:

[mastodon]
instance_url=https://social.anoxinon.de
user_credentials=/home/dirk/workspace/feed2toot/feed2toot_usercred.txt
client_credentials=/home/dirk/workspace/feed2toot/feed2toot_clientcred.txt

[cache]
cachefile=/home/dirk/workspace/feed2toot/feed2toot.db
cache_limit=10000

[lock]
lock_file=/home/dirk/workspace/feed2toot/feed2toot.lock
lock_timeout=3600

[rss]
uri=https://www.deimeke.net/dirk/blog/index.php?/feeds/index.rss2
toot={title} - {link}\n{summary:400}
no_uri_pattern_no_global_pattern=true

[hashtaglist]

[feedparser]
accept_bozo_exceptions=true

[media]

Beim Aufbau des toot-Parameters haben mir die folgenden beiden Kommandos geholfen:

$ feed2toot --rss-sections -c ~/workspace/feed2toot/feed2toot.ini

$ feed2toot --dry-run -c ~/workspace/feed2toot/feed2toot.ini

Wenn alles in Ordnung ist, kann der Cache einmalig gefüllt werden, damit nicht gleich alle Feedartikel veräffentlicht werden.

$ feed2toot --populate-cache -c /home/dirk/workspace/feed2toot/feed2toot.ini

Wenn alles wie gewünscht funktioniert, baut man sich ein Miniskript, macht es ausführbar und führt es via Cron regelmässig aus.

#!/bin/bash
set -o errexit

source /home/dirk/venv/feed2toot/bin/activate

/home/dirk/venv/feed2toot/bin/feed2toot -c /home/dirk/workspace/feed2toot/feed2toot.ini

Mitarbeit an FLOSS zu Hause

Seit reichlich Jahren engagiere ich mich für Free/Libre Open Source Software (kurz FLOSS). Viele der Dienste oder viel von der Software, die die "normalen" Menschen jetzt zum ersten Mal sehen, nutze ich schon seit Jahren, weil eine interkontinentale Zusammenarbeit sonst gar nicht möglich wäre.

Viel von dem, was viele früher für "nerdiges Zeug" oder Werkzeuge für Geeks gesehen haben, gehört heute zur Normalität. Das ist prima und ein grosser Erfolg. Ich hoffe, das Verständnis bleibt über die derzeitige Zwangslage hinaus.

In dem Zusammenhang habe ich häufig den Kommentar gelesen: "Ach so, das, was ich mache, nennt sich jetzt Quarantäne". Tut mir leid, so ist es nicht. Wenn man etwas freiwillig wählt, dann komplett unterschiedlich zu einem Zwang, etwas machen zu müssen.

Nebenbei: Man kann auch als "non-coding-contributor" (nicht-programierender Unterstützer) zu FLOSS-Projekten beitragen. Dass das geht, seht Ihr an mir. Ich habe vor einigen Jahren auch einen Vortrag darüber gehalten.

Komische Ideen

In Zeiten von "viel zu Hause sein müssen" kommen mir schon einmal komische Ideen. Tatsächlich habe ich mit dem Gedanken gespielt, ein neues Blog mit Bashblog anzulegen, um mit Euch ein paar Ideen und Beobachtungen zu teilen, die mir rund um das zwangsweise (!) Arbeiten zu Hause durch den Kopf gehen.

Da aber dieses Blog nicht so wahnsinnig aktiv ist, mache ich das lieber hier. Das tut mir gut und hoffentlich auch Euch ;-)

In der Regel werden das nur sehr kurze Artikel werden, dafür mache ich dann lieber mehr davon.

Es werden also einige Artikel mit dem Tag remotework versehen werden. Ich bin sehr auf Eure Kommentare gespannt.

Bildschirm teilen mit Jitsi unter Fedora

Fedora setzt als Default Wayland als Display-Server Protokoll ein. Leider funktioniert damit das Teilen des Bildschirms via Jitsi nicht.

Um das Protokoll - zumindest für diese Zeit mit vielen Videokonferenzen - auszuschalten, genügt es, Wayland in der Datei /etc/gdm/custom.conf auszuschalten, so dass wieder X11 verwendet wird. Danach muss die Maschine neu gestartet werden.

WaylandEnable=false

Update: Vereine, die FLOSS-Dienste anbieten

Nicht nur als Vorbereitung für meinen Vortrag auf den Chemnitzer Linux-Tagen, nein, auch generell wollte ich den Artikel Vereine, die Floss-Dienste hosten aktualisieren.

Grossartig ist, dass die Dienste, die ich im damaligen Artikel erwähnt habe, auch heute noch aktiv sind. Das spricht für die Vereine bzw. Organisationen. Ich führe sie weiter unten der Vollständigkeit halber auf.

An dieser Stelle möchte ich gerne zusätzlich darauf hinweisen, dass es auch viele Privatpersonen gibt, die Dienste, die auf FLOSS basieren, anbieten.

Bei meiner Frage via Mastodon sind ein paar neue Dienstanbieter empfohlen worden.

Neu dazugekommen: Update durch Kommentare oder Anmerkungen im Fediverse: Die "grossen Alten":

Server OS LifeCycle

linux

Meine Server laufen seit etwa fünf Jahren unter CentOS 7. In der Zeit gab es ordentlich Updates und tatsächlich keine Probleme, die auf der Software basierten.

Eigentlich läge damit CentOS 8 als neues Betriebssystem für die Server nahe. Allerdings schreibt schon Michael Kofler, dass CentOS 8 über sechs Wochen ohne Updates war und wirft Oracle Linux in die Waagschale.

Das hört sich auf den ersten und zweiten Blick komisch an, ist es auch. Aber Oracle bietet sein Linux als FLOSS-Lösung an, die gratis ist, solange man kein System hat, bei dem man für den Support durch Oracle bezahlt. In dem Fall werden alle Instanzen kostenpflichtig. Komisches Modell, oder?

Nebenbei: Ich nutze sehr gerne VirtualBox, ebenfalls von Oracle, da muss man aufpassen, dass sich die Lizenzbestimmungen mit der Nutzung des Extension Packs ändern.

Also, was tun?

Der Vorteil von CentOS war und ist, dass es sehr lange (rund zehn Jahre) unterstützt wird und tatsächlich bin ich auch noch nicht in der Not zu wechseln. Der Support für CentOS 7 läuft erst am 30. Juni 2024 (Tabelle) aus, also erst in viereinhalb Jahren. Der Nachteil ist, dass CentOS über die Lebenszeit garantiert, API-kompatibel zu bleiben, was zum Teil in sehr alter Software resultiert (Tabelle bei DistroWatch. Das wiederum bedeutet, dass man reichlich Fremdrepositories verwenden muss - bei mir EPEL, die Remi-Repostitories für PHP und Repos für MariaDB - um halbwegs aktuelle Webanwendungen betreiben zu können. Das Web ist voll von Fragen, wie man eine bestimmte Software unter CentOS zum Laufen bekommt.

Also Plan A ist, bei CentOS zu bleiben. Die "Synergien" zwischen dem, was ich beruflich mache(n muss), nämlich Red Hat Enterprise Linux zu betreiben, und dem, was ich dann privat mache, sind schon sehr gross. Bedingung dafür wäre, dass es regelmässiger Updates gibt.

Plan B wäre, die Distribution zu wechseln, hier bieten sich quasi sofort Ubuntu und Debian an, wobei ich im Fall eines Wechsels zu Debian tendieren würde.

Es gibt natürlich noch einen Plan C, das wäre ein Docker (bzw. Podman) basiertes Setup. Mich würde sehr reizen, das mit Alpine Linux als Basis zu versuchen. Eine Alternative könnte sogar Fedora Core OS sein.

Kein Plan D, aber eine interessante Alternative könnte tatsächlich Fedora in der Server-Variante sein. Allerdings sind die Wechsel zwischen den halbjährlichen Releases schon sehr drastisch und bedürfen der ständigen Nacharbeit (vermute ich). Fedora auf dem Desktop ist super (langweilig), das funktioniert einfach richtig gut, selbst mit aktiviertem SELinux sind keine Nacharbeiten nötig.

Jetzt Ihr. Was wären Eure Empfehlungen? Viel wichtiger als "was" wäre mir das "warum" Ihr ein bestimmtes Server-OS empfehlt. FreeBSD oder OpenBSD wären auch noch nachdenkenswerte Varianten.