In den letzten Wochen habe ich ein kleines Tool entdeckt, das mir die Arbeit mit meinen SSH-Verbindungen deutlich erleichtert hat: SSHPilot. Wer regelmäßig mit verschiedenen Servern arbeitet, verliert schnell den Überblick über benötigte Schlüssel, spezielle Konfigurationen oder fortgeschrittene Funktionen wie Port-Weiterleitungen.
Genau hier setzt SSHPilot an und erweitert das klassische Terminal um eine übersichtliche Oberfläche auf Basis der Libadwaita, die bewusst einfach bleibt und viele SSH-typische Aufgaben deutlich vereinfacht. Damit eignet sich SSHPilot besonders für GNOME-User etwa als Alternative zum Windows-Klassiker PuTTY, den es auch als KiTTY für Linux gibt.
SSHPilot bietet ein lokales Terminal und schnellen Zugriff auf entfernte Server via SSH. Die Oberfläche wirkt aufgeräumt und erleichtert die Organisation vieler paralleler Verbindungen.Das Interface lässt sich umfangreich anpassen. Neben einem Dark Mode gibt es mehrere Farbpaletten für das Terminal, sodass sich das Programm gut an persönliche Vorlieben angleichen lässt.Neue SSH-Verbindungen richtet ihr mit einem kleinen Assistenten ein. Dadurch spart ihr Zeit und müsst Konfigurationsdateien nicht mehr von Hand bearbeiten oder anpassen.
Mehr als nur ein Terminal
SSHPilot präsentiert sich als vollwertiger SSH-Manager mit eingebautem Terminal, der aber jederzeit die Möglichkeit bietet, Verbindungen auch im bevorzugten Terminal zu öffnen. Die Anwendung integriert sich nahtlos in den GNOME-Desktop und unterstützt sowohl helle als auch dunkle Farbschemata. Für das Terminal selbst stehen mehrere Farbpaletten zur Auswahl, die sich unabhängig von den GNOME-Einstellungen auswählen lassen.
Schriftart und Farbpalette des Terminals könnt ihr unabhängig von den GNOME-Einstellungen konfigurieren. So passt sich SSHPilot individuell an den eigenen Workflow an.
Besonders praktisch für erfahrene Anwender: SSHPilot kann bestehende Einstellungen aus der ~/.ssh/config direkt einlesen und dauerhaft speichern. Passwörter und Schlüssel-Passphrasen werden dabei sicher verwahrt, ohne dass sensible Daten im Klartext gespeichert oder unnötig in die Zwischenablage gelegt werden.
SSHPilot kann gespeicherte Passphrasen und Schlüssel sicher handhaben, ohne dass geheime Informationen im Klartext abgelegt werden. So bleibt der Zugriff auf sensible Daten gut geschützt.
Übersichtlichkeit und praktische Verwaltung
Die Bedienung ist darauf ausgelegt, viele Verbindungen und Servergruppen übersichtlich zu verwalten. Ihr könnt Hosts bündeln und per Tastenkombination schnell wechseln, ohne mehrere Terminals parallel offen halten zu müssen. Zusätzlich bindet SSHPilot entfernte Verzeichnisse per SFTP direkt in den Dateimanager der GNOME Desktop-Umgebung ein. So habt ihr bequemen Zugriff auf die Dateien des Servers und könnt Daten ohne Umwege hoch- und herunterladen.
Mit einem Klick öffnet ihr den integrierten Dateimanager und könnt Dateien auf dem Remote-Server direkt bearbeiten, hochladen oder herunterladen – ganz ohne zusätzlichen Client.
Darüber hinaus unterstützt SSHPilot lokale, entfernte und dynamische Port-Forwardings, womit viele typische SSH-Szenarien abgedeckt werden. Auch SCP für schnellen Datei-Upload ist integriert. Besonders nützlich: Beim Aufbau einer Verbindung können definierte Kommandos automatisch lokal oder auf dem Zielsystem ausgeführt werden, was Routineaufgaben erheblich vereinfacht.
Installation: DEB, RPM oder AUR
Die Installation ist unkompliziert: Für Debian- und Fedora-basierte Systeme gibt es fertige Pakete, und auch ein AUR-Paket für Arch Linux steht bereit. Der Quellcode liegt offen auf GitHub, was Anwendern volle Transparenz und Kontrolle über die eigene Software garantiert. Bei mir hat die Installation über das AUR unter Arch Linux problemlos funktioniert.
$ yay -Ss sshpilot
aur/sshpilot 3.5.4-1 (+0 0.00)
SSH connection manager with integrated terminal,
tunneling, tabbed interface and scp upload support.
$ yay -S sshpilot
Nützliche Ergänzung zum klassischen SSH
Für mich ist SSHPilot keine Konkurrenz zum Terminal, sondern eine sinnvolle Ergänzung, die Ordnung schafft und Routineaufgaben erleichtert. Wer regelmäßig zwischen vielen Servern wechselt, Port-Weiterleitungen nutzt oder Dateien überträgt, findet hier einen verlässlichen Helfer. Das Programm bleibt leichtgewichtig und verzichtet auf unnötigen Ballast, wodurch es sich bestens in den Arbeitsalltag integriert. Die DEB- und RPM-Pakete findet ihr auf der Projektseite, sodass die Installation problemlos gelingt.
In den erweiterten Einstellungen lassen sich SSH-Verbindungen bis ins Detail konfigurieren. So können auch komplexe Szenarien abgebildet werden, ohne die Übersicht zu verlieren.
PipeWire 1.4.6 open-source server for handling audio/video streams and hardware on Linux is now available for download with various fixes and improvements.
Fedora nimmt oft die Pole-Position bei der Einführung neuer und der Entfernung alter Technologien ein. Das führt derzeit wieder zu kontroversen Diskussionen.
Ich weiß derzeit noch nicht, ob das Problem an meinem Server oder an WordPress liegt. Möglicherweise ist es auch ein Plug-in und das Problem kann ich nicht reproduzieren. Allerdings habe ich eine Lösung gefunden, wie es sich bereinigen lässt. In der Zwischenzeit ist das Problem bereits dreimal aufgetreten. Warum? Weiß ich nicht, wie bereits erwähnt. Was ist passiert? Was sind die Symptome? Beim Speichern oder beim Veröffentlichen hat sich anscheinend irgendwas verhaspelt. Folgende Probleme sind dann aufgetreten: Der Post lässt […]
Wie ihr schon im ersten Teil dieser kleinen Artikelserien zu LanguageTool lesen konntet, ist die Integration einer bestmöglichen Rechtschreibkorrektur in ein System gar nicht so einfach. Betreut man mehrere Rechner im Netz oder soll LanguageTool im Browser ohne den proprietären Dienst des kommerziellen Projekts funktionieren, lohnt es sich daher, selbst einen LanguageTool-Server aufzusetzen. So funkt LanguageTool weniger ins Netz und eure Texte bleiben vollständig unter eurer Kontrolle. Es braucht nur einen kleinen Rechner im eigenen LAN mit ausreichend freiem Speicherplatz, mindestens 4 GByte solltet ihr übrig haben. Optional installiert ihr euch den Server auf der eigenen Workstation.
Ursprünglich hatte ich auch gedacht, dass LanguageTool eine ideale Ergänzung für meinen Raspberry Pi wäre, der hier im LAN bereits als File-, Drucker- und Scan-Server sowie generell als stromsparende eierlegende Wollmilchsau arbeitet. Doch hier wirds leider hakelig: LanguageTool benötigt zwingend ein 64 Bit-System als Basis. Das bietet die vierte Generation des Raspberry Pi zusammen mit der ARM64-Version des Raspberry Pi OS zwar, doch am Ende scheitert es an Java-Bibliotheken, die auch auf dieser Version des Betriebssystems nur in der 32 Bit-Version vorliegen. Auf die Situation gehe ich am Ende des Artikels ein. Im Folgenden nutze ich einen kleinen Server auf Basis von Debian.
Installation von LanguageTool
Für den LanguageTool-Server benötigt ihr ein Linux-System mit einer Java-Runtime-Umgebung. Auf einem Debian-basiertem System, wie etwa auch Ubuntu oder Linux Mint, spielen die folgenden Kommandos alles Nötige ein. Die Installation der N-Gramm-Daten (zum Erkennen von Schreibfehler wie „viel“ statt „fiel“, „seit“ statt „seid“ oder „Stil“ statt „Stiel“) ist optional. Sie verbessert die Erkennung von oft falsch geschrieben Wörter, schaufelt allerdings nochmal ein paar Gigabyte mehr an Daten auf den Rechner. Für optimale Ergebnisse würde ich diesen Schritt allerdings nicht übergehen und zumindest die N-Gramm-Daten für Deutsch einspielen.
### LanguageTool benötigt über 3 GByte Speicherplatz:
$ du -hs /opt/LanguageTool
3.4G /opt/LanguageTool
Für einen ersten Test wechselt ihr nun auf dem Terminal in das Installationsverzeichnis unter /opt/LanguageTool des LanguageTool-Archivs. Das zweite Kommando aus dem folgenden Listing startet dann testweise die Server-Komponente von LanguageTool. Der Dienst lauscht auf Port 8081 auf Anfragen, mehr braucht es bei diesem Schritt auch noch nicht. Mit der Tastenkombination [Strg]+[C] beendet ihr den Dienst und kehrt wieder auf die Shell zurück.
$ cd /opt/LanguageTool
$ java -cp languagetool-server.jar org.languagetool.server.HTTPServer --port 8081
2021-12-17 20:47:34.423 +0100 INFO org.languagetool.server.DatabaseAccessOpenSource Not setting up database access, dbDriver is not configured
2021-12-17 19:47:34 +0000 WARNING: running in HTTP mode, consider running LanguageTool behind a reverse proxy that takes care of encryption (HTTPS)
2021-12-17 19:47:37 +0000 Setting up thread pool with 10 threads
2021-12-17 19:47:37 +0000 Starting LanguageTool 5.5 (build date: 2021-10-02 12:33:00 +0000, 5e782cc) server on http://localhost:8081...
2021-12-17 19:47:37 +0000 Server started
Damit LanguageTool jetzt die von euch optional installierten N-Gramm-Daten integriert, erstellt ihr nun mit einem Editor wie Nano unterhalb des Ordners /opt/LanguageTool die Konfigurationsdatei languagetool.cfg. Als Inhalt fügt ihr die Ausgabe nach dem im folgenden Listing eingefügten Kommando cat languagetool.cfg ein. Mit der Tastenkombination [Strg]+[O] und [Eingabe] speichert ihr die Änderung des Editors ab, mit [Strg]+[O] geht es dann zurück auf die Shell. Selbstverständlich könnt ihr auch jeden anderen Editor verwenden.
Damit der LanguageTool-Server nun automatisch mit dem Rechner hochfährt, legt ihr eine sogenannte Unit für Systemd an. Dazu übertragt ihr den Inhalt aus dem folgenden Listing in die noch zu erstellende Datei /etc/systemd/system/languagetool.service. Orientiert euch beim Aufruf des Editors an der Nano-Zeile im vorhergehenden Listing. Alle Pfade beziehen sich auf den bei der Installation gewählten Ordner /opt/LanguageTool. Habt ihr ein anderes Installationsziel gewählt, müsst ihr die Pfade selbstverständlich in der Unit-Datei anpassen.
Damit LanguageTool nicht mit Root-Rechten oder mit den Rechten eures Benutzers laufen muss, legt ihr nun noch einen eigenen System-Benutzer mit dem Namen languagetool an, ein Home-Verzeichnis braucht er nicht. Er muss sich auch nicht anmelden, daher wird auch kein Passwort gesetzt. Anschließend lasst ihr Systemd seine Konfiguration neu einlesen und aktiviert das Starten des LanguageTool-Servers. Danach ruft ihr den Dienst einmal von Hand auf und lässt euch zur Kontrolle den Status ausgeben. Der Dienst sollte sich mit active (running) zurückmelden und auch die ersten Logeinträge ausgeben.
$ sudo adduser --system --no-create-home languagetool
$ sudo systemctl daemon-reload
$ sudo systemctl enable languagetool
$ sudo systemctl start languagetool
$ sudo systemctl status languagetool
● languagetool.service - LanguageTool
● languagetool.service - LanguageTool
Loaded: loaded (/etc/systemd/system/languagetool.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2021-12-18 00:36:38 CET; 4s ago
Main PID: 4763 (java)
Tasks: 14 (limit: 2314)
Memory: 72.3M
CPU: 1.569s
CGroup: /system.slice/languagetool.service
└─4763 /usr/bin/java -cp /opt/LanguageTool/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 8081 --allow-origin * --public
Dez 18 00:36:38 lui-test systemd[1]: Started LanguageTool.
Dez 18 00:36:39 lui-test java[4763]: 2021-12-18 00:36:39.486 +0100 INFO org.languagetool.server.DatabaseAccessOpenSource Not setting up database access, dbDriver is not configured
Dez 18 00:36:39 lui-test java[4763]: 2021-12-17 23:36:39 +0000 WARNING: running in HTTP mode, consider running LanguageTool behind a reverse proxy that takes care of encryption (HTTPS)
Dez 18 00:36:39 lui-test java[4763]: 2021-12-17 23:36:39 +0000 WARNING: running in public mode, LanguageTool API can be accessed without restrictions!
Dez 18 00:36:40 lui-test java[4763]: 2021-12-17 23:36:40 +0000 Setting up thread pool with 10 threads
Dez 18 00:36:40 lui-test java[4763]: 2021-12-17 23:36:40 +0000 Starting LanguageTool 5.5 (build date: 2021-10-02 12:33:00 +0000, 5e782cc) server on http://localhost:8081...
Dez 18 00:36:40 lui-test java[4763]: 2021-12-17 23:36:40 +0000 Server started
Chrome/Firefox und LibreOffice konfigurieren
Im Gegensatz zur LanguageTool-Erweiterung für LibreOffice arbeiten die Browser-Erweiterungen für Chrome und Firefox in der Standardkonfiguration immer mit dem kommerziellen Backend des Dienstes zusammen. Um nun euren eigenen LanguageTool-Server in die Einstellungen einzutragen, öffnet ihr (unter Chrome) über das Menü mit den drei Punkten rechts oben den Eintrag Weitere Tools | Erweiterungen. Dort sucht ihr dann die Karte zur Grammatik- und Rechtschreibprüfung – LanguageTool heraus und tippt auf den Button Details, im nächsten Dialog dann weiter auf die Optionen. In den Einstellungen zu LanguageTool angekommen, müsst ihr euch via Ausloggen vom Dienst abmelden. Danach könnt ihr unter Experimentelle Einstellungen (nur für Profis) die URL zum eigenen LanguageTool-Server in der Art http://Server-IP:Port/v2 eintragen.
Nach der Installation tragt ihr euren LanguageTool-Server in Chrome oder Firefox ein.
Ähnlich funktioniert die Konfiguration auch mit der LanguageTool-Erweiterung für LibreOffice. Hier öffnet ihr über den Menüeintrag Extras | LanguageTool | Optionen… die Einstellungen. Die URL zu eurem Server tragt ihr dann im Reiter Allgemein ein. Im Gegensatz zur Konfiguration der Browser-Erweiterung kommt hier allerdings kein /v2 an das Ende der URL. Es genügt die Server-IP zusammen mit der Nummer des Ports einzutippen. Das N-Gramm-Verzeichis (wie im Screenshot abgebildet) müsst ihr nicht zwingend lokal abspeichern. Nutzt ihr einen Server mit eigenen N-Gramm-Daten, ist dieser Schritt natürlich nicht nötig.
Auch die LanguageTool-Erweiterung kann man auf einen den eigenen Server umleiten.
LanguageTool auf einem Raspberry Pi
Im Prinzip erfüllt der Raspberry Pi die Anforderungen von LanguageTool: Ausreichend Speicherplatz lässt sich mit einer entsprechend großen Speicherkarte schaffen. Auch die Rechenkapazität der vierten Generation des Mini-Rechners genügt vollkommen. Und der Raspberry Pi 4 lässt sich zusammen mit der ARM64-Version des Raspberry Pi OS auch mit 64 Bit fahren, den Server gibt es nur in einer 64-Bit-Version. Die Installation und der Aufruf funktioniert daher auch, schiebt man allerdings die ersten Texte zur Korrektur auf den Raspberry Pi, dann meldet das System Probleme mit Hunspell und BridJ.
pi@raspberrypi:/opt/LanguageTool $ java -cp /opt/LanguageTool/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 8081 --allow-origin "*" --public
[...]
/tmp/BridJExtractedLibraries1395486954380915815/libbridj.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform))
[...]
Caused by: java.lang.RuntimeException: Could not create hunspell instance. Please note that LanguageTool supports only 64-bit platforms (Linux, Windows, Mac) and that it requires a 64-bit JVM (Java).
Die Thematik wird bereits im Github des LanguageTool-Projekts diskutiert. Dort gibt auch einen Patch für BridJ sowie einen Workaround für Hunspell — ich habe beides allerdings hier bei mir nicht zum Laufen gebracht. Wer noch ein wenig mehr Experimentieren möchte, dem würde ich zu diesem Docker-Image für LanguageTool von Erik van Leeuwen raten. Es soll auch auf ARM64 laufen, also auch auf einem Raspberry Pi der vierten Generation. Ich habe hier bei mir allerdings LanguageTool inzwischen zufriedenstellend auf einem kleinen Intel Nuc laufen, von daher habe ich mich nicht weiter mit dem Betrieb von LanguageTool auf einem Raspberry Pi beschäftigt.
