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!

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*

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

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!

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

1. Eine funktionierende Hibiscus-Installation (unter Ubuntu) wird vorausgesetzt.
2. Installation des Jameica-Plugins „jameica.scripting“
   1. Download von http://www.willuhn.de/products/jameica/releases/nightly/jameica.scripting-1.0-nightly.zip
   2. Entpacken der Dateien nach ~/.jameica/plugins/
3. Installation des Scraping Script~/.jameica/plugins/
   1. Download der Datei http://sites.google.com/site/niqs24boxx/files-hibiscus/boscotland.js?attredirects=0&d=1
   2. Kopieren dieser Datei in den Ordner ~/.jameica/plugins/jameica.scripting/scripts/
      (Hinweis: Der Ordner "scripts" existiert so nicht. Ich habe ihn zur besseren Übersicht selber erstellt. Ihr könnt das boscotland.js-Skript auch woanders ablegen, ihr müsst es nachher nur wiederfinden…)
   3. Download der HTMLUnit-Bibliotheken von http://sourceforge.net/projects/htmlunit/files/
   4. Nach dem Entpacken müssen alle Dateien aus dem Unterordner lib in den Jameica-Ordner ~/.jameica/plugins/jameica.scripting/lib/ kopiert werden.
4. Jetzt Hibiscus starten und unter „Datei“ → „Einstellungen“ im Reiter „Scripting“ die Datei/das Skript boscotland.js (s.o.) hinzufügen.
5. Nun noch schnell das BoS-Konto als „Offline-Konto“ erstellen & speichern.
6. Und schon könnt ihr auf der Übersichtseite des neuen BoS-Kontos mittels des neuen Buttons „Via Scripting synchronisieren“ alle Transaktionen abrufen.

Danke an: Olaf, Andreas & Ben!

Und falls ihr für ein Offline-Konto Daueraufträge simulieren wollt, dann schaut euch mal das OffKontoDauerauftrag-Skript an!

Nun fand ich letztens den Hörspielkino-Trailer „Bud Spencer und Terence Hill“ so nett, dass ich ihn mir gerne – für das private Archiv – herunterladen wollte. Doof daran war, dass die MP3 in dem Flash-Player „JW Player“ eingepackt ist und somit nicht einfach über einen Rechtsklick herunterladbar ist.

Auf der Suche nach einer Lösung bin ich dann über RTMPDump gestolpert und konnte die MP3 nach der Installation unter Ubuntu mittels

$ sudo aptitude install rtmpdump

mit dem Aufruf

$ rtmpdump -r rtmp://stream5.rbb-online.de/rad -o radio1-trailer.mp3 -y mp3:_programm/8/201103_hsk_bud

in den aktuellen Ordner streamen/herunterladen. (Die URL für den -r Parameter findet man im Quelltext der Seite, auf der der JW Player eingebunden ist…)

Etwas später bin ich dann – wohl durch Zufall – auch noch über den Direktlink zu der MP3-Datei gestolpert: http://download.radioeins.de/mp3/_programm/8/201103_hsk_bud.mp3 *naja*
MP3-Datei direkt hier anhören

…das mal so kurz am Rande…

1. neues WordPress-Theme: LightWord – Irgendwie siehts nett aus und lässt (nach ein paar kleinen Anpassungen des Plugins) auch den Lifestream vernünftig aussehen.
2. neuer RSS-Reader: rssLounge – Schon vor ner Weile hatte ich mich für meinen Web-Feed-Reader unter rss.sokai.name nach einer Alternative zum (leider!) nicht mehr weiterentwickelten Gregarius umgeschaut und auch rssLounge gefunden. Damals störte mich, dass es entweder nur mit Passwort oder komplett ohne (also auch die Veränderung der Einstellungen) funktionierte. Nach der heutigen Installation von Version 1.7 ist dies nicht mehr so. *supi* Ein paar ‚Kleinigkeiten‘ (bspw. private Feeds, die nur mit Login sichtbar sind, Feeds und verbesserte Sonderzeichenunterstützung) fehlen noch, aber da hab ich Hoffnung. Allerdings werde ich rssLounge ersteinmal nur zusätzlich benutzen, zum Austtesten halt…
3. neues WP-Plugin für deutsche Umlaute in den Slugs: wp-cleanumlauts2 – Ich hatte zwar das (seit WP 3.1 auch nicht mehr funktionierende) „German Permalinks“-Plugin installiert, aber nun is ja wieder alles gut… *thx2cashy*
4. neuer Jabber-Account: me[at]sokai[dot]name (wie meine E-Mailadresse) – Sowas wollte ich schon immer haben und der bastla hats nun auf unserem Kommune-Serverchen mal umgesetzt… *jubel&thx*
5. kein Ohloh mehr im Roaster – Sehr schade, dass ohloh.net den Jabber-/XMPP-Support an den Nagel gehängt hat, wie hier (offiziell) und hier (im Forum) zu lesen ist. .oO(Und ich hab mich schon gewundert, weshalb der Buddy schon seit Monaten immer off is…)
6. neues Git-Repo: WordPress-Plugin ID-Permalinker – Bastelversion, um im Backend schnell auf eigene (alte) Beiträge dauerhaft (denn es wird die post-id mittels Smartcode verlinkt und nicht der Slug) verlinken zu können.
7. neuer Shell-Einzeiler:

   $ find . -iname "*.txt" -exec sed -i "s/SUCHSTRING/ERSETZUNG/g" {} \;

   Dieser findet alle Dateien mit der Endung txt und ersetzt in diesen den SUCHSTRING mit dem ERSETZUNG. Dabei wird mit dem sed-Schalter -i eine Sicherungskopie vor dem Ersetzen gemacht, die bei Erfolg wieder gelöscht wird. *sokannnixschiefgehen*

So viel also von der Bastelfront… .oO(Wozu man nicht so alles kommt, wenn die Frau mal aus dem Haus ist… ; ))

sofar|sokai

1. Server-Adresse: (https://)banking.s-fints-pt-bb.de/PinTanServlet
2. HBCI-Version: „FinTS 3″

Durch Zufall hatte ich diese Angaben – ohne die es nur HBCI-Kommunikationsfehler gibt – im Onlinebanking-Forum (onlinebanking-forum.de) gefunden.
Weitere Informationen und Anleitungen findet ihr auch direkt auf den MBS-Seiten unter https://www.mbs-potsdam.de/module/aktion_if/aktion_if_migration/software/.

PS:
Wer Hibiscus einfach und schnell unter Ubuntu benutzen möchte, dem seien das PPA von dennis-benndorf (ppa:dennis-benndorf/ppa) und das ubuntuusers-Wiki empfohlen!

Download: kopete-antispam-kde3_04-2_all.deb

Das Paket wurde aus den Sourcen konvertiert, ist für KDE3 (3.5.10) und funktioniert unter Kubuntu (Hardy Heron; 8.04) mit Kopete 0.12.7 einwandfrei.

alno ist – genau wie bei Version 0.3 – schon angemailt und wird das Paket sicher demnächst auch auf der offiziellen SorceForge-Seite des Projekts zum Download bereitstellen…

FYI: Für alle, die sowas bei Gelegenheit auch mal machen wollen, gibts bei ubuntuusers.de nen netten kleinen Wiki-Eintrag.
FYI2: Die Installation klappt auf der Konole mittels des Befehls

dpkg -i $pfad_zum_deb/kopete-antispam-kde3_04-2_all.deb

, oder mittels des Programms „gdebi-kde“, welches aufgerufen wird, wenn man das deb-Paket unter KDE doppelklickt.