Letzte Woche bin ich über unhosted.org – „Personal data freedom; A movement to separate web apps from user data“ – gestolpert. Und die haben die Web-App „Libre Docs“ auf Basis von Etherpad Lite geschaffen, die das von Libre Docs zur Verfügung gestellte Etherpad nutzt, die erzeugten Daten bzw. Dokumente jedoch in der Cloud ablegt/speichert. Und der Oberknaller daran ist, dass diese Cloud-Schnittstelle mittels der Javascript-Client-Bibliothek remoteStorage.js, die die Realisierung einer W3C-Spezifikation ist, umgesetzt wurde und somit auch meine eigen Cloud benutzt werden kann.

Wie jetzt, meine eigene Cloud…!? – Na die, die ich mit ownCloud auf meinem Webspace betreibe und in der ich schon meine(n) Kalender (CalDAV), mein Adressbuch (CardDAV) und ein paar Dateien (WebDAV) mittels Desktop (Thunderbird & Ubuntu) und Smartphone (Android) verwalte und synchronisiere.

Also ich kanns nur empfehlen und bedanke mich jetzt schon mal bei allen Beteiligten der oben genannten Projekte!

Nach etwas Suchens bin ich dann zu einer Lösung gekommen: Installation der Version 1.4.
Allerdings ist diese Version nur (direkt) über addons.mozilla.org und nicht über die Hauptseite des „Mozilla Calendar“ Projekts erhältlich. Auf der Projektseite wird als aktuelle Versionsnummer die 1.3 angegeben… *naja*

Trotz alledem: Es funktioniert wieder alles und die CalDAV-Unterstützung, welche IMHO (auch) durch das Team von Inverse inc. unterstützt/voran getrieben wird, ist großartig!

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

• den launchpad-Bug #509180 („ecryptfs sometimes seems to add trailing garbage to encrypted files“) und
• den Blog-Artikel „eCryptfs Fehler und seine Ursache“ von Raphael (aus dem Jahr 2010) gestolpert.

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

Speziell in den letzten Tagen bzw. Wochen habe ich wieder viele Dinge gelernt und auch die letzten drei Jahre haben einige Erkenntnisse geliefert. Die präsentesten (und aktuell in meinem Kopf herum spukenden) davon will ich im Folgenden mal ganz kurz, ungeordnet & nicht vollständig aufschreiben…

Also:
Grafiken/Bilder/… in einer Arbeit, die am Ende auch ausgedruckt wird, sollte man nicht unbedingt mit einer hohen Kompression speichern, denn das sieht in der Print-Version echt blöd aus! (Auch wenn es nett ist, dass das PDF mit 70 Seiten, 25 farbigen Abbildungen und einem im Anhang eingebundenen einseitigen PDF nur knapp 3 MB groß ist…)

Ebenso sollte man sich die digitale Version der Arbeit vorab (zu Teilen) mal ausdrucken um zu schauen, ob die die eingebundenen Abbildungen in einem guten Größenverhältnis (zum Text und zur Seite) eingebunden sind. – Man hat nur eine recht ungenaue (wenn nicht sogar falsche) Vorstellung davon, wenn man sich nur das PDF vorab anschaut…

Wenn man die Arbeit mit/in (La)TeX schreibt und eine externe BibTeX-Datei für die Literatur und/oder eine externe Glossar-Datei einbindet, sollte man für das korrekte Setzen der Referenzen mehrere Kompilierdurchläufe benutzen. Ich habe es in Anlehnung an einen Tipp auf TeX-SE so gemacht:
pdflatex Masterdokument && bibtex Masterdokument && makeglossaries Masterdokument && pdflatex Masterdokument && pdflatex Masterdokument && evince Masterdokument.pdf

Sollte man eine Graustufenversion eines schönen bunten (und mit Links versehenen) PDF benötigen, empfehle ich die Konvertierung der farbigen Version mittels Ghostscript wie (schon 2008) bei handyfloss.net beschrieben.

Selbst definierte TeX-Makros – in meinem Fall fest stehende und mehrfach verwendete Strings (wie bspw. das Makro „\art“ für „Bachelor-Arbeit“) sollten bei der Benutzung im Dokument am Ende mit einem geschützen Leerzeichen versehen werden, denn sonst wird das Leerzeichen nämlich einfach vergessen/nicht berücksichtigt… – So wäre (eine mgl.) korrekte Verwendung:
blatext2 \art\ blatext2

Es ist (zwar recht arbeitsintensiv aber letztlich auch) enorm hilfreich und Freude bereitend, wenn man sich ein Thema aussucht, welches echt spannend ist!

Man sollte nicht zu viel Zeit für einen Abschluss benötigen, denn sonst kann es durchaus passieren, dass selbst die (soziale) Hans-Böckler-Stiftung die Förderung eines (direkt an den Bachelor-Abschluss anschließendes) Master-Studiums mit der Begründung „der zu langen Vorstudienzeit“ ablehnt. .oO(…)

Es ist nicht unbedingt notwendig, sich mit Lehrpersonal ab dem ersten Semester anzulegen… – Das kann nämlich dazu führen, dass man ganz klar an den Noten der belegten Module erkennen kann, wer diese Person ist. Und das ist dann dem Gesamtnotendurchschnitt (der in unserer „Leistungsgesellschaft“ ja nicht ganz unwichtig ist…) nicht wirklich zuträglich! (An allen Modulnoten auf meinem Datenkontrollblatt, die zwischen 2,7 und 4,0 liegen und somit die schlechtesten sind, ist immer eine Person beteiligt gewesen… *verrückt,oder!?*)

So viel dazu… – Grüßle!

POLYKON – die Datenbank für Polymere als Konservierungs- & Restaurierungsmittel enthält strukturierte Informationen zur chemischen Einordnung, den Eigenschaften und der Verwendung zahlreicher Polymere, die in der Restaurierung eingesetzt wurden und werden. Sie haben die Möglichkeit mit Hilfe der Schnellsuche oder der erweiterten Suche nach Produkten, Polymertypen oder Anwendungsbeispielen zu recherchieren.

So steht es unter polykon.fh-potsdam.de geschrieben und ich bin sehr froh, dass wir es so (schön) geschafft haben! (Aus der v1.0 von heute wird aber bestimmt in den nächsten Tagen noch ne v1.5 oder so…)

Danke an Alle!

Ich werde dann jetzt mal mit der Dokumentation beginnen… *puhhh*

PS:
Der Code-‘Wahnsinn‘ gehört da hin…

PPS:
Die URL www.polykon.fh-potsdam.de funktioniert nicht!

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*

Vorab

Zuerstmal stand ich vor dem Problem, alle notwendigen Informationen zusammen zu kramen. – Irgendwie gibt es kaum Anleitungen im (sonst so vollen) WWW. Am Ende kam ich immer wieder auf die beiden Seiten in unserem Wiki zurück:

• http://wiki.freifunk-potsdam.de/Nanostation2_einrichten und
• http://wiki.freifunk-potsdam.de/OpenWRT_Backfire_einrichten.

Image bauen (lassen)

Wie schon geschrieben, habe ich den Imagebuilder benutzt. – Das Bauen des benötigten Images geht damit echt einfach und ich möchte an dieser Stelle ein dickes Dankeschön an die Machenden aussprechen!
Folgende Änderungen an der (vorgegebenen) Grundeinstellung sind für das neue Image (einer Nano M2 für den Potsdamer Freifunk!) im Imagebuilder vorzunehmen:

• „Community“ → „potsdam“;
• „Target“ → „ar71xx-backfire-29592″ (danach „Submit“ klicken);
• „Profile“ → „UBNT“;
• „Hostname“ → bitte an unserer Wikiseite IP-Adressen (und den enthaltenen Links) orientieren;
• korrekte Parameter für „Latitude“ & „Longitude“ wählen (danach zum Reiter „Freifunk“ wechseln);
• „Wifi IP:“ → bitte an unserer Wikiseite IP-Adressen (und den enthaltenen Links) orientieren;
• wenn ein DSL-Anschluss für den Freifunk freigegeben werden soll, bitte einen Haken bei „Share internet connection“ machen (danach zum Reiter „Contact“ wechseln);
• bitte alle Felder ausfüllen (danach zum Reiter „Submit“ wechseln);
• jetzt wird das Image (mit den Grundeinstellungen) durch einen Klick auf „GENERATE“ gebaut.

Danach könnt ihr euch das fertige Image herunterladen. Dabei ist zu beachten, dass es zwei Images zur Auswahl gibt:

• openwrt-ar71xx-ubnt-nano-m-squashfs-factory.bin (3.3M) und
• openwrt-ar71xx-ubnt-nano-m-squashfs-sysupgrade.bin (3.3M).

Dabei stehen „ar71xx“ für den verwendetet WLAN-Chipsatz, „ubnt“ für das verwendete Profil (s.o.), „nano-m“ für das Modell des APs/Routers, „squashfs“ für das zu verwendende Dateisystem und „factory“ bzw. „sysupgrade“ für die Art des Flashens (s.u.).

Flashen

Je nach Ausgangsvoraussetzungen, müsst ihr euch für ein bestimmtes Image entscheiden, welches auf die Nano gespielt werden soll. Habt ihr schon OpenWRT (vllt. kann das auch die Originalfirmware?) auf der Büchse, könnt ihr das „sysupgrade“-Image direkt über das Web-Frontend hochladen. Solltet ihr die Kiste per TFTP flashen wollen/müssen, nehmt das Image mit „factory“ im Dateinamen.
Das Ubiquiti Wiki hat einen kleinen und ausreichenden Artikel zum Firmware-Flashen per TFTP unter http://wiki.ubnt.com/Firmware_Recovery.

Randbemerkungen

1. Bei mir hat nach dem Flashen der Login (http://192.168.1.1/cgi-bin/luci/admin/) ohne Passwort nicht geklappt. – Nachdem ich dann ein originales OpenWRT-Image (von [0]) installiert, dort das Passwort geändert und dann das „sysupgrade“-Image (ohne Konfigurationsänderungen!) geflasht habe, konnte ich mich erfolgreich mit dem neuen Passwort als „root“ anmelden. (Ich habe nirgendwo im Netz einen Hinweis darauf gefunden, dass es sich um einen bekannten Bug handelt…)
2. Aktuell ist meine Nano eine Sackgasse, da das mit dem WAN als Gateway (= „Share internet connection“) nicht so klappt. – Keine Ahnung, woran das liegt. Ich habe nichts an den Grundeinstellungen geändert und auch die Firewall-Regeln etc. scheinen korrekt zu sein…
3. Das kleine Progrämmchen „horst“ (siehe [1] & [2]) – welches man einfach per „opkg install horst“ per SSH installieren kann – tut nicht das, was es soll, sondern beendet sich direkt nach dem Aufruf mit der Meldung „wrong monitor type. please use radiotap or prism2 headers“. – Nach einigem Rumsuchen nach einer Lösung, bin ich im Wiki der Linzer Funkfeuer-Leute fündig geworden. Eine korrigierte (und bei mir lauffähige) Version der Datei „/usr/sbin/horst.sh“ (die für solche Fälle wohl vorgesehen ist) findet ihr unter http://paste.sokai.name/v/4efca6961b1a7.
4. Ach und… Bei mir wollte am Anfang der OLSR nicht so richtig. – Bis ich dann (eher zufällig) gesehen habe, dass die (durch das für das Image ausgewählte Freifunk-Profil) eingestellte BSSID nicht „02:CA:FF:EE:BA:BE“, sondern „D2:CA:FF:EE:BA:BE“ war und ich sie korrigiert hatte.

So dann… – Viel Spaß mit euren Spielzeugen & immer her mit guten Tipps!

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!)

• Homepage (auch) der Potsdamer DGerInnen „Hyzernauts“: http://hyzernauts.de
• Potsdamer DG-Parkour im „Volkspark Potsdam“: http://hyzernauts.de/courses/potsdam/potsdam_start.html (und hier als Korb-für-Korb Foto-Galerie
• Offizielle Trainigszeiten (auch) der Potsdamer DGerInnen: http://hyzernauts.de/hermes/html/trainingszeiten.html
• Homepage der „BC Crew“: http://discgolf-bcc.jimdo.com
• Homepage der „Edelschwinger“: http://www.edelschwinger.de
• Feine DG-Scheiben gibts im Spieleladen „Galadriel“: http://www.galadriel-spiele.de
• „4. Halloween Doubles“ (Turnier) am 30. Oktober 2011: http://gto.ec08.de/events/details/311

PS:
Ich weiß, dass diese Informationen irgendwie redundant sind, aber ich finde die Homepage der Hyzernauts leider arg unübersichtlich… Außerdem ist es IMO echt unQL, wenn News über das Gästebuch verbreitet werden oder nur über (den geschlossenen Bereich) von FB zugänglich sind… :-/

Nun wollte ich einfach das „proposed“-Repo deaktivieren und mein System sozusagen (wieder auf den Standard) „deaktualisieren“. Aber irgendwie funktioniert das nicht so einfach…

Nach einigem Suchen habe ich dann einen funktionierenden Weg bei „Ask Ubuntu“ gefunden, den ich hier mal (auch für mich zum Merken) verlinke: „How can I revert back from an upgrade to the Proposed repository?“.

Noch ein kleiner Hinweis zu obigem Vorgehen: Bevor ihr die beiden Skripte durchlaufen lasst, deaktiviert das „proposed“-Repo nicht. Erst nachdem ihr euer System deaktualisiert habt, könnt ihr bspw. über die Software-Paketquellen-Verwaltung auf dem Reiter „Aktualisierungen“ den Haken beim Repo weg machen.

Viel Glück!