Die Owncloud ist eine bekannte Open-Source-Software zur Bereitstellung einer privaten Cloud – ganz ohne Google, Dropbox und Co. Nebenbei kann der in PHP programmierte Owncloud-Server auch noch Kalender und Kontakte synchronisieren.

Doch wenn der Server-Administrator im Backend eine neue Version signalisiert bekommt, dann ist erst einmal Schluss mit lustig. Denn Owncloud-Upgrades sind alles andere als ein Selbstläufer. Eine Aktualisierung per Mausklick im Browser ist zwar möglich, doch raten die Entwickler selbst davon ab. Außerdem werden die Owncloud-Erweiterungen für Kontakte und Kalender nicht automatisch mit der Kern-Software aktualisiert. Die Zahl der Foren-Berichte verzweifelter User, die sich ihre Owncloud unfreiwillig zerschossen haben, ist beunruhigend hoch. Das ist schade, denn in Zeiten, wo sowohl Firmen als auch Geheimdienste Big Data abschöpfen wollen, sollte eine private Cloud so einfach wie möglich einzurichten sein.

Anstatt zum Gebetbuch zu greifen, empfehle ich – aus mehrjähriger Owncloud-Erfahrung – einen kühlen Kopf und die nachfolgende Schritt-für-Schritt-Anleitung zum erfolgreichen Upgrade. Update: Getestet und funktioniert ebenfalls für die Aktualisierung von Owncloud 8.2.3 auf 9.0.0; in Owncloud 9 wurde die Integration von Kalender und Kontakten in den Core verbessert.

Drei Wege führen zur Aktualisierung einer Owncloud. Von der einfachsten Variante per Updater App über den Browser raten sogar die Entwickler ab; bei der kostenpflichtigen Enterprise-Edition ist diese App erst gar nicht enthalten. Der in der Owncloud-Dokumentation empfohlene Weg über das Paketmanagement der installierten Linux-Distribution bleibt hier ebenfalls außen vor – aus prinzipiellen Gründen (warum eine Web-Anwendung über das Paketmanagement aktualisieren?) ebenso wie aus praktischen Erwägungen; denn das Einspielen der Pakete und die damit verbundenen Nacharbeiten ergeben keinen zeitlichen Vorteil gegenüber der hier angewandten dritten Methode; zudem muss man – nach dem Fiasko veralteter Owncloud-Pakete in Ubuntu – zunächst ein Drittanbieter-Repository als Paketquelle hinzufügen und per Schlüssel-Import beglaubigen. Nein, das lohnt nicht. Bleibt also noch der dritte Weg zur Owncloud-Aktualisierung: eigenhändig per Kommandozeile.

Der Einfachheit halber lädt man sich das Owncloud-Server-Paket direkt ins richtige Verzeichnis auf dem eigenen Webspave. Der Link zur aktuellen Community-Edition von Owncloud (beim Verfassen dieses Postings war 8.2.2 die aktuelle Owncloud-Version und 8.2.1 der zu aktualisierende Vorgänger) findet sich auf der Installationsseite. Beim Entpacken des Owncloud-Paketes wird das Verzeichnis owncloud erstellt. Serviert man also auf seinem Server die Owncloud-Website aus dem Verzeichnis /var/www/owncloud, dann wird das Installationspaket ins Verzeichnis /var/www heruntergeladen:

$ cd /var/www
$ wget https://download.owncloud.org/community/owncloud-8.2.2.tar.bz2

Anschließend gilt es, die Integrität der Archivdatei anhand der auf der Owncloud-Website angebotenen Prüfsummen-Datei zu verifizieren:

$ wget https://download.owncloud.org/community/owncloud-8.2.2.tar.bz2.md5
$ md5sum -c owncloud-8.2.2.tar.bz2.md5 
owncloud-8.2.2.tar.bz2: OK

Bevor die alte Owncloud-Installation durch die neue ersetzt werden kann, muss die Owncloud mit dem occ-Tool (Owncloud Commandline Client) in den Wartungsmodus versetzt werden. Da occ gerne mit dem User des Webservers ausgeführt werden möchte, wechseln wir zuvor noch schnell die Persönlichkeit – bei Debian/Ubuntu heißt der Apache-User www-data:

$ su - www-data
$ owncloud/occ maintenance:mode --on
Maintenance mode enabled
$ exit

Scheitert der Wechsel an der Fehlermeldung „This account is currently not available“, dann liegt das daran, das www-data normalerweise keinen Login erlauben sollte und folglich auch keine Shell konfiguriert ist – geben wir www-data also vorübergehend eine Shell mit:

$ su - www-data -s /bin/bash

Die Owncloud ist jetzt im Wartungsmodus. Anfragen von Clients werden jetzt nicht mehr beantwortet. Deshalb heißt es, jetzt hübsch effizient erst das Backup der bisherigen Version anzufertigen und dann das Update auf die neue zu fahren. Also los: Zuerst wird die alte Installation beiseite geschafft und ein Backup der Owncloud-Datenbank angefertigt:

$ mv /var/www/owncloud /var/www/owncloud8.2.1
$ mysqldump -uroot -p owncloud > owncloud821.sql

Außerdem empfiehlt die Owncloud-Dokumentation, ein Backup des Verzeichnisses data anzufertigen. Nun, sofern das Daten-Verzeichnis (wie empfohlen) außerhalb des Owncloud-Verzeichnisses liegt, sollte ein Upgrade gar nicht damit in Berührung kommen. Außerdem sollten die in der Owncloud gespeichert Daten ohnehin mit anderen Geräten synchronisiert sein. Wer trotzdem ein Backup anfertigen will, mag das tun; je nach Umfang der Daten kann das aber ein paar Minuten dauern:

$ tar cpzf /var/www/data.tgz /pfad/zu/data/

Bitte noch einmal kontrollieren: im Verzeichnis /var/www müssen jetzt eine Datei owncloud821.sql und ein Verzeichnis owncloud8.2.1/ mit aktuellen Zeitstempel liegen. Dies sind unsere Backups, die wir wieder zurückspielen können, wenn das Update nicht funktioniert.

Alles klar? Dann kann jetzt endlich das neu heruntergeladene Owncloud-Installations-Paket in /var/www/ entpackt werden:

$ cd /var/www
$ tar -xjf owncloud-8.2.2.tar.bz2

Nun muss die Konfigurationsdatei von der alten in die neue Owncloud-Installation kopiert werden:

$ cp -p owncloud8.2.1/config/config.php owncloud/config/

Damit der Webserver auf die Dateien zugreifen kann, müssen die Rechte entsprechend gesetzt werden:

$ chown www-data -R owncloud/
$ chmod 700 -R owncloud/

Okay, wer eine feinere Rechtevergabe als das recht lässige „chmod 700“ wünscht, findet in der Owncloud-Doku ein Kapital über Strong Directory Permissions. Damit ist der „händisch“ zu erledigende Teil des Upgrades bewältigt. Aufmerksame Zeitgenossen werden zudem gemerkt haben, dass ich bei meinem „effizienten“ Upgrade etwas geschummelt habe, denn bis gerade eben war die Owncloud für Clients von außen nicht etwa im Wartungsmodus, sondern gar nicht erreichbar, da ja das alte Owncloud-Verzeichnis per mv an einen anderen Ort beiseite geschafft wurde und die neue Owncloud erst nach den Backups dorthin entpackt wurde.

Das Update der Datenbank und der offiziellen Owncloud-Software erledigt wieder die Kommandozeilen-Anwendung occ:

$ su - www-data
$ owncloud/occ upgrade
$ owncloud/occ maintenance:mode --off

Mit dem letzten Kommando ist der Wartungsmodus wieder abgeschaltet. Der Zugriff auf die Owncloud sollte nun wieder möglich sein. Sofern nur „offizielle“ Owncloud-Apps am Start sind, ist das Upgrade damit abgeschlossen. Doch nicht zu früh freuen: Leider sind so beliebte Apps wie Kalender oder Kontakte eben nicht „offiziell“, und wer sie nutzt, wird in der Ausgabe des occ-Upgrade-Kommandos unter anderem folgende Zeilen bemerkt haben:

Disabled 3rd-party app: calendar
Disabled 3rd-party app: contacts

OCC-Upgrade hat also die nicht-offiziellen Apps deaktiviert. Falls danach noch folgende Zeilen auftauchen, dann wurden diese Apps ebenfalls aktualisiert:

Update 3rd-party app: calendar
Update 3rd-party app: contacts

Das war bei mir beim Upgrade von 8.2.1 auf 8.2.2 der Fall, zuvor aber nicht immer. Eine nicht aktualisierte App kann jedoch die ganze Owncloud samt Admin-Backend lahmlegen, wenn nämlich die API der Server-Software geändert wurde, die veraltete App aber davon noch nichts weiß. In diesem Fall findet man im Log lauter Fehlermeldungen mit dem Namen der schuldigen App. Dann hilft nur noch, selbst im Owncloud-App-Verzeichnis nachzuschauen, ob es nicht zumindest eine Beta-Version gibt, und dieses dann eigenhändig herunterzuladen und auf dem Server im Verzeichnis owncloud/apps zu entpacken. Falls für die benötigte App noch kein Update verfügbar ist, dass sie auf den aktuellen Stand bringt, oder falls auch die Beta-Version nicht funktioniert, gibt es genau zwei Möglichkeiten:

• Entweder muss man die schuldige Owncloud-App selbst deaktivieren; wenn das Backend nicht mehr erreichbar ist, hilft nur noch die eigenhändige Manipulation des zugehörigen Konfigrationseintrags in der Owncloud-Datenbank. Beispiel: Die Kalender-App wird mit dem SQL-StatementUPDATE oc_appconfig SET configvalue='no' WHERE configkey='enabled' AND appid='calendar';deaktiviert. Danach sollte die Owncloud wieder funktionieren, allerdings ohne die App.
• Oder man kehrt per Backup auf den vorigen Software-Stand zurück; so hat man zwar ein veraltetes System (und sollte prüfen, ob sich daraus Sicherheits-Lücken ergeben), aber die Owncloud samt Problem-App läuft wieder.

Aktualisierte Apps, die keinen „offiziellen“ Charakter haben, werden vom OCC-Upgrade-Tool nicht automatisch aktiviert – selbst wenn das Tool sie aktualisiert hat. Man muss also noch einmal selbst Hand anlegen und dieses Versäumnis als Administrator via Web-Browser App für App nachholen. Unter Administration > Apps > nicht aktiviert finden sich die schlummernden Anwendungen. Per Klick auf Aktivieren lassen sie sich wiederbeleben. Falls Owncloud zur Aktivierung einen weiteren Upgrade-Prozess durchführen will: bitte sehr. Den Hinweis, doch bitte Backups durchzuführen, kann man hier getrost ignorieren – wir haben das ja gerade erst für die komplette Installation samt Datenbank gemacht. Wenn alle nicht-offiziellen Backups ohne Kollateralschaden wiederbelebt sind, dann – endlich – ist das Owncloud-Upgrade gestemmt.

In jedem Fall sollte man die Mahnung der Owncloud-Entwickler beherzigen und jedes einzelne Upgrade einspielen, ohne auch nur eines auszulassen. Sollte dennoch einmal etwas richtig schiefgehen, lässt sich per Backup wieder der Zustand vor der misslungenen Upgrade-Prozedur herstellen:

$ rm -rf /var/www/owncloud
$ mv /var/www/owncloud8.2.1 /var/www/owncloud
$ mysql -uroot -p -e "DROP DATABASE owncloud"
$ mysql -uroot -p -e "CREATE DATABASE owncloud"
$ mysql -uroot -p owncloud < owncloud821.sql

Wichtig ist, dass sich neue und alte Dateien und Daten nicht vermischen. Deswegen wird bei einem Downgrade aus den Backups nicht nur das Installationsverzeichnis komplett von der Platte geputzt, bevor die alten Dateien per mv zurückgeschoben werden, sondern auch die Datenbank komplett geleert (wir machen das hier ganz unorthodox per DROP DATABASE und dann wieder CREATE DATABASE, weil es keine MySQL-Kommando DELETE ALL TABLES gibt), bevor die alte Version zurückgespielt wird. Wer das vergisst, hat seine Owncloud eigenhändig zerschossen und darf sich nicht bei den Owncloud-Entwicklern beschweren …