.

Bash – Befehlshistorie speichern

Die Bash bringt mit “history” ja eigentlich schon ein Protokoll der zuletzt eingegebenen Befehle mit. Praktisch auch, dass man in dieser Historie mit “[strg]+r” Kommandos, die man bereits abgesetzt hat, über die Eingabe einiger Zeichen aus der Befehlskette noch einmal aufrufen kann. Auch das “!”-Kommando in seinen verschiedenen Spielarten kann ganz nützlich sein (siehe “man history”).

Einzig ein “Langzeit-Protokoll” ist über diese Funktion nicht möglich, zu alte Befehle werden aus der Datei ~/.history nach einiger Zeit rausgeschmissen.

Und genau so ein Langzeitprotokoll macht gerade bei aufwändigen Programm- oder Dienstinstallationen und -Konfigurationen durchaus Sinn, wenn man im Nachhinein noch einmal den Installationsverlauf nachvollziehen möchte. Dann fehlen nämlich gerade die Teile des Verlaufes, die man sich später noch einmal ansehen möchte.

Zur Lösung dieses “Problems” gibt es beispielsweise folgende Ansätze.

Richtig gut ist “script”. Hier werden nicht nur die eingegebenen Befehle protokolliert, auch die Rückgaben der Kommandos werden in die Protokolldatei geschrieben. Das Protokoll entspricht somit genau der Ausgabe, die man in seiner Sitzung auf dem Bildschirm hatte.

Interessieren einen jedoch nur die eingegebenen Befehle selbst, hilft die Umgebungsvariable “PROMPT_COMMAND”:
export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo $$ $USER "$(history 1)" >> ~/installationsverlauf'

Links: Bash eternal history


Xen Server 5.5 – Virtuelle Maschinen über Snapshots sichern

Letzte Woche haben wir unsere Xen-Server-Farm auf die aktuelle Version 5.5 hochgezogen. Herausragendste Merkmale des aktuellen Virtualisierers sind imho v.a. das Workload-Loadbalancing, die “native” Unterstützung unseres SAN sowie die Möglichkeit, Snapshots von laufenden virtuellen Maschinen anzulegen.

So ist es endlich möglich, automatisiert Backups der Server anzulegen. Ich habe für unsere Umgebung ein kleines Sicherungsscript erstellt, das für einen Server einen Snapshot anlegt, aus diesem eine virtuelle Maschine generiert, und diese in einen NFS-Share wegsichert:

#!/bin/bash

### Backup einer virtuellen Maschine in NFS-Share
# $1 – Name der zu sichernden Maschine
#
# (w) 07/2009 Stefan Peters
#

PATH=/opt/xensource/bin:/sbin:/bin:/usr/bin:$PATH

# Variablen definieren
BACKUP_SHARE=server:/var/nfsshare
BACKUP_DIR=/media/backup

DATUM=$(date +%F)

logger -s “Backup VM ${1} – Backup gestartet”

# Existiert das Zielverzeichnis für den NFS-Mountpoint?
if [ ! -d ${BACKUP_DIR} ]; then
mkdir -p ${BACKUP_DIR}
fi

# pruefen, ob die NFS-Freigabe fuer die Backups gemountet ist und ggf. einhaengen
mount |grep ${BACKUP_DIR} >/dev/null
if [ "$?" -ne "0" ]; then
mount.nfs $BACKUP_SHARE $BACKUP_DIR 2>/dev/null
if [ "$?" -gt "0" ]; then
logger -s “Backup VM ${1} – Backup-Share konnte nicht gemounted werden”
exit 1
fi
fi

# pruefen, ob die zu sichernde VM existiert
xe vm-list |egrep “RW\): ${1}$” >/dev/null
if [ "$?" -ne "0" ]; then
logger -s “Backup VM ${1} – VM existiert nicht”
exit 1
fi

# Snapshot erstellen
strSnapshot=$(xe vm-snapshot vm=${1} new-name-label=${DATUM}_${1})

# Snapshot zu VM wandeln
xe template-param-set is-a-template=false uuid=${strSnapshot}

# Snapshot sichern
BACKUP_VM=${BACKUP_DIR}/${1}.xva
BACKUP_VM_OLD=${BACKUP_VM}_TMP

if [ -f "${BACKUP_VM}" ]; then
mv “${BACKUP_VM}” “${BACKUP_VM_OLD}”
fi

xe vm-export vm=${strSnapshot} filename=”${BACKUP_VM}”
if [ "$?" -ne "0" ]; then
logger -s “Backup VM ${1} – Backup fehlgeschlagen”
else
rm “${BACKUP_VM_OLD}”
logger -s “Backup VM ${1} – Backup erfolgreich abgeschlossen”
fi

# Snapshot loeschen
xe vm-uninstall uuid=${strSnapshot} force=true

# Backup-Share unmounten
umount $BACKUP_DIR 2>/dev/null

exit 0

Dem Script wird als Parameter der Name der zu sichernden Maschine mitgegeben.

Wenn bereits eine Sicherung der betreffenden Maschine existiert, so wird diese zunächst umbenannt und erst nach dem erfolgreichem Abschluss der Serversicherung gelöscht.


Minitip: 3D-Effekte temporär deaktivieren

Ich nutze mittlerweile auf allen Linux-Desktops die Compiz-Effekte. Damit arbeitet es sich einfach fluffiger und produktiver, zumindest, wenn man die Effekte dezent einsetzt.

Manchmal kann es aber auch nötig sein, Bildschirmlupe und Co. kurzzeitig komplett zu deaktivieren, zum Beispiel, wenn man die ja eigentlich immer zu knapp bemessenen System-Ressourcen für wichtigere Dinge benötigt. Und so geht’s:
$ metacity --replace &
Und wenn Compiz wieder an den Start soll:
$ compiz --replace &


Partition sicher löschen

Ich hatte neulich einmal wieder eine Festplatte zu löschen. Da auf der Platte Patientendaten gespeichert waren, und die Platte per Post rausgeschickt werden sollte, wurde:
$ sudo dd if=/dev/random of=/dev/[partition] bs=1024k
abgesetzt.

Doch trotz Boliden mit aktueller Hardware, der Zufallsgenerator braucht einfach viiiiel zu lange. Ich hab’s nicht ausgerechnet, aber der Wipe-Vorgang hätte für die zu löschenden 160GB schon einige Tage gebraucht.

Bei Serverplatten interessiert mich das nicht wirklich, da ich dort meist nicht wirklich unter Zeitdruck stehe. Da wird der dd-Prozess angeschmissen und rappelt dann nach Lust und Laune vor sich hin, bis er fertig ist.

Wer ungeduldig ist oder es einfach nur eilig hat, kann aber mittlerweile – und ohne wirklichen Sicherheitsverlust – die zu löschende Platte einfach mit Nullen vollhauen:
$ sudo dd if=/dev/zero of=/dev/[partition] bs=1024k

Oder man benutzt “shred” aus dem coreutils-Paket.

Kleiner Tipp am Rande. Wer während des dd-Laufes den aktuellen Fortschritt sehen möchte, der muss einfach nur ein SIGUSR1 an den laufenden dd-Prozess absetzen:
# sudo kill -SIGUSR1 $(pidof dd)


Shutdown mit Rückfrage – Update

Ein cooler Tipp von Christian:

Wer regelmäßig auf mehreren Konsolen gleichzeitig per ssh arbeitet, der hat mit Sicherheit schon einmal versehentlich im falschen Fenster einen System-Shutdown ausgelöst. Und schwupps ist der falsche Server heruntergefahren.

Hier helfen die Scripts aus dem Debian-Paket “molly-guard” weiter. Diese installieren in /usr/sbin/ Links mit dem Namen der eigentlichen Shutdown-Befehle (halt, poweroff, shutdown und reboot) auf /usr/share/molly-guard/shutdown. Löst man nun eines dieser Scripte aus, verlangt molly erst nach der Eingabe des herunterzufahrenden Servernamens.

Spätestens hier kann man einen fast begangenen Fehler noch verhindern.

Blöd ist nur, dass ich meist “init” benutze, um meine Systeme herunterzufahren oder neu zu starten, und das wird von molly-guard nicht berücksichtigt… ich werde das Script auf jeden Fall einmal entsprechend anpassen und testen, ob es irgendwo zu Wechselwirkungen kommen kann.

Das Testergebnis gibt’s dann hier.

Links:
blog.256bit.org

Edit
Ein paar kleine Tests haben – auch mit verlinktem “init” und angepasstem Script bisher funktioniert. Wer’s ausprobieren möchte:
# ln -s /usr/share/molly-guard/shutdown /usr/sbin/init
und im Shutdown-Script die Zeilen

case “$CMD” in
halt|reboot|shutdown|poweroff)
if [ ! -f $EXEC ]; then

ändern zu:

case “$CMD” in
init|halt|reboot|shutdown|poweroff)
if [ ! -f $EXEC ]; then

.

Das Ganze ist allerdings ohne Gewähr.


Shell-Helferlein: watch

Ich wurde gerade auf “watch”, einem kleinen Utility für die Shell, aufmerksam.

Mit watch ist es möglich, Befehle periodisch immer wieder auszuführen.

Bisher habe ich nie den großen Sinn in dem Tool gesehen, gibt es doch eine Crontab oder while-Schleifen.

Watch knallt die Bildschirmausgaben der ausgeführten Befehle aber nicht einfach untereinander weg, sondern leert vorher den Bildschirm. Dabei, und das ist das, was das Programm interessant macht, ist es möglich, die Veränderungen zwischen zwei von watch ausgelösten Befehlsausgaben markieren zu lassen. Diese Änderungen lassen sich auch kumulativ über die gesamte Laufzeit von watch markieren.

Auf diese Weise lässt sich beispielsweise sehr einfach überwachen, ob ein Prozess neue Forks erstellt, ob sich Dateigrößen geändert haben, ob neue Dateien in ein Verzeichnis kopiert wurden, ob sich Benutzer am System angemeldet haben, …

Das einzige was stört ist, dass watch keinen Parameter kennt, der nur eine festgelegte Anzahl von Befehlsdurchläufen anstößt.

Doch alles in allem, ein interessantes Tool.

Und ja, ich weiß: es gibt vielfältige Alternativen. :)

Links:
http://www.debian-administration.org/articles/605


nopaste-Service für die Shell

Gerade auf [pimp my shell] gefunden:

sprunge.us ermöglicht es, direkt aus der Shell einen Beitrag auf dem “nopaste-Service” zu posten, sprunge.us liefert die URL zurück auf die Shell.

Auf sprunge.us steht, wie es geht.

Ich habe mir das ganze noch ein wenig vereinfacht und ~/bin/nopaste mit folgendem Inhalt angelegt:
#!/bin/bash
curl -F 'sprunge=< -' http://sprunge.us

Jetzt kann ich simpel mit
$ echo foobar | nopaste
“nicht einfügen”.

Sehr praktisch.


Minitip – Datenrettung mit foremost

Heute morgen kam ein Bekannter, ziemlich aufgeregt, zu mir. Er hatte versehentlich alle Bilder von seiner Micro-SD-Karte des Mobiltelefons gelöscht, ohne diese vorher zu sichern. (Glücklicherweise hatte er sich selbst noch nicht an einer Datenrettung versucht, ich hatte also noch Chancen. ;) )

Nach dem Einlegen der Karte in den Kartenleser meines Lenny-Boliden, zeigte mir ein “fdisk -l”, wen sollte es verwundern, einen VFAT-formatierten Datenträger.

Nun folgte nur noch der wenig aufregende, forensische Teil der Datenrettung:
$ mkdir -p ~/rescue/daten
$ dd if=/dev/sdb1 of=~/rescue/sdcard.img
$ foremost -v -i ~/rescue/sdcard.img -o ~/rescue/daten/

Foremost (aus dem gleichnamigen Debian-Paket) beschreibt sich selbst mit: “Recover files using their headers, footers, and data structures”, und versucht Daten anhand ihrer Header-Daten im Input-File (oder Input-Datenträger) wiederherzustellen. Und da das Programm sich v.a. auf Multimedia-Daten (jpg, gif, avi, wmv, mov, …) versteht, war es in meinem Fall genau die richtige Wahl:

Foremost version 1.5.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Thu Feb 14 7:35:17 2008
Invocation: foremost -v -i sdcard.img -o daten
Output directory: /home/stefan/rescue/daten
Configuration file: /etc/foremost.conf
Processing: sdcard.img
|——————————————————————
File: scard.img
Start: Thu Feb 14 7:35:17 2008
Length: 982 MB (1030101504 bytes)

Num Name (bs=512) Size File Offset Comment

0: 00001293.jpg 347 KB 662016
1: 00001997.jpg 218 KB 1022464
2: 00002445.jpg 308 KB 1251840
[...]
291: 00613197.jpg 307 KB 313956864
292: 00462189.gif 31 KB 236640768 (183 x 244)
293: 00506253.mov 1 MB 259201564
********|
Finish: Thu Feb 14 7:36:06 2008

294 FILES EXTRACTED

jpg:= 286
gif:= 7
mov:= 1
——————————————————————

Foremost finished at Thu Feb 14 7:36:06 2008

Saubere Leistung.

Mit einem Image des eigentlich betroffenen Datenträgers sollte man arbeiten, da so die Gefahr eines Verlustes der Originaldaten minimiert wird.


Konsistente Backups mit LVM-Snapshots

Bislang habe ich, um die Datenkonsistenz der Backups von Mailservern sicherzustellen, eigentlich immer offline gesichert. D.h. Postfix und Cyrus gestoppt, die Daten mit rsync weggesichert und die Mailserverdienste wieder gestartet. Ein sehr unbefriedigendes Mittel, auch wenn die Offline-Zeiten des MTA sehr absehbar sind und um 3 Uhr morgens nicht wirklich jemanden stören.

Aus diesem Grund machte ich mich vor der letzten Mailserver-Installation auf die Suche nach einer besseren Backup-Methode, einer die möglichst ohne Mailserver-Auszeit auskommen sollte.

Und da ersuchmaschinte ich ein Feature des Linux Logical Volume Manager (LVM), dass ich persönlich bis dato gar nicht kannte: Snapshots.

Für diejenigen, die noch nicht mit dem LVM gearbeitet haben:

Was sind Logical Volumes?
Theoretisch können mehrere physikalische Datenträger (oder Partitionen) zu einer logischen großen Einheit (der sog. Volumegroup, oder kurz VG) zusammengefasst werden, die sich, vereinfacht gesagt, nach außen hin als eine großer Datenträger präsentiert.

In der erstellten Volume-Group werden dann wieder Logische Volumes (sinnigerweise als LV abgekürzt) erstellt, die sich als formatierbare Partitionen darstellen.

Warum diese ganze Bastelei?
Nun, man stelle sich vor, in einem Server hängen zwei Platten mit je 50GB Plattenplatz, man benötigt aber für eine Partition 80GB. Im Normalfall müsste man nun einen 80GB-Datenträger zusätzlich in den Rechner hängen, damit man eine entsprechend große Partition anlegen kann. Mit dem LVM erstellt man stattdessen einfach für die beiden vorhandenen Platten je ein Physical Volume (PV) und hängt diese in eine Volume Group. So erhält man einen virtuellen Datenträger mit 100GB. Nun kann man darauf ein logisches Volume mit 80GB erstellen und erhält somit die gewünschte Partition, die sich jetzt einfach formatieren und anschließend mounten lässt.

Und was ist ein Snapshot?
Vereinfacht gesagt, funktioniert das so: Wird ein Snapshot für ein Logical Volume angelegt, friert der Zustand des Volumes quasi ein und wird als eigenes Device zur Verfügung gestellt.

Solange der Snapshot aktiv ist, laufen alle Dateioperationen auf das eigentliche LV in eine Art “Puffer”. Dieser Puffer wird nach dem Aushängen des Snapshots wieder in das LV integriert, die Anwendungen, die mit dem betroffenen Volume arbeiten, merken von dieser Aktion nichts und können ganz normal weiterlaufen.

Der Snapshot selbst ist konsistent, man sichert also Daten von einem Datenträger, dessen Inhalte sich in einem definierten Zustand befinden und sich während des Backup-Vorgangs nicht ändern.

Wer weitere Informationen zum LVM haben möchte, dem sei das LVM Howto von AJ Lewis als Lesematerial empfohlen.

Aber jetzt auf zur Praxis:

Zum vollständigen Beitrag »


Debian und iSCSI

Im Dezember haben wir nach langer Vorbereitung endlich unser SAN in Betrieb nehmen können. Als erstes Storage kommt darin die PS100E von Equallogic zum Einsatz.

Ein sehr zum empfehlendes Gerät: simpel in der Einrichtung, mächtig an Funktionen, und aufgrund der dreifachen (und über den zweiten Controller dann auch noch redundant auslegbaren) Netzwerkanbindung auch sehr performant.

Ist das Gerät einmal ausgepackt, in das Rack eingebaut und verkabelt, ist das erste Volume (auch ohne große Vorkenntnisse) nach spätestens 20 Minuten erstellt und steht im SAN zur Verfügung.

Nachdem nun die wichtigsten Daten der Windows-Domäne seit ein paar Wochen ihr Dasein auf dem SAN im Echtbetrieb fristen, war heute dann der erste Debian-Server dran, Verbindungen über iSCSI aufzubauen, um als VMWare-Server seine Images im SAN ablegen zu können.

Und weil die Einrichtung doch ein wenig Bastelarbeit war, für diejenigen, die vor dem gleich Problem stehen (oder für andere, die es einfach interessiert ;) ), hier eine kurze Beschreibung, wie man in Etch iSCSI-Targets einhängen kann:

Zum vollständigen Beitrag »


Kalender
März 2010
M D M D F S S
1234567
891011121314
15161718192021
22232425262728
293031EC
Ereignisse
    • Keine Termine.
Du befindest Dich in der Kategorie: '#!/bin/bash'.
Kategorien
Archiv
Wichtiges!?

.