Butschek.de

Mit screen kann man auf einer Textkonsole mehrere Konsolen starten, die man dann per Tastenkombinationen wechseln kann.

Das ist natürlich schön, wenn man gerade per SSH im Editor steckt und nebenbei noch was nachsehen will, ohne jedesmal eine neue SSH-Sitzung zu öffnen. Der ganz große Vorteil von Screen dürfte aber sein, dass Screen beim Abbruch der SSH-Verbindung die laufenden Programme nicht unterbricht, da sich der Nutzer später wieder per ’screen -a’ mit der laufenden Sitzung verbinden kann. Dafür dürfte jeder dankbar sein, der schon mal kurz vor Ende eines 5h-Jobs einen 24h-Kick vom Provider bekam.

Die Installation unter Debian und Ubuntu erfolgt mit aptitude install screen. Ich empfehle danach in der /etc/screenrc noch folgende Zeilen aufzunehmen:

startup_message off
hardstatus alwayslastline "%H: %-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< "
bindkey -k k7 prev
bindkey -k k8 next

Die erste Zeile sorgt dafür, dass Screen sofort startet. Zeile 2 blendet unten am Bildschirm eine Leiste mit allen offenen Sessions und den jeweiligen laufenden Programmen ein. Die Ausgabe des Hostnamens hilft außerdem bei Remote-Sitzungen, schnell den richtigen Rechner zu finden. Die letzten beiden Zeilen binden den Wechsel zur vorherigen / nächsten Konsole auf die Tasten F7 / F8 – so ist die Bedienung etwas einfacher.

Mit ‘[STRG]+[a] :title name’ läßt sich für jede Konsole der Name frei setzen. Mit ‘[STRG]+[a] [c]‘ (Connect) läßt sich eine neue Konsole starten. Beendet wird sie unix-typisch einfach mit ‘exit’ oder per [STRG]+[d]. Eine Hardcopy des aktuellen Bildschirminhalts gibt’s mit ‘[STRG]+[a] [h]‘ und mit ‘[STRG]+[a] [?]‘ erscheint eine kurze Hilfe.

Besonders interessant für längere Jobs: Mit ‘[STRG]+[a] [d]‘ (Disconnect) läßt sich eine Screen-Sitzung beenden, jedoch läuft Screen und alle gestarteten Programme weiter. Diese läuft sich später mit ’screen -a’ wieder aufnehmen. Mit ’screen -x’ kann sich sogar ein zweiter und dritter Benutzer dazuschalten – nett, um jemanden auf der Shell etwas zu zeigen.

IT, LST Linux, screen, Shell

Oft möchte man eine Konsolensitzung aufzeichnen. Ob nun zu Ausbildungszwecken, als Nachweis oder auch nur zur Sicherheit, dass man dem Support später zeigen kann, was man falsch gemacht hat. In jedem Fall ist das kleine Tool script eine Lösung. Wird es mit ’script dateiname’ gestartet, öffnet es eine neue Shell und zeichnet jede Ausgabe darin in die angegebene Datei auf. Das Ergebnis der Aufzeichnung läßt sich später auf jedem Rechner mit ‘cat dateiname’ anzeigen.

Mit dem Parameter -a kann man übrigens auch mehrere Sitzungen in einer Datei speichern. Doch die Freunde in den Augen einiger Admins muss ich auch gleich wieder eindämmen: Nein, es ist nicht erlaub, dauerhaft alle User aufzuzeichnen.

Die in der Manpage vorgeschlagene Möglichkeit, mit einem Fifo live zuzusehen finde ich nicht so interessant, hier nutzt ich stattdessen screen.

IT, LST Linux, script, Shell

Oft braucht man eine Idee für ein neues Passwort, doch die Idee fehlt. Wie man solche einfach erfindet, habe ich im Artikel Sichere Passwörter schon erklärt. Doch kommt es manchmal auch vor, dass man viele Passwörter automatisch erzeugen muss. Hier helfen entweder viele kleine Tools oder eben die Shell.

Zuerst hole ich mir mit dd zufällige Daten, sagen wir mal 10 kByte. Diese schicke ich durch eine RegEx und entferne alle Zeichen, die nicht den gewünschten Zeichen entsprechen. Ich nehme hier im Beispiel nur Buchstaben und Zahlen. Nun muss ich nur noch dafür sorgen, dass nur so viele Zeichen wie benötigt ankommen, was ebenfalls wieder durch eine RegEx passiert.

Das Ergebnis sieht dann so aus:

dd if=/dev/urandom bs=1024 count=10 2>/dev/null \
  | perl -pe "s/[^a-zA-Z0-9]//g" \
  | perl -pe "s/^(.{12}).*$/1/g"

Nun gibt es aber einen Sonderfall, bei dem ich weitere Ausnahmen mache: Das Root-Kennwort.

Ein externer Login (via SSH) mit Passwort ist bei meinen Systemen nicht möglich (nur via Public Key). Das Passwort wird bei mir also nur benötigt, wenn ein Techniker es im Rechenzentrum lokal eingeben muss. Daher sollten alle Zeichen einfach tippbar sein, âáà sind das bei nodeadkeys meist nicht. Außerdem sollte man an die Verwechslungsgefahr denken: Der Techie mit dem Ausdruck des Passwortes in seiner Hand kann bei typischer RZ-Beleuchtung sicher keinen Unterschied zwischen | und l erkennen.

Folgende Zeichen der oben generierten Passworter erachte ich als Störend:

• Kleines Ludwig (l), großes Ida (I), die Zahl Eins (1), das Pipe-Symbol: lI1|
• Großes Otto (O), die Zahl Null (0): O0
• Das Ypselon und das Zet (weil auf US-Keyboards vertauscht)

So würde das nun aussehen, wenn wir diese Zeichen nun entfernen:

dd if=/dev/urandom bs=1024 count=10 2>/dev/null \
  | perl -pe "s/[^a-zA-Z0-9]//g" \
  | perl -pe "s/[lI1O0yYzZ]//g" \
  | perl -pe "s/^(.{12}).*$/\1/g"

Die beiden RegEx könnte man zusammenfassen, indem man schon beim ersten nur gewünschte Zeichenbereiche freigibt. Aber ich finde es so leichter lesbar und besser zu bearbeiten.

IT, LST dd, Linux, Shell, Sicherheit, urandom

Meinen Server sichere ich gerne vollständig, da ich so im Falle eines Ausfalls schnell wieder an die Daten komme. Sofern man keine Technologien wie Snapshot & Co nutzen kann, genügt hierzu auch ein einfaches tar.

Erstmal sollte man einige Verzeichnisse ausnehmen, z.B. /proc, /dev oder /sys. Auch können Temp-Verzeichnisse sowie /var/run und /var/lock ausgenommen werden. Je nachdem, wie wichtig die Logfiles sind, können die auch weg, brauchen sie doch nur viel Platz.

Die Spool-Files vom Mailserver sind oft auch unsinnig: Ein 6h altes Backup enthält viele Mails, die längst zugestellt sind, andererseits keine Mails der letzten 6 Stunden. Sowas lohnt im Backup nicht. Wer viel Wert auf das Mailbackup legt, könnte höchstens das aktuelle Spool-Verzeichnis sehr häufig per rsync anderswo sichern.

Datenbanken sollten nicht live weggezogen werden, besser ist eine vorher erstellte konsistente Kopie (z.B. ein MySQL Dump), die im Backup landet, während das Arbeitsverzeichnis der Datenbank ausgenommen wird. In meinem Fall ist das /var/lib/mysql.

Eine Sache ist für die Herstellung noch ganz wichtig: Es sollte nicht das Verzeichnis selbst vom Backup ausgenommen werden, sondern nur dessen Inhalt. Das Verzeichnis (samt zugehöriger Owner- und Rechteeingestellungen) sollte im Backup bleiben. In tar geht das so, dass man das Verzeichnis nicht mit ‘–exclude=pfad’ sondern mit ‘–exclude=pfad/*’ ausnimmt.

Zuletzt sollte man das Backup selbst auch noch ausnehmen – nicht wäre dümmer als eine rekursive Sicherung des Backups selbst. Das Ergebnis als Kommando sieht dann so aus:

tar czf /pfad/zum/backup.tgz
    --exclude=proc/*
    --exclude=dev/*
    --exclude=sys/*
    --exclude=tmp/*
    --exclude=var/tmp/*
    --exclude=var/run/*
    --exclude=var/lock/*
    --exclude=var/log/*
    --exclude=var/lib/mysql/*
    --exclude=var/spool/postfix/*
    --exclude=pfad/zum/backup.tgz
    /

Die am Ende der Zeilen zeigen der Bash an, dass die Zeile noch nicht abgeschlossen ist. So lassen sich mehrzeilige Kommandos eingeben, was der Ãœbersichtlichkeit dient. Das / am Ende ist wichtig, es sagt tar, dass wir / sichern wollen, also die ganze Platte.

IT, LST Backup, Linux, Shell, tar

Wer hin und wieder schon mal in einem Apache-Log die Referer durchsucht hat, kennt das Problem mit der Zeichenkodierung: Sonderzeichen werden als zweistellige hexadezimale Zeichen mit vorangestelltem Prozentzeichen dargestellt. Aus ‘Wörter mit Äh, Ãœh und Öh’ wird so schnell ein ‘W%F6rter+mit+%C4h%2C+%DCh+und+%D6h’, was für den Admin wirklich schwer zu lesen sein dürfte.

Eine ganz einfache Möglichkeit der Umwandlung bietet Perl durch die Möglichkeit, die Suchergebnisse eines regulären Ausdrucks durch eine Callback-Funktion zu schicken:

echo 'W%F6rter+mit+%C4h%2C+%DCh+und+%D6h'
  | perl -pe 's/%([A-Fa-f0-9]{2})/pack("C", hex($1))/seg'

Nur die Pluszeichen (welche für Space eingesetzt werden) bleiben bestehen, das erschwert die Lesbarkeit jedoch kaum. Falls es doch stört, einfach das Ergebnis nochmal durch ‘tr‘ schicken…

IT, LST Linux, perl, Shell, urldecode