Hinweis: Dieser Artikel behandelt die Einrichtung von ownCloud 8 unter Ubuntu Server 15.10. Es gibt einen Nachfolge-Artikel, der die Installation von ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt beschreibt.
Cloud-Dienste sind eine nützliche Sache: Dateien, Termine oder Kontakte können mittels der Cloud über mehrere Geräte synchronisiert werden – vom Desktop-Rechner bis hin zum Smartphone. Dienste wie DropBox, OneDrive und Co. sind dabei allerdings keine Option für Leute, die hohen Wert auf Privatsphäre legen und ihre Daten Dritten gegenüber nicht preisgeben wollen. Wer dennoch nicht auf die Bequemlichkeit von Cloud-Diensten verzichten möchte, für den stellt die Open-Source-Lösung ownCloud eine echte Alternative dar – die Cloud zum Selberbasteln.
Dieser Artikel zeigt die Einrichtung von ownCloud auf Ubuntu Server mittels nginx, MariaDB und PHP.
Auch wenn für die Installation und Konfiguration viele einzelne Schritte notwendig sind, habe ich mich dabei bemüht, immer auch ein wenig Hintergrundinformationen in den Artikel mit einfließen zu lassen, so dass auch ein Linux-Neuling nicht überfordert sein sollte.
Der Beitrag ist daher recht umfangreich, allerdings findet man am Ende des Artikels eine Checkliste zum Download, in der noch einmal sämtliche Schritte zusammengefasst sind, die für die Installation von ownCloud notwendig sind.
Update 28.11.2015: Der Artikel wurde komplett überarbeitet, so dass nun die aktuellsten Programmversionen zum Einsatz kommen und ebenfalls die damit verbundenen Änderungen erläutert werden. Dies betrifft v.a. die Einrichtung von Redis für das Transactional File Locking von ownCloud.
Update 24.12.2015: Hinweis auf Let’s Encrypt zur Erzeugung von SSL-/TLS-Zertifikaten hinzugefügt. Die Notwendigkeit, selbst signierte Zertifikate zu verwenden, ist somit nicht mehr gegeben. Die Anleitung zum erzeugen von selbst signierten Zertifikaten wurde dennoch nicht aus dem Artikel entfernt, falls Let’s Encrypt nicht zum Einsatz kommen soll.
Update 20.05.2016: Hinweis auf den neuen Artikel (ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt) hinzugefügt.
Zielsetzung
Der Artikel wurde mit folgender Zielsetzung geschrieben:
- Installation von ownCloud unter Linux (Ubuntu Server 15.10) mit nginx, MariaDB und PHP
- Erhöhte Sicherheit (PHP-Konfiguration, SSL, ownCloud-Konfiguration laut ownCloud Server Administration Manual)
- Verschlüsselte Verbindung zur ownCloud über das lokale Netzwerk als auch über das Internet (DynDNS)
- ownCloud soll in einem Unterverzeichnis des Webservers liegen, d.h. nicht über myserver.dyndns.org, sondern über myserver.dyndns.org/owncloud erreichbar sein. Dies macht es möglich, dass mehrere Webseiten über die gleiche Domain gehostet werden können.
- Im Administrator-Bereich von ownCloud sollen keine Warnungen angezeigt werden
Alle Schritte sind mit folgenden Programmversionen getestet. Da die Entwicklung von ownCloud noch im Fluss ist, kann es passieren, dass einige Schritte des Tutorials angepasst werden müssen, wenn andere Programmversionen zum Einsatz kommen.
- Ubuntu 15.10 („Wily Werewolf“)
- nginx 1.9.7
- MariaDB 10.0.22
- PHP 5.6.11
- ownCloud 8.2.1
Exkurs: Der LEMP Stack: Linux, nginx, MySQL/MariaDB, PHP
Manch einer wird sich nun fragen, warum dieser Artikel so umfangreich ist. Dies liegt darin begründet, dass ich zur Installation nicht auf die offiziellen ownCloud-Pakete zurück greife, da hier immer automatisch Apache und MySQL neben ownCloud selbst installiert werden. Ich wähle hier einen anderen Weg…
Lange Zeit galt der sog. LAMP Stack (Linux, Apache, MySQL und PHP) als Standard, wenn es darum ging, dynamische Webseiten zu hosten.
Dieser Artikel zeigt jedoch die Installation und Einrichtung von ownCloud auf einem LEMP Stack: Linux als Betriebssystem (in diesem Fall Ubuntu Server), nginx (sprich: Engine-X) als Webserver, MariaDB als Datenbank und PHP als Skriptsprache für dynamische Inhalte.
Durch die Verwendung dieser alternativen Programme ist daher einiges an Handarbeit notwendig, weil vieles manuell installiert und konfiguriert werden muss. Jedoch bietet der Einsatz von nginx und MariaDB handfeste Vorteile:
- nginx arbeitet generell ressourcenschonender als Apache. Dies liegt z.T. darin begründet, dass Apache bei neuen Verbindungen neue Prozesse bzw. Threads erzeugt, um diese Connections abzuarbeiten. Dies ist besonders bei vielen gleichzeitigen Verbindungen sehr speicherintensiv. nginx hingegen arbeitet mit einer konfigurierbaren Anzahl an Threads, die sämtliche Verbindungen asynchron bearbeiten.
Somit ist nginx deutlich im Vorteil, wenn viele gleichzeitige Verbindungen bestehen (was bei einer private gehosteten Cloud-Umgebung weniger oft der Falls ein dürfte) oder die Hardware-Ressourcen begrenzt sind, was beispielsweise bei einem Raspberry Pi der Fall ist. - MariaDB ging aus einem Fork von MySQL hervor. Nach der Übernahme von MySQL durch Sun bzw. Oracle dauert es mitunter sehr lange, bis Änderungen oder Patches in die MySQL-Pakete übernommen werden. Außerdem ist unklar, wie Oracle die Entwicklung von MySQL in Zukunft vorantreiben wird.
MariaDB ist dabei ein 1:1-Ersatz für MySQL (sog. drop-in replacement), d.h. sämtliche von MySQL bekannten Befehle, Schnittstellen und Tools sind auch unter MariaDB verwendbar.
Seit Ende 2012 haben etliche Linux-Distributionen MySQL durch MariaDB als Standard-Datenbanksystem ersetzt. MariaDB macht momentan einen sehr zukunftssicheren Eindruck, daher fiel die Wahl auf MariaDB als Datenbanksystem. Da MariaDB ein 1:1-Ersatz für MySQL ist, kann man natürlich auch MySQL verwenden. Die Schritte zur Einrichtung von ownCloud sind im Grunde genommen dieselben.
Voraussetzungen
Betriebssystem/Hardware
Der Artikel beschreibt die Einrichtung von ownCloud auf einem neu installiertem Ubuntu Server 15.10 („Wily Werewolf“). Für einen eigenen Home-Server bietet sich v.a. die Verwendung einer LTS-Version (Long Term Support) von Ubuntu an. Zum Zeitpunkt als der Artikel verfasst wurde, war dies 14.04 („Trusty Tahr“). Allerdings habe ich mich aus zwei Gründen hier bewusst für die Version 15.10 (nicht LTS) entschieden:
- Bessere Unterstützung durch Hyper-V: Ich verwende für den Artikel eine virtuelle Maschine unter Windows Server 2012 R2 mit Hyper-V (die Installation von Ubuntu Server mit den Besonderheiten bzgl. Hyper-V beschreibt der Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten). Laut Microsoft (siehe TechNet-Artikel) werden mehr Hyper-V Features unter Ubuntu 15.04 unterstützt, als noch mit 14.04.
- Aktualisierte Pakete unter 15.10: Einige Pakete (wie beispielsweise php5-apcu) liegen unter Ubuntu 14.04 noch in älteren Versionen vor, die nicht voll mit ownCloud kompatibel sind. Dies führt meist zu Warnungen im Administrator-Bereich von ownCloud oder verminderter Performance. Einzige Lösung wäre hier, die aktuellste Programmversion manuell zu kompilieren und einzubinden.
Generell ist die eingesetzte Linux-Distribution allerdings unerheblich. Die Installation von ownCloud und den benötigten Komponenten funktioniert auf anderen Distributionen identisch.
Auch die verwendete Server-Hardware spielt im Wesentlichen keine Rolle. Alle Schritte des Artikels können auch angewendet werden, wenn beispielsweise ein Raspberry Pi (Affiliate Link) mit Raspbian als Betriebssystem oder ein Intel NUC (Affiliate Link) mit Debian zum Einsatz kommt.
Zugriff per SSH
Für die Installation und Einrichtung des Linux-Servers empfiehlt sich der Zugriff per SSH (z.B. mit PuTTY). Eine genauere Beschreibung hierzu findet mal ebenfalls im Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten.
DynDNS
Damit die ownCloud-Installation später auch über das Internet verfügbar ist, muss der Router per DynDNS zu erreichen sein. Ohne DynDNS ändert sich in den meisten Fällen die (externe) IP des Routers nach einer Zwangstrennung (in der Regel alle 24 Stunden). Es gibt hier eine große Auswahl an DynDNS-Anbietern – sowohl kostenlose, als auch Anbieter, die sich ihren Dienst bezahlen lassen.
Im Rahmen dieses Artikels gehe ich davon aus, dass die URL, unter der ownCloud später erreichbar sein soll myserver.dyndns.org/owncloud lautet. Zu beachten ist hier, dass ownCloud in einem Unterverzeichnis liegt (/owncloud). Dazu später mehr.
Arbeiten mit Root-Rechten
Bevor es losgeht noch ein letzter Hinweis: So gut wie alle nachfolgend aufgeführten Befehle erfordern Root-Rechte. Damit nicht vor jedem Befehl ein sudo eingegeben werden muss, arbeite ich bei der Einrichtung des Rechners mit dauerhaften Root-Rechten. Diese erlangt man über den Befehl:
sudo -s
Am Ende sollte man sich dann mit exit wieder abmelden. Ein dauerhaftes Arbeiten mit Root-Rechten ist aus Gründen der Sicherheit nicht empfohlen.
Nun kann es aber losgehen…
Updates einspielen
Zunächst einmal bringen wir den Recher auf den neusten Stand und starten ihn anschließend neu:
apt-get update apt-get upgrade -V reboot
Hinweis zum Parameter -V bei apt-get upgrade: Mittels dieses Parameters werden zusätzliche Versions-Informationen über die installierten Pakete und die zur Verfügung stehenden Updates angezeigt. Dieser Parameter ist eigentlich immer empfehlenswert, besonders wenn man ein bereits laufendes System aktualisieren möchte. Hier sollte man immer genau darauf achten, was bei einem Upgrade passiert.
Statische IP-Adresse zuweisen
Mit einem frisch installierten Linux bekommt der Rechner in den meisten Fällen durch den Router eine dynamische IP per DHCP. Für den vereinfachten Zugriff empfiehlt es sich jedoch, eine statische IP-Adresse zu verwenden. Dazu muss folgende Konfigurations-Datei bearbeitet werden:
nano /etc/network/interfaces
Hier sind alle Netzwerkkarten aufgelistet. eth0 ist dabei die primäre Netzwerkkarte. Hier passen wird den Eintrag entsprechend an. In diesem Beispiel gehe ich davon aus, dass der verwendete Router die IP 192.168.178.1 hat und der Linux-Rechner die statische IP 192.168.178.20 haben soll.
auto eth0 iface eth0 inet static address 192.168.178.20 netmask 255.255.255.0 network 192.168.178.0 broadcast 192.168.178.255 gateway 192.168.178.1 dns-nameservers 192.168.178.1
Nach einem Neustart des Rechners ist dieser fortan immer unter der IP 192.168.178.20 zu erreichen.
Programm-Installation
Bevor ownCloud installiert werden kann, muss zunächst einmal der Webserver, MariaDB und PHP installiert werden.
nginx installieren
In den Paketquellen von Ubuntu 15.10 ist noch die recht alte Version 1.9.3 von nginx vorhanden. Um eine aktuellere Version installieren zu können, muss das nginx-Repository direkt in die Paketquellen aufgenommen werden.
Dazu muss zunächst einmal der Schlüssel des nginx-Repositories im System bekannt gemacht werden. Ohne diesen Befehl werden bei der Installation der aktuellen nginx-Version Warnungen angezeigt.
wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -
Anschließend werden die Paketquellen hinzugefügt:
nano /etc/apt/sources.list
Wir ergänzen die Datei am Ende mit:
# Nginx (Mainline) deb http://nginx.org/packages/mainline/ubuntu/ wily nginx deb-src http://nginx.org/packages/mainline/ubuntu/ wily nginx
Hinweis: Ich nehme hier die Mainline-Version von nginx. Diese stellt den aktuellen Entwicklungszweig dar und gilt als stabil. Es gibt darüber hinaus noch den Stable-Entwicklungszweig. Wie der Name zwar vermuten lässt, ist dieser Zweig allerdings nicht unbedingt stabiler als der Mainline-Zweig, sondern nur Feature-Stable. Konkret bedeutet dies, dass hier keine neuen Features mehr implementiert werden und auch nur noch wichtige Bugfixes nachgeliefert werden – siehe nginx-Blogbeitrag (How Branch Renumbering Works). Ein anderer Beitrag aus dem nginx-Blog empfiehlt explizit die Verwendung des Mainline-Zweigs.
Nach dem Hinzufügen der Paketquellen folgt die eigentliche Installation von nginx:
apt-get update apt-get install nginx
Die Installation des Webservers kann getestet werden, indem man die IP des Rechners im Browser aufruft:

MariaDB installieren
Für die aktuelle Version von MariaDB ist ein ähnliches Vorgehen wie schon bei nginx empfehlenswert. Die MariaDB-Homepage liefert dazu ein praktisches Repository Configuration Tool. Hier die notwendigen Schritte:
Zunächst fügen wir den Key-Server für MariaDB hinzu:
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
Dann werden die Paketquellen hinzugefügt:
nano /etc/apt/sources.list
Folgende Zeilen fügen wir am Ende der Datei hinzu:
# MariaDB 10.0 repository list - created 2015-09-15 15:17 UTC # http://mariadb.org/mariadb/repositories/ deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.0/ubuntu wily main deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.0/ubuntu wily main
Nun kann die Datenbank installiert werden:
apt-get update apt-get install mariadb-server
Während der Installation wird man dazu aufgefordert, ein Passwort für den Root-Zugriff anzugeben. Man sollte diesen Schritt nicht überspringen und ein ausreichend sicheres Passwort wählen:

PHP installieren
Bevor nun ownCloud installiert werden kann, muss noch die Installation von PHP mit allen für ownCloud benötigten Paketen durchgeführt werden. Die ownCloud-Dokumentation listet dafür alle benötigten Pakete auf. Einige dieser Pakete werden nur benötigt, wenn spezielle Features von ownCloud zum Einsatz kommen sollen.
Für den Anfang reicht die Installation folgender Pakete für PHP:
apt-get update apt-get install php5-fpm php5-gd php5-json php5-mysql php5-curl php5-intl php5-mcrypt php5-imagick php5-apcu
Wenn später weitere Pakete benötigt werden, können diese jederzeit nachinstalliert werden.
Konfiguration des Servers
Nach der Installation der benötigten Programme werden diese anschließend konfiguriert.
SSL-Zertifikat
Bevor die Konfiguration von nginx angegangen wird, sollte zunächst einmal ein SSL-Zertifikat generiert werden: Die ownCloud-Instanz soll später per HTTPS erreichbar sein, damit sämtliche Datenübertragungen verschlüsselt ablaufen. Dazu wird ein SSL-Zertifikat benötigt. Dies kann man über eine Zertifizierungsstelle anfordern (die meisten Webhoster bieten ebenso SSL-Zertifikate an). Allerdings werden hier z.T. sehr hohe Preise verlangt.
SSL-Zertifikat generieren (Let’s Encrypt)
Seit Anfang Dezember ist allerdings das Projekt Let’s Encrypt in der öffentlichen Beta-Phase. Mit Hilfe dieses Programms (dem sog. Client) ist es nun einfach möglich, SSL-/TLS-Zertifikate zu erzeugen. Der goße Vorteil an diesen Zertifikaten ist, dass alle gängigen Browser diese als vertrauenswürdig einstufen. Damit entfällt die Notwendigkeit, ein selbst signiertes Zertifikat auf dem Client-Rechner/Mobilgerät installieren zu müssen, damit keine für den Benutzer abschreckende Warnung beim Zugriff auf die ownCloud angezeigt wird.
Wie Zertifikate über Let’s Encrypt erzeugt und in nginx eingebunden werden können, habe ich in einem weiteren Artikel detailliert beschrieben: HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx. Im Folgenden gehe ich davon aus, dass ein Zertifikat verwendet wird, welches über Let’s Encrypt erzeugt wurde.
Hinweis: Im Rahmen dieser Anleitung gehe ich immer von der Verwendung einer DynDNS-Domain aus. Beim Einsatz von Let’s Encrypt zur Erstellung eigener Zertifikate kann es bei DynDNS-Domains zu Problemen kommen, wenn bereits zu viele Leute Zertifikate für die spezielle DynDNS-Second-Level-Domain erzeugt haben. Eine genauere Beschreibung der Problematik und ein eleganter Lösungsansatz ist im Artikel HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx zu finden.
Nach der Erzeugung der Zertifikate liegen die dazugehörigen Dateien in folgendem Verzeichnis: /etc/letsencrypt/live/myserver.dyndns.org
- cert.pem: Das öffentliche Zertifikat in Reinform
- chain.pem: Öffentliches Zertifikat aus der sog. Keychain
- fullchain.pem: entspricht cert.pem + chain.pem
- privkey.pem: Privates Zertifikat
Selbst signiertes Zertifikat erstellen
Der Vollständigkeit halber, hier noch die Vorgehensweise, wenn doch ein selbst signiertes Zertifikat zum Einsatz kommen soll. Wer sich die Zertifikate über Let’s Encrypt erzeugt hat, kann den folgenden Abschnitt überspringen.
Zunächst erzeugen wir ein Verzeichnis, welches die SSL-Zertifikate beinhaltet, die nginx verwenden soll:
mkdir -p /etc/nginx/ssl
Anschließend wird das SSL-Zertifikat über folgenden Befehl generiert.
openssl req -new -x509 -days 365 -nodes -out /etc/nginx/ssl/certificate.crt -keyout /etc/nginx/ssl/certificate.key
Man wird dann dazu aufgefordert, einige Angaben (z.B. zum Standort) zu machen. Prinzipiell ist es hier nicht zwingend notwendig, dass diese Eingaben auch stimmen. Wichtig ist nur, dass die URL, unter der der ownCloud-Server später erreichbar sein soll, unter Common Name angegeben wird (besonders, wenn später der Zugriff auch mit einem Windows Phone erfolgen soll). Wie bereits erwähnt, verwende ich im Rahmen des Artikels die URL myserver.dyndns.org.

Erweiterte Sicherheit: Diffie-Hellman-Parameter
Um die Sicherheit noch weiter zu erhöhen, sind auch noch sog. Diffie-Hellman-Parameter zu generieren. Dies sorgt für eine sichere Verschlüsselung, die ansonsten nicht mit immer garantiert werden kann. Mehr Informationen zu diesem Thema sind hier zu finden (englisch): Guide to Deploying Diffie-Hellman for TLS
Dies sollte immer ausgeführt werden, ganz gleich, ob ein selbst signiertes Zertifikat, oder ein Zertifikat von Let’s Encrypt zum Einsatz kommt.
openssl dhparam -out /etc/nginx/ssl/dhparams.pem 2048
Zugriffsberechtigungen für Zertifikat-Dateien setzen
Aus Sicherheitsgründen sollten nun noch die Zugriffsberechtigungen auf die Zertifikat-Dateien eingeschränkt werden:
chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/cert.pem chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/chain.pem chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/fullchain.pem chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/privkey.pem
Bei einem selbst signierten Zertifikat lauten die Befehle wie folgt:
chmod 600 /etc/nginx/ssl/certificate.crt chmod 600 /etc/nginx/ssl/certificate.key chmod 600 /etc/nginx/ssl/dhparams.pem
Konfiguration nginx
Wenn das SSL-Zertifikat bereit steht, geht es nun an die Konfiguration des Webservers. nginx muss an einigen Stellen angepasst werden, um einen sicheren und reibungslosen Betrieb sicher zu stellen.
Webroot anlegen
Das Root-Verzeichnis unseres Webservers soll in /var/www liegen. Dieses Verzeichnis muss neu angelegt werden und mit den entsprechenden Rechten für den Webserver-Benutzer ausgestattet werden. Das gleiche gilt für das Datenverzeichnis von ownCloud, welches wir hier auch gleich mit anlegen können. Zu beachten ist dabei, dass sich aus Sicherheitsgründen das Datenverzeichnis der Cloud außerhalb des Webroots befinden sollte.
mkdir -p /var/www mkdir -p /var/oc_data chown -R www-data:www-data /var/www chown -R www-data:www-data /var/oc_data
Allgemeine nginx-Konfiguration anpassen
Es folgt die allgemeine Anpassung der nginx-Konfiguration:
nano /etc/nginx/nginx.conf
Hier muss der Benutzer angegeben werden, unter dem der Webserver laufen soll (user). Ebenfalls sollte die Anzahl der Threads angepasst werden, mit dem nginx die Verbindungen abarbeitet (worker_processes). Wird hier auto angegeben, wird pro CPU-Kern ein Thread angelegt. An dieser Stelle kann auch noch gleich die nginx-Versionsinformation entfernt werden, die z.B. auf Fehlerseiten angezeigt wird (server_tokens).
Die komplette nginx.conf sieht somit folgendermaßen aus (Änderungen sind markiert):
user www-data www-data; worker_processes auto; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; server_tokens off; include /etc/nginx/conf.d/*.conf; }
Default-Seite deaktivieren
nginx ist nach der Installation so konfiguriert, dass eine sog. Default-Seite aktiv ist. Diese sieht man beim Aufruf mit dem Browser (siehe oben). Da diese Default-Seite nur dazu gedacht ist, die initiale nginx-Installation zu testen, kann diese deaktiviert werden.
Dazu wird die entsprechende Konfigurations-Datei umbenannt (nginx lädt nur die Konfigurations-Dateien, die mit .conf enden). Nach dem Neustarten von nginx wird diese Default-Seite nicht mehr im Browser angezeigt.
mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.disabled service nginx restart
Virtuellen Host für ownCloud anlegen
Nachdem wir bereits die Default-Seite deaktiviert haben, ist es nun an der Zeit, einen neuen virtuellen Host für ownCloud anzulegen, d.h. eine neue Konfigurations-Datei für nginx. Ich habe mich dazu entschieden, ownCloud nicht im Webroot (myserver.dyndns.org) laufen zu lassen, sondern in einem Unterverzeichnis (myserver.dyndns.org/owncloud). Dies hat den Vorteil, dass man auch mehrere Websites auf dem gleichen Webserver mit nur einem virtuellen Host laufen lassen kann.
Leider wird in Tutorials zu diesem Thema immer nur die von ownCloud vorgeschlagene nginx-Konfiguration übernommen und nur leicht abgeändert. Für einen Zugriff über ein Unterverzeichnis sind hier allerdings viele Anpassungen notwendig.
Zunächst legen wir eine neue nginx-Konfiguration an. Ich benenne diese immer wie die URL, unter der der Server später erreichbar sein soll:
nano /etc/nginx/conf.d/myserver.dyndns.org.conf
Der komplette Inhalt dieser Datei sieht dann folgendermaßen aus:
upstream php-handler { server unix:/var/run/php5-fpm.sock; } server { listen 80; server_name myserver.dyndns.org 192.168.178.20; # enforce https return 301 https://$server_name$request_uri; } server { listen 443 ssl; server_name myserver.dyndns.org 192.168.178.20; ssl_certificate /etc/letsencrypt/live/myserver.dyndns.org/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myserver.dyndns.org/privkey.pem; # Bei einem selbst signierten Zertifikat: #ssl_certificate /etc/nginx/ssl/certificate.crt; #ssl_certificate_key /etc/nginx/ssl/certificate.key; # Add headers to serve security related headers add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; add_header X-Content-Type-Options nosniff; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; ssl_dhparam /etc/nginx/ssl/dhparams.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; # Path to the root of your installation root /var/www/; index index.php index.html; # General PHP handler location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS on; fastcgi_pass php-handler; } # # ownCloud # rewrite ^/owncloud/caldav(.*)$ /owncloud/remote.php/caldav$1 redirect; rewrite ^/owncloud/carddav(.*)$ /owncloud/remote.php/carddav$1 redirect; rewrite ^/owncloud/webdav(.*)$ /owncloud/remote.php/webdav$1 redirect; location /owncloud { # set max upload size client_max_body_size 513M; fastcgi_buffers 64 4K; # Disable gzip to avoid the removal of the ETag header gzip off; # Uncomment if your server is build with the ngx_pagespeed module This module is currently not supported. # pagespeed off; error_page 403 /owncloud/core/templates/403.php; error_page 404 /owncloud/core/templates/404.php; # The following 2 rules are only needed with webfinger rewrite ^/owncloud/.well-known/host-meta /owncloud/public.php?service=host-meta last; rewrite ^/owncloud/.well-known/host-meta.json /owncloud/public.php?service=host-meta-json last; rewrite ^/owncloud/.well-known/carddav /owncloud/remote.php/carddav/ redirect; rewrite ^/owncloud/.well-known/caldav /owncloud/remote.php/caldav/ redirect; rewrite ^(/owncloud/core/doc/[^\/]+/)$ /owncloud/$1/index.html; try_files $uri $uri/ /owncloud/index.php; # ownCloud specific PHP handler location ~ \.php(?:$|/) { fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTPS on; fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice fastcgi_pass php-handler; fastcgi_read_timeout 300; fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/oc_data:/dev/urandom"; } } location = /owncloud/robots.txt { allow all; log_not_found off; access_log off; } location ~ ^/owncloud/(?:\.htaccess|data|config|db_structure\.xml|README){ deny all; } # Optional: set long EXPIRES header on static assets location ~* ^/owncloud(/.+\.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf))$ { expires 30d; # Optional: Don't log access to assets access_log off; } }
Noch ein paar Erläuterungen zu dieser Konfiguration:
- Der Zugriff auf die Cloud erfolgt immer verschlüsselt per HTTPS. Dafür sorgt der erste Server-Block. Hier werden sämtliche unverschlüsselte Verbindungen an den zweiten Server-Block weitergegeben, der per HTTPS zu erreichen ist.
- Mit
server_name
werden die Domains (oder IP-Adressen) angegeben, auf die der entsprechende Server-Block reagieren soll. In unserem Fall „bedient“ der Server die Domain myserver.dyndns.org (Zugriff aus dem Internet). Ebenfalls wird hier die IP-Adresse des Rechners angegeben, so dass der Webserver auch unter dieser Adresse im lokalen Netzwerk erreichbar ist.
- Es folgt die Einbindung des soeben erstellten SSL-Zertifikates.
- Die
add_header
Anweisungen sind für die erhöhte Sicherheit notwendig. Ohne diese Einträge werden später Warnungen im Admin-Bereich von ownCloud angezeigt.
- Anschließend werden die zuvor erzeugten Diffie-Hellman-Parameter eingebunden.
- Der erste Handler für PHP ist für alles außerhalb vom Verzeichnis /owncloud zuständig. Ich habe mich hier für zwei getrennte PHP-Handler entschieden, da dem ownCloud-PHP-Handler weitere Parameter übergeben werden.
- Es folgt die Konfiguration für das Verzeichnis /ownCloud. Diese ist an die vorgeschlagene nginx-Konfiguration der ownCloud-Dokumentation angelehnt, wurde aber dahingehend angepasst, dass ownCloud in einem Unterverzeichnis (myserver.dyndns.org/owncloud) installiert wird.
- Der ownCloud-spezifische PHP-Handler beinhaltet mehr Parameter als der allgemeine PHP-Handler (s.o.). Wichtig ist hier, dass durch
fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/oc_data:/dev/urandom";
der Wert
open_basedir
aus der php.ini überschrieben wird. ownCloud bekommt hiermit Zugriff auf Webroot, das tmp-Verzeichnis, das Datenverzeichnis und die virtuelle Gerätedatei /dev/urandom, die einen Zufallszahlen-Generator für ownCloud bereitstellt.
Nun sollte der nginx Webserver neu gestartet werden, damit die neue Konfiguration auch geladen wird. Der zuvor aufgeführte Befehl testet diese Konfiguration zunächst. Falls irgendetwas nicht stimmen sollte (z.B. auf Grund eines Tippfehlers), wird dies hier angezeigt.
nginx -t service nginx restart
Konfiguration MariaDB
MariaDB ist nach der Installation noch nicht für maximale Sicherheit konfiguriert. Dies holen wir nun mit folgendem Befehl nach:
mysql_secure_installation
Da bereits ein Root-Passwort während der Installation vergeben wurde, muss dies nicht mehr geändert werden. Alle anderen Fragen sollte man allerdings mit Ja (y) beantworten.

Ebenfalls muss die Datenbank-Konfiguration angepasst werden:
nano /etc/mysql/my.cnf
Im Abschnitt [mysqld] muss hier folgender Eintrag zu finden sein, ansonsten wird das ownCloud-Setup später auf Fehler laufen:
binlog_format = MIXED
MariaDB sollte nach diesen Änderungen anschließend neu gestartet werden:
service mysql restart
Konfiguration PHP
Es folgt die Konfiguration von PHP, um einen sicheren Zugriff auf ownCloud zu ermöglichen.
Zunächst wird die php.ini für den FastCGI Process Manager (fpm) angepasst. Über fpm kommuniziert nginx mit PHP:
nano /etc/php5/fpm/php.ini
Folgende Werte sollten hier angepasst werden:
-
post_max_size = 513M
Wird zusammen mit dem nächsten Wert für den Upload von großen Dateien benötigt.
-
upload_max_filesize = 513M
-
cgi.fix_pathinfo = 0
Wird von nginx benötigt
-
open_basedir = /var/www/:/tmp/
Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis ein. Dadurch kann PHP auf sonst keine Dateien des Systems zugreifen oder diese verändern.
Neben fpm kann PHP auch über die Kommandozeile aufgerufen werden. Dies wird später für den ownCloud-Cron-Job benötigt. Hier erfolgt die Konfiguration in einer anderen Datei:
nano /etc/php5/cli/php.ini
-
cgi.fix_pathinfo = 0
siehe oben.
-
open_basedir = /var/www/:/tmp/:/var/oc_data
Schränkt die oben erwähnt den Zugriff von PHP ein. Zusätzlich wird hier das Datenverzeichnis von ownCloud mit angegeben, da dies außerhalb des Webroots liegt.
-
apc.enable_cli = 1
Wird benötigt, damit der Cron-Job von ownCloud später auch vom Caching Gebrauch machen kann. Ohne diesen Eintrag ist der Cron-Job nicht lauffähig.
Wenn das Verzeichnis /etc/php5/cli nicht vorhanden sein sollte, fehlt vermutlich das Paket php5-cli. Eigentlich sollte dieses bereits als Abhängigkeit der anderen php-Pakete mit installiert worden sein. Falls dieses Paket dennoch fehlen sollte, muss dieses nun nachinstalliert werden:
apt-get install php5-cli
Die letzte Anpassung für PHP erfolgt in der sog. Pool-Konfiguration (fpm definiert einen Pool, der alle PHP-Anweisungen behandelt):
nano /etc/php5/fpm/pool.d/www.conf
Hier sucht man nach dem Eintrag Pass environment variables like LD_LIBRARY_PATH. ALL &VARIABLES are taken from the current environment. Hier sind die Kommentare (Semikolon) bei allen Einträgen zu entfernen, die mit env beginnen. Ohne diese Änderung wird ownCloud später eine Warnung im Admin-Bereich anzeigen, dass keine Umgebungs-Variablen definiert sind.
Mit einem Neustart von PHP werden die Änderungen übernommen:
service php5-fpm restart
Einrichtung ownCloud
Nachdem nun Webserver, Datenbank und PHP soweit konfiguriert sind, geht es nun endlich an die Installation von ownCloud.
Download
Zunächst einmal braucht man den Download-Link zur aktuellen ownCloud-Version: Auf der ownCloud-Homepage klickt man auf Download und wählt dann unter Punkt 1 (Download ownCloud) wiederum den Button Download. Nun werden Links zum direkten Download als .tar.bz2 oder .zip Datei angezeigt. Fährt man mit der Maus über einen Link, wird das Ziel im unteren Teil des Browserfensters angezeigt.

Nun kann man auf dem Linux-Rechner das entsprechende Archiv herunterladen und in das Web-Verzeichnis entpacken. Anschließend kann das Archiv wieder gelöscht werden:
wget https://download.owncloud.org/community/owncloud-8.2.1.tar.bz2 tar –xjf owncloud-8.2.1.tar.bz2 –C /var/www rm owncloud-8.2.1.tar.bz2
Nun werden noch einmal explizit die Rechte für das ownCloud-Verzeichnis und das dazugehörige Datenverzeichnis gesetzt. Ansonsten beschwert sich das Setup später über fehlende Schreibrechte.
chown -R www-data:www-data /var/www/owncloud chown -R www-data:www-data /var/oc_data
Datenbank anlegen
Bevor das ownCloud-Setup über den Browser aufgerufen wird, muss noch eine Datenbank speziell für ownCloud angelegt werden. Dies wird in der Kommandozeile von MariaDB erledigt, die mit Root-Rechten aufgerufen wird (das Passwort ist dabei das bei der Installation vergebene Root-Passwort):
mysql -u root -p
Nun werden die Datenbank und ein eigener Datenbank-Benutzer angelegt. Durch die Angabe localhost kann der Zugriff auf die Datenbank nur vom lokalen Rechner aus erfolgen. Als Passwort sollte hier wieder ein sicheres Passwort verwendet werden.
create database owncloud_db; create user owncloud_user@localhost identified by 'MeInPasSw0rT'; grant all privileges on owncloud_db.* to owncloud_user@localhost; flush privileges; exit;
ownCloud Setup
Nach diesen Vorbereitungen kann das ownCloud Setup aufgerufen werden. Dazu einfach im Browser die Adresse https://192.168.178.20/owncloud eingeben.
Wenn ein selbst signiertes Zertifikat zum Einsatz kommt, folgt zunächst eine Warnung, dass das verwendete Zertifikat nicht überprüft werden kann. Diese Meldung kann ignoriert werden (Mit dieser Website fortfahren (nicht empfohlen) – die genaue Meldung ist abhängig vom verwendeten Browser), da es sich ja um ein selbst signiertes Zertifikat handelt. Wenn das Zertifikat über Let’s Encrypt erzeugt wurde, betrachtet der Browser dieses als vertrauenswürdig und zeigt dementsprechend auch keine Warnung an.

Zur Ersteinrichtung wird zunächst einmal ein Administrator-Konto angelegt. Der Benutzername ist hierbei frei wählbar. Besonders wichtig ist hier die Wahl eines sicheren Passwortes, da die Login-Seite der Cloud später öffentlich über das Internet erreichbar sein wird. Darüber hinaus wird der Pfad zum Datenverzeichnis abgefragt (/var/oc_data). Die Angaben zur Datenbank-Verbindung entsprechen der zuvor angelegten Datenbank. Mit einem Klick auf Installation abschließen wird die Einrichtung nach einem kurzen Moment abgeschlossen.

Hinweis: Falls beim ersten Aufruf der ownCloud oder nach dem Klick auf Installation abschließen Fehlermeldungen angezeigt werden, dann sollten die zuvor durchgeführten Schritte noch einmal kontrolliert werden. Meistens liegt dies dann an fehlenden Schreibrechten im Webroot- oder Datenverzeichnisses. Ebenso bricht das Setup mit einer Meldung ab, wenn das binlog_format von MariaDB nicht auf MIXED geändert wurde.
Anpassung der ownCloud-Konfiguration
Damit ist das Setup zunächst abgeschlossen und die eigene Cloud kann verwendet werden. Dennoch sollte man die nochmals die Konfiguration kontrollieren und ggf. anpassen:
nano /var/www/owncloud/config/config.php
Vertrauenswürdige Domains
Momentan greifen wir noch über die lokale IP-Adresse auf die Cloud zu. Damit der Zugriff später auch über die (öffentliche) DynDNS-Domain möglich ist, muss diese zu den vertrauenswürdigen Domains hinzugefügt werden:
array ( 0 => '192.168.178.20', 1 => 'myserver.dyndns.org', ),
Zeitzone einstellen
Optional kann hier gleich die Zeitzone angepasst werden. Dies betrifft v.a. die Logeinträge der ownCloud.
'logtimezone' => 'Europe/Berlin',
Warnungen im Admin-Bereich
Nach der Anpassung der Konfiguration sollte man sich nun als Administrator anmelden und einen Blick in den Admin-Bereich der ownCloud werfen: Benutzername (rechts oben) > Administration. In diesem Bereich gibt ownCloud Warnungen aus, wenn irgendetwas an der Konfiguration oder den Zugriffsrechten nicht passt.

In unserem Fall sollten nun zwei Warnungen ausgegeben werden:
-
Transactional file locking is using the database as locking backend, for best performance it’s advised to configure a memcache for locking. See the documentation for more information.
- Es wurde kein PHP Memory Cache konfiguriert. Konfiguriere zur Erhöhung der Leistungsfähigkeit, soweit verfügbar, einen Memory Cache. Weitere Informationen finden Sie in unserer Dokumentation.
Beide Warnungen stellen dabei keinen Fehler in der Installation dar, sondern weisen lediglich darauf hin, dass die Performance der ownCloud-Installation mit weiteren Schritten verbessert werden kann. Gerade bei Installationen, auf die nur wenige Benutzer zugreifen, kann man diese Warnungen auch ignorieren. Im Folgenden wird die ownCloud-Installation dennoch angepasst, so dass keine Warnung mehr im Administrations-Bereich angezeigt wird.
Verwendung von PHP Memory Cache
Das Problem, welches den PHP Memory Cache betrifft, ist dabei recht schnell zu lösen. Dazu muss noch einmal die ownCloud-Konfiguration angepasst werden:
nano /var/www/owncloud/config/config.php
Hier aktivieren wir lediglich den PHP Memory Cache. Voraussetzung ist hierfür, dass das Paket php5-apcu bei der Installation der PHP-Pakete mit installiert wurde (s.o.).
'memcache.local' => '\OC\Memcache\APCu',
Transactional File Locking
Die weitere Warnung betrifft das sog. Transactional File Locking: Wenn ein Benutzer gerade eine Datei bearbeitet, sollte diese für die anderen Benutzer gesperrt sein. Dieses Locking wird standardmäßig über die Datenbank realisiert, was allerdings nicht besonders performant ist.
ownCloud bietet aber auch die Möglichkeit, dieses Locking über eine spezielle In-Memory-Datenbank zu realisieren: Dabei kommt die No-SQL-Datenbank Redis zum Einsatz.
Vor den folgenden Schritten sollte kontrolliert werden, ob unter den ownCloud-Apps die File Locking App zu finden ist. In diesem Fall muss diese App deaktiviert werden, weil ich die beiden Locking-Mechansimen ansonsten gegenseitig aussperren.
Anschließend müssen zunächst einmal die fehlenden Pakete nachinstalliert werden:
apt-get install php5-redis redis-server
Nach der Installation muss die Redis-Konfiguration angepasst werden, damit ownCloud diese Datenbank verwenden kann:
nano /etc/redis/redis.conf
Da die ownCloud-Installation nur auf einem Rechner läuft, ist die generelle Empfehlung, Redis für die Verwendung von Unix-Sockets zu konfigurieren. Dazu sind zwei Zeilen in der Konfiguration anzupassen:
unixsocket /var/run/redis/redis.sock unixsocketperm 770
Besonders wichtig ist hier das Setzen der korrekten Berechtigung, damit der Webserver-User (unter dem die ownCloud-Instanz läuft) den entsprechenden Unix-Socket verwenden kann.
Anschließend kann die Konfigurations-Datei gespeichert werden. Nun muss nur noch der Webserver-User (in unserem Fall www-data) in die Gruppe der Redis-Benutzer hinzugefügt werden. Wird dieser Schritt nicht ausgeführt, kann ownCloud später nicht auf Redis zugreifen und man erhält bei jedem Datei-Zugriff eine Fehlermeldung (redis went away).
usermod -a -G redis www-data
Der letzte Schritt stellt wieder die Anpassung der ownCloud-Konfiguration dar, damit für das File Locking Redis verwendet wird. Dazu einfach folgende Zeile in die config.php eintragen:
'filelocking.enabled' => 'true', 'memcache.locking' => '\OC\Memcache\Redis', 'redis' => array( 'host' => '/var/run/redis/redis.sock', 'port' => 0, 'timeout' => 0.0, ),
Unter host muss der zuvor beschriebene Unix-Socket angegeben werden.
Nach diesen Schritten sollten die Warnungen im ownCloud-Adminbereich verschwunden sein. Dennoch empfehle ich, die Verwendung von Redis sofort noch einmal zu testen, da bei einer falschen Konfiguration keine Warnung o.ä. angezeigt wird. Dazu einfach unter Dateien eine neue Text-Datei erstellen und anschließend speichern. Fall dabei keine Fehlermeldung bzgl. Redis angezeigt wird, ist die Konfiguration fehlerfrei.
Abschließend noch einmal die komplette Konfigurations-Datei von ownCloud. instanceid, passwortsalt und secret habe ich hier entfernt, diese sollten nach dem Setup nicht mehr verändert werden. Alle anderen Änderungen, die soeben durchgeführt wurden, sind markiert:
<?php $CONFIG = array ( 'instanceid' => '...', 'passwordsalt' => '...', 'secret' => '...', 'trusted_domains' => array ( 0 => '192.168.178.20', 1 => 'myserver.dyndns.org', ), 'datadirectory' => '/var/oc_data', 'overwrite.cli.url' => 'https://192.168.178.20/owncloud', 'dbtype' => 'mysql', 'version' => '8.2.1.4', 'dbname' => 'owncloud_db', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'owncloud_user', 'dbpassword' => 'MeInPasSw0rT', 'logtimezone' => 'Europe/Berlin', 'installed' => true, 'memcache.local' => '\OC\Memcache\APCu', 'filelocking.enabled' => 'true', 'memcache.locking' => '\OC\Memcache\Redis', 'redis' => array( 'host' => '/var/run/redis/redis.sock', 'port' => 0, 'timeout' => 0.0, ), );
Weitere Warnung im Admin-Bereich
Sollten nun noch weitere Warnungen im Bereich Administration der ownCloud angezeigt werden, so liegt vermutlich ein genereller Fehler bei der Konfiguration vor. Dazu gibt es eine Seite in der ownCloud-Dokumentation, die die Warnungen und deren Ursachen genau beschreibt: Warnings on Admin Page
Zugriffsrechte anpassen
Nach der Installation von ownCloud sollten die Datei-/Verzeichnis-Berechtigungen aus Sicherheitsgründen noch einmal explizit gesetzt werden. Dies geschieht durch folgende Befehle:
find /var/www/owncloud/ -type f -print0 | xargs -0 chmod 0640 find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0750 chown -R root:www-data /var/www/owncloud/ chown -R www-data:www-data /var/www/owncloud/apps/ chown -R www-data:www-data /var/www/owncloud/config/ chown -R www-data:www-data /var/www/owncloud/themes/ chown -R www-data:www-data /var/oc_data/ chown root:www-data /var/www/owncloud/.htaccess chown root:www-data /var/www/owncloud/data/.htaccess chmod 0644 /var/www/owncloud/.htaccess chmod 0644 /var/oc_data/.htaccess
Dabei kann es sein, dass die Datei /var/oc_data/.htaccess nicht existiert und eine entsprechende Fehlermeldung ausgegeben wird. Dies kann jedoch ignoriert werden.
ownCloud Cronjob einrichten
Standardmäßig werden Hintergrundaufgaben, die in regelmäßigen Abständen erledigt werden müssen, von ownCloud über AJAX ausgeführt. D.h. dass diese Hintergrundaufgaben immer dann ausgeführt werden, wenn ein Benutzer angemeldet ist und eine Seite geladen wird. Dies ist jedoch nicht sehr performant und es bietet sich daher an, diese Hintergrundaufgaben per Cron erledigen zu lassen.
Dieser Schritt ist nicht zwingend notwendig, empfiehlt sich aber besonders beim Einsatz eines Raspberry Pi oder ähnlich schwacher Hardware, da die Ausführung per Cron viel ressourcenschonender ist.
Dazu legen wir einen neuen Cronjob für den Webserver-Benutzer an:
crontab -u www-data -e
Wenn das System nachfragt, wie wir die Datei bearbeiten möchten, wählt man am besten den bekannten Editor nano. Folgendes wird nun am Ende der Datei eingefügt:
*/15 * * * * php -f /var/www/owncloud/cron.php > /dev/null 2>&1
Dies sorgt dafür, dass die Hintergrundarbeiten alle 15 Minuten ausgeführt werden.
Damit diese Aktivitäten nun nicht doppelt (per AJAX und per Cron) ausgeführt werden, muss man noch im Admin-Bereich von ownCloud unter dem Punkt Cron die Einstellung AJAX auf Cron ändern.

Weitere Konfiguration der ownCloud
Damit ist die Einrichtung der ownCloud abgeschlossen. Alle weiteren Schritte zur Konfiguration (z.B. die serverseitige Verschlüsselung) hängt vom individuellen Einsatzzweck ab. Dazu verweise ich hier auf das offizielle Administrations-Handbuch von ownCloud.
Abschluss-Arbeiten: Port-Forwarding und Zertifikat installieren
ownCloud ist nun installiert und einsatzbereit. Es fehlen nur noch zwei Schritte, damit die persönliche Cloud auch über das Internet erreichbar ist und beim Zugriff keine Warnungen mehr von Browser ausgegeben werden.
Port-Forwarding einrichten
Bisher ist die ownCloud-Installation nur im lokalen Netzwerk erreichbar. Damit man auch aus dem Internet darauf zugreifen kann, muss nun noch eine Weiterleitung der entsprechenden Ports 80 (für HTTP) und 443 (HTTPS) im Router eingerichtet werden. Das Vorgehen dazu unterscheidet sich von Router zu Router. Hier das beispielhafte Vorgehen bei einer FritzBox:
- Die Erweiterte Ansicht muss aktiv sein (erster Punkt der unteren Menüleiste).
- Unter Internet > Freigaben klicken wir auf den Button Neue Portfreigabe.
- Portfreigabe aktiv für: Andere Anwendungen
- Protokoll: TCP
- von Port: 80
- bis Port: 80
- an Computer: <Name des Rechners, auf dem ownCloud läuft>
- an Port: 80

Das gleiche muss nun noch für den TCP Port 443 wiederholt werden, damit der Zugriff auch per HTTPS möglich ist.
Ebenfalls muss in der Konfiguration des Routers die Anmeldung an den DynDNS-Dienst konfiguriert sein, damit dieser dann über die DynDNS-Adresse (in diesem Beispiel myserver.dyndns.org) erreicht werden kann.
Zertifikat installieren (nur bei selbst signierten Zertifikaten)
Der folgende Abschnitt muss nur beachtet werden, wenn ein selbst signiertes SSL-Zertifikat zum Einsatz kommt. Wenn – wie empfohlen – ein Zertifikat über Let’s Encrypt generiert wurde, betrachten moderne Browser dieses als vertrauenswürdig und zeigen daher auch keine Warnung beim Zugriff auf die ownCloud an.
Bisher gibt der Browser beim Zugriff auf ownCloud eine Warnung aus, dass das benutzte Zertifikat nicht bekannt ist. Da es sich hierbei um ein selbst signiertes Zertifikat handelt, kann der Browser dies ja auch nicht kennen. Damit diese Warnung nicht mehr angezeigt wird, ist es daher notwendig, dass das Zertifikat auf dem Rechner installiert wird. Hierbei sei erwähnt, dass dies ein optionaler Schritt ist: Unabhängig davon, ob das Zertifikat installiert ist oder nicht, die gesamte Kommunikation mit der Cloud läuft verschlüsselt ab.
Das folgende Vorgehen bezieht sich auf Windows-Rechner. Auf anderen Betriebssystemen ist hier ein anderes Vorgehen notwendig.
Am besten führt man die Schritte mit dem Internet Explorer aus, da auf diese Weise das Zertifikat systemweit installiert wird und jeder andere Browser das Zertifikat ebenso akzeptieren wird.
Dazu starten wir den Internet Explorer mit Administrator-Rechten (wichtig!) und rufen die URL der ownCloud-Installation auf. Die Zertifikat-Warnung wird ignoriert. Nun wird die Adressleiste des Browsers rot gefärbt. Wir klicken hier auf Zertifikatfehler und anschließend auf Zertifikate anzeigen.

Nun öffnet sich ein Fenster mit Informationen zum Zertifikat. Man klickt hier nun auf den Button Zertifikat installieren…
Es öffnet sich der Assistent zur Zertifikat-Installation. Hier wählt man im ersten Schritt Lokaler Computer als Speicherort. Anschließend wählt man Alle Zertifikate im folgenden Speicher speichern und gibt hier den Ordner Vertrauenswürdige Stammzertifizierungsstellen an.

Durch einem Klick auf Weiter und Fertig stellen wird das Zertifikat installiert.
Nach einem Neustart des Browsers wird das Zertifikat nun ohne Warnung akzeptiert (nicht nur vom Internet Explorer, sondern auch von anderen auf dem Rechner installierten Browsern, wie z.B. Chrome).
Download Checkliste
Hier noch einmal eine Zusammenfassung aller zur Installation benötigten Schritte als PDF. Dieses Dokument verzichtet auf die Erklärungen und Hintergrundinformationen des Artikels, sondern listet nur alle verwendeten Befehle und Eingaben hintereinander auf. Somit ist es vielmehr eine Checkliste, die einfach abgearbeitet werden kann.
Der Mühe Lohn
Wenn alle Schritte dieses doch recht langen Artikels abgearbeitet wurden, hat man nicht nur eine sichere und performante ownCloud-Installation, die auch mühelos auf einem Raspberry Pi läuft, sondern behält v.a. die Hoheit über seine eigenen Daten.
Ich selbst habe viel Zeit investieren müssen, um die Prozedur der Installation und Konfiguration soweit zu optimieren, dass ownCloud nun optimal läuft. Ich hoffe, dass ich dem einen oder anderen mit diesem Artikel etwas Zeit zum Suchen und Rumprobieren ersparen kann. Falls es dennoch Unklarheiten oder Verbesserungsvorschläge gibt, schreibt mir diese einfach in die Kommentare. Ich versuche euch dann soweit wie möglich weiter zu helfen.
Weiterführende Artikel
- Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten
- ownCloud Updates richtig durchführen
- HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx
Links
- Cloud Computing (Wikipedia)
- Offizielle ownCloud Homepage
- Offizielle nginx Homepage (englisch)
- nginx Wiki mit vielen Anleitungen und Beispielen (englisch)
- Offizielle MariaDB Homepage (englisch)
- Offizielle PHP Homepage (englsich)
- ownCloud Server Administration Manual (englisch)
- Offizielle Redis Homepage (englisch)
- Let’s Encrpyt Homepage (englisch)
Hallo,
Ich nutze die Owncloud nun eine Ganze weile in dieser Konfiguration. Es gibt kaum Probleme alles ist stabil und es sind bis auf Meldungen der StoragesCharts App sind keine Fehler im Log.
Danke noch einmal für diese tolle Konfigurationsanleitung.
Genutzt wird die Cloud von 4 Android Mobiltelefonen (4 Personen) Es werden Dateien mit Folder Sync gebackupt und Synchronisiert und Calender und Kontakte mit DavDroid Synchronisiert.
Das Funktioniert alles gut.
Vor ca. 2 Wochen habe ich festgestellt, dass die Cloud im Webinterface sehr langsam geworden ist –> je klick ca. 10 Sek. warten.
Obwohl der Server recht performant ist (4 Cores bis zu 4 GB Dynamischer RAM die Installation und Files liegen auf einer SSD)
Kann ich hier noch etwas optimieren, oder kommt die Cloud nicht mit so vielen Daten klar (in Summe ca. 20Gb kleine Files)
Gruß Bernd
Hallo Bernd,
Performance-Probleme konnte ich bei meiner Installation bisher noch nicht feststellen, allerdings hat meine Cloud auch nur zwei Benutzer und es werden relativ wenige Dateien gespeichert (zusammen ca. 100 MB).
Ich verweise hier mal auf einen Thread im ownCloud-Forum, der Performance-Optimierungen auflistet.
Ansonsten würde ich zunächst einmal probieren, den Wert für worker_processes in der /etc/nginx/nginx.conf zu erhöhen, damit Requests mit mehr Threads abgearbeitet werden können. Bei 4 Cores würde ich mal einen Wert von 8-10 ausprobieren.
Wenn das noch nichts hilft, muss man zunächst einmal herausfinden, wo der Flaschenhals sitzt. Hier helfen u.U. die Logs weiter. Auch kann man mal die CPU-Last einzelner Prozesse (Datenbank, Webserver) im Auge behalten.
PHP-Cache (memcache) und Redis (für das Transactional File Locking) hast du aktiviert?
Gruß,
Jan
Hallo,
Danke für deine Antwort.
Ich habe den PHP-Cache (memcache) und Redis (für das Transactional File Locking) genau wie in der Anleitung aktiviert.
Der worker process steht aktuell auf auto. Soll ich dort dann einfach 10 eintragen?
Ist htop zum überwachen der Leistung ausreichend um den Flaschenhals zu erkennen, oder gibt es hier besseres?
PS: die Owncloud läuft auf einem server 2012 R2 in einer 2. Generation VM.
Konfiguriert habe ich alles wie von dir in dem Artikel auf deiner HP beschrieben.
Gruß Bernd
Hallo,
danke für deine Antwort.
Ich habe zum Aufsetzen des Ubuntu Servers auf dem Hyper V deine Anleitung befolgt, bzw. genau die Anleitung befolgt, die hier für Owncloud vorgegeben ist.
Das Caching ist also aktiviert.
ich bekomme beim Boot folgende Felhermeldungen:
Error assets Folder does not exist and/or could not be generated. a few seconds ago
Error PHP mkdir(): Permission denied at /var/www/owncloud/lib/private/template.php#390 a few seconds ago
Error assets Folder does not exist and/or could not be generated. a minute ago
Error PHP mkdir(): Permission denied at /var/www/owncloud/lib/private/template.php#390 a minute ago
Error PHP Array to string conversion at /var/www/owncloud/lib/private/template/functions.php#36 a minute ago
Error assets Folder does not exist and/or could not be generated. a minute ago
Error PHP mkdir(): Permission denied at /var/www/owncloud/lib/private/template.php#390 a minute ago
Error assets Folder does not exist and/or could not be generated. a minute ago
Error PHP mkdir(): Permission denied at /var/www/owncloud/lib/private/template.php#390 a minute ago
Sonst bekomme ich keine/auer von der Storagecharts app.
Gruß Bernd
Hallo Bernd,
hat dein Webserver-User (meistens www-data) Schreibrechte auf das betroffene Verzeichnis? Sieht mir nach fehlenden Berechtigungen aus. Mehr Infos dazu evtl. hier.
Der andere Fehler („Error PHP Array to string conversion“) kommt meiner Erfahrung nach häufiger vor, ich konnte allerdings keine negativen Auswirkungen beobachten.
Gruß,
Jan
Sorry für den doppelpost, nur habe ich meinen Comment nach dem erstellen nicht gesehen :)
Hallo nochmal,
ja, manche Kommentare stehen (warum auch immer) unter Spam-Verdacht und müssen manuell frei geschaltet werden. Also nicht wundern, wenn ein Kommentar nicht unverzüglich angezeigt wird. Ich gebe mir Mühe, jeden nicht-Spam-Kommentar möglichst früh freizuschalten. Innerhalb ein paar Stunden sollte ein solcher Kommentar sichtbar sein.
Gruß,
Jan
Ich möchte mich (nicht nur für diese) super Anleitung bedanken! Vor allem die Erläuterungen zu den einzelnen Schritten bilden einen echten Mehrwert!
Deine Seite liegt nun unter meinen Bookmarks… ;)
Hallo Jan,
super Anleitung, die mich dazu beflügelt hat, den guten alten Apache hinter mir zu lassen. ;-) Aktuell rennt meine ownCloud auf einem kleinen HP-Server mit SSD, der unter meinem Schreibtisch steht. Die Daten sind also genau dort, wo ich sie haben möchte.
Eine Frage habe ich jedoch an dich:
Aktuell ist die ownCloud über server.heimat.de/owncloud erreichbar. Ich möchte die ownCloud jedoch sehr gerne über z. B. cloud.heimat.de erreichen.
Kann ich in dem Fall die vorhandene server.heimat.de.conf übernehmen, die Pfade anpassen und mir so einen weiteren vHost erzeugen, der direkt auf das /var/www/owncloud Verzeichnis zeigt?
Grüße
Jan
Hallo Jan,
danke für das Lob!
Ja, im Prinzip hast du Recht: Du brauchst nur eine zweite conf-Datei, die dann exklusiv für ownCloud zuständig ist und auf cloud.heimat.de lauscht. Du musst dann allerdings die speziellen ownCloud-Anpassungen, die ich im Artikel erwähnt hatte (damit ownCloud in einem Unterverzeichnis des Webservers erreichbar ist), rückgängig machen. Wirf dazu mal einen Blick auf die offizielle Dokumentation bzgl. ownCloud und nginx: Hier wird dir vieles bekannt vorkommen, nur dass in meiner conf-Datei immer noch das Verzeichnis owncloud in sämtlichen Pfadangaben auftaucht. Wenn diese Pfadangaben angepasst werden, ist die Cloud über das Root-Verzeichnis des Server-Blocks (vHost) erreichbar.
Bevor du nun gleich loslegst: Wenn du DynDNS verwenden solltest, sehe ich hier evtl. noch ein anderes Problem. DynDNS wird mit der Domain server.heimat.de angemeldet sein. Du bräuchtest nun eine zweite DyDNS-Anmeldung mit cloud.heimat.de. Das ist aber nicht möglich, da dein Router ja nur eine öffentliche IP hat.
Genau aus diesem Grund habe ich mich für die Verwendung von Unterverzeichnissen am Webserver entschieden, damit ich darüber mehrere Dienste laufen lassen kann.
Gruß,
Jan
Moin Jan,
danke für deine Rückmeldung. Werde das Projekt die Tage mal angehen und dann Bericht erstatten. ;-)
Das von dir im letzten Absatz beschriebene Problem habe ich nicht, da ich verschiedene Domains und Subdomains per CNAME auf meine DynDNS-Adresse zeigen lassen. Das funktionierte mit meinem Apache schon reibungslos und mit dem nginx jetzt ebenfalls.
Grüße
Jan
Hallo Jan,
ich habe mich daran versucht. Aktueller Stand:
ownCloud ist über beide Domains (server.domain.org/owncloud & server2.domain.org) erreichbar.
Komischerweise konnte ich keine Files mehr herunterladen, betrachten und synchronisieren. Daher habe ich testweise die REDIS-Einstellungen aus der config.php entfernt, was dazu führte, dass ich wieder Dateizugriff habe.
Hast du eine Idee, woran das liegen kann? Habe mich explizit an deine Hinweise gehalten.
Zudem scheint irgendwo intern noch ein falscher Pfad eingetragen zu sein. Er sucht teilweise ein paar Bild- und CSS-Dateien immer im /owncloud-Ordner, den es natürlich bei der direkten Domain nicht mehr gibt.
Grüße
Jan
Hi Jan,
zu redis: Kommt hier eine Fehlermeldung, wenn redis aktiviert ist – „redis went away“ wird dann nur ganz kurz am oberen Bildschirmrand angezeigt, wenn im Browser versucht wird, auf eine Datei zuzugreifen? Das wichtige Detail meiner Konfiguration ist dabei das Setzen der Zugriffsrechte in der Datei /etc/redis/redis.conf. Wenn diese nicht auf 770 stehen, wird redis mit ownCloud zusammen nicht funktionieren, da der Webserver-Benutzer (www-data) keine Berechtigung hat.
Auch die verwendete Version deines Betriebssystems kann dir bzgl. redis einen Strich durch die Rechnung machen. Beispielsweise liegt das in den Paketquellen enthaltene php5-redis bei Ubuntu 14.04 in einer zu alten Version vor, die mit ownCloud nicht kompatibel ist. Dafür gibt es zwar Workarounds (siehe z.B. hier), aber die sind mit Vorsicht zu genießen – hier solltest du genau wissen, was du tust!
Zu den anscheinend falschen Pfadangaben: Kontrollier bitte noch einmal, dass du auch bei allen Pfadangaben das /owncloud/ entfernt hast. Irgendwo wird da noch ein falscher Pfad angegeben sein, der natürlich vom System nicht gefunden werden kann.
Gruß,
Jan
Moin Jan,
leider scheint es sich bei Redis um ein anderes Problem zu handeln. Die Meldung „redis went away“ erscheint bei mir nicht.
Ganz kurios:
Wenn ich redis in der config.php aktiviere, funktioniert der Zugriff auf alle Dateien im Browser und per App für ein paar Minuten. Erst dann tritt der Fehler auf, dass im Browser keine Dateien mehr dargestellt werden, ich keine Ordner erstellen kann etc. und die App nicht mehr synchronisiert.
GIbt’s bei redis eine Art Datenbank oder Speicher, der z. B. „voll laufen“ kann oder fehlerhafte Daten beinhaltet?
Das Problem mit den fehlerhaften Pfaden bei einigen Grafiken konnte ich bisher noch nicht nachvollziehen. Alle Pfade in meiner nginx .conf passen.
Kann es sein, dass der Pfad während der Installation irgendwo in der mySQL-Datenbank gespeichert ist und dort ggf. geändert werden muss?
Grüße
Jan
Hi Jan,
ja, klingt irgendwie danach, als ob redis irgendwann abschmiert und dann die ganze Cloud mit runter zieht. Schau doch mal in die Log-Datei von redis (/var/log/redis/redis-server.log): wenn hier was schief läuft, sollte im Log zumindest ein Hinweis darauf zu finden sein. Wenn nicht, wären nginx-Log, ownCloud-Log und PHP-Log die nächsten Anlaufstellen, die ich untersuchen würde.
redis ist übrigens kein Muss, wenn du eine ownCloud betreibst. Wenn kein redis installiert/konfiguriert ist, wird das File Locking über die Datenbank realisiert. Erst wenn sehr viele Nutzer zeitgleich auf die Cloud zugreifen, wird dies relativ langsam und redis kann seine Vorteile ausspielen. Aber wenn nur ein paar wenige Nutzer die ownCloud verwenden, hast du mit redis eigentlich keinerlei Vorteile.
Dass Pfade in der ownCloud-DB gespeichert werden, kann ich mir nicht vorstellen. Wirf doch auch hierfür mal ein Blick in das nginx-Log. Vielleicht findest du ja hier einen Hinweis.
Gruß,
Jan
Vielen Dank für diese wunderbare Anleitung!
Habe mir die ownCloud damit einrichten können und sie ist mit Nginx wirklich performant.
Nur zwei Sachen habe ich und vielleicht hat ja jemand einen Tipp:
– Wenn ich die App „News“ installiere, dann stürzt die ownCloud immer ab. Um wieder in die ownCloud-Adminoberfläche zu gelangen muss ich die App „News“ wieder deaktivieren
– Um eine Bruteforce-Attacke zu verhindern wollte ich „fail2ban“ in Betrieb nehmen. Habe zwar einige Anleitungen gefunden und es wird auch offensichtlich geloggt, aber gebannt wird da nichts. Hat jemand da einen guten Leitfaden?
Viele Grüße
Sven
Hallo Sven,
danke für das Lob!
Zur News-App: Da ich diese App nicht verwende, kann ich darüber nicht viel sagen. Ich habe allerdings die Erfahrung gemacht, dass einige ownCloud-Apps nicht wirklich stabil laufen: Dein Problem, dass man die App wieder deaktivieren muss, um überhaupt in die Admin-Oberfläche zu kommen, kommt mir irgendwie bekannt vor. Hier würde ich erst einmal kontrollieren, ob es evtl. für die App ein Update gibt (und dieses ggf. manuell installieren). Ansonsten hilft evtl. auch ein Blick in das ownCloud-Log, um heraus zu finden, was hier schiefläuft.
fail2ban setze ich persönlich auch ein, um die Cloud etwas sicherer zu machen. Das A und O ist hierbei der verwendete Regex-Ausdruck, um fehlgeschlagene Login-Versuche zu erkennen. Die komplette conf-Datei für ownCloud sieht bei mir folgendermaßen aus:
[Definition]\)","level":2,"time":".*"}
failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '
ignoreregex =
Reicht dir diese Info bereits, um weiter zu kommen? Wenn nicht, könnte ich die Einrichtung von fail2ban bzgl. ownCloud ja mal in einem Blogeintrag behandeln.
Gruß,
Jan
Hallo Jan,
der Ubuntu Server erschien mir nach meinen Experimenten nicht mehr sicher zu sein, so dass ich den lieber dann noch einmal aufgesetzt hatte.
Nun habe ich mich für Debian 8.3.0 entschieden und deine Anleitung weitestgehend übernommen.
Meine Hauptbeweggrund war dabei die längere Supportzeit.
Die größte Schwierigkeit stellte die Installation dar, wobei der einzige Unterschied zu Ubuntu Server lediglich ein Treiber war, der unter Non-Free fiel. Der Treiber betraf die Netzwerkkarte und war entsprechend wichtig.
Hier musste ich diesen per weiteren USB-Stick nachladen (FAT32 formatierter Stick und darauf einfach nur das entsprechende .deb-Paket packen).
Bei nginx bin ich noch deinem Weg gefolgt (natürlich angepasst auf Debian Jessie). Für MariaDB reicht mir die angebotene Datenbank aus (kann ich ja bei Bedarf immer noch anpassen).
APCu liegt als Version 4.07 vor.
Was ich bewusst anders gemacht hatte ist zum einen der Pfad von /var/oc_data auf /media/oc_data (ist als große HDD eingehängt, der Rest liegt auf einer SSD) und zum anderen sollte die ownCloud im Rootverzeichnis sein.
Wenn ich es richtig verstanden habe, kann ich nginx ja entsprechend für verschiedene Domains konfigurieren und dies ist auch bei dynamischen IPs möglich (beschreibe ich weiter unten).
Redis habe ich vorerst weggelassen, um einen möglichen Fehler auszuschließen.
Das Log lasse ich von der ownCloud nun ins Syslog schreiben und damit war die Konfiguration von fail2ban deutlich einfacher.
Mit deinem Regex könnte ich nun auch wieder ein separates Logfile benutzen. Muss ich mir noch einmal überdenken.
Ob mein Problem mit der News-App nun an Ubuntu Server, Redis, einer Paketversion oder an einer anderen ownCloud-App lag, weiß ich noch nicht zu beurteilen.
Dies werde ich aber weiter untersuchen.
Was nun aber genauso interessant ist, ist die Backupfrage (und vor allem die Wiederherstellungsfrage ;-)) und die Verschlüsselung.
Deine Anleitung hat aber erheblich viel Zeit gespart und war auch für meinen Schwenk nach Debian echt Gold wert!
Hoffe, dass mein langer Kommentar auch irgendjemanden helfen kann!
Bzgl. DynDNS mit eigener Domain:
Ich habe mehrere extern gehostete Domains und habe eine davon testweise zum Anbieter http://freedns.afraid.org ausgelagert.
Eine Subdomain ist nun unauffällig mit einer dynamischen IP verbunden (es würden auch mehrere (Sub-)Domains auf eine IP gehen.
Das FreeDNS kann man kostenlos nutzen. Wer dies schätzt kann aber natürlich auch etwas spenden. :)
Viele Grüße
Sven
Hallo Sven,
danke für den ausführlichen Kommentar. Dieser ist sicher hilfreich, wenn Debian als OS zum Einsatz kommen soll.
Jedoch muss ich doch mal nachfragen: Warum beurteilst du den Ubuntu Server als „nicht mehr sicher“? Egal, ob 14.04 (LTS) oder die aktuelle Version 15.10, beide würde ich als sicher erachten (auch wenn man unter 14.04 einige Sachen manuell installieren/updaten muss, um ownCloud richtig zum Laufen zu bekommen). Was für Experimente hast du hier durchgeführt?
Die Backupfrage sollte natürlich geklärt sein, bevor man die Cloud produktiv einsetzt. Für meinen Teil bin ich fein raus, da die Cloud auf einer Hyper-V VM läuft, die automatisch in den Backup-Prozess des Windows Servers eingebunden ist. Backup und Wiederherstellung in weniger als 5 Minuten.
Wenn die Cloud auf physischer Hardware läuft, muss man sich natürlich etwas anderes ausdenken. V.a. wenn man ein Backup im laufenden Betrieb (Live-Backup) machen möchte, ist dies noch eine Herausforderung. Ich wollte die Cloud ursprünglich auf einem Intel NUC laufen lassen. Nach einigen Experimenten bzgl. Live-Backup (LVM-Snapshots, etc.) bin ich dann aber nicht zu einer befriedigenden Lösung gekommen. Daher habe ich mich für die Variante mit einer VM entschieden.
Gruß,
Jan
Hallo Jan,
meine Bedenken bzgl. der Sicherheit waren auf mein Verhalten zurückzuführen und nicht auf Ubuntu.
Ich habe für fail2ban ein ownCloud-Skript gefunden und ausgeführt. Mir ging es da vorerst nur um die Frage, ob ich alles zum Laufen bekomme und mir war da schon klar, dass ich noch einmal eine komplette Einrichtung machen werde.
Entsprechend habe ich den Quellcode des Skripts nicht durchgeschaut, ob dieser Schadcode beinhalten könnte.
Ubuntu selber erhält von mir genug Vertrauen, so dass ich Ubuntu GNOME als Hauptsystem einsetze.
Andere Distributionen wie Manjaro empfinde ich aufgrund der Firmenphilosophie von Canonical zwar als besser, aber ich habe derzeit nicht die Zeit mich mit den Problemen zu beschäftigen, die ich habe, wenn ein Paket nur für Ubuntu angeboten wird (was auf die Verbreitung von Ubuntu zurückzuführen ist).
Microsoft hat mein Vertrauen schon lange verspielt und ich mag mich von der GNOME Shell nicht mehr trennen.
Eine VM-Lösung ist bzgl. den Snapshots natürlich sehr gut und äußerst flexibel. Ich tendiere zur Zeit in Richtung mysqldump und duplicity.
Bei der Datenbank ist es gefährlich, wenn diese nicht angehalten wird und ein physikalisches Backup gemacht wird.
Der Dump kann später relativ leicht wieder eingespielt werden.
Gerne melde ich mich, sobald ich eine Lösung für mich erarbeitet habe.
Gruß
Sven
Hi Jan,
habe auch einen Ubuntu Server mit Owncloud aufgesetzt. Leider bekommen ich nach der Aktivierung von Redis im Adminbereicht die meldung das Transacational file locking noch die „database“ nutzt.
Redis und Memcache ist richtig konfiguriert.
Transactional file locking is using the database as locking backend, for best performance it’s advised to configure a memcache for locking.
Diese Fehlermeldung kommt noch in der Logfileauswertung.
PHP Startup: Unable to load dynamic library ‚/usr/lib/php5/20121212/redis.so‘ – /usr/lib/php5/20121212/redis.so: cannot open shared object file: No such file or directory at Unknown#0
Hast du einen Idee wo der Fehler liegen könnte?
Im Verzeichnis /usr/lib/php5/20121212 liegt auch kein redis.so
Danke im Voraus
mario
Hallo Mario,
schwierig zu sagen. Bei mir ist die Datei redis.so vorhanden, wenn ich in einem anderen (Datums-)Verzeichnis.
Um dir hier weiterhelfen zu können, bräuchte ich ein paar mehr Infos: Welche Programm-/Library-Versionen nutzt du (Ubuntu, PHP, redis)? Am besten kannst du diese Infos mit phpinfo() auslesen.
Ich vermute mal fast, dass du noch Ubuntu 14.04 LTS einsetzt: Hier ist das redis-Paket zu alt, um problemlos mit ownCloud zusammen zu arbeiten. Hier könnte das hier beschriebene Vorgehen helfen. Aber Achtung: Damit installierst du Software abseits der offiziellen Paketquellen. Hier solltest du genau wissen, was du tust.
Meine Empfehlung für solche Fälle: redis ist kein Must-Have, wenn nur wenige User die ownCloud nutzen. Hier ist das DB-Locking genauso schnell/effektiv. Erst wenn wirklich viele User die Cloud zeitgleich nutzen, wirst du mit redis einen Vorteil bemerken. Daher kann man die Warnung in dem meisten Fällen getrost ignorieren (bzw. bis zum nächsten Ubuntu LTS Release abwarten, hier dürfte es dann keine Probleme mehr geben).
Gruß,
Jan
Hi Jan,
ja du hast recht, es ist Ubuntu Server 14.04LTS mit php 5.5.9-1.
Redis wurde von externer Quelle installiert (Version Redis-Server 2.8.4) zusätzlich ist auch APCu in der Version 4.0.7-1 drauf.
Ich habe es noch noch mal Schritt für Schritt nach deiner Anweisung oben konfiguriert.
Anscheinend habe ich (oder er wurde nicht sauber ausgeführt) den Schritt mit install php5-redis nicht gemacht. nachdem ich das erledigt hatte ist die Fehlermeldung weg und es läuft ohne Probleme.
dies habe ich noch zusätzlich ausgeführt:
INSTALL THE PHPMODULE FOR REDIS WITH PECL
$~: sudo pecl install -Z redis
Danke
Grüße
mario
Hi Mario,
danke für die Rückmeldung und super, dass es bei dir nun klappt.
Ich sag mal: Einfach die nächste LTS-Version von Ubuntu abwarten. Ich hätte damals, als ich meinen Server aufgesetzt habe, auch gerne die 14.04 LTS eingesetzt, aber hier gab es zu viele Sachen, die nicht ohne manuelles Eingreifen funktioniert haben. Daher bin ich auch schon gespannt auf 16.04 LTS: Hier dürfte dann einiges einfacher sein.
Gruß,
Jan
Vielen Dank für deine ausführliche Erklärung, hat auch mit Raspbian und meinem Pi2 gut funktioniert.
Planst du eine Aktualisierung mit php 7? Denn gerade schwache Rechner sollten davon ja ordentlich profitieren.
Hallo Rumbah,
wenn PHP 7 erst einmal in den offiziellen Ubuntu-Paketquellen zu finden ist, werde ich die Beschreibung auch dahingehend anpassen, bringt ja anscheinend ziemliche Vorteile.
Zuvor werde ich es allerdings bei PHP 5 belassen, auch wenn es über Umwege schon heute möglich wäre. Allerdings bin ich kein Fan von PPA, etc.
Gruß,
Jan
auch von mir ein herzliches dankeschön für die tolle anleitung. ich habe mittlerweile nach einigen tutorials owncloud auf einem raspberry (b+, jessie) zu installieren. mit dieser hier hat es am besten (und verständnisvollsten – danke für die erklärungen zu den einzelnen befehlen!) geklappt.
an einigen stellen haben manche befehle nicht funktioniert, aber mit ein wenig geduld und untersuchen der ordnerstrukturen etc. habe ich es zumindest bis zur einrichtungsseite von owncloud geschafft. jetzt warte ich auf den bestellten 128gb-usbstick, der erstmal ausreichend platz für die daten bereitstellen soll. wenn ich den eingebunden und als data festgelegt habe, werde ich die konfiguration abschließen und mich um die erreichbarkeit von außen kümmern. soweit schaut aber alles super aus!
Hallo,
gibt es für diese top Anleitung später ein Update mit Ubuntu 16.04 bzw. der Owncloud 9 :) (Releasemäßig liegt ja beides nah aneinander)
Das wäre super klasse!
Gruß Bernd
Hallo Bernd,
ja, das ist auf jeden Fall in der Planung. ownCloud 9 dürfte ja wieder einiges an Neuerungen bringen und Ubuntu 16.04 ist als nächster LTS-Release der bessere Unterbau für die eigene Cloud.
Ich weiß nur noch nicht, ob ich einen komplett neuen Artikel verfasse oder den alten Beitrag grundlegend überarbeite. Denn es wird sich sicherlich einiges ändern, gerade die manuellen Anpassungen kann man sich dann wohl unter 16.04 sparen.
Gruß,
Jan
Klaasse!!!
Ich freu mich drauf!
Gruß Bernd
Hallo,
gibt es schon ein release Date für die anleitung Ubuntu 16.04 und OC 9 auf PHP 7 :)
bzw. kommt dazu eine Anleitung?
Gruß Bernd
Hi Bernd,
ja, ist bereits in Arbeit, könnte aber noch ein paar Tage dauern…
Gruß,
Jan
Super DANKE!!! Freu mich schon darauf!!!!
Gruß Bernd
Habe noch ein paar Tage Geduld. ;)
Ich habe aber in der Zwischenzeit den Artikel über die Einrichtung von Ubuntu Server als Hyper-V-Gast aktualisiert: Hier wird nun die Installation von Ubuntu Server 16.04 LTS gezeigt.
Gruß,
Jan
Die installation von PHP schlägt bei mir fehl:
http://pastebin.com/SqLrCQPu
Woran liegt es?
Hallo Lukas,
nutzt du vielleicht schon Ubuntu 16.04? Hier sind nur noch die PHP 7 Pakete in den Paketquellen enthalten.
Gruß,
Jan
Hallo, richtig. Ubuntu 16.04. Danke für den Hinweis. Kann man die älteren PHP Pakete noch integrieren?
Hallo Lukas,
wieso willst du die alten Pakete in 16.04 einbinden? Fehlt dir irgend etwas bei den PHP 7 Paketen? Die PHP 7 Pakete heißen jetzt nur ein wenig anders: Aus php-fpm wird nun z.B. php7.0-fpm.
Ich arbeite übrigens gerade an einem neuen Artikel, der auf Ubuntu 16.04 und ownCloud 9 basiert. Dieser wird nochmals umfangreicher wie dieser hier und sollte mit etwas Glück bald fertig werden.
Gruß,
Jan
Cool, danke. Dann werde ich auf den Artikel warten. Wann dürfte der denn etwa online sein? So grob?
Grüße,
Lukas
Hi!
Ich peile mal das kommende Wochenende oder Mitte nächster Woche an. Lieder fehlt mir dazu im Moment etwas die Zeit, aber der Artikel ist so gut wie fertig.
Gruß,
Jan
Super cool, danke dir dafür!
Hallo Jan
erst mal super Anleitung :d hast du nicht mal lust eine Anleitung zu schreiben wie man den apache2 der bei der Owncloud mit installiert wird zu ersetzen mit Nginx .
sprich wie man einfach im laufenden System von Apache auf Nginx umschaltet ?
angeblich soll das auf einen Raspi3 ja besser rennen oder ?
Hallo Malte,
ja, ist sicher eine gute Idee, sich einfach das owncloud-Paket zu installieren und danach erst Apache zu entfernen und durch nginx zu ersetzen. Vielleicht ist das ja auch eine gute „Abkürzung“ im Vergleich zur traditionellen Vorgehensweise. Ich behalte die Idee mal im Hinterkopf. Zunächst möchte ich erst einmal den neuen Artikel zu Ubuntu 16.04 + ownCloud 9 fertig stellen.
Gruß,
Jan
Hallo,
klasse und umfangreiche Anleitung.
Ich betreibe die OC9.0.3 auf einem Pi3
Ich habe hier im Log folgenden Fehler, dieser kommt alle 15min vor, daher denke ich vom Cron-Job.
Alle PHP.ini Dateien habe ich nochmals geprüft und auch die /etc/nginx/conf.d/myserver.dyndns.org.conf sind nach Anleitung egänzt.
„Error PHP
is_readable(): open_basedir restriction in effect. File(/dev/urandom) is not within the allowed path(s): (/var/www/:/tmp/:/var/oc_data) at /var/www/owncloud/3rdparty/paragonie/random_compat/lib/random.php#66“
Bin gerade ratlos.
Grüße
Jens
Hallo Jens und danke für das Lob,
dieser Fehler wird verursacht durch eine fehlende Zugriffsberechtigung, wenn der Cron-Job laufen soll – da hast du vollkommen recht.
Hier sollte es helfen, /dev/urandom in die „erlaubten“ Verzeichnisse von open_basedir mit aufzunehmen. Dazu einfach die php.ini öffnen, die bei der Ausführung von Cron-Jobs verwendet wird:
nano /etc/php5/cli/php.ini
Anschließend die Variable open_basedir anpassen:
open_basedir = /var/www/:/tmp/:/var/oc_data:/dev/urandom
Nun sollte dieser Fehler nicht mehr auftreten und der Cron-Job ordentlich durchlaufen.
Gruß,
Jan
Hi Jan,
vielen Dank. Fehler ist weg und die OC läuft jetzt ohne Mucken.
Hallo!
Habe nginx soweit installiert.
Probleme gibt es, sobald ich in „/etc/nginx/nginx.conf“ die Zeile „server_tokens off“ einfüge, um die Versionsnummer zu verstecken – dann lässt sich nginx mit „service nginx restart“ nicht mehr neu starten.
Es kommt die Fehlermeldung:
„Job for nginx.service failed because the control process exited with error code. See „systemctl status nginx.service“ and „journalctl -xe“ for details.
Ein weiteres Problem ist, dass sich in „/etc/nginx/“ weder der Ordner „sites-available“, noch „sites-enabled“ und demnach auch keine Datei „default“ befindet!
Benutze die Desktop-Version 16.04 LTS von Ubuntu und nicht die Server-Version.
Hi,
siehe Antwort zum neuen Artikel.
Gruß,
Jan
hi, ich habe die Anleitung befolgt, jedoch bekomme ich nach der Konfiguration von owncloud im Browser den Fehler „404 Not Found“. Nginx Errorlog sagt folgendes:
2016/08/08 18:21:53 [error] 17961#0: *2 open() „/var/www/owncloud/index.php/login“ failed (20: Not a directory), client: 192.168.178.79, server: nekohb.ddns.net, request: „GET /index.php/login HTTP/1.1“, host: „192.168.178.22“
Was kann das bedeuten?
MfG
Hi neko,
das scheint ein recht unspezifischer Fehler zu sein. Ich denke aber mal, dass hier ein Problem mit dem virtuellen Host von ownCloud vorliegt. Kontrollier doch bitte noch einmal, ob dieser Host genau so wie im Tutorial beschrieben aussieht.
Gruß,
Jan