Mir ist in der letzten Zeit immer mal wieder aufgefallen, dass GMail (innerhalb von Chrome oder Chromium geöffnet) manche Mails mit einer sehr krackeligen Schrift anzeigt. Analysiert man die betroffenen Nachrichten ein wenig genauer, dann erkennt man recht schnell, dass das Problem in der Darstellung der Microsoft-Schriftart Calibri liegt. Die Thematik betrifft jedoch nun nicht nur Browser (auch in Firefox ist die Darstellung der Schrift misslungen), sondern generell alle Anwendungen wie etwa LibreOffice, die Calibri als Schrift nutzen. Es gibt jedoch einen Workaround, mit dem sich die Darstellung der Schriftart generell optimieren lässt.
Das Problem lässt sich wohl auf vielen Linux-Systemen (ich habe Arch und Ubuntu 16.04 getestet) nachvollziehen, auf denen Calibri als Schriftart installiert wurde. Ein weiteres Beispiel für das schlechte Rendering dieser Schrift wäre etwa die finnische Nachrichtenseite Uusi Suomi — Nein, Finnisch gehört nicht gerade zu den Sprachen, die ich fließend spreche, die Seite war in einem Bugreport zum Thema als weiteres Beispiel verlinkt. Auch hier erscheint die Schrift in weiten Teilen krakelig. Alternativ könnt ihr auch in LibreOffice ein Writer-Dokument öffnen und Calibre als Schriftart einstellen. Auch hier sollte das Problem schnell erkennbar sein.
Krakelige Darstellung von Bitmap-Fonts
Ohne Fontconfig-Hack: Krackelige Darstellung von Calibri bei Gmail.Ohne Fontconfig-Hack: Krackelige Darstellung von Calibri auf anderen Webseiten.
Die krakelige Schriftdarstellung tritt nun bei allen Fonts auf, die Bitmap-Schriften enthalten. Dazu zählt nicht nur der wohl am häufigsten auftretende Fall Calibri, sondern auch andere Microsoft-Schriften wie etwa Cambria (seit Windows Vista und Microsoft Office 2007) oder Monaco (stammt aus OS X). Unter Linux lässt sich der Gebrauch dieser Bitmap-Schriften nun aber recht leicht abstellen. Dazu müsst ihr die Datei /etc/fonts/conf.avail/20-no-embedded.conf mit Root-Rechten anlegen und den Inhalt aus folgendem Listing einfügen. Damit die Einstellung noch aktiv wird, erstellt ihr am Ende ein Symlink der Datei nach /etc/fonts/conf.d/.
Euer System sollte die Konfiguration direkt aufgreifen, ihr müsst lediglich die gewünschten Anwendungen komplett neu starten — Zur Not loggt ihr euch einfach einmal aus der Desktopoberfläche aus und gleich wieder neu ein. Alternativ zum beschriebenen Vorgehen, packt ihr das Listing ohne Root-Rechte in das Homeverzeichnis eures Benutzers nach ~/.config/fontconfig/conf.d/20-no-embedded.conf. Allerdings gilt die Einstellung dann nur für euren User, sodass andere Benutzer wieder über das schlechte Rendering der Schrift klagen werden.
Wenn man gerne mit dem Raspberry Pi oder anderen Single-Board-Computern wie dem Banana Pi, Odroid und Co. bastelt, dann kommt man immer wieder mit SSH in Kontakt. Die für diese Mini-Rechner geeigneten Images basieren ja in der Regel auf einem Linux und bringen von daher auch meistens einen integrierten SSH-Zugang von Haus aus mit. In der „Bastelpraxis“ setzt man diese Rechner nun aber immer wieder neu auf oder zieht mal schnell den Stromstecker, um das Gerät „einfach“ mal schnell durchstarten zu lassen. Dadurch kommt jedoch auch SSH aus dem Tritt: Nach der Installation eines neuen Systems passt der gespeicherte SSH-Schlüssel oder beim plötzlichen Abziehen des Netzsteckers bleibt der SSH-Client hängen. Diese Probleme kann man Quick&Dirty lösen, allerdings gibt es auch immer einen sauberen Weg.
Beim Verbindungsaufbau via SSH speichert der SSH-Client in der Regel den öffentlichen SSH-Schlüssel des entfernten Systems zusammen mit dem Rechnernamen und der IP-Adresse in der Datei ~/.ssh/known_hosts im Homeverzeichnis des aktuellen Benutzers auf dem Client-Rechner. Dies wird unter anderem gemacht um Man-in-the-Middle-Angriffe zu verhindern, bei denen ein Angreifer vorgibt der Zielrechner zu sein, sodass man die Zugangsdaten abfischen kann. Nun schlägt diese Sicherheitsmaßnahme aber auch zu, wenn gar keine Bedrohung vorliegt: Etwa wenn man einen RasPi neu aufsetzt und man sich wieder per SSH einzuloggen versucht. SSH meldet dann in so einem Fall in großen Lettern WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED.
$ ssh pi@192.168.111.100
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Please contact your system administrator.
Add correct host key in /home/toff/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/toff/.ssh/known_hosts:10
ECDSA host key for 192.168.111.100 has changed and you have requested strict checking.
Host key verification failed.
Nun könnte man die Datei ~/.ssh/known_hosts in einen Texteditor öffnen und die problematische Zeile 10 von Hand aus der Liste löschen, es gibt jedoch einen besseren Weg: Mit ssh-keygen -R IP-Adresse lässt sich der Schlüssel aus der Datei mit einem Kommando entfernen, sodass man beim nächsten Aufbau der Verbindung wieder bei „Null“ anfängt — den Schlüssel also wie beim allerersten Verbindungsaufbau zu diesem Rechner bestätigen muss. Das Ganze funktioniert auch, wenn ihr statt der IP-Adresse den Rechnernamen für den Verbindungsaufbau nutzt. Zur Sicherheit kopiert das Kommando den alten Stand nach ~/.ssh/known_hosts.old im selben Verzeichnis.
$ ssh-keygen -R 192.168.111.100
# Host 192.168.111.100 found: line 10
/home/toff/.ssh/known_hosts updated.
Original contents retained as /home/toff/.ssh/known_hosts.old
$ ssh pi@192.168.111.100
The authenticity of host 'raspberrypi (192.168.111.100)' can't be established.
ECDSA key fingerprint is SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.111.100' (ECDSA) to the list of known hosts.
pi@192.168.111.100's password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Apr 22 08:40:10 2016 from 192.168.178.57
pi@raspberrypi:~ $
SSH-Verbindung gewaltsam trennen
Ist man auf einem entfernten Rechner per SSH eingeloggt und fährt diesen per shutdown, halt oder reboot herunter, dann beendet das System die SSH-Verbindung nicht gewaltsam. Das System beendet den SSH-Server während des Herunterfahrens sauber, sodass man wieder im Terminal des Clients-Rechners landet und dort mit demselben Terminalfenster weiterarbeiten kann. Nun stecke ich — und mit Sicherheit auch andere RasPi-Bastler — ganz gerne den Raspberry Pi vom Strom ab und wieder an, um den Rechner kurz und schmerzlos neu zu starten. Dieses Verfahren ist mit Sicherheit nicht ideal für die Integrität der Daten auf der Speicherkarte, aber wenn ich das System auf dieser sowieso neu aufsetzen möchte, kümmert mich diese wenig.
SSH-Verbindungen lassen sich mit einer Reihe von Steuercodes managen.
Der Nachteil ist nun aber, dass bei diesem Vorgang in der Regel auch SSH im Terminal hängen bleibt — schließlich hat man sich gerade den Stuhl unter dem Hintern weggezogen. Nun könnte man den SSH-Prozess abschließen oder das Terminal-Fenster schließen und wieder neu öffnen, doch auch für diese Situation gibt es eine saubere Lösung: SSH kennt eine Reihe von Steuerkommandos, mit denen sich die aktuelle SSH-Sitzung managen lässt. Ihr bekommt eine Übersicht über die zur Verfügung stehenden Kommandos, wenn ihr ~? (also [AltGr]+[+] und [Umschalt]+[ß]) in eine neue Zeile des Terminals eingebt — Man ein Linux-Einsteiger mag [AltGr] verwirren: Mit dieser ist die rechte Alt-Taste neben der Leertaste gemeint. Zur Sicherheit drückt ihr vorher daher einfach einmal auf die Eingabetaste
pi@raspberrypi:~ # ~?
Supported escape sequences:
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~C - open a command line
~R - request rekey
~V/v - decrease/increase verbosity (LogLevel)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
Die von der Hilfe anzeigte erste Sequenz ist bereits die gesuchte Funktion: Gebt ihr während einer SSH-Sitzung als Text ~. ein, drückt also die Tasten [AltGr]+[+] und danach [.], dann beendet ihr die aktuelle SSH-Verbindung ohne Rücksicht auf Verluste. Dies funktioniert eben nicht nur bei einer noch aktiven und weiterhin funktionierenden SSH-Sitzung (die hier ja auch mit exit jederzeit schließen könntet), sondern auch dann, wenn ihr beispielsweise den RasPi vom Strom nehmt und sich im Terminal nichts mehr tut. Auch hier kann es hilfreich sein, vor dem eigentlich Kommando noch einmal zur Sicherheit die Eingabetaste zu drücken. Sonst läuft das Steuerkommando eventuell ins Leere.
SSH-Verbindung pausieren und fortsetzen
Mit den Steuercodes lassen sich jedoch auch andere praktische Dinge machen. So könnt ihr beispielsweise eine SSH-Verbindung unterbrechen und später wieder fortsetzen, ohne dass ihr einen Terminalmultiplexer wie screen oder tmux einsetzen müsst. Braucht ein Prozess mehr Zeit als gedacht, könnt ihr die Verbindung auf diesem Weg parken, der Prozess auf dem entferneten Rechner läuft weiter. Im Gegensatz zu den beiden genannten Terminalmultiplexern müsst ihr nicht im Vorfeld daran denken, dass der Vorgang länger brauchen könnte und diese vorsorglich starten. Das entsprechende Steuerzeichen nennt sich nun etwas kryptisch ~^Z, der Zirkumflex steht dabei nicht als Zeichen, sondern als Steuerzeichen. Ihr müsst also [AltGr]+[+] und danach [Strg]+[Umschalt]+[Z] drücken. Anschließend landet ihr wieder im Terminal des Rechners, auf dem ihr ursprünglich ssh ausgeführt habt. Von dort aus könnt ihr die Verbindung wieder mit dem Aufruf von fg und [Eingabe] aufgreifen.
Eine SSH-Verbindung pausieren und wieder fortsetzen.
Arbeitet ihr auf einem „richtig“ entfernten System über das Internet, kann es durchaus passieren, dass die Verbindung abbricht. Dies liegt auf der einen Seite daran, dass der Server bei Inaktivität die Verbindung beendet, auf der anderen Seite kann es zu Situationen kommen, in denen die eigene Netzwerk-Infrastruktur (sprich der Router) dazwischenfunkt: Es gibt jedoch die Möglichkeit den Timeout mit einer Keep-Alive-Funktion zu verhindern. Je nach Situation könnt ihr entweder den SSH-Server entsprechend konfigurieren (dazu benötigt ihr natürlich Root-Rechte) oder ihr ruft die SSH-Verbindung gleich mit den entsprechenden Parameter auf. Für diesen Fall benötigt ihr keine besonderen Rechte auf beiden Systemen.
Keep-Alive serverseitig
### Keep-Alive-Standardeinstellung:
$ grep Alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
### Die Konfiguration des SSH-Servers bearbeiten:
$ sudo nano /etc/ssh/sshd_config
### Die entsprechenden Zeilen sollte am Ende so aussehen:
$ grep Alive /etc/ssh/sshd_config
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 3
### SSH-Server einmal neu durchstarten:
$ sudo systemctl restart sshd
Keep-Alive clientseitig
### SSH-Verbindung clientseitig am Leben halten
$ ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=1 pi@raspberrypi
Im ersten Fall gilt die Einstellung für alle User, die sich per SSH auf dem System einloggen möchten. In der Regel sollte man diese Konfiguration daher nur dann vornehmen, wenn auch alle User tatsächlich diese benötigen. Meistens braucht man das Keep-Alive allerdings nur im Ausnahmefall, von daher ist es sinnvoll die Option nur bei Bedarf mit dem Aufruf von ssh zu setzen. Bei mir ist das beispielsweise bei einem Web-Service der Fall, bei dem ich mich per SSH einloggen kann. Stoße ich dann dort längere Zeit laufende Backups an, dann beendet mein Router die Verbindnung bevor der Backupprozess erfolgreich den Vollzug melden kann. Mit den genannten Keep-Alive-Settings beim Aufruf ist das jedoch kein Problem mehr.
Früher oder später wird man als Linux-User sein erstes kleines Shell-Skript schreiben. Nicht, weil man unter Linux nicht ohne Kommandos, die Shell oder gar eigens „programmierte“ Skripte auskommen würde, sondern weil man dies freiwillig tut, da sich mithilfe von einfachen Bash-Skripten die eine oder andere Aufgabe deutlich beschleunigen lässt. Als Einsteiger bastelt man so lange vor sich hin, bis das Skript funktioniert und seine Aufgabe erledigt. Doch in der Regel macht man dabei eine Reihe von Fehlern, die nicht unmittelbar auffallen, ShellCheck hilft diese aufzudecken und euren „Programmierstil“ zu verbessern.
ShellCheck gibt es unter shellcheck.net im Netz und auch in der Paketverwaltung, der meisten Linux-Distributionen. Unter Debian/Ubuntu, wie auch unter Arch Linux lässt sich das Programm direkt mit einem Kommando einspielen. Anschließend könnt ihr das kleine Programm direkt auf euer Skript loslassen. Solltet ihr auf einem System arbeiten, auf dem sich keine weiteren Programme installieren lassen oder wo euch dazu die nötigen Rechte fehlen, könnt ihr auf die webbasierte Variante zurückgreifen. Am Ende zeigen diese immer dasselbe Ergebnis an.
### ShellCheck unter Debian/Ubuntu installieren...
$ sudo apt install shellcheck
### ShellCheck unter Arch Linux installieren...
$ sudo pacman -S shellcheck
### Die Hilfe zu ShellCheck...
$ shellcheck --help
unrecognized option `--help'
Usage: shellcheck [OPTIONS...] FILES...
-e CODE1,CODE2.. --exclude=CODE1,CODE2.. exclude types of warnings
-f FORMAT --format=FORMAT output format
-C[WHEN] --color[=WHEN] Use color (auto, always, never)
-s SHELLNAME --shell=SHELLNAME Specify dialect (sh,bash,dash,ksh)
-x --external-sources Allow 'source' outside of FILES.
-V --version Print version information
Im Terminal zeigt ShellCheck die Hinweise auf schlechten Skript-Still in seiner Ausgabe farbiert markiert an. Die Beschreibung hinter dem Report-Codes (SC2046, SC2086 etc.) gibt euch einen ersten Eindruck, von dem was ihr falsch macht. Für weiterführende Details gebt ihr den Code in die Suchfunktion des ShellCheck-Wiki ein. Dort erklärt ShellCheck genauer, was ihr warum falsch macht, zudem gibt es dort Beispiele, wie man die angemahnte Stelle besser gestalten sollte.
Das Programm lässt sich in den meisten Distributionen aus der Paketverwaltung installieren.
Alternativ kopiert ihr euren Code in die webbasierte Version von ShellCheck. Dies macht zwar ein wenig Arbeit, dafür könnt ihr die Report-Codes direkt anklicken, wohin euch der Browser direkt auf die Wiki-Seite führt. Diese Variante ist also besonders dann sinnvoll, wenn ihr ein längeres Skript mit vielen Fehlern überprüfen wollt. So erspart man sich das hin- und herkopieren der Fehlercodes zwischen Terminal und Browser.
ShellCheck hilft beim Schreiben sauberer Shell-Skripte ohne problematische Ausdrücke.In der Webversion von ShellCheck lassen sich Hinweise zu den problematischen Stellen aufrufen.
Die Oberfläche der Gnome Shell basiert bekanntlich zu weiten Teilen auf JavaScript und CSS. Aufgrund dessen lässt sich das Design und Verhalten relativ einfach modifizieren. Mit den Gnome-Erweiterungen muss man dafür nicht einmal programmieren können. Es genügt die Gnome-Extensions-Sammlung im Browser zu öffnen und sich sein Wunsch-Erweiterungen zusammenzuklicken. Allerdings gibt es seit einiger Zeit einen Haken: Das für die Installation von Gnome-Erweiterungen benötigte Browser-Plugin funktioniert nur noch mit wenigen Browsern. Es braucht „Internet“ (aka Epiphany oder Firefox). Andere Browser wie etwa Chrome unterstützen keine NPAPI-Plugins (dazu gehört auch Adobe Flash) mehr. Als Alternative bietet sich ein Kommandozeilen-Tool an.
Der Gnome Shell Extension Installer ist ein kleines Bash-Skript, mithilfe dessen sich Gnome-Erweiterungen über die Kommandozeile installieren lassen. Das Skript durchsuch die Gnome-Extension-Datenbank, zeigt entsprechende Treffer an und gibt auch aus, welches Plugin welche Gnome-Version unterstützt — Viele Plugins hecheln immer ein, zwei Versionen hinterher, was besonders bei Usern von Rolling-Release-Distributionen für Ärger sorgt, da die Erweiterungen nach einem Release einer neuen Gnome-Version erst einmal für eine ganze Weile nicht mehr funktionieren.
Nur noch wenige Browser wie etwa Firefox unterstützen das für die Installation von Erweiterungen nötige Plugin.
Gnome-Erweiterungen ohne Browser installieren
Unter Arch Linux lässt sich das Skript recht einfach aus dem AUR installieren. Auf anderen Distributionen lädt man sich das Skript von Hand aus dem Github und schiebt das kleine Programm dann beispielsweise nach ~/bin ins eigene Homeverzeichnis. Alternativ bietet sich als Speicherort auch das Systemverzeichnis /usr/local/bin/ an. Dort ließe sich das Programm dann von jedem User ausführen. Zum Kopieren muss man sich allerdings Root-Rechte besorgen.
### Gnome Shell Extension Installer unter Arch installieren
$ pacaur -Ss gnome shell installer
aur/gnome-shell-extension-installer 1.4.2-1 (7, 0,59)
A bash script to search and install GNOME Shell extensions
$ pacaur -S gnome-shell-extension-installer
Nach der Installation ruft man das Skript mit dem Kommando gnome-shell-extension-installer auf. Der Schalter -s bewirkt eine Suche in der Gnome-Extensions-Datenbank. Die Ergebnisse spuckt das Programm in einer nummerierten Liste auf. Jeder Eintrag informiert über den Entwickler wie auch über die Gnome-Versionen, zu denen die Erweiterung kompatibel sein sollte.
Der Gnome Shell Extension Installer als CLI
Bei gleichnamigen Treffern ist es nicht ganz einfach die richtige Erweiterung zu ermitteln. Prüft daher eventuell anhand des Namens des Entwickler auf extensions.gnome.org ab, ob ihr auch wirklich die gewünschte Erweiterung installiert. Mit Eingabe der Nummer ladet ihr dann die Erweiterung herunter und installiert sie für euren User. Weitere Hilfe bekommt ihr durch die Eingbe von h oder help.
$ gnome-shell-extension-installer -s system monitor
[system] Performing search
Displaying 10 item(s). Page 1 of 26.
0: System Menu, by jonius
Versions: 3.6
[...]
4: System Monitor, by elvetemedve
Versions: 3.20 3.18 3.16 3.14 3.12 3.10
[...]
Type "help" to get information on how to use the search.
Enter a command: 4
[System Monitor] Downloading extension
[System Monitor] Extracting extension
[System Monitor] Enabling extension
[System Monitor] Extension enabled
Enter a command: help
<number(s)> Install extension(s)
c Display comments
d<number(s)> Get description(s)
l<number(s)> Get link(s) on extensions.gnome.org
s<number(s)> Save the extension(s) on the current directory
p Go to page
r Print the search content again
sn Sort by name
sr Sort by recent
sd Sort by downloads
sp Sort by popularity (default)
/ Perform another search
home Load extensions.gnome.org homepage
h or help Show this message
q or quit Exit search shell
Damit Gnome die frisch installierte Erweiterung auch lädt, müsst ihr in den meiste Fällen die Gnome-Shell mit der Tastenkombination [Alt]+[F2] und danach [R], [Eingabe] neu starten. Anschließend sollte die Erweiterung automatisch geladen werden und beispielsweise in den Gnome Tweak Tools auftauchen. Dort lassen sich in der Regel die meisten Erweiterungen auch konfigurieren.
Mit dem Gnome Shell Extension Installer lassen sich Gnome-Erweiterungen ohne Browser installieren.Die auf diesem Weg installierten Erweiterungen erscheinen automatisch im System.
Alles in allem erweist sich der Gnome Shell Extension Installer als praktisches Werkzeug, besonders wenn man im Alltag weder den Gnome-Browser noch Firefox auf Surfturen im Netz verwendet. Praktisch ist auch, dass man über das Skript sofort sieht, welche Erweiterung mit welcher Gnome-Version kompatibel ist. Diese Information lässt sich aus der Gnome-Extensions-Webseite nicht so leicht herausziehen.
Ich helfe ab und an anderen Linux-Usern Probleme mit ihrem System zu lösen. Üblicherweise genügen dafür ein paar Mails oder ein Chat, manchmal greife ich aber auch auf Teamviewer zurück und schaue direkt auf den betroffenen Rechner. Doch nicht immer gibt es diese Option. Das liegt in der Regel nicht am durchaus zuverlässig funktionierenden Teamviewer: Wenn ein Distributions-Upgrade auf die nächste Ubuntu-Version schief läuft und der Xserver nicht mehr startet, scheidet eben auch Teamviewer als Hilfsmittel aus.
In so einem Fall steht man mit Recht stumpfen Waffen da. Um weiter helfen zu können müsste man erstmal wieder die den Xserver oder die Paketverwaltung zum Laufen bekommen, doch damit sind Einsteiger üblicherweise überfordert — selbst wenn man sie telefonisch dazu anleitet. Die beste Option wäre ein Login über SSH, doch dazu müsste man den Openssh-Server installieren und eine Portweiterleitung vom Router zum Rechner einrichten. Mit einer defekten Paketverwaltung funktioniert auch dieses nicht, selbst wenn man die Hürde Portweiterleitung meistert.
Tmate, der Teamviewer für das Terminal
Als Lösung für dieses Dilemma bietet sich nun aber Tmate an. Das Programm basiert auf dem Terminalmultiplexer Tmux (ähnlich dem Kommando screen), allerdings hat Tmat eine Remote-SSH-Funktion integriert, die sich ähnlich wie Teamviewer durch ein NAT-Netzwerk oder eine Firewall hindurchtunnelt. Das Programm müsst ihr sowohl auf dem Zielrechner wie auch eurem System installieren. Man erhält es unter Arch aus dem AUR, für Ubuntu-User gibt es ein PPA. Alternativ gibt es auch Builds für FreeBSD, Gentoo oder MacOS X via Homebrew.
Tmate auf dem Rechner des Helfenden installieren
### Installation von Tmate unter Arch Linux
$ pacaur -S tmate
### Installation von Tmate unter Ubuntu
$ sudo add-apt-repository ppa:tmate.io/archive
$ sudo apt update
$ sudo apt install tmate
Sollte auf dem Zielrechner die Paketverwaltung nicht funktionieren, von daher die Installation weiterer Pakete nicht möglich sein oder es kommt eine andere Distribution wie beispielsweise Fedora oder Debian zum Einsatz, dann kommt man mit dem PPA natürlich auch nicht weiter. Für diesen Fall gibt es von den Tmate-Entwicklern „Static Builds“ für 32- und 64-Bit Systeme. Diese muss man lediglich in Form eines TAR-GZ-Archivs auf dem betroffenen Rechner herunterladen, entpacken und anschließend das tmate Binary aufrufen.
Tmate behelfsmäßig als statisches Binary laden
### Static Build von Tmate für 64-Bit Rechner herunterladen...
$ wget https://github.com/tmate-io/tmate/releases/download/2.2.1/tmate-2.2.1-static-linux-amd64.tar.gz
### Static Build von Tmate für 32-Bit Rechner herunterladen...
$ wget https://github.com/tmate-io/tmate/releases/download/2.2.1/tmate-2.2.1-static-linux-i386.tar.gz
### Tmate enpacken und starten (im Falle eines 64-Bit-Systems)
$ tar xzf tmate*
$ tmate-2.2.1-static-linux-amd64/tmate
Solltet ihr einem Einsteiger helfen wollen, dann würde ich empfehlen die Aktion ein wenig zu vereinfachen: Holt euch das Binary und packt es ein Unterverzeichnis in ein neues Archiv mit einem einfacheren Dateinamen. Legt dieses dann auf einem eigenen Webspace ab und kommuniziert dem Hilfesuchenden ein Wget-Kommando mit einer Kurz-URL (nutzt dafür einen URL Shortener eurer Wahl). Das erspart dem Hilfesuchenden viel Tipparbeit und verhindert Fehler. Im Beispiel belasse ich es jedoch bei den „original“ Dateinamen und Pfaden. Achtet darauf, dass es natürlich auch demnächst neue Versionen des Programms gibt.
Ist Tmate auf dem Patienten installiert, erhält der User eventuell beim ersten Aufruf des Programms die Meldung [tmate] Reconnecting... (SSH keys not found. Run 'ssh-keygen' to create keys and try again.) auf dem Schirm. Dies passiert, wenn auf dem Rechner bislang noch kein SSH-Server installiert war… was bei einem Linux-Einsteiger oft der Fall ist. Ubuntu installiert beispielsweise den OpenSSH nicht von Haus aus als Server. Andere Distributionen liefern diesen jedoch oft automatisch mit aus.
Eventuell fehlt beim ersten Aufruf von Tmate noch der SSH-Schlüssel.
In Falle des Fehlers könnte man nun den SSH-Server nachinstallieren, allerdings muss das gar nicht sein. Es genügt das System anzuweisen einmalig die SSH-Schlüssel erstellen zu lassen. Weist daher den Hilfesuchenden an, Tmate mit der Eingabe von exit zu beenden und das Kommando ssh-keygen einzutippen — es braucht dazu auch keine Root-Rechte. Jede der anschließenden Fragen kann ganz simpel mit [Eingabe] ohne weitere Eingaben abgenickt werden. Am Ende landet der user wieder auf einer Eingabeaufforderung.
Der SSH-Key lässt sich recht leicht mit einem Kommando erstellen.
Nun könnt ihr die eigentliche Tmate-Sitzung starten: Beim Aufruf des Programms erscheint eine Zeile in der Art ssh sehr-sehr-lange-tmate-id@tmate-server unten in der Statuszeile des Anwendungsfensters — An dieser Stelle gilt es ein wenig Aufmerksam zu sein und die Adresse rechtzeitig zu sichern. Nach ein paar Sekunden verschwindet diese Zeile und man muss Tmate mit exit einmal beenden und wieder neu aufrufen, um eine neue ID zu erstellen. hat es geklappt, muss euch der Hilfesuchende den kompletten SSH-Befehl auf irgendeine Art und Weise zukommen lassen. Am leichtesten fällt in der Regel die Adresse per Copy&Paste in eine E-Mail zu übertragen.
Tmate ist quasi ein Teamviewer für die Konsole. Die Session-ID muss man dem Helfer schicken.
Sollte der Xserver hingegen nicht funktionieren, sodass ich nicht mit dem Hilfesuchenden vom Rechner aus per Chat oder E-Mail kommunizieren kann, behelfe ich mir hier meist mit der Bitte einfach das Fenster mit einem Smartphone abzufotografieren und mir den „Screenshot“ per Mail oder Chat zu schicken. In diesem Fall muss ich den doch recht länglichen Code zwar abtippen, ich vermeide jedoch Buchstaben oder Zahlendreher beim telefonischen durchgeben der Tmate-ID — Achtet dennoch drauf, dass gar nicht so einfach ist, den Unterschied zwischen „1“,“l“ und „I“ oder „O“ und „0“ zu erkennen.
Habt ihr das SSH-Kommando richtig eingegeben, landet ihr umgehend auf dem Rechner eures Gegenübers. Ein Passwort zum Login muss nicht eingeben werden. Das Terminalfenster stellt das dar, was der Hilfesuchende selbst in seinem Terminal (oder dem virtuellen Terminal, falls der Xserver nicht funktioniert) sieht — sollte euer Terminalfenster mehr Platz bieten, zeigt Tmate rund um den Inhalt des Gegenübers Punkte an. Da nur Text übertragen werden muss, funktioniert Tmate auch ohne Probleme über eine dünne Mobilfunkleitung.
Über die Session-ID kann man sich dann ohne Portforwarding oder andere Klimmzüge per SSH einloggen.
Kommandos und deren Ausgaben werden unmittelbar übertragen. Für Reparaturaktionen, die Root-Rechte erfordern, muss euch der Hilfesuchende nicht zwingend das Root-Passwort oder sein Passwort für Sudo-Kommandos mitteilen, er kann bei Bedarf einfach selbst das Passwort eingeben. So muss man keine unangenehmen Fragen nach dem Root-Passwort stellen, wenn man sein Gegenüber weniger gut kennt. Zudem kann der Hilfesuchende selbst jederzeit eingreifen.
Wenn der Xserver wie hier im Beispiel im gezeigten Beispiel noch funktioniert, bräuchte man Tmate eigentlich nicht zwingend — schließlich gäbe es mit Teamviewer ja eine grafische Option, die ebenso zuverlässig funktioniert. Fährt die grafische Desktopumgebung allerdings nicht mehr hoch, kommt die Stunde von Tmate. Nicht desto trotz muss man den User dennoch ein wenig unter die Arme greifen, ganz so einfach ist der Weg zu einer Remote-SSH-Session via Tmate nämlich auch nicht. Ubuntu bietet hier mit dem Recovery-Modus jedoch ein gutes Werkzeug.
Der Recovery-Modus von Ubuntu als letztes Hilfsmittel
In meinem letzten Fall lief auf dem Ubuntu-Rechner einer in der Schweiz ansässigen Bekannten beim Update von Ubuntu 14.04 auf 16.04 etwas schief. Das Ergebnis: Beim nächsten Start lief der Xserver nicht mehr hoch und die Paketverwaltung war komplett aus dem Tritt; es ließen sich keine Pakete mehr installieren. Setzt der Hilfesuchende ein Ubuntu-System (alternativ Linux Mint, oder ein anderes Ubuntu-Derivat) ein, dann habt ihr mit dem Recovery Modus ein mächtiges Werkzeug an der Hand.
In diesen gelangt der User, indem er kurz nach dem Einschalten des Ubuntu-Rechners die Escape-Taste drückt (ruhig mehrmals, unmittelbar nach Einschalten des Computers). Es sollte das Grub-Menü erscheinen, in dem man über die Option Erweiterte Optionen für Ubuntu in ein weiteres Menü gelangt, in dem man die auf dem System installierten Kernel sieht. Der User soll den obersten Eintrag mit dem Zusatz (recovery mode) auswählen. Funktioniert dieser nicht, dann soll er den Rechner hart abschalten, neu starten und einen älteren Eintrag auswählen, der (hoffentlich) funktioniert.
Durch Drücken von Escape direkt nach dem Anschalten des Rechners gelangt man ins Menü des Grub-Bootmanagers.Hinter dem Eintrag „Erweiterte Optionen für Ubuntu“ versteckt sich der Recover-Modus.
Am Ende landet man in einem Wiederherstellungsmenü, wobei der „Dateisystemstatus“ erstmal auf „Nur Lesen“ steht. Zudem baut das System im Recovery Modus keine Netzwerkverbindung auf — Beides lässt sich mit der Option network / Netzwerk aktivieren korrigieren. Die Funktion schaltet die Netzwerkkarte ein, holt sich eine IP vom Router und bindet die Laufwerke des Rechners mit Schreib- und Leserechten ein. Beachtet, dass dies lediglich über kabelgebundenes Netzwerk so einfach funktioniert. Den Rechner im Recovery Modus per WLAN ins Netz zu hängen, verursacht in der Regel deutlich mehr Aufwand, als kurzzeitig ein Kabel zu ziehen oder den Rechner in die Nähe des Routers zu tragen, sodass man ihn direkt dort anstecken kann.
Durch Aktivieren des Netzwerks bekommt man auch Schreibrechte im Notfall-System.Aus der Root-Shell heraus kann man dan Tmate installallieren und sich helfen lassen.
Wer „professionell“ seinen Kunden per Tmate Support anbieten möchte, kann den benötigten Server auch selbst hosten. Den entsprechenden Code gibt es auf Github, Hinweise zur Installation findet ihr auf der Homepage des Projekts (ganz am Ende) unter „Host your own tmate server“. Man braucht am Ende „nur“ einen kleinen Linux-Server im Netz. Für einfache Zwecke genügt wahrscheinlich schon ein Raspberry Pi, den man per DnyDNS aus dem Internet unter einer statischen Adresse erreichbar macht. Weiter untem auf der Homepage gibt es auch weiterführende Informationen wie Tmate eigentlich funktioniert.
Es gibt zahlreiche WordPress-Themes im Netz, die auf dem Plugin Visual Composer von WPBakery aufsetzen. So auch das von mir hier genutzt Theme Newsmag von TagDiv sowie dessen Brüderchen Newspaper. Mit dem Visual Composer lassen sich Seiten und Beiträge mit einer aufwändigeren Formatierung wie beispielsweise Spalten oder Blöcken recht leicht umsetzen und mit einer grafischen Oberfläche gestalten. Die Autoren dieser meist kommerziellen Themes legen das WordPress-Plugin dem Theme mitsamt einer Lizenz für dieses bei, sodass man sich bei der Installation des Themes nicht weiter um den Visual Composer kümmern muss. In der Praxis stören dann allerdings unnötige Update-Hinweise sowie Aufforderungen zum Registrieren des Plugins.
Nach der Installation eines „Visual-Composer-Themes“ meldet sich dieses Add-on immer wieder im WordPress-Backend mit dem Wunsch aktiviert zu werden: Hola! Please activate your copy of Visual Composer to receive automatic updates. Diesem Wunsch muss und kann man jedoch nur nachkommen, wenn man das kommerzielle Plugin direkt kauft und nicht — wie bei den TagDiv-Templates — die Lizenz über ein Theme bekommen hat. Die Meldung über das „X“ am Ende der Zeile wegzuklicken schafft für eine Weile Ruhe, doch löscht man (wie ich) beim beenden des Browsers sämtliche Cookies, dann kommt die Meldung spätestens beim nächsten Login in das Backend wieder auf den Schirm.
Das in viele WordPress-Themes integrierte Plugin Visual Composer nervt andauernd mit dem Wunsch aktiviert zu werden.Mit dem Plugin „My Custom Functions“ lassen sich sehr leicht eigene Funktionen in WordPress einbauen.
Ruhe bekommt man nur, wenn man dafür sorgt, dass der Cookie dauerhaft erhalten bleibt. Daher ist es in meinen Augen sinnvoller sich eine kleine WordPress-Funktion zu bauen, die den Cookie beim Laden des Backends automatisch in den Browser schreibt. Dazu fügt man die folgenden zwei Zeilen am Ende der Datei functions.php des gerade aktiven WordPress-Themes ein. Im Fall von Newsmag findet man diese entsprechend im Verzeichnis wp-content/themes/Newsmag. Dabei sollte man beachten, dass man diese Datei beim Aktualisieren des Themes in der Regel überschreibt. Ich baue die Zeilen daher über das Plugin My Custom Functions ein. Auf diesem Weg erspart man sich das Editieren des Themes, sodass die Änderungen bei Updates oder einem Wechsel des Themes erhalten bleiben.
Vielleicht noch einen Tick eleganter ist es ein kleines Snippet als WordPress-Plugin zu erstellen. Ein Beispiel dafür findet sich bei Stanislav Khromov, einem Webentwickler beim schwedischen Aftonbladet. Das von ihm erstellte „Stop Visual Composer Activation Nag“-Plugin (den Code findet ihr im nächsten Kasten) speichert ihr als stop-vc-nag.php im Verzeichnis wp-content/plugins eurer WordPress-Installation ab. Danach öffnet ihr das Backend eures Blogs und aktiviert das neue Plugin in den Einstellungen. Beide Lösungen führen zum Ziel: Ihr werdet nie mehr die Aktivierungsmeldung sehen, ohne dass man direkt am Theme oder am Visual Composer etwas ändern müsste. Die Lösung bleibt also auch bei Updates erhalten.
Ein weiterer störender Punkt beim Einsatz von Visual-Composer-Themes ist der Update-Hinweis des Plugins. Da man ja bei diesen Themes den Visual Composer über das Theme bezieht, lässt sich dieser nicht über die WordPress-Updates aktualisieren. Für Updates ist der Autor des jeweiligen Themes verantwortlich, dieser testet in der Regel sein Theme auf Kompatibilität zu einer neuen Version des Visual Composers, packt diese mit in den Theme-Ordner und veröffentlicht dann eine neue Version seines Themes zusammen mit einer neuen Version des Visual Composers. Direkt nach einem Theme-Update ist dann so auch der Visual Composer Up-to-date, nach ein paar Tagen oder Wochen hinkt das lokale Plugin jedoch wieder hinterher und man muss so lange mit der Update-Meldung leben, bis der Theme-Autor wieder nachlegt.
Beinhaltet das Theme bereits eine Lizenz für den Visual Composer, so muss/kann man das Plugin nicht auf diesem Weg aktualisieren.
Aber auch hier lässt sich wieder relativ leicht Abhilfe schaffen — die Lösung lässt sich dabei auch auf andere Plugins übertragen, die man von der Aktualisierung ausklammern möchte (weil die aktuelle Version eventuell etwas verschlimmbessert hat). Dazu braucht es erneut einen Eintrag in die functions.php des aktuell genutzten Themes. Im Fall von Newsmag also wieder im Ordner wp-content/themes/Newsmag eurer WordPress-Installation. Dort fügt ihr am dann Ende die Zeilen aus dem folgenden Listing ein. Wieder als Tipp: Mit dem Plugin My Custom Functions lässt sich dieser Eintrag vornehmen, ohne dass man die Theme-Datei selbst bearbeiten muss. So bleibt die Änderung auch im Falle eines Updates unangetastet.
Möchtet ihr ein anderes Plugin als den Visual Composer von den Updates (und somit den Update-Meldung) ausnehmen, dann ändert ihr einfach den Pfad mitsamt dem Dateinamen des Plugins in der Unset-Zeile (hier im Beispiel in der zweiten Zeile). Am Ende sollte der Visual Composer nun endlich Ruhe geben: Ihr müsstet jetzt vom Wunsch aktiviert und aktualisiert zu werden in Zukunft verschont bleiben. Achtet beim Einspielen eines Theme-Updates nun aber darauf, dass ihr eventuell auch den Visual Composer von Hand aktualisieren müsst. Vergesst ihr das, drohen Inkompatibilitäten mit dem Theme oder gar Sicherheitslücken durch den Visual Composer.
Oft sind es ja die kleinen Dinge, die einen Unterschied machen. Wie in diesem Beispiel: Ab und an möchte man wissen, ob und wohin das System einen USB-Stick oder eine SD-Karte gemountet hat. Für diese Aufgabe wirft man grafische Tools wie die Laufwerkverwaltung von Gnome an, oder man öffnet ein Terminal, gibt mount ein und schaut sich die Ausgabe des Programms an. Das Kommando liefert eigentlich sämtliche Informationen, die man für diese Aufgabe benötigt, doch die Ausgabe ist alles andere als übersichtlich. Sämtliche Infos stehen ungegliedert in einer Zeile
$ mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=3991400k,nr_inodes=997850,mode=755)
[...]
/dev/sdb1 on /home type ext4 (rw,relatime,data=ordered)
[...]
/etc/autofs/auto.misc on /misc type autofs (rw,relatime,fd=6,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect)
-hosts on /net type autofs (rw,relatime,fd=12,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect)
/etc/autofs/auto.nas on /mnt/nas type autofs (rw,relatime,fd=18,pgrp=1207,timeout=60,minproto=5,maxproto=5,indirect)
//192.168.178.79/daten on /mnt/nas/daten type cifs (rw,relatime,vers=1.0,cache=strict,username=me,domain=NAS,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.178.79,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
[...]
Zur Ausgabe von Laufwerksinformationen bietet sich jedoch als Alternative zu mount das Kommando findmnt an. Es steckt schon seit geraumer Zeit im Paket mount und findet sich in der Regel von Haus aus auf dem System. Allerdings nutzt kaum jemand das kleine Programm, im Forum von ubuntuusers.de wird es beispielsweise nur in ein Dutzend Threads erwähnt. Ohne weitere Optionen gibt findmnt einen Verzeichnisbaum mit der Geräte-ID, dem Dateisystemtyp und dem Mount-Optionen aus. Bei Bedarf kann man die Ausgabe nach Mount-Punkten filtern oder beispielsweise nach Dateisystemarten filtern.
Den Unterschied zwischen den Ausgaben beider Kommandos wird am besten über einen Screenshot verdeutlicht. Während man mit mount am besten gleich nach einem bestimmten Eintrag per mount | grep foo filtert, erhält man mit findmnt einen übersichtlich formatierten Verzeichnisbaum, den man ohne umständliche Pipes sofort im Blick hat. Zusätzlich könnte man mit etwa findmnt --poll --mountpoint /foo/bar gezielt einen Mountpunkt überwachen lassen und in einem Skript Aktionen auslösen.
Die Ausgabe von findmnt gliedert alle gemounteten Laufwerke übersichtlich auf.
Es soll ja noch immer Menschen geben, die ab und an versuchen das Internet auszudrucken Im Vergleich zu Firefox oder dem Internet Explorer hinkte Chrome bzw. Chromium allerdings sehr sehr lange Zeitbei dieser Aufgabe zurück: Chrome wie auch die quelloffene Basis Chromium konnten den Text innerhalb der Druckansicht nicht skalieren. Wer Papier beim Drucken sparen oder zu klein geratenen Text vergrößern wollte, musste sich daher mit Tricks behelfen, die nicht immer zuverlässig funktionierten. Zahlreiche Nutzer beklagen sich schon seit Jahren über die fehlende Funktion in der Druckroutine
Mit der Version 56 von Chrome und Chromium haben die Entwickler die Druckfunktionen nun aber endlich aufgebohrt. Ausdrucke lassen sich jetzt inklusive Texten und Bildern innerhalb der Druckansicht skalieren. Die neue Funktion ist allerdings nicht von Haus aus im Druckdialog vorhanden: Sie erscheint erst, sobald man in den chrome://flags den Punkt Druckskalierung aktiviert und den Browser einmal komplett neu startet. Anschließend findet ihr im Druckdialog die Option Skalieren über die sich die Druckgröße in Prozentschritten einstellen lässt.
Die Skalierung von Drucken lässt sich ab Chrome 56 in den Chrome Flags aktivieren.Google Chrome 56 kann nun endlich wie auch Firefox oder der IE die Schrift- und Bildgröße skalieren.
Eine der Stärken von Linux liegt in allgemeinem daran, dass das System seit Urzeiten als Mehrbenutzersystem konzipiert ist. User starten Anwendungen im Rahmen ihrer Benutzerrechte, sodass diese in der Regel nichts am System ändern können. Malware beeinträchtigt somit höchstens den Datenbestand des Users, der diese ausführt. Dennoch machen wir Linuxer immer wieder gerne ein Türchen auf: Sobald wir beispielsweise einen Editor mit Root-Rechten starten, etwa um eine Konfigurationsdatei zu bearbeiten, führen wir diesen mitsamt dem kompletten Toolkit (also GTK oder Qt) mit administrativen Rechten aus. Dadurch läuft mehr Code mit administrativen Rechten, als eigentlich nötig, daran ändert auch der Aufruf des Programms mit gksu oder gksudo nichts.
Sudoedit, das bessere sudo $editor
Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.
$ sudo -e /etc/hosts
$ sudoedit /etc/hosts
Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.
Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.
### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts
Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.
Der mit sudoedit gestartete Gedit-Editor arbeitet ohne Root-Rechte.
Root-Rechte für Files aka Nautilus
Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.
Durch Eingabe von admin:// kommt man in den Administrations-Modus.Für die Root-Rechte benötigt man natürlich auch administrative Rechte
In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.
Das Schloss-Symbol kennzeichnet besonders geschützte Ordner und Dateien.Aus dem Dateimanager lassen sich dann geschützte Dateien bearbeiten.Und natürlich auch in einem Texteditor mit Root-Rechten bearbeiten.
In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.
Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.
Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.
Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.
Der Firefox-Browser verwendet bekanntlich mit XUL ein eigenes Toolkit, um die Oberfläche auf dem Bildschirm darzustellen. Aus diesen Grund passt sich Firefox auch nicht an das Theme der Desktopumgebung an. Für Gnome-User gibt es jedoch schon länger ein Adwaita-/Gnome-Theme, das den Browser gut in den Gnome-Desktop integriert. Das Problem: Das Theme wird schon seit einer ganzen Weile nicht mehr aktiv gepflegt. Es ist zu Firefox 45.0 bis 48.0a1 kompatibel, der Versionszähler von Firefox steht aktuell jedoch bereits bei Firefox 51. Im Github des Gnome Integration Team schlagen immer wieder User mit Fehlerberichten auf, dass das Theme nicht mehr funktioniert, eine Reaktion gab es bisher jedoch nicht.
Nun hat sich mit Nicholas Reis ein unabhängiger Entwickler der Sache angenommen. Sein Fork des Gnome 3 Theme für Firefox ist zur aktuellen Firefox-Version wieder kompatibel, zudem hat er eine Reihe von Bugs ausgebügelt. Zusammen mit den bereits etablierten Add-Ons Gnome Theme Tweak und HTitle (das trotz des Hinweises, dass das Add-On aufgegeben wurde, nach wie vor funktioniert) lässt sich somit Firefox wieder sehr gut an das offizielle Gnome-Theme anpassen. Aufgrund des Toolkits passt sich Firefox zwar weiterhin nicht an andere Gnome-Themes an, doch im Großen und Ganzen sieht der Mozilla-Browser so wieder unter Gnome deutlich besser aus.
Der aktuelle Firefox 51 in der Gnome Shell ohne alle Anpassungen.Firefox 51 mit dem überarbeiteten und jetzt wieder kompatiblen Gnome-Theme.
Firefox-Theme für Gnome 3
Die Installation des Theme ist nicht weiter schwer: Installiert die folgenden 3 Add-ons beziehungsweise Themes. Anschließend ruft ihr über das Hamburger-Menü (der Button mit den drei übereinander gestapelten Strichen in der Toolbar) die Add-ons auf. In den Einstellungen zum Gnome Theme Tweak und HTitle lassen sich dann noch ein paar Konfigurationen ändern. So kann man beispielsweise die Ausdehnung der Tabs anpassen oder den Dropdown-Pfeil in der Adressleiste abschalten. Zudem lassen sich die Buttons „flach“ darstellen, also ohne einen Knopf um den Schalter herum.
Über HTiltle lässt sich sich die Fensterleiste deaktivieren, sodass möglichst viel Platz auf dem Bildschirm bleibt. In der Grundeinstellung passiert dies nur, wenn man das Fenster auf dem Desktop maximiert. HTitle lässt sich jedoch auch so einstellen, dass es die Fensterleiste komplett ausblendet. In diesem Fall lässt sich das Firefox-Fenster jedoch nur noch sehr schwer per Mausklick verschieben: Entweder muss man nun immer eine der wenigen freien Stellen in der Toolbar finden oder das Fenster zukünftig mit [Super]+[Linke Maustaste] an einer beliebigen Stelle anpacken und dann auf dem Bildschirm verschieben.
Mit dem Add-on Gnome Theme Tweak lässt sich das Gnome-Theme noch weiter anpassen.Das Firefox-Add-on HTitle entfernt im Vollbildmodus die Fensterleiste, sodass mehr Platz bleibt.
Im Vergleich zu Firefox oder dem Internet Explorer hinkte Chrome bzw. Chromium allerdings sehr sehr lange Zeitbei dieser Aufgabe zurück: Chrome wie auch die quelloffene Basis Chromium konnten den Text innerhalb der Druckansicht nicht skalieren. Wer Papier beim Drucken sparen oder zu klein geratenen Text vergrößern wollte, musste sich daher 
