Marco Gabriel

Die Webkrauts zeigen, wie man seinen Wysiwyg Editor in Modx, Wordpress oder anderen Umgebungen erweitert und dem eigenen Bedarf anpasst. Mir kam das heute sehr gelegen.

Es gibt für PHP ja so einige Möglichkeiten, Logs zu erzeugen. Apache Log4PHP dürfte die bekannteste sein, aber ich suchte etwas ganz einfaches und habe KLogger gefunden.

Einfaches Beispiel:

$log = new KLogger('/var/log/'); # Specify the log directory
$log->logInfo('Returned a million search results'); //Prints to the log file
$log->logFatal('Oh dear.'); //Prints to the log file
$log->logInfo('Here is an object', $obj); //Prints to the log file with a dump of the object

Ideal für meinen Einsatzzweck und in wenigen Minuten implementiert.

Ab und an dauert ein rsync Job länger als geplant. Wenn man sicherstellen möchte, dass rsync in einem Cronjob nur ausgeführt wird, falls es nicht schon läuft, kann man folgendes Konstrukt verwenden:

pgrep -c rsync || rsync [options] quelle ziel

Ich hatte das vor einiger Zeit bei Serverfault schon mal als Antwort eingestellt, aber eigentlich ist es in meinem Blog auch gut aufgehoben. 

Ich bin mit ATARI gross geworden. http://www.spiegel.de/wirtschaft/unternehmen/atari-meldet-in-den-usa-insolvenz-an-a-878715.html

Eigentlich automatisch kommt bei einem Monitoring-Projekt die Anforderung schöne, Endbenutzer-kompatible Berichte zu sehen, um den aktuellen Systemstatus täglich, wöchentlich oder monatlich einsehen zu können.

Kann doch eigentlich nicht sein, dass sich da seit Jahren nichts weiter entwickelt hat. Ich habe jedenfalls nichts wirklich gutes finden können. 

Heute habe ich längst fällige Dinge erledigt. Ich habe mein Blog vom ältesten auf den jüngsten Server umgezogen und meine alte Homepage auf Basis von Typo3 habe ich dabei gerade abgeschaltet. Ich hatte sie sowieso seit Jahren nicht gepflegt und wollte Typo3 ja schon länger loswerden.

Done. 

Vor einigen Wochen habe ich irgendwo im weiten Internet ein paar Artikel und Aufrufe gelesen, doch wieder mehr in eigene Blogs zu tippen als nur Twitter, Facebook und Google Plus zu verwenden. Auch wenn ich damit grundsätzlich konform gehe, hat meine wieder neu gestartete Bloggerei damit allerdings relativ wenig zu tun. Meine Erklärung ist eine Andere.

Ich bilde mir ein, dass meine Artikel für meine Twitter-Follower, Facebook-Freunde und Plussums nicht so interessant sind wie für die, die explizit nach einer Problemlösung suchen. Dabei kommen dann so einige technische Artikel hier im Blog eben besser als ein Eintrag bei dem Social Network unseres Vertrauens.

Und nebenbei macht es irgendwie auch mehr Spaß auf der eigenen Seite was zu schreiben. 

Eben mal ein Update von der 4.1 auf die aktuelle Virtualbox 4.2 durchgeführt. Für daheim ist das ganz prima und tut genau das was es soll. Es ist an sich, obwohl es zwischenzeitlich im Rahmen der SUN Übernahme von Oracle geschluckt wurde, ein hervorragendes Werkzeug für die Virtualisierung auf dem Desktop. Man kann damit relativ schnell Testszenarien bauen, anpassen und wieder verwerfen.

Für die Server Virtualisierung würde ich es jedoch nicht verwenden. Da bleibe ich lieber bei Proxmox VE.

SpON berichtete über einen RSS Reader, der im Vergleich zum altbekannten Google Reader self-hosted ist: Fever

Webspace bringt man selbst mit, die Software kauft man einmalig für schlanke $30. Das Ergebnis ist ein selbst gehosteter RSS Reader, der zudem ein paar schöne Features mitbringt die selbst dem Google Reader fehlen.

Was macht man heute mit einem Palm Tungsten T3? Verschenken, verkaufen oder entsorgen?

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.