Seit ein paar Tagen habe ich in meinem /var/log/syslog ein paar hässliche Meldungen, die das ganze syslog ‚vollmüllen‘.

Hier mal ein Beispiel:

Apr 24 08:55:10 axolotl kernel: [36283.935663] Valid eCryptfs headers not found in file header region or xattr region, inode 1717173
Apr 24 08:55:10 axolotl kernel: [36283.935674] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Auf der Suche nach Ursache & Lösung bin ich über

Das Problem der Meldungen (siehe Raphaels Erklärungen) ist wohl, dass es in meinem (mit eCryptfs verschlüsseltem) home Dateien gibt, die eine Größe von 0 Bytes haben. Wie die da hin gekommen sind kann ich nicht mehr rekapitulieren, da ich mir auch nicht mehr ganz sicher bin, seit wann die Meldungen im syslog stehen (und ich ebenfalls wenig Lust habe, die alten syslog-Dateien zu durchsuchen…).

Am Ende habe ich nun Folgendes durgeführt, um das eCryptfs wieder konsisten zu machen & somit auch die Meldungen los zu werden.

  1. sudo find /home/.ecryptfs/$username/.Private/ -xdev -size 0c ($username = mein Login-Name)
  2. Der erste Befehl sucht alle Dateien mit der 0-Byte-Größe und gibt diese aus. – Bei mir waren es zehn dieser Dateien.
  3. Danach habe ich alle ausgegebenen Dateien per Hand nochmal kontrolliert – ls -lha $datei.
  4. Abschließend (nachdem ich festgestellt hatte, dass alle Dateien wirklich mir gehören & wirklich 0 Bytes groß waren) habe ich dann alle zehn Dateien einzeln gelöscht: sudo rm "$datei".

Das Ganze habe ich immer mit root-Rechten (sudo) gemacht, da es ohne diese ständig zu Fehlermeldungen bzgl. der Rechte kam – was aber auch an der Benutzung von trash-cli liegen kann!

Zusammenfassend kann ich sagen, dass

  • seit dem die Meldungen im syslog nicht mehr vorhanden sind *claro!*;
  • ich seit dem keine Probleme feststellen konnte,
  • der Bug offensichtlich (für bestimmte Anwendungen) bereits gefixed ist (nichts desto trotz kann ein Systemcrash nat. dazu führen, dass diese Dateien wieder existieren und dann mosert eCryptfs ja zurecht…) und
  • ich der Meinung bin, dass man die Dateien relativ gefahrlos löschen kann – 0 Byte große Dateien haben keinen (privaten) Inhalt und sollte es sich um Spezialdateien von bestimmtn Anwendungen handeln, werden die beim Neustart der Anwendung wahrsch. wieder neu erstellt.

In diesem Sinne & ohne die Übernahme irgend welcher Gewehre,
der sokai

…ich bin kein PHP-Programmierer, aber für meine B.A.-Arbeit mache ich es (mehr recht als schlecht) & bekomme dabei manchmal fast ne Kriese…

So zum Bsp. in den letzten beiden Tage. – Da wurde aus einer kleinen 40zeiligen Funktion (die die gewollten Grundfunktionalitäten liefert) ein kleines Monster mit 164 Zeilen… – Aber jetzt isses halt echt viel schöner & die Bedarfe Aller sind befriedigt… ;)

Außerdem noch schnell nen Link zu dem Projekt RIPS: http://rips-scanner.sourceforge.net.
Damit kann man offline PHP-Code auf Fehler & Schwachstellen prüfen lassen… – Sehr nett! (Aber bitt enicht nur darauf verlassen. ;) )

*soundjetztgehtsinsbett-wink*

An dieser Stelle soll es heute mal kurz um ein Problemchen und dessen ‚Lösung‘ gehen, welches mich gestern (fast) den ganzen Tag beschäftigt hat.

Ich hatte die Aufgabe zu lösen, mittels eines HTML-Formulars und PHP ein Bild (als BLOB) in einer MySQL-Datenbank abzulegen. – Eigentlich ja nicht allzu schwierig, denn Anleitungen & Code-Schnipsel dazu gibts im Netz wie „Sand am Meer“…

Am Ende entschied ich mich für die Variante, die hochgeladene Datei ohne file handler (fopen, fread, fclose) in die DB zu hexen. Denn man kann recht einfach mittels mittels der globalen PHP-Variable „$_FILES“ auf die (mittels POST) hochgeladene Datei zugreifen.

if (isset($_FILES[‘bild‘]) && is_uploaded_file($_FILES[‘bild‘][‘tmp_name‘]) && $_FILES[‘bild‘][’size‘] > 0) {
$mimetype = $_FILES[‘bild‘][‘type‘];
$blob = bin2hex(file_get_contents($_FILES[‘bild‘][‘tmp_name‘]));

Da ich beim Insert immer die Meldung bekam, dass ich einen Fehler in der SQL-Syntax habe, wenn ich für den BLOB mysql_real_escape_string(file_get_contents($_FILES['bild']['tmp_name'])) oder addslashes(file_get_contents($_FILES['bild']['tmp_name'])) (wie bspw. hier beschrieben) benutzt habe, habe ich letztlich die Funktion bin2hex() für das Speichern der binären Daten (des Bildes) in der MEDIUMBLOB-Spalte der DB verwendet.

Nach ein paar Test-Uploads stellte ich dann jedoch fest, dass größere Bilder nicht hochgeladen werden können – wg. der Begrenzung auf dem Server. Also habe ich etwas gesucht und die dafür zuständigen PHP-Einstellungen bzw. -Variablen gefunden. Diese spuckten mir allerdings aus, dass meine max. Upload-Größe 32MB beträgt, was bei einem Upload von einem ca. 1,5MB großen Bild jedoch nicht ’stimmte‘. Denn da kam dann dann die MySQL-Meldung „Got a packet bigger than ‚max_allowed_packet‘ bytes“ und der Datensatz wurde nicht in die DB geschrieben.

‚Gut, dass die MySQL-Meldung so aussagekräftig ist‘, dachte ich mir und suchte erneut nach einer Lösung… – Und siehe da, auch dazu gibt es Lösungen, wie bspw. diese. Ärgerlich war nur, dass ich den ganzen Tag der Meinung war, dass der MySQL-Parameter „max_allowed_packet“ dynamisch zur Laufzeit des Servers per PHP beeinflussbar ist. *gml*
Dies kam zum Beispiel auch daher, dass das Auslesen des Parameters (mit mysql_query("SHOW VARIABLES LIKE 'max_allowed_packet'")) und das Neusetzen des Wertes (mittels mysql_query("SET max_allowed_packet=16777216;")) zwar anstandslos funktionierte, aber leider den Upload nicht verbesserte. Trotz des neu gesetzten Wertes (auf 16MB), war die Uploadgrenze in Wirklichkeit immer noch beim Standardwert 1MB.

Lange Rede, kurze Erkenntnis:
Das Ändern des MySQL-Wertes „max_allowed_packet“ zur Laufzeit per PHP funktioniert (i.d.R.) nicht. (Man kann, wenn man MySQL-Root-Rechte mit seinem Login hat, versuchen, den globalen MySQL-Parameter zu verändern.)
Man muss/sollte/kann die Einstellung serverseitig vornehmen und entweder dauerhaft den Eintrag max_allowed_packet=16MB; in der my.cnf machen oder mit MySQL-Root-Rechten den Wert mittels SET max_allowed_packet=16777216; zur Laufzeit ändern (dann ist dieser bei einem Neustart allerdings wieder weg).

Außerdem ist anzumerken, dass die BLOBs in der DB irgendwie (ca.) doppelt so groß sind/werden, wie die Original-Dateien. – Aus einem Bild mit 991K wird bspw. (bei mir) ein BLOB mit 2.03MB. *strange&doof* (Bitte jetzt kein Bashing, ob es überhaupt sinnvoll ist, Bilder direkt in der DB zu speichern. – Es muss dieses Mal so sein!)

Ich habe sie schon ein paar Tage an meiner Wand hängen und wollte sie seit dem schon immer mal hier posten…

Die Regeln basieren auf dem Buch „Debugging“ von David J. Agans. Wer noch ein paar Details zu den einzelnen Regeln lesen möchte, der kann hier mal schauen.

Doch nun (endlich) die (Lebens)Weisheit:

  1. Understand the system
  2. Make it fail
  3. Quit thinking and look
  4. Divide and conquer
  5. Change one thing at a time
  6. Keep an audit trail
  7. Check the plug
  8. Get a fresh view
  9. If you didn’t fix it, it ain’t fixed