CleanPress

Kategorie: Softwareperlen

  • Bildbearbeitung: Hintergründe mit Rembg entfernen

    Bildbearbeitung: Hintergründe mit Rembg entfernen

    Wer kennt es nicht: Hintergründe aus Bildern entfernen ist mit GIMP immer eine größere Aktion, besonders für Ungeübte. Dabei kann es viel einfacher sein, wenn man sich auf die Konsole einlässt und das kleine Tool Rembg einsetzt.

    Hintergründe mit AI entfernen

    Rembg steht für Remove Backgrounds und ist eine Python-Bibliothek. die genau das und nur das macht. Mit Rembg lassen sich Hintergründe automatisch mittels AI aus Bildern oder ganzen Verzeichnissen mit Bildern entfernen. Dazu bedient sich das Tool bei dem Machine-Learning-Projekt PyTorch und der Mustererkennungs-Software U2-Net. Rembg wird auf GitHub gepflegt.

    Ab Python 3.8

    Voraussetzung für Rembg ist mindestens Python 3.8. Am einfachsten installiert ihr Rembg mit Pip, dem Package-Installer für Python-Pakete. Dazu müsst ihr, falls noch nicht vorhanden, das Paket python3-pip über euer Paketmanagement installieren. Darauf folgt: 

    pip install torch==1.7.1+cpu torchvision==0.8.2+cpu -f https://download.pytorch.org/whl/torch_stable.html

    und abschließend 

    pip install rembg

    Dann kann es auch schon losgehen. Die Syntax für lokale Bilder lautet:

    rembg -o ./output-image.png ./input-image.jpg

    oder für ein Verzeichnis:

    rembg -p <input_directory> <output_directory>

    Ihr könnt aber auch Bilder im Netz freistellen:

    curl -s https://input.png | rembg > output.png

    Ergebnis immer als PNG

    Bei der ersten Anwendung von Rembg ist etwas Zeit gefragt, da im Hintergrund Muster heruntergeladen werden. Danach arbeitet das Tool recht flott. Auch wenn der Input als JPEG vorliegt, muss das Resultat immer ein PNG sein, da als JPEG der Hintergrund nicht transparent, sondern weiß dargestellt würde. Natürlich lässt sich Rembg auch in Scripten verwenden.

    Um Hintergründe aus Videos zu entfernen, empfiehlt der Autor Daniel Gatis den Fork Rembg-Greenscreen. Gatis hat Rembg selbst in weiteren Projekten wie Facematch oder Docscan eingesetzt.

    Dank geht an Jens für den Tipp zu Rembg

  • Open Source-Software zur Blutdruckverwaltung

    Open Source-Software zur Blutdruckverwaltung

    Wessen Blutdruck in diesen Zeiten nicht ab und zu ansteigt, der hat vermutlich nicht mehr viel Leben in sich. Wenn dieser Zustand aber chronisch wird, bedarf der Blutdruck der Überwachung. Ein Leser hat mich auf eines seiner Projekte hingewiesen, das die Verwaltung der gemessenen Werte als Open Source erledigt und gängige Hardware zur Blutdruckmessung unterstützt. Die Software heißt Universal Blood Pressure Manager (UBPM) und wird auf Codeberg gepflegt. Der Einfachheit halber veröffentliche ich einfach die Mail von Entwickler Thomas Löwe (LazyT) an mich:

    Ich möchte euch heute auf ein vielleicht für eure Leser interessantes Projekt hinweisen: Universal Blood Pressure Manager.

    Es handelt sich dabei um eine kostenlose, quelloffene und plattformübergreifende Desktop-Software basierend auf Qt5 für die Betriebssysteme Windows/Linux/macOS zum Verwalten von Blutdruckdaten. Als Sprache kann derzeit DE/EN/FR/NL/NO/ES gewählt werden. Werbung oder Ähnliches gibt es nicht, es werden auch keinerlei Daten ins Internet übertragen. Lediglich für die (optionale) Online-Aktualisierung wird eine Internetverbindung benötigt.

    Eine Installation ist nicht erforderlich, man lädt einfach das Paket für sein Betriebssystem (WIN = exe, LIN = AppImage, MAC = dmg) und startet es. Alle Abhängigkeiten sind dort bereits integriert, Hersteller-Treiber für die derzeit unterstützten Messgeräte von Beurer/Hartmann/Omron sind ebenfalls nicht erforderlich.

    Damit können dann Blutdruckwerte:

    • manuell eingegeben, aus einer Datei (csv, xml, json, sql) importiert oder direkt von unterstützten Messgeräten ausgelesen werden
    • in eine Datei (csv, xml, json, sql) exportiert werden
    • als Diagramm, Tabelle oder Statistik dargestellt werden
    • für den Arzt ausgedruckt oder direkt gemailt werden
    • per SQL-Analyse ausgewertet werden (z.B. zeige alle Messungen deren Systolischer Wert > 130 und Diastolischer Wert > 85 war)

    Das Programm verfügt über eine Erweiterungsschnittstelle, über welche Blutdruckmessgeräte beliebiger Hersteller mit PC-Anbindung (USB, Bluetooth) eingebunden werden können. Dazu muss allerdings erstmal deren Übertragungsprotokoll bekannt sein. Vielleicht findet sich so ja sogar der ein oder andere Programmierer, welcher sein Messgerät bereits „gehackt“ hat und ein Plugin beisteuern könnte? Man muss den Messgeräte-Herstellern mit Ihren Cloud-Lösungen ja nicht unbedingt seine sensiblen Gesundheitsdaten anvertrauen. Meist wird auch noch Windows vorausgesetzt, das muss doch nun wirklich nicht sein.

  • USBImager als Alternative zu Etcher

    USBImager als Alternative zu Etcher

    Es gibt unter Linux viele Wege, um ein Abbild bootfähig auf einen USB-Stick oder eine SD-Card zu legen. Auf der Kommandozeile ist das Werkzeug der Wahl dd, was für disk dump steht und Festplatten, Partitionen oder Dateien Bit für Bit unterhalb der Dateisystemebene ausliest und schreibt. Wer dd nutzt, sollte sicher sein, das richtige Device zu verwenden, denn ist dd einmal gestartet, wird das Ziel gnadenlos ohne Rückfrage überschrieben.

    In den letzten Jahren sind zur Erstellung bootfähiger USB-Stick einige grafische Tools in Mode gekommen. Einige Distributionen bieten eigene Tools an, andere sind unabhängig von Distribution oder Betriebssystem. Für Windows steht seit 10 Jahren Rufus bereit, breiter aufgestellt ist das für Linux, macOS und Windows verfügbare balenaEtcher, kurz Etcher, das Anfängern unter Linux gerne empfohlen wird. Etcher lässt sich sowohl grafisch als auch per CLI bedienen.

    Etcher basiert auf Electron

    Gegenüber dd haben diese Tools den Vorteil, dass sie Fehlbedienungen zu verhindern suchen. Um Datenverlust zu vermeiden, zeigt Etcher Partitionen, die über die übliche Größe von USB-Sticks hinausgehen, als großen Datenträger an. Der entscheidende Nachteil von Etcher ist die Verwendung des Electron-Frameworks und die daraus resultierende Größe der als AppImage ausgelieferten Anwendung von über 90 MByte. Zudem wird seit einiger Zeit während des Schreibens Werbung eingeblendet.

    Minimale Lösung

    Dass das auch besser geht, beweist das seit einem Jahr entwickelte minimalistische grafische Open-Source-Tool USBImager, das ebenfalls für Linux, macOS und Windows sowie für die ARM-Plattform verfügbar ist und als .deb gerade mal 180 KByte auf die Waage bringt. Dabei bietet es sogar mehr Funktionen als Etcher.

    Neben den Binärdateien und dem Quellcode auf GitLab ist USBImager lediglich im AUR von Arch Linux zu finden. Beim Download direkt aus dem Repo ist zwischen Versionen, die nur schreiben und solchen, die auch lesen können zu unterscheiden. Letztere bieten zusätzlich die Möglichkeit, das Ergebnis nach dem Schreibvorgang zu verifizieren sowie das Erstellen von Sicherungen. Der Download als Zip-Archiv anstatt der Binärdatei erlaubt die Verwendung der ausführbaren Datei auch ohne Installation und damit ohne Systemintegration.

    USBImager bei der Arbeit

    Images lesen und Schreiben

    Die GUI ist einfach gehalten und bietet Auswahlfelder für das zu schreibende Abbild, das Device und die Puffergröße. Zudem kann angehakt werden, dass das Ergebnis überprüft wird. Ein weiterer Klick sorgt für eine weitere Kompression. Das Tool versucht durch Ausblenden größerer Partitionen zu verhindern, dass bei falscher Auswahl des Ziels die Systemplatte überschrieben wird. Alle Laufwerke werden beim Start auf der Kommandozeile mit dem Parameter -a angezeigt. Für ein rund 3 GByte großes Abbild inklusive Überprüfung braucht USBImager knapp 4 Minuten.

    Mehr Funktionen als Etcher

    USBImager kann mit den Formaten .img, .bin, .raw und .iso umgehen und kann komprimierte Abbilder wie .zip, .zzz, .tar, .cpio und .pax on-the-fly lesen. Es können über den Schalter Lesen komprimierte Backups roh oder im ZStandard-Format erstellt werden. Die resultierenden Dateien werden auf dem Desktop mit der Endung .dd abgelegt. Wird gleichzeitig komprimiert, lautet die Endung .dd.zst. Zudem können Abbilder über die serielle Schnittstelle an Mikrocontroller geschickt werden. Wie diese und weitere Optionen funktionieren, zeigt ein ausführliches Handbuch (PDF).

  • Effektive Paketsuche mit APT

    Effektive Paketsuche mit APT

    Wer unter Debian lieber auf der Kommandozeile zu Hause ist als in der bunten Welt der GUIs, der wird seine Aufgaben der Paketverwaltung vermutlich mittels APT, Aptitude und DPKG erledigen. Was macht ihr, wenn ihr unter Debian ein Paket installieren wollt, aber den genauen Paketnamen nicht (mehr) wisst? Ich nutze dann apt search. Alternativ kann man auch apt-cache search nutzen, dass sich lediglich in der Formatierung der Ausgabe unterscheidet und eine sicherere Verwendung in Scripten gewährleistet als apt search.

    Um effektiv nach Paketen suchen zu können, sind die vorhandenen Befehle ohne zusätzliche Parameter aber meist nicht besonders zielführend.

    Ohne Eingrenzung untauglich

    Wer schon einmal eine Suche nach

    apt search git

    gestartet hat, wird sich gewundert haben, dass er viele Treffer erhält, die vermeintlich nichts mit dem Suchbegriff zu tun haben. Das liegt daran, dass der Suchbegriff nicht weiter eingegrenzt wurde. Es werden Pakete gefunden, die den String git im Namen haben (also z. B. auch digital) oder bei denen git in der Paketbeschreibung vorkommt. Sucht man etwa mit diesem Befehl, so erhält man fast 10.000 Treffer

    ft@blue:~$ apt search git | wc -l
9608

    Zur Eingrenzung können reguläre Ausdrücke (Regex) zum Einsatz kommen. So sorgt

    apt search ^git$

    dafür, dass ein Paket gesucht wird, das mit g beginnt, mit einem i fortfährt und mit einem t endet. Das begrenzt die Suche auf genau diesen Suchbegriff. Möchte man aber auch zusammengesetzte Paketnamen wie etwa qgit oder libnoggit-java finden, so empfiehlt sich

    apt search --names-only git | less

    oder verkürzt

    apt search -n git | less

    um alle Vorkommen zu finden, die git im Namen haben. Damit reduziert sich die Zahl der Treffer immerhin um die Hälfte im Vergleich zur Suche ohne -n auf ~ 5.000. Zur besseren Übersicht wurde hier der Pager less genutzt.

    Wenn wir uns nicht genau an den Paketnamen erinnern, können auch zwei Suchbegriffe kombiniert werden. Schauen wir einmal, was das mit und ohne -n bewirkt:

    ft@blue:~$ apt search lint rpm
Sortierung… Fertig
Volltextsuche… Fertig
cmake-fedora/unstable,testing 2.7.2-1 all
  Set of scripts and cmake modules that simplify the release process

debaux/unstable,testing 0.1.12-1.1 all
  Debian-Hilfsprogramme

rpmlint/unstable 1.11-0.2 all
  RPM package checker

    Und nun mit -n:

    ft@blue:~$ apt search -n lint rpm
Sortierung… Fertig
Volltextsuche… Fertig
rpmlint/unstable 1.11-0.2 all
  RPM package checker

    Ist der Name gänzlich entfallen, aber eine Kategorie bekannt, so können wir auch danach suchen:

    apt search metasearch engine
Sortierung… Fertig
Volltextsuche… Fertig
python3-searx/unstable,testing 0.18.0+dfsg1-1 all
  Privacy-respecting metasearch engine - library package

searx/unstable,testing 0.18.0+dfsg1-1 all
  Privacy-respecting metasearch engine

    Wenn ihr wissen wollt, ob die Fundstelle auch dem gesuchten Paket entspricht, so hilft euch die Ausgabe der Paketbeschreibung mit apt show [Paketname] weiter.

    Nur am Rande

    Ein Dauerbrenner in Debian-Foren und Chats ist die Diskussion, ob apt oder aptitude das bessere Werkzeug als Frontend für DPKG ist, denn aptitude bietet sogar eine mächtigere Suche. Die Frage stellt sich für mich so allerdings nicht, da ich über die Jahre festgestellt habe, dass aptitude bei Upgrades in Debian Stable gut funktioniert, während es bei schnell wechselnden Paketbeständen oft klüger ist als es sein sollte und apt oft besser mit der Auflösung komplizierter Upgrade-Situationen klarkommt als aptitude. Letzteres nutze ich nur, wenn ich komplexe Abfragen tätigen muss. So listet etwa der Befehl

    aptitude search '?narrow(?installed, !?archive(stable))'

    nur Pakete auf, die aus einem anderen Zweig als Stable installiert wurden.

  • Wie funktionieren Flatpak Portals?

    Wie funktionieren Flatpak Portals?

    Um das gleich vorwegzunehmen: Flatpak Portals ist nicht ganz die richtige Bezeichnung und wurde nur wegen der etwas griffigeren Überschrift gewählt. Richtigerweise muss es XDG Desktop Portals heißen. Und nun, da wir das aus dem Weg haben, erkläre ich mal für die, die es noch nicht kennen, was Portals sind und wozu sie im Zusammenhang mit Flatpak dienen.

    Portale für gezielte Berechtigungen

    Portals stellen eine Reihe von D-Bus-Schnittstellen bereit, die über APIs gezielt bestimmte Rechte wie unter anderem Zugriff auf Dateien oder Geräte wie Drucker, Soundkarte etc. definieren. Sie sind ein wichtiger Baustein bei Flatpak, denn sie regeln darüber die dynamischen Berechtigungen. Das ist ein Mechanismus, über den Anwendungen innerhalb einer Sandbox mit der Host-Umgebung dynamisch interagieren können, ohne dass zusätzliche Sandbox-Berechtigungen erforderlich sind. Beispiele für Funktionen, auf die über Portals zugegriffen werden kann sind das Öffnen von Dateien über einen Dateiauswahldialog, das Drucken oder das Erstellen von Screenshots.

    Desktop-spezifische Portals

    So kann etwa mit dem FileChooser-Portal Zugriff auch auf einzelne Dateien im Dateisystem gewährt werden. In letzter Zeit wurden Desktop- und Toolkit-spezifische Portals erstellt, wie etwa das GTK-Backend xdg-desktop-portal-gtk, das KDE-Backend xdg-desktop-portal-kde oder das Wayland-spezifische xdg-desktop-portal-wlr (wlroots). Generell erlauben Portals fein gegliederte Berechtigungen, die nur das eben Nötige erlauben. Einen Überblick über verfügbare Portals, deren API und Handhabung gewährt die Portal Documentation.

    Auch in Flatseal

    Portals haben kürzlich auch Einzug in das Tool Flatseal gehalten, das ich für die kommende Ausgabe des LinuxUser ausführlich beschrieben habe. Dadurch werden die in Flatseal erlaubten oder verbotenen Aktionen nicht mehr durch Portals überschrieben.

  • Trash-CLI – die sicherere Alternative zu rm

    Photo by Pawel Czerwinski on Unsplash

    Wer als Kommandozeilen-Ritter noch nie eine Datei versehentlich mit rm [wichtige Datei] oder gleich ein ganzes Verzeichnis mit rm -r gelöscht hat, der hebe jetzt die Hand. OK, keiner, ist also jedem schon mal passiert. Wohl dem, der dann ein Backup hat. Aber darum geht es hier nicht, sondern um eine sicherere Alternative zu dem rigorosen Befehl rm.

    Pendant zum Mülleimer der Desktops

    Es geht um ein Paket, das keinen hohen Bekanntheitsgrad hat, obwohl es in fast allen Distributionen verfügbar ist. Ich kannte es bis vor kurzem auch nicht, bevor ich zufällig über diesen Blogeintrag stolperte. Die kleine Anwendung, um die es geht und die bereits seit 14 Jahren entwickelt wird, heißt trash-cli und stellt das Pendant zum Mülleimer der gängigen Desktops dar, mit denen es sogar zusammenarbeitet. Trash-cli löscht Dateien unter Angabe des ursprünglichen Pfads, des Löschdatums und der Berechtigungen. Es verwendet den gleichen Mülleimer wie KDE, GNOME und Xfce, wird aber auch von der Kommandozeile (und Skripten) aus aufgerufen werden. Trash.cli richtet sich dabei nach der Spezifikation von Trash von freedesktop.org.

    Installation

    Wie bereits erwähnt, ist trash-cli weit verbreitet, allerdings meist in der veralteten Version 0.17.1.14-x. Wer die aktuelle Version 0.21.7.24 bevorzugt, muss den Python-Paket-Installer pip bemühen, der in Debian und seinen Ablegern mit dem Befehl sudo apt install python3-pip installiert werden kann. Unter Fedora führt sudo dnf install python3-pip zum Ziel. Daraufhin wird die Anwendung mit pip install trash-cli installiert.

    Verwendung

    Dann kann mit trash-put foo, oder vereinfacht mit trash foo die erste Datei oder Verzeichnis in den Müll verschoben werden. Dabei werden die Inhalte in ~/.local/share/Trash/files abgelegt, dem Ort, der auch die zu löschenden Inhalte der unterstützten Desktop-Umgebungen aufnimmt. Das Tool unterstützt die Autovervollständigung, sodass Inhalte mit Leerstellen im Titel automatisch escaped werden.

    Wenn dann mit trash-list mehr als der eben zum Löschen vorgemerkte Inhalt angezeigt wird, dann sind dies Inhalte im Mülleimer der jeweiligen Desktop-Umgebung. Wiederherstellen lassen sich Inhalte mittels trash-restore, wobei aber nur Inhalte zur Auswahl stehen, die auch mit der CLI-Version in den Mülleimer gelegt wurden. Das Entfernen temporärer Inhalte des Mülleimers gelingt wiederum mit trash-rm '*~' und erlaubt so eine bessere Übersicht über die restlichen Inhalte.

    Trash benötigt nur wenige Befehle, um seine Aufgabe zu erfüllen:

    trash-put (vereinfacht: trash)   Dateien und Verzeichnisse in den Mülleimer schieben.
trash-empty                      Mülleimer leeren
trash-rm [foo]                   einzelne Inhalte aus dem Mülleimer löschen
trash-list                       Dateien im Mülleimer auflisten
trash-restore                    Datei aus dem Mülleimer wiederherstellen

    Alles weitere Wissenswerte über trash-cli hält die entsprechende GitHub-Seite bereit.

  • RPort – Der TCP Tunnelbauer

    Photo by Mathew Schwartz on Unsplash

    Gastartikel von Sven Wick

    Möchte man komplette Netze verbinden, nimmt man in der Regel eine VPN Lösung, für einzelne Systeme oder Ports ein Forwarding. Für Letzteres z.B. den Router oder ein Werkzeug wie SSH, wobei OpenSSH schon seit Längerem auch komplette Netze tunneln kann…

    Ein Port Forwarding im Router möchte oder kann man vielleicht nicht einrichten, ein VPN für ein oder zwei Systeme wäre Overkill oder macht potenziell zu viel des eigenen Netzes erreichbar. Für den spontanen Zugriff strickt sich der versierte Anwender mal kurz was mit SSH zurecht. Soll das aber dauerhaft und robust laufen, muss man zu Tools wie autossh oder sidedoor greifen oder baut sich mit Systemd-Hausmitteln selbst etwas.

    Diese funktionieren für ihren Anwendungs-Bereich sehr passabel, haben jedoch alle ihre kleineren Einschränkungen:

    • mehrere Tunnel nicht möglich oder umständlich einzurichten
    • kein komfortables Management der Tunnel
    • keine Übersicht der Tunnel und deren Zustände
    • nicht für alle Betriebssysteme verfügbar ( systemd z.B. Linux-only )

    Eine heterogene Lösung

    Hier tritt nun RPort auf den Plan und möchte dies auf das nächste Level heben. Die Entwickler von rport haben erkannt (wie auch die PowerShell Macher), dass heutzutage heterogene statt Insel Lösungen gebraucht werden. rport wurde daher bewusst in Go geschrieben damit eine Binärdatei hinten rausfällt, die auf so vielen Plattformen wie möglich einfach gestartet werden kann.

    Konzept

    RPort besteht aus folgenden Komponenten:

    • Server
    • Client
    • API – mit CLI oder Webinterface nutzbar (optional)

    Verwendet wird das Port Forwarding Konzept aus SSH, genutzt wird dazu aber nicht der lokale SSH Client, sondern die SSH Library in Go. Der Server ist die zentrale Anlaufstelle für die Clients, die auch hinter Routern stehen können.Diese bauen über HTTP eine Verbindung auf, über die dann SSH gesprochen wird.
    Über diese SSH Verbindung kann der Server den Client dann steuern, beispielsweise welcher Port wohin weitergeleitet werden soll. Es lassen sich aber auch CLI Programme oder Skripte ausführen, falls das Zielsystem dies unterstützt. Für Windows Systeme kann sogar die PowerShell verwendet werden.

    Management

    Der Server beinhaltet eine API, die auch vom eingebauten Webinterface genutzt wird, in dem man eine Übersicht aller Clients, den Tunneln sowie weitere Metadaten vorfindet. Das Webinterface unterstützt den Anwender auch damit, sich bequem auf dem Remote-System einzuloggen. Hier wird dann der lokale SSH-, RDP- oder VNC- Client gestartet.Zusätzlich gibt es rport-cli um sich z.B. auch von der Shell aus eine Übersicht zu verschaffen oder automatisiert Tunnel zu erstellen.

    Sicherheit

    Das Projekt bietet einige Mechanismen an, um die Tunnel abzusichern, z.B. lassen sich ACLs setzen, damit auf ein Zielsystem nur bestimmte Clients dürfen, über Gruppen den Zugriff einschränken oder auch Befehle filtern, die auf Zielsystemen nicht ausgeführt werden dürfen.

    Dokumentation

    Mehr Info und Möglichkeiten findet man in der Dokumentation

    • https://oss.rport.io/docs/
    • https://kb.rport.io/

    Ausblick

    In der Vorstellung des Projektes auf der FrOSCon wurde erwähnt, dass man Features wie das Fernsteuern wie von TeamViewer gewohnt oder eine Art Ansible Framework zukünftig mitliefern will, damit man etwas mehr als nur Befehle oder Skripte ausführen kann.

  • glow – Der pfiffige CLI Markdown Viewer

    Photo by JOHN TOWNER on Unsplash

    Gastbeitrag von Sven Wick

    Wer viel mit Markdown Dateien ( z.B. auf Github/Gitlab) arbeitet, möchte nicht immer zuerst Pushen um zu merken, dass die Änderungen nicht so aussehen, wie man sich das gedacht hat. Grafische Markdown Viewer und Editoren gibt es mittlerweile viele. Für die CLI fällt die Auswahl schon etwas geringer aus. Neben grip und mdless gibt es noch das pfiffige glow das dem Ganzen noch einen schicken charm verleiht.

    Features

    • Schicke Darstellung von Markdown im Terminal
    • Findet alle Markdown Dateien automatisch
    • Speichern von Dateien in der Charm Cloud (Stashing)
    • Dateien werden mit dem lokalen SSH PublicKey verschlüsselt

    Benutzung

    Markdown anschauen:

    glow README.md

    Markdown anschauen (mit Pager)

    glow -p README.md

    Interaktiv (TUI)

    glow

    Installation

    Für einige Distros gibt es schon Pakete, glow lässt sich aber auch einfach runterladen, da es (wie von Go und Rust gewohnt) nur eine einzige Binärdatei ist. Das Github Repo hat auch fertige Distro-Pakete (Deb, rpm, apk),die man nutzen kann, um seinem Paketmanager treu zu bleiben.

  • SSH-Tools – den Alltag mit OpenSSH bequemer machen

    Photo by Hunter Haley on Unsplash

    Gastbeitrag von Sven Wick

    OpenSSH, das Schweizer Taschenmesser des Admins für den täglichen Remotezugriff. Das Projekt liefert einzelne Tools mit, die einfach zu benutzen sind und als sehr sicher gelten.Man kann sie daher in die Kategorie
    Keep It Simple and Secure einordnen. Das bedeutet aber nicht, dass der Alltag damit auch immer bequem ist. Wer kennt es nicht, der begehrte Server steht hinter einem JumpHost oder man muss erst durch einen VPN-Tunnel. Oder beides.

    Nun muss der Weg dorthin angepasst werden, z.B. die Umstellung des VPN Tunnels zum Kunden. Ab hier fängt die mühsame Dauerschleife an. Der Kunde meldet Vollzug auf seiner Seite und selbst hat man seine VPN Config auch schon angepasst, ein Login Versuch via SSH schlägt aber noch fehl:

    • Eigene Firewall Regeln nochmal geändert.
    • Der nächste manuelle Login Versuch.
    • Geht immer noch nicht.
    • Kunde anschreiben
    • Kunde meldet sich irgendwann später. Nochmal probieren..
    • Nächster manueller Login-Versuch.
    • Tut sich nix.
    • …

    Einen normalen Ping nebenher in einem Terminal laufen lassen um das Prozedere zu vereinfachen, ist hier leider nutzlos, da ein JumpHost dazwischensteht. Den ICMP Echo Request leitet dieser nicht weiter. Außerdem wollen wir wissen, ob der SSH Zugriff geht – nicht ein Ping. Ein Check auf Port 22 z.B. mit Netcat bleibt hier auch wirkungslos. Hier kommen nun die ssh-tools ins Spiel, die das KISS Prinzip um CISS erweitern.

    Scripte für den OpenSSH-Client

    Die ssh-tools sind Wrapper-Skripte um den OpenSSH-Client, die vieles bequemer machen. Für das oben beschriebene Problem gibt es z.B. ssh-ping, das prüft, ob ein SSH Server auch wirklich erreichbar ist. Das funktioniert sogar durch JumpHosts hindurch, vorausgesetzt diese sind über die SSH Config eingerichtet. Damit kann man sich nun in Ruhe auf seine VPN, Firewall oder SSH Config konzentrieren und parallel auf ssh-ping schauen, ob die Anpassungen fruchten.

    Weitere Tools

    Neben ssh-ping gibt es noch weitere Tools, die des Admins Leben versüßen:

    1. ssh-version: Zeigt die Version des SSH Servers an
    2. ssh-diff: Eine Datei über SSH diffen
    3. ssh-facts: Basisinfo über das Remotesystem anzeigen ( z.b. Welche Distro ist installiert )
    4. ssh-hostkeys: Die Fingerprints der HostKeys in verschiedenen Formaten ausgeben
    5. ssh-keyinfo: SSH PublicKeys in verschiedenen Formaten ausgeben (alte SSH Server schreiben z.B. noch MD5 Fingerprints ins Syslog)
    6. ssh-certinfo: Zeigt an, ob und wie lange SSH Zertifikate (nicht PublicKeys) noch gültig sind. (Damit kann man z.B. monitoren, ob SSH Zertifikate erneuert werden müssen.)
    7. ssh-force-password: Erzwingt bei PubKey Authentifizierung die Passwort Abfrage (z.B. um Passwort Änderungen zu testen)

    Pakete

    Die ssh-tools sind mittlerweile für die gängigen Distributionen paketiert, können aber auch direkt von Github runtergeladen und ausgeführt werden.

  • Die Lösung für die Notizen?

    Für viele Anwendungszwecke habe ich schon meine Softwareperlen gefunden. Meine E-Mails gehen ein und aus dank Thunderbird, meine Literaturrecherche (und mehr) mache ich mit Zotero, Firefox ist dank der Add-ons für mich ein Segen und Passwörter kann ich mit KeepassXC sicher verstauen. Und auch die meisten meiner Artikelentwürfe für die Zukunft für dieses Blog befassen sich mit Applikationen, die mein Leben reicher machen. Nur an einer Front bin ich bislang immer gescheitert: Notizen.

    Das Problem kennt wahrscheinlich jeder: Hier Post-its, da mal eine App, hier noch eine zweite, analoges Notizbuch und Anmerkungen im Terminkalender. Weiteres in LibreOffice-Dokumenten oder gar in LaTeX-Code. Dazu mal was in OneNote, mal etwas in Evernote, ein bisschen Tagebuch mit Lifeograph – oder doch lieber Rednotebook?

    Anfang des Jahres schrieb »muc« hier ausführlich einen tollen Artikel über Joplin und ZIM, zwei Open-Source-Lösungen zu dem Thema. Aber irgendwie konnten mich die beiden Lösungen nicht final überzeugen.

    Das Ziel: Ein zweites Gehirn!?

    Dafür bin ich immerhin meinen Vorstellungen für die mir passende Lösung weitergekommen. Die unter den Selbstoptimierern propagierte Lösung heißt meist Second Brain oder Zettelkasten. Für mehrere Tausend Euro kann man sich da auch gleich coachen lassen. Ich bin da ehrlicherweise etwas genügsamer und starte mit einigen Zielen:

    • Ich möchte ein System, in dem alles rund um das Thema »Texte« von mir landen kann. Sei es mein Tagebuch, meine To-do-Liste, Artikelentwürfe oder ein Post-it, schlichtweg alles, wo ich nicht von Anfang an weiß, dass ich ein »Spezialprogramm« brauche.
    • Auch die technische Grundlage soll ebenso universell sein. Es sollen Textdokumente sein, die in meinem Besitz bleiben und damit auch noch in zwanzig oder dreißig Jahren funktionieren.
    • Neben dem Top-down will ich noch Bottom-up: Es soll noch ein bisschen mehr sein als ein ausgeklügeltes Ordnersystem mit den Textdateien. Verbindungen, die in meinem Kopf entstehen, sollen sich auch in meinen Notizen wiederfinden.
    • Synchronisation. Meine Textdokumente möchte ich auch auf anderen Endgeräten nutzen können.

    Auf meinem Weg hier die passende Lösung zu finden, habe ich viele Dienste gefunden, die sich in diesem Bereich zwischen »Knowledge Database« und »Second Brain« bewegen. Neben den oben Genannten las ich über Notion, Roam Research und Remnote, die dann doch meinen Ansprüchen nicht genügten. Zumal es auch alle die typischen, unfreien Abomodelle sind, die teilweise auf Linux nicht vertreten sind. Weitere Open Source Alternativen stelle ich am Ende vor.

    Gefunden: Obsidian

    Denn die Lösung, die ich für mich gefunden habe, passt eigentlich gar nicht zu diesem Blog. Denn Obsidian legt seinen Quellcode nicht offen. Das ist für viele Nutzer verständlicherweise ein Ausschlusskriterium.
    Dennoch konnte ich Obsidian als Softwareperle für mich gewinnen, die ich unter Linux als Snap, AppImage oder über Flathub installieren kann.
    Obsidian macht im Prinzip zwei Dinge: Zum einen erstellt es Markdown-Dokumente und zum anderen erstellt es ein Gewölbe („Vault“) rund um die Notizen. Während Ersteres banal ist, stellt Letzteres den Clou dar.

    Markdown

    Es ergibt Sinn, auf Markdown zu setzen für Textdokumente. Denn tatsächlich ist es ein ganz einfaches Dateiformat, das technikaffine Anwender schon seit langer Zeit schätzen. Die entstehenden Dateien sind klein und lassen sich mit einer Vielzahl von Programmen öffnen und editieren. Auch Bilder lassen sich beispielsweise einbinden. Diverse andere Programme bieten dann auch einen Import oder Umwandlung von Markdown-Dateien an. Und so ist es auch die erste Komponente von Obsidian: Man kann schnell und leicht Markdown-Dokumente erstellen und lokal in Ordnern hierarchisch speichern (Top-down). Nun können das auch viele andere Programme.

    Vaults dank Backlinking

    Das Entwickeln des „Vaults“ hingegen ist die große Stärke von Obsidian. Denn zwischen den einzelnen Notizen können Verbindungen angelegt werden. Während es für unser menschliches Gehirn vollkommen normal ist, Verbindungen zu knüpfen und darüber neue Ideen zu entwickeln, erscheint es mir das zu sein, was ich am meisten an meinen bisherigen Versuchen, die Notizen zu ordnen, vermisste. Das funktioniert mit dem sogenannten »Backlinking«. Mit dem Setzen von zwei eckigen Klammern kann auf andere Notizen verlinkt werden. Das kann man sich dann schließlich auch grafisch darstellen. Dabei werden die Einzelnotizen als Punkte ebenso visualisiert wie die Verbindungen zwischen ihnen.

    Plug-ins

    Noch viel mehr Funktionen werden über Plug-ins gelöst. Die gibt es angefangen bei einem Audiorekorder über Kalender, Kanban-Boards bis hin zu einem Publish-Service. Viele der Plugins sind Open Source und von einer aktiven Community gepflegt.

    Geschäftsmodell

    Für Obsidian muss man weder Geld noch mit seinen Daten zahlen, das Versprechen gilt »für immer«. Das Geschäftsmodell basiert mehr auf Freiwilligkeit. Nur wer Obsidian kommerziell nutzt, muss pro Nutzer pro Jahr 50 Dollar zahlen. Allerdings darf man Katalysator werden und so Geld zahlen, im Tausch für Early Access und Badges. Auch gibt es zwei Add-ons, die Geld kosten. Der Synchronisierungsdienst kostet monatlich 4 $ (das kann man aber auch mit eigenen Diensten oder git umsetzen), wer seinen Vault online stellen möchte, muss dafür 8 $ im Monat zahlen.
    Tatsächlich stellt sich die Frage, ob man so ein Geschäftsmodell nicht auch als Open Source Projekt hätte mit mindestens dem gleichen Erfolg haben können. Denn letztlich muss der Nutzer für gar keine Funktion zahlen. Auch dort, wo kostenpflichtige Add-ons angeboten werden, werden andere Alternativen in der Dokumentation vorgestellt. Auch ein umfangreicher Thread im Forum versucht die Macher des Projekts davon zu überzeugen, dass es sinnvoll wäre, auf Open Source umzusatteln. Stand jetzt erfolglos, denn die Macher fürchten, dass andere sich allzu großzügig an der eigenen Arbeit bedienen. Seit kurzer Zeit gibt es jetzt auch für Android und iOS Apps.

    Die Alternativen

    Auch an dieser Stelle möchte ich noch einmal auf den Artikel von »muc« verweisen. Denn zu den freien Alternativen gehören Joplin und ZIM ganz sicher. Auch TiddlyWiki ist eine Alternative. Hier landet alles in einer HTML-Datei. Foam bietet so wie Obsidian auch die grafische Ansicht an und orientiert und positioniert sich ganz klar als freie Alternative zu Roam Research. Umgesetzt wird es mit Visual Studio Code. Emacs-Enthusiasten werden dank »Org-roam« über meinen Artikel wahrscheinlich nur müde lächeln und VIM-Experten dank vim-Wiki ebenso. Zettlr und Trilium Notes sind ebenso eine Erwähnung wert.