Sitzungsverwaltung mit screen
Persistente Sitzungen gewährleisten, mehrere Terminals multiplexen oder einfach fürs Multitasking – das Linux-Tool „screen“ bietet viele praktische Vorteile für die Arbeit in der Kommandozeile, insbesondere bei SSH-Verbindungen oder Servern. In unserem Expertise-Blog zeigt Jürgen Weigert, unser Linux-Consultant und Co-Autor von screen, an konkreten Best Practices die Vorteile von screen bei der Sitzungsverwaltung.
Als Systemadministrator*in ist man oft auf mehreren Servern eingeloggt - z.B. um schnell etwas nachzuschauen, oder um länger laufende Prozesse im System zu beobachten. Dafür nutzt man heute in der Regel Remote-Verbindungen, arbeitet bequem vom Arbeitsplatzrechner aus und hat dabei viele einzelne Fenster auf dem Bildschirm.
Typische Arbeiten im Linux-Umfeld passieren auf der Konsole mit einem Shell-Prompt, so dass wir gar keine graphische Benutzeroberfläche brauchen. Bei Remote-Maschinen öffnet man ein Terminal-Fenster, gibt dort am Shell-Prompt einen SSH-Befehl oder ähnliches ein und bekommt einen Shell-Prompt der Remote-Maschine.
Soweit, so gut. Aber, …
- Wie lange hält die SSH-Verbindung?
- Wie viele Verbindungen gibt es im Laufe der Woche? Wie hält man Ordnung?
- Wie baut man alle wieder auf, wenn die Verbindungen wegbrechen?
- Speichert vim - der remote läuft - wenn die SSH-Verbindung abbricht?
Bei länger andauernden Arbeiten, die sich über mehrere Tage oder Wochen hinziehen, werden das wiederholende Tätigkeiten, die man gerne vermeiden oder automatisieren möchte.
Anwendungsbeispiel: Datenmigration
Als Beispiel dient uns eine größere Datenmigration von Server A nach Server B. Dabei ist die Datenmenge so groß, dass der Migrationsvorgang länger dauert und man nicht die Zeit investieren möchte, physisch dabei zu bleiben. Wir möchten auf Server B beobachten, was wie ankommt, während wir von Server A aus die laufende Übertragung starten und beobachten.
Das ist auf den ersten Blick ein recht einfacher Vorgang, kann aber kurz vor Feierabend plötzlich ein Problem werden: Was tue ich, wenn ich mich verschätzt habe, und der rsync noch viele Stunden in die Nacht hinein laufen wird? Wenn ich jetzt meine Terminal-Fenster schließe, wird der rsync vermutlich nicht mehr lange weiterlaufen. Spätestens wenn er wegen der Fortschrittsanzeige ein paar Kilobytes Ausgaben loswerden möchte, aber keine Verbindung zum Arbeitsplatzrechner mehr besteht, wird der Kernel dem rsync einen IO-ERROR melden. Der Kopiervorgang wird beendet, obwohl der eigentliche Datentransport von Server A zu Server B weiterlaufen könnte. Damit der Transport weiter läuft, brauchen wir zwei Fenster, eins für jeden Server. Auf gut Glück lasse ich also meine SSH-Fenster zu den Servern offen, bleibe eingeloggt, sperre nur meinen Desktop, hoffe und gehe. Aber wie sicher ist es, dass mein Arbeitsplatzrechner (Büro, Homeoffice, ...) über Stunden seine Verbindung zum Server aufrecht erhalten kann? Vielleicht werden z.B. längere Zeit keine Daten transportiert und nach einer Stunde schlägt ein timeout zu? Vielleicht gibt es kurz nach Mitternacht eine Netztrennung durch den Provider?
Sichere Datenmigration Dank screen
Um den Vorgang etwas zuverlässiger zu gestalten, kommt hier ein "uraltes" Admin-Werkzeug ins Spiel: screen.
Die Benutzung ist in diesem Fall sehr einfach. Nach dem SSH auf Server A, startet man dort am Shell-Prompt das Kommando screen. Screen ist üblicherweise bei allen Linux Distributionen enthalten. Unter Ubuntu/Debian kann es, falls nötig per
apt install screeninstalliert werden. Nach dem Start von screen, wird man vielleicht überrascht sein, das nichts passiert ist. Man sieht wieder einen Shell-Prompt, und sonst erscheint alles unverändert. Ohne weitere Parameter, startet screen eine frische "screen Session" (Sitzung) und darin eine Shell. In dieser Shell kann man genauso arbeiten wie zuvor und z.B. den rsync zu Server B starten. Der kleine aber feine Unterschied ist die zwischengeschaltete screen Session. Screen fängt eine einzige Tastenkombination ab. Standardmäßig ist das CTRL-A. Alle anderen Eingaben (und Ausgaben) werden 1:1 durchgeleitet.
Screen speichert aber auch einige Zeilen Ausgaben zwischen. Standard sind hier 100 Zeilen, was recht wenig ist. Man kann die Zahl aber bei Bedarf hochsetzen.
Nach CTRL-A : erscheint eine eigene kleine screen-interne Kommandozeile, hier geben wir das Kommando scrollback 2000 ein, und bestätigen mit der ENTER-Taste. Also etwa so:
CTRL-A : scrollback 2000 Screen bestätigt mit der Einblendung scrollback set to 2000, die nach ein paar Sekunden (oder bei der nächsten Eingabe) wieder verschwindet.
Jetzt kann die Verbindung zwischen Arbeitsplatzrechner und Server A abgebrochen werden, die screen Session (mit Shell und allem darin) läuft weiter. Man kann also am Abend bedenkenlos die Terminal-Fenster am Desktop schließen. (Oder einfach offen lassen, und warten ob die Verbindung von alleine abbricht.)
Sobald man sich als Benutzer mit einer neuen SSH-Verbindung wieder auf Server A einloggt, kann man prüfen, ob die screen Session noch läuft:
screen -ls
There is a screen on:
20259.pts-12.HSMLP14S-15 (Detached)
1 Socket in /run/uscreens/S-j.weigert.Die Sitzung hat einen Namen und den Vermerk (Detached). Letzteres bedeutet, dass niemand damit verbunden ist. Um sich zu verbinden, benutzt man
screen -r
(Den Namen - oder einen kurzen Teil davon - gibt man hinter screen -r an, falls man unter mehreren Sessions wählen muss).
Man ist nun wieder direkt mit der ursprünglichen Shell verbunden und auch dem rsync, falls der nicht in der Zwischenzeit fertig geworden ist. Der Bildschirminhalt zeigt den letzten Zustand, d.h. falls es Fehlermeldungen gab, sehe ich diese jetzt so, als wäre die Verbindung nie unterbrochen worden. Aus Sicht der Prozesse, die in dieser Shell gestartet wurden, gab es nie eine Unterbrechung. (Technisch: screen emuliert ein sogenanntes "Pseudo-Terminal" oder pty).
Falls es viele Ausgaben gab, passt nicht mehr alles auf die Fenstergröße. Inhalte, die die obere Kante des Bildschirms verlassen haben, kann ich über den Scrollback-Puffer von screen wieder zurückholen.
CTRL-A ESC CTRL-U CTRL-U CTRL-U ...Hier funktionieren auch normale Cursor-Tasten und die vom Editor vi bekannte H, J, K, L Steuerung, Bild-Auf, Bild-Ab, und viele andere an vi angelehnte Kommandos. Mit ESC verlässt man den Scrollback-Puffer und kommt wieder zur normalen Shell zurück.
Weitere hilfreiche Screen-Features
Eine screen Session bietet noch viele weitere nette, aber mehr oder minder gut versteckte Features. Beispielsweise startet
CTRL-A : log on eine Log Datei. Alle Ausgaben und Eingaben werden (in recht roher Form inklusive aller Steuerzeichen) mitprotokolliert.
Bekanntestes Feature ist vermutlich die klassische "Fensterverwaltung". Ich kann innerhalb der screen Session mehrere Shells (jede mit eigenem pty und eigenem Bildschirminhalt und Scrollback) gleichzeitig verwalten.
CTRL-A c startet eine neue Shell, und mit
CTRL-A 0, CTRL-A 1, ... kann man umblättern. Im screen-Jargon hat diese Session jetzt mehrere "windows" (Fenster).
CTRL-A LEERTASTE blättert von einem Fenster zum nächsten. Und am Ende der Liste wieder zurück zum ursprünglichen Fenster 0.
CTRL-A w blendet eine Liste aller Fenster ein, falls man etwas Orientierung braucht. Die Fenster haben dort Nummern, und heißen zunächst alle bash. Man verwendet eventuell
CTRL-A SHIFT-A neuer-name...Vollständiger Arbeitsablauf der Datenmigration
Nochmal zum Überblick: Der komplette Arbeitsablauf der oben gezeigten Datenmigration könnte also etwa so aussehen:
ssh ServerA
screen
cd ... # dorthin, wo man den rsync starten will. Bevor man wirklich startet, vielleicht noch schnell
CTRL-A c # erzeuge ein neues Fenster (Nummer 1)
ssh ServerB # um auf dem Zielsystem nach dem richtigen Verzeichnis mit ausreichend Platz zu schauen.
cd ...; ls -l; df; ...
CTRL-A 0 # zurück zur ersten Shell auf Server A
rsync ... user@ServerB:...
CTRL-A c
top # während der rsync läuft, mache ich ein weiteres Fenster in der screen Session auf, um zu überwachen, wie viel Systemlast der rsync erzeugt.
CTRL-A 1 # das müsste das Fenster auf Server B sein.
ls -la # dort besucht man den Dateibaum, und prüft, ob alles korrekt ankommt.
CTRL-A 2 # nachschauen, was top derweil ausgibt
CTRL-A 0 # zurück zum noch laufenden rsync.
CTRL-A d # detach. Die screen Session wird vom ursprünglichen ssh abgekoppelt.
exit
Das Ganze kann auch durch Feierabend oder Mittagspause unterbrochen werden. Selbst ein Wechsel zwischen mehreren Büros (Home-Office) ist problemlos möglich. Dabei kann es passieren, dass man im screen -ls den Vermerk (Attached) sieht. Das bedeutet dann, dass diese Session noch anderswo verbunden ist. Man kann sich die Session dann "herüberholen" mit
screen -d -r Ein komplexeres Beispiel
Eine langwierige Fehlersuche könnte z.B. beinhalten: Ein less auf das apache logfile hier, ein top dort, ein df, und noch irgendwo Netzwerk Statistiken. Eine Datenmigration von einem Server zum anderen oder eine Neuinstallation mit Editoren in diversen Konfigurationsdateien, Paketmanager aufrufen etc.,
Dadurch baut man sich recht viel Arbeitsumgebung auf, die auf mehrere Server verteilt ist. Wenn man das alles in einer (oder mehreren) screen Sessions macht, hat das den weiteren Vorteil, dass man den kompletten Kontext nicht unbedingt verliert, wenn man wegen Mittagspause oder Feierabend unterbrochen wird, oder gar seinen Arbeitsplatzrechner neu starten muss.
Damit das alles gut klappt, sind einige Dinge zu beachten:
- Rechtzeitig an screen denken. Wenn bereits 20 unterschiedliche Terminal-Fenster mit diversen SSH-Verbindungen laufen, kann man diese nicht mehr nachträglich in eine screen Session hereinholen. (das wäre mal ein Feature !!!)
- Auf welchem Rechner starte ich screen?
- Auf meinem Arbeitsplatzrechner eher nicht, wenn der Gefahr läuft, gebootet zu werden.
- Auf jedem einzelnen Server? Das hilft wunderbar gegen Verbindungsabbrüche und Neustarts, dann muss man sich aber auch merken, wo überall eine 'kleine' screen Session verteilt ist.
- Ideal ist ein Admin-Rechner im Rechenzentrum, der immer läuft und den man oft als jumphost braucht. Dort lasse ich meine screen Session gerne laufen. Ich erreiche sie per SSH, und mache von den einzelnen Fenstern der screen Session weitere SSH-Verbindungen zu allen benötigten Servern.
- Nach einigen Wochen ergeben sich wiederholende Muster, und man hat gelernt, dass z.B. der Backup-Server immer in Fenster 5 ist, und die Firewall auf Fenster 8.
In einer lang laufenden screen Session kann man die Nummerierung und Benennung der einzelnen Fenster vorher planen. Dazu legt man sich auf dem Host, auf dem die Session gestartet werden soll, eine Datei ~/.screenrc an.
Beispiel:
defscrollback 2000 # Default (Voreinstellung) für neue Fenster ist nun 2000 Zeilen Puffer.
screen # Erst einmal eine Shell. Ohne weiter Parameter wird das Fenster Nummer 0.
screen -t top 1 top # In Fenster 1 will ich anstelle einer shell gleich direkt einen top laufen lassen.
screen -t bck 5 ssh backup-user@backup-host.net # Eine der backup-Maschinen. Weil ich dort vermutlich öfter was nachschauen werde.
screen -t fw1 8 ssh root@firewall1.intra.net # startet eine ssh Verbindung in Fenster Nummer 8, welches den Namen "Firewall" trägt.Mit diesem ~/.screenrc wird ein einfacher screen Aufruf eine Session mit vier vordefinierten Fenstern starten. Zwei lokal, und zwei remote. Lücken in der Nummerierung sind kein Problem. Diese werden von späteren CTRL-A c genutzt.
Mehrere ineinander verschachtelte screen Sessions sind möglich, aber Vorsicht: Ein Ctrl-A a schickt ein einfaches CTRL-A ins Fenster, wenn man also Sessions verschachtelt, dann kann es schon mal nötig werden, dass man z.B. CTRL-A 2 CTRL-A a 5 drücken muss, um in der im Fenster 2 verbundenen anderen screen Session auf das dortige Fenster 5 zu wechseln.
Spätestens jetzt ist ein Blick ins Handbuch angeraten, um nachzuschauen, ob man nicht statt CTRL-A auch eine andere magische Taste verwenden kann. CTRL-B beispielsweise. Ja man kann. Das Handbuch gibt es übrigens auf diversen Webseite, aber in guter Unix-Tradition auch als mitgelieferte man-page.
man screenUnd alle Admins, die im Team arbeiten, lernen dort auch, was man mit dem multiuser mode und mit screen -x noch anstellen kann.
Autor: Linux-Consultant Jürgen Weigert, (Heinlein Consulting)
Kommentare