Tag: software

seit version 4 bietet owncloud die moeglichkeit, “externes” storage einzubinden. d.h. man kann bereits vorhandene “cloudspeicher” einbinden und ueber das owncloud interface darauf zugreifen. irgendie soll das wohl mit dropbox und gdrive usw funktionieren, aber ich habs erstmal mit ftp probiert. hilfe findet man auf der seite “Custom Mount Configuration“. da steht auch nix von dropbox etc. geschrieben.

um einen ftp server einzubinden muss man die datei config/mount.php anlegen. in meinem falle mit folgendem inhalt (benutzernamen etc. sind natuerlich anzupassen);

array(
  'ich'=>array(
   '/ich/files/mountpoint/'=>array('class'=>'OC_Filestorage_FTP',
    'options'=>array('host'=>'www.ftphost.tld',
                     'user'=>'ftpUserName',
                     'password'=>'ftpPassWord'))
    	)
    )
);
?>

diese mounts kann man wahlweise fuer bestimmte user und gruppen oder auch fuer alle anlegen. details siehe link oben.
ich habe auf dem besagten ftp ca. 3000 bilder liegen. owncloud “scannt” diese natuerlich erstmal. dabei werden die dateisystem objekte erstmal mit name, datum, hashwert etc in der tabelle fscache abgelegt. wenn es sich um bilder handelt und man mit der integrierten gallery durch diese browst, legt owncloud auch noch thumbnails im userverzeichnis (unterverzeichnis “gallery”) unterhalb des “datadirectory” an.
zu weiteren spielereien bin ich noch nicht gekommen… ich finds aber irgendwie suboptimal, dass owncloud fuer meine 3000 bilder auf dem remoteserver 22672 (!) einzelne logins gemacht hat.

mit der version 4 hat sich auch die url geaendert, die man fuer den zugriff auf kalender und adressbuch mit clients benoetigt. im gegensatz zu vorher stimmt nun die angegebene url im backend von owncloud (einstellungen -> persoenlich).. da ists jetzt extra fuer ios und osx angegeben:

https://servername/remote.php/carddav/principals/username/

bzw.

https://servername/remote.php/caldav/principals/username/

die “alten” urls funktionieren aber auch noch. hauptsache ein sack voll leute hat sich monatelang die zaehne daran ausgebissen 😉

.. von version 3 auf 4… sieht scheisse aus:

der kalender sah aehnlich aus. und so kriegt man es weg, ohne an der collation der datenbank rumschrauben zu muessen. was jetzt sinnvoller ist, mag ich fuer mich gerade nicht entscheiden. so hab ich wenigstens die datenbank so, wie sie bei der installation mal angelegt wurde.

UPDATE calendar_objects SET summary = REPLACE(summary, 'ä', 'ä');
UPDATE calendar_objects SET summary = REPLACE(summary, 'ü', 'ü');
UPDATE calendar_objects SET summary = REPLACE(summary, 'ö', 'ö'); 
UPDATE calendar_objects SET summary = REPLACE(summary, 'Ãœ', 'Ü');
UPDATE calendar_objects SET summary = REPLACE(summary, 'Ä', 'Ä');
UPDATE calendar_objects SET summary = REPLACE(summary, 'Ãœ', 'Ö');
UPDATE calendar_objects SET summary = REPLACE(summary, 'ß', 'ß');

UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'ä', 'ä');
UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'ü', 'ü');
UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'ö', 'ö'); 
UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'Ãœ', 'Ü');
UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'Ä', 'Ä');
UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'Ãœ', 'Ö');
UPDATE calendar_objects SET calendardata = REPLACE(calendardata, 'ß', 'ß');

UPDATE contacts_cards SET carddata = REPLACE(carddata, 'ä', 'ä');
UPDATE contacts_cards SET carddata = REPLACE(carddata, 'ü', 'ü');
UPDATE contacts_cards SET carddata = REPLACE(carddata, 'ö', 'ö'); 
UPDATE contacts_cards SET carddata = REPLACE(carddata, 'Ãœ', 'Ü');
UPDATE contacts_cards SET carddata = REPLACE(carddata, 'Ä', 'Ä');
UPDATE contacts_cards SET carddata = REPLACE(carddata, 'Ãœ', 'Ö');
UPDATE contacts_cards SET carddata = REPLACE(carddata, 'ß', 'ß');

UPDATE contacts_cards SET fullname = REPLACE(fullname, 'ä', 'ä');
UPDATE contacts_cards SET fullname = REPLACE(fullname, 'ü', 'ü');
UPDATE contacts_cards SET fullname = REPLACE(fullname, 'ö', 'ö'); 
UPDATE contacts_cards SET fullname = REPLACE(fullname, 'Ãœ', 'Ü');
UPDATE contacts_cards SET fullname = REPLACE(fullname, 'Ä', 'Ä');
UPDATE contacts_cards SET fullname = REPLACE(fullname, 'Ãœ', 'Ö');
UPDATE contacts_cards SET fullname = REPLACE(fullname, 'ß', 'ß');

soso…

naechste woche werde ich dann mal mein owncloud auf die version 4 aktualisieren. mit der 3er versuche ich garnicht erstm mich mit der app zu verbinden 😉

das postie plugin nervt seit version 1.4.4 mit “possible xss attack – ignoring email” rum, wenn ich z.b. mit dem iphone per mail ein bild bloggen wollte.

das problem ist schon gut bekannt. abhilfe hat von den entwicklern noch keiner geschaffen. ich hab dann einfach kurzen prozess mit der komischen sicherheitsabfrage gemacht und in der datei /wp-content/plugins/get_mail.php ab zeile 36 den kram auskommentiert.

 // check for XSS attacks - we disallow any javascript, meta, onload, or base64
    if (preg_match("/.*(script|onload|meta|base64).*/is", $email)) {
      echo "possible XSS attack - ignoring email\n";
      continue;
    }

was ich nicht so ganz verstanden habe… in der mail vom iphone ist der anhang base64 codiert. also hab ich erst das rausgeschmissen aus der abfrage. ging trotzdem nicht, obwohl in der ganzen mail nix von “script|onload|meta” drinne stand. erst nachdem ich die komplette abfrage auskommentiert habe, brachte das das gewuenschte ergebnis.

heute thunderbird v15.0 installiert. man kann nun chats einbinden… hmm.. gleich mal ausprobieren. und natuerlich hats auf anhieb nicht geklappt. die fehlerkonsole sagt:

not authorized? passwort, benutzername und server/port alles richtig eingegeben.

und wie das immer so ist, findet man erstmal nichts, wenn man nach “brandneuen” problemen sucht. irgendwann bin ich auf einen ganz frischen eintrag in einem forum gestossen, der das problem erkannte:

We identified today the cause of the “Not authorized” error message for people connecting to OpenFire.
OpenFire doesn’t follow the standard DIGEST-MD5 exchange, and Thunderbird closes the connection when it receives something unexpected.

ahja.. der thunderbird mag also nicht mit meinem openfire reden. also dem openfire die DIGEST-MD5 methode zur authentifizierung abgewoehnen und alles ist gut. PLAIN login reicht mir vollkomen, da die verbindung ja sowieso verschluesselt ist. in der openfire.xml also diesen eintrag hinzufuegen:

PLAIN 

das muss in der config irgendwo zwischen diesen beiden tags stehen:

...

dienst neu starten und gut 🙂

und der facebook chat scheint auch zu funktionieren (auch jabber/xmpp basiert)… denn prompt kam ne nette video chat anfrage 😉

naja… vielleicht bauen die das ja auch noch in den thunderbird ein.

UPDATE: nachdem ich voller vorfreude den kram zum laufen gebracht habe, stelle ich fest: der chat client kann quasi nix. alles sehr rudimentaer gehalten.. aber scheint zu funktionieren.

bisher wars naemlich echt ein kampf und krampf…

aber warum “heroku”? die meisten pod betreiber duerften wohl eigene server betreiben. aber schonmal ein schritt nach vorne…

mysql kann einen auch irritieren mit den fehlermeldungen…

Error: ‘Lost connection to MySQL server at ‘reading initial communication packet’, system error: 113′ errno: 2013

gegoogelt wie ein grosser. irgenwelche leute sagen es waere ein bug. die ganzen seiten mit replikationsproblemen durchkaemmt. nix. bis ich dann die netzwerkverbindung geprueft habe.. kein netz. von wegen lost connection. garkeine connection.

nach dem update eines debian auf squeeze gabs bei einem upload in wordpress immer einen “500 internal server error” und im apache error log stand dann sowas:

mod_fcgid: HTTP request length 131538 (so far) exceeds MaxRequestLen (131072)

das liegt daran, dass unter lenny dieser wert (MaxRequestLen) noch 1GB war und seit squeeze nur noch 128kb. abhilfe schafft eine weitere zeile in der datei /etc/apache2/mods-available/fcgid.conf, welche den wert setzt:

    ...
    FcgidMaxRequestLen 134217728
    ...

den wert sollte man so machen, wie es die php.ini erfordert:

upload_max_filesize = 128M
post_max_size = 128M