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.
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 FileForemost 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 2008294 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.
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:
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:
Auf meiner letzten Debian-Installation - also bis zum letzten Festplattenversager - hatte ich mir den Luxus geleistet, mir über Mbrola per Sprachsynthese vorlesen zu lassen, wie viele ungelesene Nachrichten in meinem Postfach liegen, oder ob das automatische Backup auf meine USB-Platte erfolgreich war.
Das war eigentlich sehr angenehm und das für Lenny im Repository vorliegende festival-Paket versprach, das Ganze in ähnlicher Form ohne großen Aufwand wieder einrichten zu können.
Ein
# aptitude install festival
verankerte die Software auch schnell im System.
Doch ein erster Test mit:
$ echo "Du hast 2 Nachrichten." | festival --tts
wurde lapidar mit
Linux: can’t open /dev/dsp
quittiert.
Die Lösung war schnell gefunden, esddsp (aus dem Paket esound-client) sollte helfen. Aber auch die “Audioausgabe” über
$ echo "Du hast 2 Nachrichten." | esddsp festival --tts
war eher ernüchternd.
Zwar kam nun “etwas” aus dem Lautsprecher, aber logischerweise klang das eher denglisch, als deutsch (”Diu häst tju Nächrigten”).
Die Suche nach einem passenden Sprachpaket (”apt-cache search festvox”) brachte nur die Unterstützung für Finnisch, Hinduistisch oder Amerikanisches Englisch als Ergebnis. Und von Marathi oder Telugu hatte ich bisher noch nie gehört.
Eine Internet-Recherche zeigte zwar, dass es auch möglich ist, Festival Deutsch beizubringen, das hätte jedoch bedeutet, die Source von Festival patchen und anschließend manuell übersetzen zu müssen, und hätte somit einigen Aufwand mit sich gebracht.
Und da ich faul bin, und ich wusste, dass das mit Mbrola einfacher geht, war Festival schnell wieder von meinem System verbannt, und die Alternativ-Installation gestartet.
Im Großen und Ganzen habe ich mich dabei an die wirklich gute Anleitung von Malte J. Wetz gehalten:
Nach unserer Server-Umstellung von Winboard (siehe z.B. “winboard.org - Auf zu neuen Servern“), stieg auf einmal Server02 aus.
Im Logfile tauchten jede Menge Einträge der Art:
Dec 1 11:00:58 server02 kernel: ip_conntrack: table full, dropping packet.
auf.
Diese Meldung sagt eigentlich nur aus: da werden mehr IP-Verbindungen benötigt, als vom System zur Verfügung gestellt werden können.
Die Folge sind Verbindungsprobleme über das Netzwerk zum Server.
Nach dem Ermitteln des Verbindungs-Limits mit:
# sysctl net.ipv4.ip_conntrack_max
net.ipv4.ip_conntrack_max = 65536
lässt sich das Limit dann ganz einfach mit:
# sysctl -w net.ipv4.ip_conntrack_max=131072
net.ipv4.ip_conntrack_max = 131072
höher setzen.
Und damit das auch nach einem Neustart noch entsprechend eingestellt ist, erweitert man einfach die Datei /etc/sysctl.conf um den Eintrag:
net.ipv4.ip_conntrack_max=131072
Screendump ist ein kleines Shell-Helferlein aus dem Paket console-tools, mit dem sich der Inhalt der lokalen Konsolen anzeigen oder speichern lässt.
screendump -s 1 >screenshot_01.txt
beispielsweise speichert einen “Screenshot” der ersten Konsole /dev/tty1 nach screenshot_01.txt
Praktisch.
Man lernt ja bekannterweise jeden Tag dazu.
Diesmal war für mich neu, was Joern unter Dateiberechtigungen unter Linux wiederherstellen gepostet hat.
So gibt es nämlich zwei Helferlein (setfacl und getfacl), mit denen man (auch rekursiv) die Berechtigungen und Besitzer von Dateien und Verzeichnissen sichern und wiederherstellen kann.
Die beiden Tools (unter Debian zu finden im Paket “acl”) werden auf jeden Fall ab sofort einen Platz in meinem virtuellen Werkzeugkasten finden.
Vielen Dank von hieraus für den Tipp.
Mich ärgert schon von jeher, dass Hersteller von Tintenstrahldruckern zwar immer schöne Füllstandsanzeigen für ihre Windows-Treiber zur Verfügung stellen, unter Linux habe ich die aber bisher nie zu Gesicht bekommen…
… bis heute 
Da bin ich nämlich bei einer Paketsuche über das verdächtig nach Tintenfüllstandermittelundanzeige aussehende Programm “ink” gestoßen. Apt-cache show verriet mir, dass ich unter Umständen einen Volltreffer landen könnte:
Description: tool for checking the ink level of your local printer
Ink is a command line tool based on libinklevel3. It provides a simple way
to check ink level of supported printers.
.
Homepage: http://ink.sourceforge.net/
Also schnell (inkl. libinklevel3) installiert, und mit “ink -p parport -n 0″ einen Testaufruf für meinen Canon i865 gestartet.
Pustekuchen.
“Printer not supported”
Aber nicht mit Stefan!
Der Mensch ist von Natur aus ersteinmal faul (zumindest bin ich das). Und gerade wenn es um das regelmäßige Anlegen von Datensicherungen des eigenen Desktops geht, ist man gerne einmal etwas nachlässig (zumindest bin ich das…).
Aus diesem Grund habe ich nach einer Lösung gesucht, die es mir unter Debian Etch ermöglicht, auf meiner USB-Platte automatisch Backups anzulegen, sobald ich diese an den Rechner anschließe und einschalte.
Und weil ich nicht nur praktisch veranlagt bin, sondern auch auf Ästhetik achte (*g*), sollte das Ganze nicht einfach nur im Hintergrund laufen und irgendwelche Logfiles füllen, sondern auch dezent akkustisch und visuell auf sich aufmerksam machen.
