ownCloud Upgrade 8.0 auf 8.1

Lohnt sich ownCloud Upgrade auf 8.1?

  • Laut den Herstellern gibt es einige spannende Neuerungen in ownCloud 8.1.
  • Für mich war die versprochene Performance-Verbesserung ausschlaggebend.
    Die gibt es auch tatsächlich – 8.1 ist deutlich schneller!
  • Die verbesserte und integrierte Dokumentation ist gewiß auch ein guter Pluspunkt.
  • Was mir zunächst im Change-Log nicht auffiel waren die „Security Improvements“.
    Sie gibt es tatsächlich, und nicht wenige – doch dafür muss man meist noch am eigenen Server etwas dafür tun, bis OC 8.1 samt Cron-Job überhaupt läuft / ohne Fehler- und Meckermeldungen läuft. Hier lotse ich Sie durch die Turbulenzen.

Manuelles Update / Upgrade von ownCloud bei Ubuntu / Plesk

Mein ownCloud befindet sich auf einer Subdomain auf einem von Plesk verwalteten Ubuntu-Server. Daher kann ich die bevorzugte Upgrade-Methode mittels OpenSUSE Build Service nicht benutzen, da diese ganz andere Pfade vorsieht als Plesk verwendet. Daher beschreibe ich im Folgenden meine Erfahrungen mit dem manuellen Upgrade.

data-Verzeichnis außerhalb vom DocRoot der Website

Standardmäßig einschl. in 8.1 befindet sich das Verzeichnis „data“, unter dem alle hochgeladenen Dateien aller User liegen, direkt unter dem DocRoot. Dies wird aus zwei Gründen nicht empfohlen:

  • Sicherheit: Die Dateien sind somit grundätzlich (bei schlecht konfiguriertem WebServer) über das Internet erreichbar.
  • Upgrades: Liegt das data-Verzeichnis außerhalb der ownCloud-Website, so muss man während des Upgrades nichts damit machen, weil sein Pfad in der config.php steht und keine der Upgrade-Schritte es berühren.

Dafür muss das data-Verzeichnis für PHP erreichbar sein, sprich im open_basedir der php.ini enthalten sein. In Plesk empfiehlt sich daher:

  • open_basedir: {WEBSPACEROOT}{/}{:}{TMP}{/}{:}[etwaige local storage]

Früher hat es SabreDav gestört, wenn open_basedir nicht der Leerstring war. Ferner hieß es beim Versuch, external Storage vom Typ  „ownCloud / WebDAV“ einzuhängen:
CURLOPT_FOLLOWLOCATION cannot be activated when safe_mode is enabled or an open_basedir is set.

Aus diesem Grund hatte ich früher „Local external storage“ über ein Symlink unter dem DocRoot eingehängt und einen leeren open_basedir. Daher habe ich als erste Aktion dieser Update-Runde mein data-Verzeichnis zum WebRoot (neben dem DocRoot) umgesiedelt, und mein Local external storage in open_basedir aufgenommen und direkt angebunden.

Achtung: Wird Local Storage entfernt und unter dem gleichen Namen auf anderem Wege wieder angebunden, so finden ownCloud Clients, die diesen Bereich synchronisieren, ihn wieder – aber sie laden alle Dateien erneut vom Server herunter.

Update 8.0.3 nach 8.0.4

Ausführungen über den Unterschied zwischen Update und Upgrade finden Sie bei ownCloud und auch bei mir (wobei ich inzwischen keinen Hinweis mehr finde über diesen Unterschied in der ownCloud-Doku). Wie dem auch sei, das Updater-App, das man aus der Administration aufruft und das in einem neuen Tab geöffnet wird, hat mir nur das Update von 8.0.3 auf 8.0.4 angeboten, obwohl 8.1.0 schon erhältlich war.

Der in owncloud integrierter Updater lief durch. Er deaktivierte einige Apps, die einfach händisch wieder aktiviert werden konnten. Einmal kurz nach dem Update bekam ich ein zweites Mal den „Update durchführen“ Dialog, abgeschickt, OK, danach Ruhe.

ownCloud 8.0.4 lief ohne Auffälligkeiten, die Error-Logs blieben leer.

Upgrade 8.0.4 nach 8.1.0

  •  „review all third party applications“ (alle Apps prüfen, die keine Core-Apps sind)
    Hier ist eine Liste der Core Apps. Ich musste deaktivieren: calendar, contacts, documents, files move.
  • „Back up your existing ownCloud Server database, data directory, and config.php file“
    Ich habe ohnehin einen nächtlichen Sicherungslauf, der u.a. dies tut (händisch nochmal aufgerufen).
  • „Download and unpack the latest ownCloud Server release (Archive file) from owncloud.org/install/ into an empty directory outside of your current installation. For example, if your current ownCloud is installed in /var/www/owncloud/ you could create a new directory called /var/www/owncloud2/“
Neues Zip nach /var/www/vhosts/{WebRoot} hochladen
# cd /var/www/vhosts/{WebRoot}
# unzip owncloud-8.1.0.zip
# chown -R {webspace-user}:psacln owncloud
# chown {webspace-user}:psaserv owncloud
# chmod 750 owncloud
Ggf. # cp -p {owncloud-docroot-dir}/nginx.conf owncloud
# cp -p {owncloud-docroot-dir}/config/config.php owncloud/config
Ggf. # cp -p {owncloud-docroot-dir}/apc.php owncloud
Ggf. # cp -p {owncloud-docroot-dir}/ocp.php owncloud 
# diff owncloud/config/config.sample.php {owncloud-docroot-dir}/config/config.sample.php
  Es gibt neue Config-Möglichkeiten (aber nichts was in meinem Fall relevant wäre).
  • Maintenance mode einschalten:
    # cd {ownCloud DocRoot} ; sudo -u {ownCloud-User} /path/to/php occ maintenance:mode –on
  • Ggf. in ownCloud Admin externe Speicher notieren und lösen.
  • Ausloggen von owncloud.
  • Den Austausch durchziehen (hier mit Nginx als Webserver, setzen Sie ggf. stattdessen Apache ein):
# service nginx stop
# mv {owncloud-docroot-dir}owncloud.old
# mv owncloud {owncloud-docroot-dir}
# service nginx start
  • Mein erster Versuch mich im neuen ownCloud einzuloggen schlug fehl:
    Internal Server Error
  • Einfach nochmal probieren, mir wurde darauf hin das Update-Dialog angeboten.
    Achtung: Dies nur bei kleinen Installationen / Web-Pakete ohne SSH akzeptieren!
    Besser ist das Updaten an der Linux-Kommandozeile:
# cd /var/www/vhosts/{WebRoot}/{DocRoot}
# sudo -u {webspace-user} /path/to/php occ upgrade

Auf dieser Weise sieht man die Meldungen vom Upgrade-Prozess recht gut.
Bei mir lief das Upgrade problemlos durch alle seiner Schritte.

  • Als ownCloud-Admin einloggen, zum Admin-Bereich gehen.
  • PUH das wird immer schärfer mit den Anforderungen an die Umgebung! Hier die Meldungen aus dem Abschnitt „Security & setup warnings“ ganz oben auf der Admin-Seite:
    1. No memory cache has been configured. To enhance your performance please configure a memcache if available. Further information can be found in our documentation.
    2. /dev/urandom is not readable by PHP which is highly discouraged for security reasons.
    3. The „Strict-Transport-Security“ HTTP header is not configured to least „15768000“ seconds.
      For enhanced security we recommend enabling HSTS as described in our security tips.
  • Zu (1) Memory Cache
    Im Gegensatz zu 8.0 versucht 8.1 per Default kein Speicher-Cache zu verwenden, man muss es nun explizit configurieren: Add to config.php: ‚memcache.local‘ => ‚\OC\Memcache\APCu‘
    (die Verwendung von APCu war bereits in meinen Plesk PHP-Settings vorgesehen).
  • Zu (2) /dev/urandom
    Das Pseudo-Device ist in Ubuntu durchaus vorhanden und lesbar – aber da es als Filesystem-Pfad daherkommt, muss es auch in open_basedir aufgenommen werden:
    {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/dev/urandom{:}[etwaige local storage]
  • Zu (3) Strict-Transport-Security
    Diverse spezielle HTTP-Headers, welche der Erhöhung der Sicherheit gelten, sind nun in der mit ausgelieferten Apache .htaccess Dateien vorgesehen. Deren Vorhandsein wird von „Security & setup warnings“ geprüft. In der inzwischen üblichen Plesk-Setup mit Nginx vor Apache geht einer dieser neuen Headers unter, der muss in der Nginx-Config für ownCloud manuell ergänzt werden:
    add_header Strict-Transport-Security „max-age=15768000; includeSubDomains; preload;“;
    Die anderen Headers, die hinter obigem Link zu sehen sind, darf man bei Nginx + Apache NICHT in der Nginx-Config einsetzen, da Apache sie erzeugt – sonst sind ihre Werte doppelt vorhanden (verfälscht).

Damit hatte ich dann „Ruhe im Karton“. Es bleiben aber weitere Schritte zu tun:

  • „Go to the Apps page and review the core apps to make sure the right ones are enabled.“
    Upps: Nach Aktivierung des ersten non-core Apps (Calendar) konnten keine Apps mehr aktiviert werden. Gleiches Verhalten wie beim Update auf 8.0.4: Log out and perform „another“ Update to 8.1.0. Und wieder. Merd, some problem with Calendar and Contacts *now* being classed as experimental apps.
  • „Finally, re-enable your third-party apps.“
    „Files move“ ist inzwischen ein „approved 3rd-party app“, verfügbar im ownCloud-Backend direkt unter „Tool“. Sh*t: Every time I enable an App, the update procedure happens )-: Danach aber alles OK.
  • Ggf. externe Speicher wieder anbinden.
  • Last cron job execution: 1 hour ago. Something seems wrong.
    {„reqId“:“2U+aPkgLLiFtquYme99V“,“remoteAddr“:““,“app“:“cron“,“message“:“Missing memcache class \\OC\\Memcache\\APCu for local cache“
    Jetzt verlangt auch das CLI-Job (cron.php) die in config.php konfigurierte APCu-Erweiterung. Dazu habe ich die für ownCloud zu-nutzende Config-Werte für APCu in die Standard-PHP.ini aufgenommen und lade die zwei benötigten Erweiterungen explizit im CLI-Aufruf:
su -c "/path/to/php -dextension=igbinary.so -dextension=apcu.so -d apc.enable_cli=1 /path/to/{owncloud-DocRoot}/cron.php" -s /bin/sh {webspace-user}

Natürlich müssen Sie die Essenz obiger Fix in Ihren Cron-Job übernehmen.

  • Im owncloud.log: Undefined index: REQUEST_URI at …/apps/contacts/appinfo/app.php#35
    Das ist ein Bug, in GitHub schon behoben (Sie müssen ggf. die korrigierte Datei holen und auf Ihre Instanz manuell einspielen).

Viel Erfolg und Freude mit ownCloud 8.1 !

Kommentare (6) Schreibe einen Kommentar

  1. Schöner Erfahrungsbericht. Danke dafür. Ich bin bisher noch mit der 8.0 unterwegs, hab das Upgrade für diesen Monat eingeplant. Ich sollte mir wohl mehr als eine Stunde dafür einplanen.

    Wie sind denn jetzt die Erfahrungen mit der Performance? Was heißt deutlich schneller?

    Antworten

    • Bitte schön. Ich habe keine Messungen vorgenommen, „schneller“ ist somit streng genommen „nur“ ein subjektiver Eindruck. Bis auf folgende Beobachtung: Ich nutze Plesk mit dem Server Health-Monitoring. Vor der Umstellung gab es Meckereien wegen der Serverauslastung, die waren nach der Umstellung weg. Also 8.1 belastet den Server insgesamt spürbar weniger – was meistens auch eine schnellere Antwortzeit impliziert.

      Antworten

  2. Sehr schöne und Informative Dokumentation.
    Besonders der Abschnitt „Zu (2) /dev/urandom“ hat mir sehr weitergeholfen.
    Vielen Dank dafür!

    Antworten

  3. Hallo Tim Reeves,
    herzlichen Dank für die Information, habe die Änderung /dev/urandom eingetragen, aber der Fortschritts-Rad bei Sicherheits- & Einrichtungswarnungen läuft und es tut sich nichts. Mein Problem ist gut in dem Thema:
    https://forum.owncloud.org/viewtopic.php?f=38&t=34840 beschrieben. Nur mode_php kann ich nicht setzen (wird im Plesk nicht angeboten).
    Vielleicht haben Sie doch noch eine andere Idee.

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Mensch - gib die Ziffern ein! *