Zum Einsatz von ownCloud habe ich ja hier und hier schon etwas geschrieben – jetzt ist ownCloud in Version 6 erschienen und kommt natürlich auch gleich auf den Prüfstand.
Meine Erkenntnisse werde ich nach und nach hier zusammentragen.
Noch ein Satz vorweg: ich habe OC6 auf einem ganz normalen Webhosting Paket bei HostEurope installiert – manche meiner Beobachtungen könnten damit zusammenhängen und folglich bei anderen Providern/Servern nicht auftreten.

Installation

Man kann leider immer noch kein Tabellenpräfix vorgeben, die Installation erfolgt standardmäßig mit oc_. Vorsicht also, wenn man die neue Version in die alte Datenbank installieren will – das dürfte ziemlich in die Hose gehen, jedenfalls wenn man keine aktuelle Sicherung der Datenbank parat hat.

Ich habe direkt nach der Installation alle Tabellen manuell (in phpMyAdmin) umbenannt:

[code lang=“sql“ gutter=“0″ collapse=“true“ title=“SQL-Befehle…“]RENAME TABLE `meineDB`.`oc_activity` TO `meineDB`.`abcde_activity`;
RENAME TABLE `meineDB`.`oc_appconfig` TO `meineDB`.`abcde_appconfig`;
RENAME TABLE `meineDB`.`oc_clndr_calendars` TO `meineDB`.`abcde_clndr_calendars`;
RENAME TABLE `meineDB`.`oc_clndr_objects` TO `meineDB`.`abcde_clndr_objects`;
RENAME TABLE `meineDB`.`oc_clndr_repeat` TO `meineDB`.`abcde_clndr_repeat`;
RENAME TABLE `meineDB`.`oc_clndr_share_calendar` TO `meineDB`.`abcde_clndr_share_calendar`;
RENAME TABLE `meineDB`.`oc_clndr_share_event` TO `meineDB`.`abcde_clndr_share_event`;
RENAME TABLE `meineDB`.`oc_contacts_addressbooks` TO `meineDB`.`abcde_contacts_addressbooks`;
RENAME TABLE `meineDB`.`oc_contacts_cards` TO `meineDB`.`abcde_contacts_cards`;
RENAME TABLE `meineDB`.`oc_contacts_cards_properties` TO `meineDB`.`abcde_contacts_cards_properties`;
RENAME TABLE `meineDB`.`oc_documents_invite` TO `meineDB`.`abcde_documents_invite`;
RENAME TABLE `meineDB`.`oc_documents_member` TO `meineDB`.`abcde_documents_member`;
RENAME TABLE `meineDB`.`oc_documents_op` TO `meineDB`.`abcde_documents_op`;
RENAME TABLE `meineDB`.`oc_documents_revisions` TO `meineDB`.`abcde_documents_revisions`;
RENAME TABLE `meineDB`.`oc_documents_session` TO `meineDB`.`abcde_documents_session`;
RENAME TABLE `meineDB`.`oc_filecache` TO `meineDB`.`abcde_filecache`;
RENAME TABLE `meineDB`.`oc_files_trash` TO `meineDB`.`abcde_files_trash`;
RENAME TABLE `meineDB`.`oc_files_trashsize` TO `meineDB`.`abcde_files_trashsize`;
RENAME TABLE `meineDB`.`oc_files_versions` TO `meineDB`.`abcde_files_versions`;
RENAME TABLE `meineDB`.`oc_file_map` TO `meineDB`.`abcde_file_map`;
RENAME TABLE `meineDB`.`oc_gallery_sharing` TO `meineDB`.`abcde_gallery_sharing`;
RENAME TABLE `meineDB`.`oc_groups` TO `meineDB`.`abcde_groups`;
RENAME TABLE `meineDB`.`oc_group_admin` TO `meineDB`.`abcde_group_admin`;
RENAME TABLE `meineDB`.`oc_group_user` TO `meineDB`.`abcde_group_user`;
RENAME TABLE `meineDB`.`oc_jobs` TO `meineDB`.`abcde_jobs`;
RENAME TABLE `meineDB`.`oc_locks` TO `meineDB`.`abcde_locks`;
RENAME TABLE `meineDB`.`oc_lucene_status` TO `meineDB`.`abcde_lucene_status`;
RENAME TABLE `meineDB`.`oc_mimetypes` TO `meineDB`.`abcde_mimetypes`;
RENAME TABLE `meineDB`.`oc_mozilla_sync_collections` TO `meineDB`.`abcde_mozilla_sync_collections`;
RENAME TABLE `meineDB`.`oc_mozilla_sync_users` TO `meineDB`.`abcde_mozilla_sync_users`;
RENAME TABLE `meineDB`.`oc_mozilla_sync_wbo` TO `meineDB`.`abcde_mozilla_sync_wbo`;
RENAME TABLE `meineDB`.`oc_permissions` TO `meineDB`.`abcde_permissions`;
RENAME TABLE `meineDB`.`oc_pictures_images_cache` TO `meineDB`.`abcde_pictures_images_cache`;
RENAME TABLE `meineDB`.`oc_preferences` TO `meineDB`.`abcde_preferences`;
RENAME TABLE `meineDB`.`oc_privatedata` TO `meineDB`.`abcde_privatedata`;
RENAME TABLE `meineDB`.`oc_properties` TO `meineDB`.`abcde_properties`;
RENAME TABLE `meineDB`.`oc_share` TO `meineDB`.`abcde_share`;
RENAME TABLE `meineDB`.`oc_storages` TO `meineDB`.`abcde_storages`;
RENAME TABLE `meineDB`.`oc_users` TO `meineDB`.`abcde_users`;
RENAME TABLE `meineDB`.`oc_vcategory` TO `meineDB`.`abcde_vcategory`;
RENAME TABLE `meineDB`.`oc_vcategory_to_object` TO `meineDB`.`abcde_vcategory_to_object`;
[/code]

und anschließend noch in der config/config.php das neue Präfix eingetragen:

[sourcecode lang=“php“ highlight=“10″ toolbar=“false“]
<?php
$CONFIG = array (
‚instanceid‘ => ‚…‘,
‚passwordsalt‘ => ‚…‘,
‚datadirectory‘ => ‚/home/www/htdocs/owncloud/data‘,
‚dbtype‘ => ‚mysql‘,
‚version‘ => ‚6.0.0.13‘,
‚dbname‘ => ‚cloud_oc6‘,
‚dbhost‘ => ‚localhost‘,
‚dbtableprefix‘ => ‚abcde_‘,
‚dbuser‘ => ‚johndoe‘,
‚dbpassword‘ => ‚mypassword‘,
‚installed‘ => true,
);[/sourcecode]

SSL-Proxy

Wer kein eigenes SSL-Zertifikat besitzt, kann ownCloud auch über einen SSL-Proxy seines Providers benutzen – bei der Einrichtung hat sich mit dem Versionswechsel nichts geändert, die config.php muss wie gehabt um ein paar Parameter erweitert werden. Die Angaben im Beispiel unten sind von HostEurope; wer woanders hostet muss entsprechend die Adressen seines Providers eintragen.

[code lang=“php“ toolbar=“false“ gutter=“false“ highlight=“4,5,6,7″]<?php
$CONFIG = array (
…
‚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).

Achtung: im ersten Anlauf konnte ich mit dem neuen Desktopclient (1.5.0) in dieser Konstellation (OC6 mit SSL-Proxy) mein eingebundenes S3-Verzeichnis (s.u.) nicht synchronisieren. Der Grund ist mir noch nicht ganz klar, aber die Fehlermeldung läßt Schlimmes vermuten: „CSync konnte sich nicht über einen Proxy verbinden. 500 Internal Server Error“.
Im zweiten Anlauf scheint es eher an OC6 als am Client zu liegen, denn mit der vorherigen Version 1.4.2 kommt die gleiche Fehlermeldung.
Mit ownCloud 6.0.0a und dem Desktop Client 1.5.0 funktioniert es jetzt – bis auf ein bekanntes Problem: Dateien mit Pluszeichen (+) im Namen werden nicht synchronisiert.

S3-Anbindung

Im Backend kann man jetzt wesentlich mehr Parameter für eine S3-Verbindung eingeben, unter anderem auch einen eigenen Hostnamen wie z.B. cs.hosteurope.de. Damit werden die Updates wieder einfacher, weil ich endlich nicht mehr in jeder neue Version die entsprechenden Dateien manuell patchen muss.

Ob der Bucketname jetzt auch Punkte akzeptiert (bei Amazon selber geht das nicht, bei Hosteurope ist das kein Problem) habe ich nicht getestet, weil es mich im Moment nicht interessiert.

Bilder werden nicht angezeigt

Auch kein neues Problem: Nicht alle Fotos aus meinem eingebundenen S3-Verzeichnis werden in ownCloud auch als Bilder angezeigt; in der Tabelle oc_filecache landen sie mit „falschem“ MIME-Typ. Mit dem Versionswechsel haben sich allerdings auch die mimetypes geändert, so dass die Einträge in der Tabelle jetzt wie folgt aktualisiert werden können:

[code lang=“sql“ gutter=“0″ toolbar=“false“]UPDATE ‚oc_filecache‘ set mimetype=6, mimepart=5 WHERE name like ‚%.jpg‘ and mimetype&amp;lt;&amp;gt;6[/code]

Auch das ist mit der 6.0.0a – zumindest bei mir – behoben.

Sonderzeichen in Dateinamen

Wie oben schon angerissen: Pluszeichen in Dateinamen führen dazu, dass die Datei nicht synchronisiert wird. Man kann zwar im Browser eine Datei mit Pluszeichen im Namen neu erzeugen, die dann sogar vom Sync-Client heruntergeldean wird (!!) – aber anschließend kommt beim nächsten Sync wieder die Fehlermeldung
Die guten deutschen Umlaute scheinen die Weboberfläche zu irritieren: der angezeigte Dateiname wird vor dem Umlaut abgeschnitten; in der Datenbank steht der komplette Name incl. Umlaut. Statt Ina Müller.mp3 wird einfach nur Ina M angezeigt, ohne Dateityp und ohne Icon.

(Fortsetzung folgt…)

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‘     =&gt; ’ssl.webpack.de‘,
‚overwriteprotocol‘ =&gt; ‚https‘,
‚overwritewebroot‘  =&gt; ‚/meinedomain/owncloud‘,
‚overwritecondaddr‘ =&gt; ‚^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()-&amp;gt;getAbsolutePath($path);
$data = @$this-&gt;getID3-&gt;analyze(‚oc://‘ . $file);
} else {
// Fallback to the local FS
$file = \OC\Files\Filesystem::getLocalFile($path);
}
*/
$file = \OC\Files\Filesystem::getLocalFile($path);
$data = @$this-&gt;getID3-&gt;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…