Skip to content

Viele, sehr viele Dateien in einem Verzeichnis unter Linux löschen

Geschrieben von Marco Gabriel am

Ein bestimmter Server wurde in letzter Zeit immer unzuverlässiger und stürzte öfter mal ab, ohne dass wir eine genaue Ursache ausmachen konnten. Gestern habe ich mich dem Server noch mal angenommen und ein bisschen Ursachenforschung betrieben. Ein einfaches ls -la /var/log dauerte schon ewig. Ich spekulierte schon über einen Festplattenschaden bis ich dann irgendwann tatsächlich eine endlose Dateiliste zu sehen bekam.

Ein ls -la | wc -l brachte hervor, dass in diesem Ordner mehr als 1,3 Millionen Files lagen. Kein Wunder, dass  der Server dabei ab und an mal Schwierigkeiten hat. Die Ursache war, dass sich auf Debian/Ubuntu Systemen der sysklogd und logrotate gegenseitig in die Quere kommen. Aber dazu vielleicht ein anderes Mal mehr. Nun musste ich erst mal die ganzen überflüssigen Dateien löschen.

Das ist etwas leichter gesagt als getan, denn ein rm /var/log/mail.0.* brachte schon einen Fehler, dass die Liste der Dateien zu gross sei.

Lösung 1:

find /var/log -name "mail.0.*" -exec rm '{}' \;

find bearbeitet jede Datei einzeln, startet dann rm um die einzelne Datei zu löschen. Das funktionierte grundsätzlich, löschte allerdings nur ca. 150 Files pro Sekunde. Somit hätte der gesamte Vorgang 144 Stunden oder 6 ganze Tage gedauert. Ich brauchte eine andere Lösung.

Lösung 2:

find /var/log -name "mail.0.*" -delete -print

Damit übergibt find die Dateien nicht mehr an rm, sondern löscht sie gleich selbst. Damit erreichte ich ca. 2.000 Files pro Sekunde. Der gesamte Vorgang verkürzte sich somit auf ca. 10 Minuten. Das -print ist übrigens nur notwendig, wenn man sehen möchte, welche Dateien find löscht. Ohne Ausgabe dürfte es noch etwas schneller gehen. Na Also, geht doch. 

EDIT: Da der Artikel in einer früheren Version unfertig gespeichert wurde, habe ich die fehlenden Lösungen noch ergänzt ;-). 

EDIT 2: "-name" ergänzt. Falscher Fehler in meiner Erinnerung. 

Automatische btrfs Snapshots vor Installation

Geschrieben von Marco Gabriel am

Btrfs, so könnte man meinen, ist der kommende Star unter den Linux Filesystemen. Bis dahin ist es zwar noch ein weiter weg, denn auch btrfs hat noch einige Baustellen, aber es werden permanent weniger und die Entwicklung schreitet mit großen Schritten voran. Noch 2012 wird Oracle, als Arbeitgeber des Hauptentwicklers Chris Mason, das Filesystem als stabil kennzeichnen und es in der kommenden Version ihres Oracle Linux ganz offiziell supporten. Das alles lässt hoffen. 

Btrfs  hat einige wirklich überzeugende Features und ich möchte einige dieser Features und konkrete Anwendungen dafür in der nächsten Zeit näher vorstellen. Den Anfang mache ich mit den btrfs Snapshots.

Ich habe kürzlich gesehen, wie jemand mit yum unter Oracle Linux vor jeder Installation einen automatischen Snapshot anlegte, um jederzeit wieder darauf zurücksetzen zu können. Das wollte ich für meine Ubuntu Installation ebenfalls. Die Umsetzung war dabei sehr leicht:

/etc/apt/apt.conf.d/70debconf 

Dpkg::Pre-Invoke {"mkdir -p /snapshots; ROOTFS=`mount | grep ' on / ' | \
cut -f1 -d' '`; mount $ROOTFS /snapshots; \
/sbin/btrfs subvolume snapshot /snapshots/@ /snapshots/@_snapshot_apt_`date +%Y-%m-%d_%H-%M-%S`; \
umount /snapshots";};

Apt (oder Aptitude) stellt eine Schnittstelle zur Verfügung um Befehle vor einer Paketinstallation auszuführen. Das können auch mehrere Befehle sein, so wie oben angegeben. 

Die Vorgehensweise ist wie folgt:

  1. Es wird ein Ordner /snapshots angelegt, sofern dieser noch nicht existiert.
  2. Wir finden heraus, welches Device als root gemounted ist
  3. Wir schneiden uns den Device Teil heraus und hängen diesen unter /snapshots noch mal ein (btrfs kann das)
  4. Ein Snapshot von / wird in /snapshot/@_snapshot_apt_(datum) erzeugt
  5. Der Mountpoint /snapshots wird wieder ausgehängt um eine unbeabsichtigte Änderung zu vermeiden.

Da ein solcher btrfs Snapshop nur Sekundenbruchteile dauert, merkt man es bei einer Installation gar nicht, aber der Systemzustand wird festgehalten. Sollte man nach der Installation nun feststellen, dass etwas nicht läuft oder es sich nur um einen Test gehandelt hat, den man nun wieder rückgängig machen möchte, geht man wie folgt vor:

  1. Das Root Device hängen wir noch mal unter /snapshots ein: mount <root device> /snapshots
  2. Ein btrfs subvolumes list /snapshots zeigt uns alle angelegten Snapshots
  3. Mittels mv @ @_oldroot und einem anschließenden mv @_snapshot_apt_(datum) @ aktivieren wir den früheren Snapshot wieder als root
  4. reboot

Nach einem Reboot des Systems sind nun alle nach dem Snapshot installierten Pakete und alle Veränderungen am Filesystem wieder zurückgesetzt worden, so als wäre es nie geschehen.

So kann man beliebig mit den Snapshots hin- und herwandern. Alle Snapshots sind übrigens auch regulär beschreibbar. Nicht mehr benötigte Snapshots kann man einfach mit einem btrfs subvolume delete /snapshots/<snapshot-name> entfernen.

Zum Ende noch eine Warnung: Da Ubuntu btrfs als root Filesystem zwar unterstützt, aber von der Standardimplementierung abweicht, funktioniert die oben angegebene Vorgehensweise nur auf Ubuntu, nicht aber auf Debian Systemen. Bei Debian Systemen ab Squeeze funktioniert dies zwar grundsätzlich schon, man muss jedoch mit den Subvolumes etwas anders umgehen. Debian hält sich an den Weg, wie ihn btrfs eigentlich vorgibt, Ubuntu weicht dagegen ab.

cdrecord unter Debian 6

Geschrieben von Marco Gabriel am

Wer in Debian 6 eine Möglichkeit sucht, ein ISO Image auf einen Rohling zu brennen, wird cdrecord vermissen. Dies ist in Debian mittlerweile nicht mehr enthalten. Stattdessen kann man aber auf wodim zurückgreifen.

aptitude install wodim
wodim tolles-image.iso


flickr und die Bilder

Geschrieben von Marco Gabriel am

Flickr verwehrt mir den (direkten) Zugriff auf meine Bilder, zeigt sie anderen zum Nutzen von Flickr aber an.

Nun die lange Story:

Ich hatte mal einen flickr Pro Account, zahlte meinen kleinen Obulus an flickr für die jährliche Nutzung des Accounts und der schönen vielen kostenpflichtigen Zusatzleistungen. So konnte ich mehr als 200 Bilder hochladen. Irgendwann gab es mal eine Diskussion, dass Flickr Mitgliedern aus Deutschland jedoch den Account zensiert und manche Bilder nicht anzeigt. Ich beschwerte mich bei Flickr, wie so viele andere zu der Zeit ebenfalls und verlängerte danach konsequenterweise meinen Pro Account auch nicht mehr. Ich war schlicht nicht mehr einverstanden mit der Art, wie Flickr mit seinen Nutzern umging. Nach Ablauf des Pro Status wurde mein Account also auf einen normalen Account zurückgestuft und unterlag somit auch wieder der Beschränkung von maximal 200 Bildern.

Nach ein paar Monaten bekam ich von jemandem eine Anfrage, ob er mein Bild bei flickr kostenlos für eine Veröffentlichung nutzen dürfe. Ich sagte zu. Ein paar Tage später fiel mir jedoch ein, dass dieses Bild bei flickr eigentlich gar nicht mehr hätte gezeigt werden dürfen. Zumindest mir wurde es in meinem Account nicht mehr angezeigt. Das habe ich dann auch noch mal überprüft und - es war nach wie vor weg.

Mit der Standardsuche bei flickr nach bestimmten Stichworten habe ich das Bild dann wieder finden können. Es war also noch da. Nur nicht mehr in meinem Account.

Vielleicht geht's ja nur mir so, aber ich finde das mindestens seltsam.

Chrome und Serendipity

Geschrieben von Marco Gabriel am

Irgendwann nach dem ich Chrome zu meinem Standardbrowser gemacht habe, stellte ich fest, dass Serendipity beim Verfassen eines neuen Beitrags immer am Ende der Seite abstützt. Zwar nur der eine Tab (Chrome sei Dank), aber das Geschriebene war weg.

Mittlerweile weiß ich, dass es nichts mit dem Betriebssystem zu tun hat, denn es passiert unter Linux genauso wie unter Windows oder Mac OS X. Und es passiert auch über die letzten Updates von Chrome und Serendipity hinweg. Es passiert auch auf anderen Serendipity-Installationen, so dass es nichts mit einer speziellen Installation zu tun haben kann. Vielleicht hat's auch nur mit einem einzigen Plugin zu tun, das ich einsetze.

In anderen Browsern habe ich kein Problem. Aber nur um einen Blogeintrag zu verfassen muss ich jetzt einen anderen Browser starten.

Kann das jemand bestätigen?

Ubuntu / Debian: Installierte .deb Pakete eines Servers auf einem anderen Server installieren

Geschrieben von Marco Gabriel am

Es kommt immer wieder mal vor, dass ein Server installiert werden muss, der einen alten Server ersetzen soll. So lange nur wenige Dienste oder Pakete auf dem alten Server installiert waren, lässt sich das auch schnell aus dem Kopf erledigen. Pakete auf dem neuen Server installieren, Config übernehmen, Config anpassen, läuft.

Allerdings gibt es auch Server, auf denen viele Pakete installiert sind und die mehrere Dienste anbieten. Hier eine Vorgehensweise, um sich das Leben einfacher zu machen:

Auf dem alten Server:

dpkg --get-selections | grep -v deinstall > package_list.txt

Auf dem neuen Server:

dpkg --set-selections < package_list.txt
dselect
3. [I]nstall
4. [C]onfig
5. [R]emove (optional)
6. [Q]uit
Oder alles in einem Schritt vom neuen Server aus (alles in einer Zeile): 
neuer-server~# ssh user@alter-server dpkg --get-selections | grep -v deinstall | \
dpkg --set-selections && dselect update && dselect install && dselect config

Danach sind die auf dem alten Server installierten Pakete auf dem neuen Server ebenfalls installiert. Die Konfiguration muss dann natürlich noch übernommen und angepasst werden, denn in der Regel kommen auf dem neuen Server auch neuere Versionen der Pakete zum Einsatz.

Zarafa 7.0.0 WebApp Screenshots (neuer Webaccess)

Geschrieben von Marco Gabriel am

Mit Zarafa 7.0.0 wird ja auch der länger ersehnte neue Webaccess kommen, allerdings als zusätzliches und zunächst optionales Paket. Man kann ihn also erst einmal parallel zum bekannten Webaccess verwenden.

Nach meinem ersten Test vor ein paar Tagen finde ich die neue WebApp sehr gelungen. Das wird eine deutliche Verbesserung zum sowieso schon sehr guten Webaccess.

Screenshots der neuen Zarafa WebApp gibt's auch schon zu sehen. Diese Screenshots werde ich auch nach und nach aktualisieren, wenn es etwas neues zu berichten gibt.

Ach ja: Damit startet auch hier im Blog die neue Kategorie "Zarafa". Dazu werde ich künftig öfter etwas schreiben, nachdem ich es nun schon ein paar Jahre verwende ;-).

Linux Backup mit Duply, Duplicity und Rdiff-Backup auf (potentiell unsichere) Online Speicher (Teil 2)

Geschrieben von Marco Gabriel am

Teil 2: Duply und Duplicity

Im ersten Teil habe ich ja bereits die Unterschiede zwischen Duply / Duplicity und Rdiff-Backup geschildert. In diesem Teil gehe ich also davon aus, dass man Duplicity verwendet, weil man vom Provider einen FTP Backup Space zur Verfügung gestellt bekommen hat oder Amazons S3 nutzt.

Installation

Unter Ubuntu 10.04 LTS / Lucid Lynx könnte es kaum einfacher sein. Die Pakete sind bereits im Repository vorhanden und können direkt mittels aptitude installiert werden.

aptitude install duply duplicity

Wer ältere Ubuntu Versionen oder andere Distributionen nutzt, kann Duply auch direkt von der Downloadsite nehmen und das Python Script unter /usr/bin legen und als ausführbar markieren (chmod +x /usr/bin/duply). Duplicity sollte in jedem halbwegs aktuellen Repository jedoch vorhanden sein.


"Linux Backup mit Duply, Duplicity und Rdiff-Backup auf (potentiell unsichere) Online Speicher (Teil 2)" vollständig lesen

Linux Backup mit Duply, Duplicity und Rdiff-Backup auf (potentiell unsichere) Online Speicher (Teil 1)

Geschrieben von Marco Gabriel am

Same procedure as every year, James!

Der neue Rootserver ist fertig, aber benötigt noch ein Backup. Hat man nun nicht gerade ein Rechenzentrum im Keller und kann dort Bänder wechseln gehen, bietet sich für Rootserver ein Backup auf verfügbaren Onlinespeicher an. Das kann in einigen Fällen ein weiterer Rootserver mit noch reichlich Platz sein, aber auch ein vom Provider zur Verfügung gestellter FTP Server oder auch Amazons S3 sind gute Alternativen.

Diverse Tools machen einem das Leben deutlich leichter und Backups zum Vergnügen. Im Folgenden gehe ich auf Duply/Duplicity und Rdiff-Backup in Verbindung mit einem weiteren Backup-Server, FTP Server und Amazon S3 ein und zeige wie man sichere Backups erstellt, die man hinterher auch wieder brauchen kann.

"Linux Backup mit Duply, Duplicity und Rdiff-Backup auf (potentiell unsichere) Online Speicher (Teil 1)" vollständig lesen

Alte Kommentare

Geschrieben von Marco Gabriel am

Uiuiui. Da klickt man versehentlich mal die Kommentaradministration an und stellt fest, dass neben Spam auch noch ca. 50 richtige Kommentare seit 2005 nicht moderiert wurden. Die habe ich nun mal nachträglich moderiert und bewilligt.

Eigentlich würde ich ja gerne auf die Antispam-Maßnahmen verzichten. Aber dann geht hier gar nichts mehr...

links for 2010-05-05

Geschrieben von Marco Gabriel am
tweetbackcheck cronjob