WE ARE ROOT

Dank eines Beitrags von Matthias (ja, diese Seite ist sehr beliebt bei mir ), habe ich – genau wie er – mit dem Tool htop das altehrwürdige top ersetzen können.

Mit freier Sortierung, Baumansicht a la pstree und der Möglichkeit sämtliche Signals an einen Prozess zu senden (direkt aus der Liste) macht sich dieses Tool fast täglich bewährt – und man kann sogar Putty in den Vollbildmodus nehmen und hat auch was davon (entgegen der festen Breite bei top).

Hier gehts zum Artikel von Matthias mit Screenshots und allem drum und dran…

Es ist ein Befehl, den ich sehr zu schätzen gelernt habe und fast täglich beim Debuggen brauche…

tail -f filename.log

Es erzeugt einen ständig aktualisierten Output für die betreffende Datei – perfekt, um das syslog nach einer Config-Änderung im Blick zu behalten.

Oder eben als rootTV: Den ganzen Tag einfach

tail -f /var/log/syslog

laufen haben und spannende Dinge sehen… zumindestens spannender als im deutschen Fernsehen.

Und mit

echo "tail -f /var/log/syslog" > ~/syslog.sh
chmod u+x ~/syslog.sh
~/syslog.sh

hat man einen noch schnelleren Weg, das syslog aufzurufen.

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:

Vorteile

In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.

Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:

• Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.
  

  Lösung: kleine Dateien übertragen durch Erstellung von Volumes

• Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.
  

  Lösung: Verschlüsselung der Daten mittels GPG

• Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).
  

  Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.

• Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.
  

  Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek

Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:

Weitere Vorteile

• Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.
  

  Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann

• Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.
  

  Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.

So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. weiterlesen…

Nun bin ich vielleicht nur faul gewesen, aber weder das kryptische vi noch das schmucklose joe konnten mir als Lieblingseditor auf der console so richtig gute Dienste leisten.

Keine Tastenorgien a la vi, keine Fingerverenkungen wie bei joe – einfache Bedienung und sinnvolle Features, das will ich.

Also habe ich den Editor, der im Midnight Commander (DEM altehrwürdigen Norton Commander-Clone) mitgeliefert wird sehr zu schätzen gelernt. (Btw: Der Debian-Paketname zur Installation ist “mc”.)

Nun ist es aber nicht immer sinnvoll den mc zu starten, nur um eine Config mit der Taste F4 zu bearbeiten. Daher wollte ich den Editor direkt aufrufen können. Offensichtlich gab es damit leichte Probleme, sodass bei Debian automatisch ein Mini-Wrapper namens mcedit-debian mitgeliefert wird. Leider ist dieser Name trotz bash-completition nicht sonderlich handlich. Also fix einen Symlink erstellt…

ln -s /usr/bin/mcedit-debian /usr/bin/edi

…und schon kann man auf der Konsole von überall mittels

edi configdatei.conf

jede Textdatei editieren.

Nun störte mich auch noch, dass ich z.B. die Cronjobs mit vi bearbeiten musste. Dazu gibt es das tolle Verzeichnis /etc/alternatives, welche Links auf die “Standardprogramme” zur Verfügung stellt.

rm /etc/alternatives/editor
ln -s /usr/bin/mcedit-debian /etc/alternatives/editor

Somit ist nun mcedit der Standardeditor und wird z.B. beim Aufruf von

crontab -e

verwendet.

HTH.

EDIT: Gerade habe ich hier gesehen, dass diverse Seiten sich bereits intensiv mit dem Thema “Lieblingseditor” beschäftigt haben. Der mcedit kommt dort aber nirgends vor… bin ich SO anders?

Im Blog von Matthias Kellermann (www.adminlife.net) habe ich einen sehr interessanten Link gefunden.

Ein erfahrener Linuxer untersucht dabei einen Server eines Freundes, stellt fest, dass dieser gehackt wurde und untersucht den ganzen Vorfall.

Hier gehts zur interessanten Analyse…