Quantcast
Channel: Wel!s Blog » QNAP
Viewing all articles
Browse latest Browse all 4

QNAP – ownCloud 4.5 auf Version 5 updaten

$
0
0

ownCloud 5 ist erschienen, leider nicht als Update sondern als eigenständige Version. Da ich es bereits auf einem Raspberry PI getestet habe und einige Features nun besser funktionieren, habe ich dann mal ein “Update” von Hand durchgeführt.

Das nachfolgende Tutorial basiert auf einer Installation von ownCloud 4.5 wie sie unter “Die eigene Wolke – ownCloud auf QNAP NAS” beschrieben ist.

Für alle die ownCloud mit “Unix user backend” betreiben, es ist nicht mehr verfügbar, da es gerade überarbeitet wird. Entweder auf LDAP umstellen oder warten bis es wieder verfügbar ist.

Für diejenigen, die ownCloud noch nicht installiert haben, einfach die Sicherheitskopie überspringen, nichts löschen und ganz wichtig, überall wo “ownCloud” eingegeben werden soll “owncloud” eingeben.

Installation vorbereiten

Zuerst ein Backup der aktuelle Installation erstellen:

[~] # cd /share/Download
[/share/Download] # tar cfvz owncloud-web.tar.gz /share/Web/owncloud 
[/share/Download] # tar cfvz owncloud-data.tar.gz /share/HDA_DATA/owncloud

Danach ownCloud aufrufen und in der Administrationsseite die ownCloud Instanz exportieren (Dateien und Datenbank):

owncoud-export

Zur Sicherheit kann zusätzlich Die Datenbank in phpMyAdmin nochmals exportiert werden. Ich habe zwar keine der Sicherheitskopien benötigt, aber man weiss ja nie.

Ist alles exportiert phpMyAdmin aufrufen und des Datenbank User “oc_admin” löschen:

phpmyadmin-del-admin

Als nächstes ownCloud in der Version 5 laden:

[/share/Download] # wget http://download.owncloud.org/community/owncloud-5.0.0.tar.bz2

Die geladene Datei entpacken:

[/share/Download] # tar -xjvf owncloud-5.0.0.tar.bz2

Damit wir die Installation zu jederzeit abbrechen können legen wird die neue Installation mit ownCloud an. Groß-Kleinschreibung beachten das “C” in ownCloud muss groß sein, da ansonsten das alte ownCloud Verzeichnis überschrieben wird:

[/share/Download] # mv owncloud /share/Web/ownCloud

In das QNAP Daten Verzeichnis wechseln:

[/share/Download] # cd /share/Web

Die Rechte sollten rekursiv dem Administrator gehören:

[/share/Web] # chown -R admin:administrators ownCloud

Für die Verzeichnisse apps und config gilt dies nicht, hier benötigen wir schreibrechte für Apache:

[/share/Web] # chown -R httpdusr ownCloud/apps 
[/share/Web] # chown -R httpdusr ownCloud/config

Als Datenverzeichnis für ownCloud verwenden wir das bereits existierende in “/share/HDA_DATA/owncloud”.

Installation durchführen

Für die eigentliche Installation muss ownCloud in einem Web-Browser aufgerufen werden:

  • https://my-qnap:8081/ownCloud/

Im Moment ist es ja eine Neu Installation, das heißt alle Daten müssen neu eingegeben werden! Hierbei ist zu beachten, dass die Benutzerangaben identisch, zur Installation der Version 4.5 sein müssen. Der Datenbankname muss allerdings anders lauten, z.B. ownCloud.

oncloud5_01

 

Nach drücken der Schaltfläche Finish setup, wurde bei mir erst einmal eine leere weiße Seite angezeigt. Sollte das passieren, etwas warten und die Seite aktualisieren. Dann wird die folgende Seite angezeigt:

oncloud5_02

Den Begrüßungsbildschirm mit dem X schließen. Wir sehen die schöne neue Oberfläche von ownCloud. Neben kleineren Icons ist das Menü für die erweiterten Einstellungen von unten links nach oben rechts gewandert.

Ruft man nun die Administrationsseite auf, stellt man fest das nirgends ein Möglichkeit existiert die oben exportierten Daten wieder in ownCloud zu importieren. Obwohl das Plugin “ownCloud Instance Migration” aktiv ist und in der Beschreibung stehet “Import/Export your owncloud instance”, findet man nur die Möglichkeit die Instanz zu exportieren. Entweder haben die beiden Autoren sich da vertippt, den Button vergessen oder was mir wahrscheinlicher erscheint, der Import hat nicht funktioniert und sie haben es wieder entfernt. Hilft nun auch nicht, muss das Update eben von Hand durchgeführt werden.

Einbinden der Benutzerkonten

Wie oben bereits erwähnt, existiert das Plugin “Unix user backend” zur Zeit nicht. Ich verwende daher die LDAP Authentifizierung. Es gibt noch eine weitere Möglichkeit, die  Authentifizierung über das Plugin “WebDAV user backend” durchzuführen. Jedoch läuft das Ganze über HTTP. Benutzername und Passwort wird also im Klartext übertragen. Außerdem dürfen beide Plugins nicht gleichzeitig aktiviert sein.

Sofern der LDAP-Server noch nicht aktiviert, die Administrationsseite des QNAPs aufrufen:

  • Unter Anwendungen → LDAP Die Konfigurationsseite öffnen.
  • Den Haken bei LDAP-Server aktivieren setzen.
  • Den Vollständigen Domänenname eingeben:
    Angenommen der Hostname des QNAPS ist “my-qnap”, dann lautet der vollständige Name “my-qnap.local”. Hinter einer FritzBox kann er auch “my-qnap.fritz.box” lauten. Der Befehl 
    nslookup my-qnap
     sollte die notwendigen Informationen Anzeigen.
  • LDAP Kennword und Kennwort prüfen eingeben.
  • Mit Übernehmen alles speichern.
  • Ist alles gespeichert, den Link Domain-Sicherheit drücken.
  • Unter Domain-Sicherheit für Dateidienste, den Punkt LDAP-Authentifizierung aktivieren.
  • Als Typ des LDAP-Servers den Eintrag LDAP Server des lokalen NAS wählen.

Der LDAP Server ist nun konfiguriert, jedoch sind alle Benutzer lokale Benutzer, wir benötigen sie aber als LDAP Benutzer. Eine Funktion lokale Benutzer in LDAP Benutzer zu überführen existiert leider nicht. Daher müssen alle lokalen Benutzer erneut angelegt werden.

  • Die QNAP Administrationsseite aufrufen und Anwendungen → LDAP wählen.
  • Den Reite Benutzer wählen.
  • Die Schaltfläche Einen-benutzer-erstellen drücken:
    • Den existierenden Benutzername eingeben.
    • Ein beliebiges Kennwort eingeben.
    • Das gleiche Password bei Kennwort prüfen eingeben.
    • Den vollständigen Namen des Benutzers bei Beschreibung eingeben.
    • Die eMail Adresse des Benutzers angeben.
    • Eine Benachrichtigungs-eMail an den neu erstellten Benutzer senden aktivieren.
    • Die Schaltfläche Weiter drücken.
    • Die Option Benutzer muss das Kennwort bei der ersten Anmeldung ändern aktivieren.
    • Die Schaltfläche Weiter drücken.
    • Die Schaltfläche Weiter drücken.
    • Die Schaltfläche Erstellen drücken.
  • Den Vorgang wiederholen, bis alle lokalen Benutzer in LDAP Benutzer überführt wurden.

Die Benutze sind zwar nun doppelt angelegt, einmal als LDAP und einmal lokal, die LDAP Benutzer behalten aber den Zugriff auf die bereits getroffenen Einstellungen ihres lokalen Accounts. Nur das Passwort ist neu und muss, beim ersten anmelden, geändert werden. Ein neuer Benutzer sollte in Zukunft direkt als LDAP Benutzer, unter Zugriffskontrolle → Benutzer → Domänenbenutzer, erstellt werden.

Zu ownCloud als Administrator wechseln und die Seite  admin → Apps aufrufen. Das Plugin LDAP user and group backend wählen und auf Enable Klicken. Danach über admin → Admin die Administrationsseite aufrufen und die LDAP Einstellungen festlegen.

  • Basis Einstellungen (für my-qnap.local):
    • Host: my-qnap.local
    • Base DN: ou=people,dc=my-qnap,dc=local
    • User DN: cn=admin,dc=my-qnap,dc=local
    • Password: Das LDAP Passwort
    • User Login Filter: uid=%uid
    • User List Filter: objectClass=person
    • Group Filter: objectClass=posixGroup
  • Erweiterten Einstellungen:
    • Connection Settings:
      • Configuration Active: aktiviert
      • Port: 389
      • Backup (Replica) Host: leer 
      • Backup (Replica) Port: 389
      • Disable Main Server: inaktiv
      • Use TLS: aktiviert
      • Case insensitve LDAP server: inaktiv
      • Turn off SSL certificate validation: inaktiv
    • Cache Time-To-Live: 600
      • Directory Settings:
      • User Display Name Field: displayname
      • Base User Tree: ou=people,dc=knuts-qnap,dc=fritz,dc=box
      • User Search Attributes:
        • displayName
        • mail
      • Group Display Name Field: cn
      • Base Group Tree: ou=people,dc=knuts-qnap,dc=fritz,dc=box
      • Group Search Attributes: cn
      • Group-Member association: uniqueMember
    • Special Attributes
      • Quota Field: leer
      • Quota Default: leer
      • Email Field: mail
      • User Home Folder Naming Rule: leer

Die Schaltfläche Test Configuration betätigen, wenn alles richtig eingestellt ist erscheint: “The configuration is valid and the connection could be established!”. Dann auf Save drücken um alles zu speichern.

Über admin → Users kann man sich nun die Benutzer anzeigen lasse. Der Login Name sieht hier etwas seltsam aus, ist auch eigentlich nicht dieser, sonder es handelt sich um die ID. Der eigentliche Name mit dem sich der Benutzer später anmeldet ist der Display Name. Allerdings ist der Login Name der Name, unter dem später das Benutzerverzeichnis auf  erstellt wird. Das bedeutet, die einzelnen Daten sind erst einmal verloren, man muss die Verzeichnisse entsprechend zu dem Login Name umbenenne.

Wer das wieder veröffentlichte Plugin “Unix user backend” verwenden möchte, muss dieses manuell Hinzufügen. Das Archiv laden und in das Verzeichnis “owncloud/apps/” extrahieren. Danach das Plugin aktivieren und zur Administrationsseite gehen um die Einstellungen festzulegen:

  • Path of the pwauth executable: /usr/local/apache/bin/pwauth
  • List of authorized UIDs: 500-XXX
    XXX entspricht der UID des letzten Benutzer bei 10 Benutzern ist dies vermutlich 510. Man kann sich dies durch
    cat /etc/passwd
      anzeigen lassen.

Einbinden der Mountignpoints

Das Plugin über admin → AppsExternal storage support → Enable aktivieren. Danach die alte Konfiguration der Mountpoints in die neue ownCloud Installation kopieren und die Rechte anpassen:

[/share/Web] # cp owncloud/config/mount.php ownCloud/config/
[/share/Web] # chown httpdusr:everyone ownCloud/config/mount.php

Anschließend wieder zur Administrationsseite gehen. Die alten Verzeichnisse sollten nun vorhanden sein und, ein neues Feature, wenn die Einbindung funktioniert ist ein grüner Punkt vorangestellt. Leuchtet er rot, funktioniert die Einbindung nicht.

owncloud5-mounts

Installation abschließen

Zum Abschließen der Installation muss der Zugriff auf ownCloud wiederhergestellt werden. Alle Clients greifen zur Zeit auf “owncloud” zu, müssten aber nun auf “ownCloud” zugreifen. Entweder ändert man nun alle Clients oder den Zugriff auf dem Server.

Auf dem Server stehen drei Möglichkeiten zur Verfügung, zuerst löschen wir aber das alte der Installation 4.5:

[/share/Web] # rm -r owncloud

Nun die verschiedenen Möglichkeiten:

  1. Eine Apache Konfigurationsdatei erstellen,
    [/] # nano /etc/config/apache/apache-owncloud.conf

    und den folgenden Inhalt hinein kopieren:
    Alias /owncloud "/share/Web/ownCloud"
    
    <Directory /share/Web/ownCloud>
            Options FollowSymLinks
            SSLRequireSSL
            Options Indexes FollowSymLinks MultiViews
            AllowOverride All
            Order allow,deny
            allow from all
    </Directory>

    Dann den folgenden Eintrag, am Ende, in der Datei “/etc/config/apache/apache.conf” hinzufügen:
    Include /etc/config/apache/apache-owncloud.conf

    Mit dem Befehl
    /etc/init.d/Qthttpd.sh restart
     Apache neu starten.
  2. Das Verzeichnis umbenennen:
    [/share/Web] # mv ownCloud owncloud

    Danach die neue owncloud Verzeichnis wechseln und .htacess Datei öffnen. Dort die beiden markierten Zeilen ändern:
    <IfModule mod_fcgid.c>
    <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
    SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
    RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
    </IfModule>
    </IfModule>
    ErrorDocument 403 /ownCloud/core/templates/403.php
    ErrorDocument 404 /ownCloud/core/templates/404.php
    <IfModule mod_php5.c>
    php_value upload_max_filesize 512M
    php_value post_max_size 512M
    php_value memory_limit 512M
    <IfModule env_module>
      SetEnv htaccessWorking true
    </IfModule>
    </IfModule>
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteRule ^.well-known/host-meta /public.php?service=host-meta [QSA,L]
    RewriteRule ^.well-known/carddav /remote.php/carddav/ [R]
    RewriteRule ^.well-known/caldav /remote.php/caldav/ [R]
    RewriteRule ^apps/([^/]*)/(.*\.(css|php))$ index.php?app=$1&getfile=$2 [QSA,L]
    RewriteRule ^remote/(.*) remote.php [QSA,L]
    </IfModule>
    <IfModule mod_mime.c>
    AddType image/svg+xml svg svgz
    AddEncoding gzip svgz
    </IfModule>
    Options -Indexes

    Das sind die Beiden einzigen Pfadangaben die ich gefunden habe.
  3. Ein symbolischer Link:
    [/share/Web] # ln -s ownCloud owncloud

    Vermutlich die einfachste Lösung. Kam ich aber erst drauf, als ich für Lösung 2 die Pfade gesucht habe.

Nun ist ownCloud wieder Funktionsbereit.

Fazit

Stellt sich nun die Frage, lohnt der Aufwand oder lieber gleich eine komplette Neuinstallation, ohne die Daten zu migrieren?

Das kommt einfach drauf an wie viele  Benutzer auf dem System vorhanden sind und wie Groß der Umfang deren Daten ist. Muss also jeder für sich entscheiden.

Eines kann ich aber sagen, wenn nur die Client Sync Verzeichnisse verwendet werden, kann getrost auf die Datenmigration verzichtet werden. Die Aktualisierung nimmt jeder Benutzer automatisch vor.

Lohnt der Umstieg überhaupt? Was ist neu, besser oder schneller?

  • Das Design ist neu, sieht etwas professioneller aus, ist aber subjektiv und bestimmt kein Grund für ein Update.
  • Viele Apps sind nicht mehr verfügbar – irgendwie auch kein Grund. Wobei die guten wohl im laufe der Zeit aktualisiert werden, so dass sich auch mit Version 5 funktionieren.
  • Was sich geändert hat, die Verzeichnisse werden im Hintergrund gescannt. Ich hatte ursprünglich mal den Ordner Music aus Multimedia global eingebunden. Dieser Ordner enthält über tausend Dateien. Da bei jedem Anmelden dieses Verzeichnis durchsucht wurde, brauchte ich mehrere Minuten bis ich drin war. Ist mit Version 5 kein Problem mehr. 
  • Allerdings finde ich die gesamt Performance schlechter. Ich bin mir jedoch nicht sicher ob das an Version 5 liegt, oder am QNAP. Nicht an der Hardware des QNAPs sondern an dessen Linux.
    Bevor ich die neue Version auf dem QNAP installierte, habe ich sie auf einem Raspberry PI getestet und dort lief alles schneller. Vielleicht doch wieder Debian auf dem QNAP installieren.
  • Das einbinden von Verzeichnissen über WebDAV und FTP funktioniert immer noch nicht. Liegt aber am QNAP, denn auf dem PI hat es funktioniert.

Letztlich ist das ganze eine Spielerei gewesen. Wer kein Spaß daran hat, sich unnötige Arbeit zu machen sollte wohl besser bei Version 4.5 bleiben.


Viewing all articles
Browse latest Browse all 4

Trending Articles