Manchmal kommt man um das Ändern von Quelltexten und Paketen nicht herum. In dem folgenden Fall ging es um das Paket cron, in dessen Quelltext der Pfad zum Speichern von Laufzeitdaten fest vorgegeben ist.
Das ist so lange kein Problem, wie das Dateisystem normal funktioniert. Nun war es bei einem Produktivsystem aber leider so, dass das Dateisystem exakt an der Stelle des cron-Laufzeitverzeichnisses einen Fehler hatte, der den Zugriff (auch Ändern, Löschen, etc. mit Root-Rechten) auf dieses verhinderte.
Quelltext anpassen
Das Wiederherstellen des Betriebssystems zur Korrektur des grundlegenden Fehlers schied zu dem Zeitpunkt aus. Es blieb als Möglichkeit nur, den Pfad innerhalb des cron-Paketes zu ändern. Diese Kurzanleitung beschreibt das Vorgehen vom Herunterladen des cron-Quelltextes bis zum Installieren des gepatchten Paketes.
Den Quelltext von cron herunterladen und die Pakete installieren, die zum Bauen benötigt werden:
cd /tmp/ apt source cron apt build-dep cron
Im cron-Quelltext alle Vorkommen des Pfades /var/spool/cron auflisten, durch den neuen Pfad /var/spool/cron2 ersetzen und das Ersetzen überprüfen:
cd cron-3.0pl1 grep var/spool/cron -r -l . grep var/spool/cron -r -l . | xargs -n 1 sed -i 's#var/spool/cron#var/spool/cron2#g' grep var/spool/cron -r -l . Nun den Quelltext übersetzen und das Paket neu bauen:
dpkg-buildpackage -us -uc Anschließend das neue Paket installieren:
cd .. dpkg -i cron_3.0pl1-127+deb8u1_amd64.deb Überprüfen, ob cron jetzt läuft und der neue Pfad existiert:
ps -A | grep cron ls /var/spool/cron2/ Die nun installierte cron-Version von späteren Aktualisierungen ausschließen:
echo cron hold | dpkg --set-selections
Mit freundlicher Genehmigung übernommen von der Webseite von Hauke Goos-Habermann. Lizenz: CC BY-NC-ND 3.0 DE
Es ist ein leidiges Thema: die Passwörter. Vor allem im Internet braucht man sie an jeder Ecke. Trotzdem haben viele Menschen Probleme damit, ein sicheres Passwort zu wählen. Das Hasso-Plattner-Institut zählt im Augenblick fast elf Milliarden geleakte Nutzerkonten.
Dumme Passwörter überwiegen
Die beliebtesten Passwörter daraus sind 123456, 123456789 oder password. In fast 14 % aller Fälle (oder zumindest jener, wo die Passwörter der Leaks gar im Klartext vorlagen), werden sie verwendet. Das stellt nun auch erstmals der Weisenrat für Cyber-Sicherheit fest. Aber nicht nur die Nutzer tragen Schuld, sondern auch Entwickler, die ihre Passwort-Datenbanken nicht ausreichend schützen, wenn sie beispielsweise veraltete Hash-Verfahren nutzen.
Überholte Regeln
Im Bericht zitierte Studien kommen zu dem Schluss, dass viele Passwort-Richtlinien wenig bringen. Das regelmäßige Ändern von Passwörtern ist schon seit längerer Zeit aus der Mode gekommen, mittlerweile stehen aber auch andere der häufig aufgestellten Regeln in der Kritik: Das betrifft vor allem eine festgelegte Anzahl an Groß- und Kleinbuchstaben sowie an Zahlen und Sonderzeichen.
Viel wichtiger ist eine ausreichende Passwortlänge (mindestens 8 Zeichen) und wo möglich eine Zwei-Faktor-Authentisierung (diese aber möglichst nicht per SMS). Auch muss sich das Passwort von Account zu Account signifikant unterscheiden und bestenfalls zufallsgeneriert sein.
Installation und Einrichtung
Nun, so sinnvoll das auch klingt, bei den Dutzenden Accounts, die man so hat, klingt das sehr unpraktikabel. Und an dieser Stelle kommen Passwort-Manager ins Spiel. Prominenter Vertreter im Linux-Kosmos ist KeePassXC. Es ist der Fork eines Forks. Ursprung ist das Windows-Programm KeePass, welches die .NET Platform benötigt. KeePassX lief dann auch nativ unter Linux.
Nachfolger KeePassXC
Nachdem es nicht mehr weiterentwickelt wird, ist KeePassXC an die Stelle getreten. Hat man bereits eine Datenbank aus einem anderen Programm oder einem anderen Dienst, so lassen sich diese einfach importieren. Sonst ist eine neue Datenbank schnell angelegt, bietet allerdings auch spezielle Verschlüsselungseinstellungen. Geschützt wird diese Datenbank mit einem Master-Passwort. Verbessern kann man den Schutz dann noch durch eine Schlüsseldatei oder einen Sicherheitsschlüssel.
In der Datenbank kann man seine Accounts nach Gruppen sortieren und so den Überblick behalten. Will man einen Eintrag hinzufügen, kann man sich auch ein Passwort, oder aber eine Passphrase generieren lassen, samt Einschätzung zur Sicherheit.
Browser-Integration
Wirklich bequem ist das Wechseln zwischen Browser und KeePassXC zum Kopieren von Nutzernamen und Passwort nicht. Zumindest im Vergleich zum Passwort-Manager des Browsers. Dem kann allerdings Abhilfe geschaffen werden: KeePassXC verfügt über eine Browser-Integration. Diese muss in den Einstellungen für den jeweiligen Browser aktiviert und das entsprechende Plug-in für den Browser installiert werden. Die Verbindung zwischen Passwort-Manager und Browser ist verschlüsselt.
Andere Plattformen
Auch die Nutzung auf anderen Plattformen ist möglich. So gibt es KeePassXC nicht nur in den Paketquellen, als AppImage oder Snap für alle gängigen Linux-Distributionen, sondern auch für macOS und Windows. Für Smartphones ist die Datenbank mit Keepass2Android und Strongbox kompatibel. Um die Synchronisation muss man sich allerdings selbst kümmern. Das kann über das Ablegen in der eigenen Nextcloud oder bei Dropbox, Google Drive und ähnlichem eingerichtet werden. Ob das allerdings eine gute Idee ist, muss jeder selbst entscheiden.
Backup
Definitiv eine gute Idee ist es allerdings ein Backup anzulegen. Denn wenn man das Master-Passwort verliert, die Datenbank beschädigt oder seinen Sicherheitsstick verlegt, kommt man an seine Passwörter sonst nicht mehr ran. Für die analoge Welt kann man dafür auch die Exportfunktion zu einer CSV oder HTML-Datei nutzen und den Ausdruck sicher abheften. Das generierte Passwort muss man in näherer Zukunft eh nicht mehr wechseln.
Einmal-Passwörter unterstützt
Darüber hinaus bietet KeePassXC noch weitere praktische Funktionen. So werden neben SSH-Agenten auch Einmal-Passwörter (TOTP), wie sie häufig für die 2-Faktor-Authentifizierung benötigt werden, unterstützt. Diese kann man bei Rechtsklick auf den Account hinzufügen. Allerdings sollte man sich bewusst sein, dass man damit durchaus den Sinn des zweiten Faktors konterkariert. Deshalb lautet die Empfehlung, für Einmal-Passwörter zumindest eine separate Datenbank anzulegen.
Dank an Lennart Diener für diesen Communitybeitrag!
Flatpak ist als modernes Paketformat im Aufschwung. Distributionen wie Fedora Silverblue oder Endless OS setzen bereits ganz oder zu großen Teilen auf das junge Format. Dabei sind die Linux-Anwender von Flatpak oder den Alternativen Snap und AppImage bisher nicht durchgehend überzeugt.
Flatpak ist nicht unumstritten
Die Eigenschaften von Flatpaks werden hochgelobt oder abgelehnt, je nachdem wen man fragt. Nehmen wir einmal die Plattformunabhängigkeit als Beispiel. Entwickler freuen sich, dass das gleiche Flatpak auf fast allen Distributionen läuft und ihnen damit Arbeit erspart. Ein Debian-Anwender wird aber beispielsweise beklagen, dass er die Anpassungen an die Debian-Richtlinien, die bisher der nun überflüssige Paket-Maintainer vornahm, vermisst.
Rechte bisher unübersichtlich
Auch was die Rechte angeht, die Flatpaks in einem System haben, herrscht Uneinigkeit. Flatpaks laufen in einer Sandbox und lassen sich von daher vollständig gegenüber dem Host-System isolieren. Das ergibt allerdings bei den allerwenigsten Anwendungen Sinn. Der Paketierer gibt dem Flatpak die benötigten Rechte, damit die Anwendung ihren Zweck erfüllen kann. Doch wie sehe ich als Anwender, worauf ein Flatpak Zugriff hat und kann ich diese Rechte ändern oder erweitern?
Über die Kommandozeile ging das schon immer mit dem Befehl flatpak override, ist aber den meisten Anwendern zu umständlich. Seit rund einem Jahr war auch die Software-Verwaltung von GNOME 3.32 in der Lage, über die Sektion Anwendungen Rechte von Flatpaks zu ändern.
Flatseal to the rescue
Mit der neuen App Flatseal ist das jetzt noch mal ein wenig einfacher geworden. Laut Eigenbeschreibung ist Flatseal »ein grafisches Dienstprogramm zur Überprüfung und Änderung grundlegender Berechtigungen von Flatpak-Anwendungen.« Das erledigt die App in übersichtlicher Weise, indem links in einer Leiste die installierten Flatpaks aufgelistet sind und rechts im Hauptfenster die entsprechenden Rechte, die über einen Schalter manipuliert werden können.
Viel mehr gibt es nicht zu sagen. Nach der Änderung von Rechten muss das Flatpak neu gestartet werden. Sollte etwas schiefgehen, lassen sich die Rechte oben rechts über eine Schaltfläche auf die im Flatpak vergebenen Rechte zurücksetzen. Das Projekt wird auf GitHub gehostet.
Ich habe gerade einen neuen Rechner in Betrieb genommen. Beim alten PC wurden die Freigaben per autofs automatisch eingebunden, da das Einbinden per fstab mit Nachteilen verbunden sein kann. Leider ist es mir nicht gelungen, die Konfiguration des alten Rechners auf die der neuen Box anzupassen.
Systemd to the Rescue
Nach Stunden des Probierens suchte ich nach Alternativen und entschloss mich, Systemd-Mounts zu testen. Und siehe da, nach 10 Minuten war der erste Share da und erschien auch im Dateimanager Dolphin. Um dahin zu kommen, mussten lediglich zwei einfache Systemd-Units erstellt werden. Als Vorgabe muss lediglich das Paket nfs-common installiert sein.
Units erstellen
Die Units bei Systemd unterscheiden sich nicht sehr von den Service-Files, die vermutlich jeder Linux-Nutzer schon mal gesehen hat. Die erste Unit endet auf .mount, die zweite auf .automount. Bei mir sehen diese wie folgt aus:
Eigentlich ist es selbsterklärend. Description ist lediglich beschreibend. Der Eintrag hinter What verweist auf die Adresse und die Freigabe, das Where legt fest, wohin gemounted wird. Der Typ ist bei mir NFS, könnte aber auch Cifs sein. Die benötigten Optionen kann man sich im NFS-Howto zusammenstellen.
Die zweite Unit mit der Endung .automount macht genau was der Name besagt: Sie liest die soeben beschriebene .mount und hängt die dort benannte Freigabe ein:
Auch hier wieder die Beschreibung an erster Stelle. Die zweite Zeile legt fest, dass die Datei NetworkManager.service benötigt wird. Der Automounter soll dann die Freigaben einhängen, nachdem das Netzwerk steht. TimeoutIdle legt fest, dass die Freigabe ohne Aktivität nach der angegebenen Zeit wieder ausgehängt wird. Die Install-Anweisung besagt, in welchem Runlevel die Unit gestartet werden soll. Ich habe hier das Multi-User-Runlevel gewählt.
Nomen est Omen
Was die Namen der beiden Units angeht, so werden sie aus dem Pfad des Einhängepunkts gebildet, indem / gegen – ausgetauscht wird. Aus media/ft/nas wird media-ft-nas.mount bzw. media-ft-nas.automount. Bei längeren Namen kann man sich auch des Befehls sudo systemd escape [mountpoint] bedienen.
Verschieben und aktivieren
Die solchermaßen benannten Dateien werden nach /etc/systemd/system verschoben. Jetzt fehlen noch zwei Befehle um die Automount-Unit jetzt und künftig beim Booten zu starten:
systemctl start media-ft-nas.automount
systemctl enable media-ft-nas.automount
Der Zustand kann mit systemctl status media-ft-nas.automount kontrolliert werden und liefert im Erfolgsfall beispielsweise zurück:
ft@blue:/etc/systemd/system$ systemctl status media-ft-nas.automount ● media-ft-nas.automount - Automount /media/ft/nas Loaded: loaded (/etc/systemd/system/media-ft-nas.automount; enabled; vendor preset: enabled) Active: active (waiting) since Sun 2019-12-22 12:45:52 CET; 2h 57min ago Triggers: ● media-ft-nas.mount Where: /media/ft/nas
Das wars auch schon. Sollte etwas nicht funktionieren, kann man als erstes testen, welche Freigaben überhaupt vorhanden sind. Das geht mittels:
sudo showmount -e 192.168.XXX.YY
Der einzige Nachteil, der ins Auge springt, ist, dass für jede Freigabe eigene Units angelegt werden müssen. Aber die müsste man in der fstab auch einzeln eintragen. Und man muss es ja nur einmal machen. Falls jemand hier eine Abkürzung kennt, ich bin ganz Ohr.
Jeder, der viel und zudem öffentlich schreibt, verwendet vermutlich zum Korrekturlesen eine Software, die dabei hilft, Rechtschreib- und Grammatikfehler auszubügeln und zusätzlich auf Stilblüten hinzuweisen. Die Auswahl an brauchbaren Lösungen hierfür ist nicht gerade üppig, fast immer handelt es sich jedoch um proprietäre Bezahl-Software.
Es geht auch anders
Dass es auch als Open Source geht, beweist die Firma LanguageTooler GmbH aus Potsdam mit ihrer App LanguageTool. Die Anwendung ist Open Source unter der GNU Lesser General Public License v2.1 und wird für insgesamt rund 30 Sprachen angeboten, die unterschiedlich gut unterstützt sind. Die sehr agile Entwicklung findet auf GitHub statt. Das Projekt wird von der Europäischen Union im Rahmen des Europäischen Fonds für regionale Entwicklung (EFRE) finanziell gefördert.
Breite Unterstützung
LanguageTool ist als Web-App, als Java-basierte Version für den Desktop (auch offline) sowie für OpenOffice/LibreOffice, Google Docs und Microsoft Word verfügbar. Zudem gibt es Erweiterungen für Firefox und Chrome, die auf allen von mir getesteten Webseiten einen guten Job machen. Darüber hinaus gibt es eine ganze Reihe von der Community gepflegter Plug-ins für Anwendungen wie unter anderem Eclipse, Emacs, InteliJ, Lyx, Thunderbird, Vim und Editoren wie Atom, Sublime oder TinyMCE 4.
Alle Freiheiten
Ein weiterer Vorteil offener Entwicklung ist die Möglichkeit, LanguageTool selbst zu bauen, mit der CLI-Erweiterung der Standalone-Version im Terminal, auf einem Server oder in Docker zu verwenden. Mit languagetool-commandline.jar aus dem Zip-Archiv lassen sich einzelne Dateien, aber auch ganze Verzeichnisse überprüfen. Ich habe LanguageTool als Plug-in in Chrome, als Web-App und Standalone sowie in LibreOffice unter Debian Sid getestet. Voraussetzung für die Standalone- und LibreOffice-Versionen ist Java 8, egal ob von Oracle oder als OpenJDK. LibreOffice sollte dazu mindestens in Version 6.x vorliegen. Obwohl Java von Oracle empfohlen wird, lief die Erweiterung auch mit OpenJDK sofort problemlos.
Die Funktionalität ist bei den von mir getesteten Versionen unter LibreOffice am größten und geht weit über die üblichen Rechtschreibprüfungen hinaus, indem eine große Zahl an Stilprüfungen genutzt werden kann. Diese sind abwählbar, wenn sie nicht gebraucht werden. Wenn die gebotene Funktionalität nicht reicht, kann zusätzlich ein riesiger N-Gramm-Datensatz eingebunden werden.
Ziemlich fehlerfrei
Die Entwickler sind freundlich und helfen schnell und ausdauernd, wenn nötig. Hilfe und Unterstützung gibt es aber auch in einem Forum und im Wiki. LanguageTool ist kostenlos, bietet aber auch eine Premium-Version, die ich mittlerweile nutze, da sie zusätzliche Optionen bietet, die ich als Autor sehr hilfreich finde. Für den Hausgebrauch schlägt sich die kostenlose Version aber prima und sorgt dafür, dass man sich mit seinen Texten und E-Mails nicht blamiert.
Screenshots gehören zum täglichen Arbeitsfluss vieler Anwender, sei es im beruflichen oder privaten Umfeld. Über die Jahre hat sich Shutter als mächtiges plattformübergreifendes Werkzeug bewährt.
Shutter ist weg
Shutter wurde allerdings zumindest aus Ubuntu 18.10 und Debian Unstable entfernt, da es veraltete Abhängigkeiten aufweist. Somit wird es auch im bald erwarteten Debian Buster nicht mehr verfügbar sein.
Zwar haben die Desktop-Umgebungen unter Linux fast alle ihre eigenen Tools für Screenshots. Diese beschränken sich aber meist auf das reine Aufnehmen von Screenshots und lassen Editierfunktionen vermissen.
Flameshot
Vor fast einem Jahr habe ich hier Flameshot vorgestellt. Ich verwende es mit Vorliebe, weil es ein etwas anderes Konzept verwendet und auf ein festes Fenster völlig verzichtet. Flameshot wird ständig weiterentwickelt und erhält neue Funktionen, obwohl es bereits recht komplett ist. Lediglich bei den Editierfunktionen kann es noch zulegen.
Ksnip
Gemeinsam ist Flameshot und Ksnip, unserer heutigen Vorstellung, die Basis Qt, wie das K im Namen bereits vermuten lässt. KSnip ist für Linux, macOS und Windows verfügbar. Wie auch Flameshot beherrscht auch Ksnip bereits Screenshots unter Wayland-Sitzungen mit GNOME oder Plasma, wenn auch noch experimentell.
Auch mit Wayland
Diese Eigenschaft ist keinesfalls selbstverständlich, denn Wayland erfordert eine andere Herangehensweise, um so etwas Alltägliches wie einen Screenshot zu erstellen. Aus Sicherheitsgründen ist im Display-Protokoll Wayland selbst nur das Nötigste definiert. Dinge wie Screen-Sharing oder auch einfache Screenshots müssen extern gelöst werden und sind in diesem Fall über PipeWire realisiert worden.
Auch für CLI
Ksnip wird beständig weiterentwickelt, aktuell ist Version 1.5, die 1.6 kann bereits getestet werden. Eine nette Zugabe im Menü ist das nachträgliche Skalieren einer Aufnahme, ansonsten ist hier alles Standard. In die Cloud geht es per Imgur. Screenshots lassen sich ausdrucken oder als ps/pdf speichern. Auch auf der Kommandozeile lassen sich Screenshots erstellen.
Im Fadenkreuz
Wird ein rechteckiger Bereich für einen Screenshot gewählt, so wird das Aufziehen durch eine Lupe mit Fadenkreuz und durch am Mauszeiger klebende horizontale und vertikale Lineale erleichtert. Sobald die Aufnahme im Kasten ist, stehen ausgereifte Editierfunktionen zur Bearbeitung bereit. Dazu zählen Stift, Marker, Rechteck, Ellipse, Text und Zahl sowie ein Blur-Effekt zum Verwischen.
Wer Shutter in seiner Distribution vermisst, findet nun neben Flameshot auch bei Ksnip ein geeignetes Werkzeug. Auf der GitHub-Seite stehen neben Paketen für Windows und macOS auch DEB- und RPM-Pakete für Linux sowie ein AppImage zum unverbindlichen Testen bereit.
Es ist bekannt dass Lithium-Ionen-Akkus ein längeres Leben haben, wenn sie nicht ständig ganz entleert oder voll geladen werden. Es ist sinnvoll, den Ladestand zwischen 20-30 und 70-80 Prozent zu halten. Bei ThinkPads mit Windows 10 bietet die Zusatzsoftware Lenovo Vantage Zugriff auf die Einstellungen.
Linux lange im Nachteil
Für Linux war lange Jahre Handarbeit angesagt. Zudem musste man bei jedem neuen ThinkPad-Modell erneut im ThinkWiki recherchieren, wie eine eventuell geänderte Firmware die Optionen handhabt. Es mussten ein oder zwei Kernelmodule installiert und dann die gewünschten Werte in virtuelle Dateien unter /sys/devices/platform/smapi eingetragen werden.
TLP samt GUI
Mittlerweile bietet die Software Linux Advanced Power Management (TLP) unter vielen anderen nützlichen Einträgen auch einen Abschnitt für den Akku, in dem diese Einstellungen vorgenommen werden können. TLP ist für die Kommandozeile entwickelt worden, allerdings gibt bereits seit Jahren die grafische Oberfläche TLPUI, um diese und andere Einstellungen auch grafisch vornehmen zu können.
Schnell installiert
Dazu wird der Code von GitHub gecloned oder als Zip heruntergeladen und entpackt. Als Abhängigkeiten erwartet die Software TLP, Python 3 und die GTK3-Bibliotheken. Dann wird aus dem Ordner TLPUI heraus der Befehl python3 -m tlpui aufgerufen.
TLPUI bereitet die Funktionen von TLP grafisch auf
Kernel-Module benötigt
Der entsprechende Abschnitt ThinkPad Battery erläutert, dass eins von zwei Kernel-Modulen erforderlich ist, damit die Einstellungen greifen. Dabei handelt es sich um die beiden gleichen Module tp-smapi-dkms und acpi-call-dkms, die man auch früher schon installieren musste, um die Funktion händisch einzurichten. Beide Module stehen unter den großen Distributionen zur Installation bereit.
Funktioniert tadellos
Da TLP nicht bestimmen kann, welches Modul bei welchem Modell benötigt wird, ergibt es Sinn, beide zu installieren. Nachdem die Einstellungen für den Akku vorgenommen wurden, nicht vergessen, diese im Menü unter Datei zu speichern. Bei mir funktioniert das mit den Modellen E580 und T540p problemlos.
Wer einmal Windows genutzt hat oder immer noch nutzt, kennt die Funktionalität von System Restore. Ist das System kaputt, spielt man eine ältere Version zurück. Vom Prinzip her macht das hier vorgestellte Script CYA das gleiche.
Kein Backup
Es handelt sich dabei nicht um ein Backup-Programm, sondern um eine Systemwiederherstellung. Die Dateisysteme Btrfs und ZFS kennen das Genre als Snapshot und diesen Begriff werde ich der Einfachheit halber auch hier verwenden.
RSync lässt grüßen
CYA ist ein Bash-Script, das einfach und mit wenigen Befehlen zu handhaben ist und im Hintergrund Befehle von Rsync abarbeitet. Standardmäßig werden drei Snapshots gespeichert, die automatisiert oder manuell angelegt wurden. Danach wird der jeweils älteste Snapshot überschrieben. Dieses Verhalten kann individuell angepasst werden.
Ausnahmen definieren
Es können auch Snapshots angelegt werden, die nicht überschrieben werden sowie Snapshots komprimiert und archiviert werden, die dann gar nicht in der Liste der Sicherungen auftauchen. Der Anwender bestimmt detailliert, was gesichert wird. Standardmäßig ist hier der gesamte Root-Baum voreingestellt. Wenn etwa /var/log oder andere Verzeichnisse nicht gesichert werden soll, werden sie ausgenommen.
Automatisiert sichern
CYA eignet sich hervorragend, um per Systemd oder Cron automatisiert ausgeführt zu werden. Auch ansonsten kann es gut in Scripte eingebunden oder auf Servern verwendet werden. Zudem funktioniert die Wiederherstellung auch dann, wenn die grafische Oberfläche nicht mehr zugänglich ist. CYA arbeitet laut dem Entwickler mit jeder Linux- und BSD-Distribution zusammen und theoretisch auf jedem System, das eine Bash und Rsync zu bieten hat. Das konnte ich bisher nicht widerlegen.
Gesamt oder einzeln
CYA erstellt einen Wiederherstellungspunkt, der den Root-Baum umfasst, das Home bleibt dabei außen vor, kann aber bei Bedarf über die Funktion CYA Mydata separat gesichert werden. Das Script CYA nutzt standardmäßig keine Komprimierung oder ein proprietäres Format. Bei einer Rücksicherung können deshalb außer dem gesamten System auch einzelne Dateien oder Verzeichnisse einfach per Dateimanager oder Terminal wiederhergestellt werden.
Anwender von Bleeding-edge-Rolling-Release-Distributionen kennen das Problem, dass man sich durch Unachtsamkeit beim Aktualisieren schnell mal das System zerschießen kann, sodass es nicht einmal mehr booted. Hier bietet sich CYA an, um in einem solchen Fall schnell wieder ein funktionierendes System zur Verfügung zu haben.
Vorbildlich dokumentiert
CYA ist hervorragend dokumentiert, allerdings lediglich auf Englisch. Die Webseite des Projekts bietet eine kurze Einleitung, der Quellcode befindet sich auf Github, wo das Tool auch ausführlich besprochen wird. Darüber hinaus werden alle Funktionen und deren technische Hintergründe in einer 17-teiligen YouTube-Serie ausführlich besprochen. Ein ausführlicher Artikel von mir zum zum Thema wird im Mai kostenlos online gestellt.
Wer oft Screenshots aufnimmt, kennt das Problem: Es gibt genügend Anwendungen in Linux, um Screenshots aufzunehmen, egal ob mit grafischer Oberfläche oder aus einem Terminal. Das Problem ist eher, das geeignete Tool passend zum eigenen Workflow zu finden. Universell im Terminal einsetzbar ist Scrot.
Grafikprogramme wie Gimp oder ImageMagick erlauben ebenfalls die Erstellung von Screenshots. Zudem bringt fast jede Desktop-Umgebung zu diesem Zweck ihr eigenes Werkzeug mit. GNOME-Screenshot und Xfce-Screenshooter sprechen für sich selbst, bei KDE Plasma heißt das entsprechende Werkzeug Spectacle. Und es gibt noch mehr.
Screenshots editieren
Was aber all diese Anwendungen nicht beherrschen ist das Editieren von Screenshots. Da ich beruflich fast täglich Screenshots aufnehme und diese auch oft editieren muss, suchte ich lange nach der idealen Lösung, die zu meinem Arbeitsstil und den Anforderungen passt. Eine Weile nutzte ich Dickschiffe wie Shutter oder HotShots. Ich finde diese Art des Arbeitens nicht intuitiv. Erst aufnehmen, speichern, dann den Editor aufrufen…
Bis ich die Qt-basierte Anwendung Flameshot entdeckte. Flameshot bietet eine simple und intuitive Oberfläche, wo alles innerhalb eines Mauswegs von einigen Zentimetern liegt und auf einen Blick erfassbar ist. Das nenne ich Ergonomie in Software. Die Anwendung quartiert sich entweder im Systemabschnitt der jeweiligen Leiste ein oder wird aus der Kommandozeile aufgerufen.
GUI, Terminal oder Tastaturkürzel
Die Befehlsstruktur ist schnell erlernt und erlaubt, zu definieren, was wann aufgenommen werden soll und wo es hinsoll. Dieses Konzept ergibt Sinn, wenn die aufgenommenen Bilder nicht bearbeitet, sondern gespeichert werden sollen. So erstellt Befehl flameshot full -p ~/screenshots -d 5000 ein Abbild des gesamten Bildschirms mit fünf Sekunden Verzögerung und speichert es im heimischen Ordner screenshots. Die Konfigfuration wird per flameshot config aufgerufen, die Hilfe über flameshot -h.
Tastaturkürzel helfen dabei, schnell zu Ergebnissen zu kommen. So erledigt Strg+Umschalt+Druck die Aufgabe, einen Screenshot der Displays allenr Monitore aufzunehmen und in der Zwischenablage zu speichern. Ich nutze aber hauptsächlich die GUI-Variante, da ich Screenshots häufig editieren muss, wenn sie im Netz oder in Zeitschriften abgebildet sind. Dabei geht es meist darum, private Informationen unkenntlich zu machen oder bestimmte Stellen der Abbildung hervorzuheben.
Aktive Weiterentwicklung
Ich habe Flameshot im Autostart, muss es im Bedarfsfall also einfach im Tray anklicken. Mit Flameshot kann ich praktischerweise Screenshots noch während des Erstellens editieren und nicht erst hinterher. Das Hinterlegen der Anwendung auf die Drucktaste geht bisher noch nicht automatisch, hier muss noch Hand angelegt werden. Auch das wird nicht lange auf sich warten lassen, ist Flameshot doch unter ständiger Entwicklung und bringt derzeit 1 – 2 mal im Monat ein Upgrade.
Flameshot ist mittlerweile in vielen Distributionen in denArchiven. Obwohl Qt-basiert, lässt sich Flameshot auch ohne großen Aufwand außerhalb von Plasma oder LXQt anwenden. Die Installation von Flameshot auf einem frisch installierten Xfce4-Desktop benötigt rund 25 MByte an Bibliotheken. Alle weiteren Informationen sind auf der Projektseite versammelt
Nach der News über die Aktualisierung zu KDE Connect 1.3 kam im IRC die Frage auf, wie denn URLs vom Desktop-Browser an ein mobiles Gerät übermittelt werden können. Dies ist eine, wie ich finde, sehr nützliche Funktion, denn oft kann man einen Artikel, den man am Desktop zu lesen begonnen hat, nicht fertig lesen, bevor man aus dem Haus muss. Mit KDE Connect und einer Browser-Erweiterung kann man unterwegs mobil einfach weiterlesen, ohne am Smartphone zunächst eine Suche starten zu müssen.
Zusätzliche Software nötig
Da sich die Nutzung dieser Funktion nicht aus KDE Connect selbst erschließt und zusätzliche Software benötigt, sei das Einrichten hier kurz erläutert. Zusätzlich benötigt wird die Kdeconnect-Chrome-Extension und für jeden zu nutzenden Browser die KDE-Connect-Erweiterung. Zunächst gilt es, die Kdeconnect-Chrome-Extension, die übrigens auch Firefox unterstützt, herunterzuladen und zu entpacken. Dann wird in einem Terminal die Installation angestoßen. Dazu dient als normaler User der Befehl ./kdeconnect-chrome-extension -install. Zuvor sollten die entsprechenden Browser geschlossen werden. Dann gilt es, den ersten Browser auszuwählen. Zur Auswahl stehen Chrome/Opera, Chromium, Firefox und Vivaldi. Zusätzlich gibt es den Eintrag Custom, den ich noch nicht weiter ergründet habe.
Erweiterung im Browser installieren
Pro Durchlauf kann nur ein Browser gewählt werden. Sollen also mehrere Browser aktiviert werden, so muss der Vorgang entsprechend oft wiederholt werden. Daraufhin wird die Erweiterung KDE Connect im jeweiligen Browser installiert. Nach einem Neustart des Browsers ist die Funktion bei Firefox über das Kontextmenü erreichbar. Bei Chrome und den weiteren unterstützten Browsern funktioniert das Versenden über das Erweiterungs-Icon oben rechts im Browser.
Ist also die zu versendende URL im Browser geöffnet, zeigt der KDE-Connect-Eintrag im Kontextmenü oder über das Icon alle verbundenen Geräte an. Nach dem Versenden ist die entsprechende Seite auf dem Mobilgerät bereits geöffnet. In den Einstellungen kann ein bestimmtes Gerät festgelegt werden, an das gesendet wird. Zusätzlich kann dabei der Eintrag im Kontextmenü ausgeblendet werden. Umgekehrt geht das natürlich auch und sogar ohne zusätzliche Software. Im Kontextmenü des Browsers wird über Share… und senden an KDE Connect die jeweilige URL im Desktop-Browser geöffnet.
