Es hat sich einiges getan beim Versionswechsel auf ownCloud 5 – es fühlt sich deutlich schneller und performanter an. Genauer gesagt: es fühlt sich jetzt so gut an, dass ich den ernsthaften Versuch unternehmen werde, mir mit ownCloud meine eigene Backup-Wolke einzurichten und mich auf ein Leben ohne Google-Synchronisierung vorzubereiten. Nicht dass ich meine Kontakte und Dateien vom Handy mit Google synchronisieren würde – aber trotzdem hätte ich sie gerne online gesichert.
Installation von ownCloud
Wie schon bei den vorherigen Versionen war die Installation bei HostEurope problemlos in ein paar Minuten durchgelaufen. Aber jetzt fangen die Herausforderungen und teilweise auch die Kämpfe mit Kinderkrankheiten der ownCloud an…
SSL-Verbindung
Als ganz normaler User mit begrenztem Budget habe ich natürlich kein eigenes SSL-Zertifikat und bin somit auf den SSL-Proxy angewiesen; das reicht mir vollkommen. In der offiziellen Dokumentation fand sich der entscheidende Hinweis auf die notwendigen zusätzlichen Parameter in der config.php; die benötigten IP-Adressen der SSL-Proxies von HostEurope (10.30.7.137 – 140) stehen in den HE FAQ:
[code lang=“php“ title=“/config/config.php“ gutter=“false“]
‚overwritehost‘ => ’ssl.webpack.de‘,
‚overwriteprotocol‘ => ‚https‘,
‚overwritewebroot‘ => ‚/meinedomain/owncloud‘,
‚overwritecondaddr‘ => ‚^10\.30\.7\.1(?:37|38|39|40)$‘,[/code]
Die Cloud wird über den SSL-Proxy mit folgender Adresse aufgerufen:
https ://ssl.webpack.de/meinedomain/owncloud
(also overwriteprotocol + overwritehost + overwritewebroot).
Aber Achtung: zumindest gefühlt ist die Verbindung über den SSL-Proxy langsamer als ohne – hier muss man sich also im Zweifelsfall zwischen gesichert und flott entscheiden. Beides funktioniert jedenfalls parallel so lange nichts anderes in ownCloud konfiguriert ist.
S3-Anbindung
ownCloud kann verschiedene Cloud-Speicher einbinden, u.a. auch Amazon S3. Mit ein paar kleinen Anpassungen an der S3-Integration kann man auch eigenen S3-Speicher bei anderen Providern (z.B. bei HostEurope) einbinden; wie das genau geht, steht im ownCloud-Forum. Folgende Dateien müssen angepasst werden:
- /apps/files_external/lib/amazons3.php
- /apps/files_external/lib/config.php
- /3rdparty/aws-sdk/services/s3.class.php
Dateien werden nicht oder falsch angezeigt
Kann ein simples Cache-Problem nach der Aktualisierung sein. Abhilfe schafft entweder eine saubere Neuinstallation oder eine manuelle Bereinigung der Datenbank (siehe hier): Die Tabellen oc_filecache und oc_storages leeren.
Keine Musikdateien gefunden
Egal ob frisch hochgeladen oder bereits vorhanden, der Musikplayer von ownCloud hat sich partout geweigert, irgendwelche Dateien zu finden. Die Lösung für mich stand hier:
[code lang=“php“ firstline=“101″ title=“/3rdparty/getid3/getid3.php“]
$option_max_2gb_check = false;
[/code]
Seit Version 5.0.5 steht der Parameter auf null und soll den richtigen Wert automatisch aus den php-Einstellungen (PHP_INT_MAX) des Servers erkennen – das funktioniert aber zumindest in meinem Setup nicht.
Und nach einer weiteren kleine Änderung in /apps/media/lib/extractor.php werden tatsächlich alle Musikdateien (auch die im angehängten S3 Speicher) gefunden. Auch hier mag das Problem an meinem Setup liegen, die automatische Erkennung anhand von allow_furl_open funktioniert bei mir nicht.
[code lang=“php“ firstline=“49″ title=“/apps/media/lib/extractor.php“]
public function extract($path) {
/* if(ini_get(‚allow_url_fopen‘)) {
$file = \OC\Files\Filesystem::getView()->getAbsolutePath($path);
$data = @$this->getID3->analyze(‚oc://‘ . $file);
} else {
// Fallback to the local FS
$file = \OC\Files\Filesystem::getLocalFile($path);
}
*/
$file = \OC\Files\Filesystem::getLocalFile($path);
$data = @$this->getID3->analyze($file);
\getid3_lib::CopyTagsToComments($data);
return $data;
}[/code]
Zeile 58 ist nur eine Kopie von Zeile 55 (weil ich die if-Abfrage komplett auskommentiert habe), Zeile 59 ist eine Ergänzung aus dem oben genannten Link.
Mediaplayer spielt nichts ab
Nachdem endlich meine MP3s angezeigt wurden, weigerte sich der integrierte Player immer noch standhaft und gab keinen Mucks von sich. Auch das ist ein bereits bekannter Fehler, für den es schon eine Lösung gibt: eine einzige Zeile in apps/media/ajax/api.php verschoben und schon höre ich Musik …
Das Problem tritt in 5.0.5 nicht mehr auf.
Dateien synchronisieren
In meinem S3 liegen schon ein paar GB synchronisierte Dateien; leider schafft der Desktop Client es nicht, hier einen sauberen Abgleich vorzunehmen. Stattdessen fängt er an, alle (lokal bereits vorhandenen) Dateien herunterzuladen und mit erweitertem Namen (aus bla.jpg wird bla_conflict-20130326-223906.jpg) abzuspeichern.
Die Ursache ist – wieder einmal – ziemlich banal: lokal sind die Dateien mit dem Aufnahmedatum abgespeichert. Nach dem Hochladen mit DragonDisk bekommen sie das Hochladedatum als „last change“. Beim Synchronisieren gewinnt natürlich die jüngste „Änderung“ und führt zu einem Duplikat.
Die Lösung ist zum Glück ebenfalls trivial, wenn auch einmalig zeitaufwändig: Alle lokalen Dateien löschen (bzw. sicherheitshalber erstmal nur an einen andren Ort verschieben) und die Synchronisation starten. Das ist auf jeden Fall besser als in die andere Richtung, denn üblicherweise hat man im Downstream wesentlich mehr Bandbreite verfügbar als im Upstream.
Bilder synchronisieren
Mit ownCloud 5.0.8 und dem Desktop Client in Version 1.3.0 ist mir noch ein „interessantes“ Phänomen aufgefallen: Bilder werden beim Hochladen in ownCloud mit dem falschen MIME-Type in der Datenbank indiziert – und sind folgerichtig nicht in der Bilder-App zu sehen. Warum das so ist und ob es dazu auch schon einen offiziellen Bug im Tracker gibt, weiß ich noch nicht.
Aber das Problem läßt sich mit einem kleinen SQL-Statement korrigieren:[sql]
update `oc_filecache` set mimetype=10, mimepart=5 WHERE name like ‚%.jpg‘ and mimetype=9
[/sql]
Wie sich die Kontakte zwischen PC, Handy/Tablet und ownCloud synchronisieren lassen steht in einem eigenen Artikel…
