ownCloud erfreut sich als „Selfmade-Cloud“ nach wie vor großer Beliebtheit. Mit der persönlichen Cloud erhält man von überall aus Zugriff auf seine Dateien, Kontakte und Kalender, ohne sich jedoch von Cloud-Anbietern wie Google, Microsoft oder Dropbox abhängig zu machen.
Dieser Artikel zeigt nun die Installation und Konfiguration von ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt.
Zu diesem Thema gibt es bereits einen älteren Beitrag: ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP. Dieser war recht erfolgreich und zeigte, dass das Interesse an dieser Konfiguration gegeben ist. Allerdings steht die Zeit in der IT-Welt ja nicht still, so dass sich mittlerweile einiges geändert hat:
- Mit Ubuntu 16.04 LTS („Xenial Xerus“) wurde die nächste Version des Betriebssystems mit verlängertem Support-Zeitraum veröffentlicht.
- ownCloud unterstützt neuerdings PHP 7 (ab ownCloud 8.2), was deutliche Performance-Verbesserungen mit sich bringt.
- Mit ownCloud 9 ist die nächste große Version der Cloud-Software erschienen.
- Let’s Encrypt (Zertifizierungsstelle für kostenlose SSL-Zertifikate) hat die Beta-Phase verlassen.
Hier haben sich somit viele Faktoren geändert, so dass ich mich dazu entschlossen habe, den alten Artikel nicht zu aktualisieren, sondern einen komplett neuen Beitrag zu verfassen.
Wenn sich zukünftig Änderungen am Vorgehen ergeben, wird der Artikel aktualisiert:
Update-Historie- Update 31.05.2016:
- Gateway-Host angepasst, so dass nun nicht mehr die nginx-Default-Seite angezeigt wird, wenn auf die Haupt-URL zugegriffen wird (owncloud9tutorial.goip.de, ohne /owncloud).
- Hinweis auf die Log-Dateien hinzugefügt – im Fehlerfall geben diese Logs meist einen Hinweis darauf, wo der Fehler liegt.
- Update 07.06.2016:
- Anpassung virtueller Host für ownCloud, damit der PHP-Handler die richtige IP des Remote-Hosts kennt. Diese Anpassung war notwendig, um den Einsatz von Fail2ban zu ermöglichen.
- Update 11.07.2016:
- Hinweis für open_basedir (PHP-Konfiguration) hinzugefügt: Hier müssen alle Verzeichnisse aufgelistet werden, auf die ownCloud später Zugriff haben soll.
- Update 13.07.2016:
- Hinweis hinzugefügt, wenn die Verzeichnisse sites-available/sites-enabled nicht vorhanden sind, oder nginx keine virtuelle Hosts auf diesen Verzeichnissen lädt.
- Update 01.08.2016:
- Es gab vermehrt Hinweise, dass die Verzeichnisse sites-available/sites-enabled für die virtuellen Hosts nicht vorhanden sind. Nach der Installation der aktuellen Programm-Versionen auf einem frisch installierten System nutzt nginx zur Verwaltung der Hosts tatsächlich das Verzeichnis /etc/nginx/conf.d. Die Beschreibung wurde dahingehend angepasst.
- Update 04.08.2016:
- Verbesserungen beim Rewrite von HTTP auf HTTPS (zuvor gab es Probleme beim Erneuern des Let’s Encrypt Zertifikats).
- Update 02.09.2016:
- Vereinfachte Generierung der SSL-Zertifikate, da Let’s Encrypt in den Paketquellen von Ubuntu 16.04 enthalten ist. Ein manuelles Clonen mittels git ist nicht mehr nötig.
- Update 03.09.2016:
- Änderung an den Konfiguration der elliptischen Kurven für ECDHE ciphers in der nginx-Konfiguration (im Gateway-Host). Hier wurde bisher ssl_ecdh_curve secp521r1; empfohlen, allerdings kommt es hier seit Chrome 53 zu Fehlern (ERR_SSL_OBSOLETE_CIPHER). Um dieses Problem lösen ist es notwendig, auf ssl_ecdh_curve secp384r1; auszuweichen.
- Update 20.09.2016:
- listen-Direktive der virtuellen Hosts für Let’s Encrypt und ownCloud angepasst, so dass diese nur noch auf lokale Anfragen reagieren (z.B. listen 127.0.0.1:82;). Dadurch wird verhindert, dass ein Zugriff über das lokale Netzwerk möglich ist, ohne den Gateway-Host zu passieren.
- Update 24.09.2016:
- Hinweis für die Installation von nginx auf einem Raspberry Pi hinzugefügt.
- Update 16.11.2016:
- Hinweis zum Hosten weiterer Web-Anwendungen auf der hier gezeigten Konfiguration hinzugefügt: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)
- Update 06.01.2017:
- Hinweis auf Konfiguration MariaDB in Datei mariadb.cnf
- Update 18.03.2017:
- Hinweis auf ownCloud Vulerability Scanner/Nextcloud Security Scan hinzugefügt
Zielsetzung und Aufwand
Folgende Ziele sollen mit diesem Artikel erreicht werden:
- Installation/Konfiguration von ownCloud 9 unter Linux (Ubuntu Server 16.04 LTS) mit nginx (Webserver), MariaDB (Datenbank) und PHP 7.
- Erhöhte Sicherheit (PHP-Konfiguration, SSL, ownCloud-Konfiguration laut ownCloud Server Administration Manual).
- Verschlüsselte Verbindung (SSL/HTTPS mit Let’s Encrypt Zertifikat) zur ownCloud über das lokale Netzwerk und über das Internet (DynDNS).
- ownCloud soll in einem Unterverzeichnis des Webservers liegen, d.h. nicht über meinedomain.de, sondern über meinedomain.de/owncloud erreichbar sein. Dies macht es möglich, dass mehrere Webseiten über die gleiche Domain gehostet werden können.
- Im Administrator-Bereich der ownCloud sollen keine Warnungen/Fehler bzgl. Sicherheit und Konfiguration angezeigt werden.
Folgende Programmversionen kommen dabei zum Einsatz.
- Ubuntu Server 16.04.1 LTS („Xenial Xerus“)
- nginx 1.11.3
- MariaDB 10.1.17
- PHP 7
- ownCloud 9.0.2
Zeitaufwand: ca. 3 Stunden
Wichtig: Alle gezeigten Schritte sind auf die o.g. Zielsetzung ausgerichtet und sollten daher genau befolgt werden. Wenn man nur ein kleines Detail übersieht (oder leicht anders macht), kann es im weiteren Verlauf zu Fehlern führen.
Falls es mal klemmen sollte: Bevor das Rätselraten losgeht, wo es nun genau hakt, sollte man auf jeden Fall zunächst einen Blick in die Logs werfen (im Verzeichnis /var/log/). Besonders das nginx Error-Log bringt einen meist auf die richtige Fährte.
Warum die Kombination mit nginx und MariaDB Sinn macht
An dieser Stelle vielleicht erst einmal ein paar Worte, warum ich mich für diese Kombination entschieden habe und welche Vorteile sich hierdurch ergeben:
Der Begriff „LAMP-Stack“ dürfte dem einen oder anderen gebräuchlich sein. Dabei handelt es sich quasi um die Standard-Umgebung, wenn es darum geht, dynamische Webseiten zu hosten: Linux, Apache, MySQL und PHP.
Natürlich kann ownCloud auf einem solchen LAMP-Stack betrieben werden: Bei der Installation der offiziellen ownCloud-Pakete bringen diese automatisch Apache, MySQL und PHP mit, sofern noch nicht auf dem System vorhanden.
Warum zeigt der Artikel nun die Installation mit einem anderen Webserver und einem anderen Datenbank-System? Die Kombination Linux, nginx, MariaDB/MySQL und PHP wird dabei auch als LEMP-Stack bezeichnet.
Gerade der Einsatz von nginx als Webserver und MariaDB als DB-System bieten dabei einige Vorteile:
- nginx arbeitet ressourcenschonender als Apache: Dies hängt zum großen Teil damit zusammen, wie die Webserver Verbindungen zu den Clients abarbeiten. Während Apache pro Verbindung neue Prozesse bzw. Threads erstellt, was bei vielen gleichzeitigen Connections sehr speicherintensiv ist, arbeitet nginx mit einem Thread-Pool. Dies ist eine feste, konfigurierbare Anzahl an Threads, die die Verbindungen asynchron abarbeiten.
Somit ist nginx klar im Vorteil, wenn viele Verbindungen gleichzeitig abzuarbeiten sind, oder auch, wenn nur begrenzte Hardware-Ressourcen zur Verfügung stehen (z.B. auf einem Raspberry Pi). - MariaDB ging ursprünglich aus einem Fork von MySQL hervor. Dabei ist MariaDB bis heute binärkompatibel zu MySQL, d.h. ist ein 1:1-Ersatz für MySQL (sog. drop-in replacement) und alle von MySQL bekannten Befehle/Tools funktionieren damit auch mit MariaDB. Die Entscheidung, ob man nun MariaDB oder MySQL als Datenbank für ownCloud verwendet, ist daher zunächst eher nebensächlich.
Jedoch haben Ende 2012 etliche Linux-Distributionen MySQL durch MariaDB als Standard-Datenbanksystem ersetzt. MariaDB macht momentan einen sehr zukunftssicheren Eindruck, daher fiel die Wahl bei diesem Artikel auf MariaDB. Wer dennoch gerne MySQL einsetzen möchte, kann dies auch gerne tun. 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 16.04 LTS („Xenial Xerus“). Für einen eigenen Home-Server bietet sich v.a. auf die Verwendung einer LTS-Version (Long Term Support) von Ubuntu an, da diese Versionen einer verlängerten Support-Zeitraum haben. Daher können LTS-Versionen über einen langen Zeitraum betrieben werden, ohne dass die Notwendigkeit besteht, jedes Distributions-Update durchzuführen.
Generell ist die eingesetzte Linux-Distribution allerdings unerheblich. Die Installation von ownCloud und den benötigten Komponenten funktioniert auf anderen Distributionen (z.B. Debian) nahezu identisch.
Auch die verwendete Server-Hardware ist nicht weiter entscheidend. 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.
Es ist ebenso möglich, eine virtuelle Linux-Maschine (VM) für ein ownCloud-Projekt zu verwenden. Wie man Ubuntu Server mittels Hyper-V auf einem Windows-Rechner installiert und optimal einrichtet, zeigt der Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten. Besonders reizvoll ist diese Vorgehensweise, da mit einer virtuellen Maschine „Prüfpukte“ definiert werden können. Dies sind Snapshots der VM, die den Zustand der Maschine speichern. Falls bei der Installation/Einrichtung etwas schieflaufen sollte, kann man in wenigen Sekunden das System wieder auf einen früheren Zeitpunkt zurück setzen. Darüber hinaus kann die automatische Sicherung einer (Hyper-V)-VM leicht in eine bestehende Backup-Strategie mit eingebunden werden. Dies macht Client-seitige Backups (fast) überflüssig.
Zugriff per SSH
Nach der Installation des Betriebssystems ist lässt man einen Server üblicherweise „headless“ laufen, d.h. ohne Monitor, Maus und Tastatur. Der Zugriff erfolgt dann normalerweise aus der Ferne per SSH (z.B. mit PuTTY). Eine genauere Beschreibung hierzu findet man ebenfalls im Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten.
DynDNS
Damit der Zugriff auf die eigene Cloud später nicht nur auf das lokale Netzwerk begrenzt ist, sondern auch über das Internet möglich ist, sollte 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), wodurch ein Zugriff sehr erschwert wird. Dazu kann ein beliebiger DynDNS-Dienst genutzt werden.
Aus eigener Erfahrung kann ich hier den kostenlosen DynDNS-Dienst GoIP empfehlen. Im Artikel verwende ich daher beispielhaft die DynDNS-Adresse owncloud9tutorial.goip.de.
Sehr zuverlässig ist auch der Webhoster All-inkl.com: Ab dem Webhosting-Paket „PrivatPlus“ ist ebenfalls ein DynDNS-Dienst enthalten, mit dem ich noch nie Probleme (Downtime, etc.) hatte.
Arbeiten mit Root-Rechten
Ein letzter Hinweis, bevor es endlich losgehen kann: Für die Konfiguration und Einrichtung von ownCloud und aller benötigter Programme, ist es meist erforderlich, mit Root-Rechten zu arbeiten. 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.
Genug der Vorrede, nun geht es endlich los…
Updates einspielen
Zunächst bringen wir das System auf den aktuellsten Stand:
apt-get update && apt-get upgrade && apt-get dist-upgrade reboot
Dieser Befehl aktualisiert die Paket-Liste, installiert verfügbare Updates und spielt auch die Updates ein, die neue Pakete oder deren Abhängigkeiten mitbringen.
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. Da sich diese IP bei jedem Neustart des Rechners ändern kann, ist dies für einen Server nicht gerade optimal. Daher wird zunächst eine statische IP-Adresse zugewiesen. 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. Diese Einstellungen müssen im konkreten Fall an die eigene Netzwerk-Infrastuktur angepasst werden.
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.
Hinweis: Durch diese Änderung ist es oftmals nicht mehr möglich, den Rechner mit seinem Rechnernamen im Netzwerk anzusprechen (v.a. beim SSH-Zugriff per PuTTY). Hier sollte ab jetzt auch immer die angegebene IP-Adresse verwendet werden, die sich ja auch nicht mehr ändert.
Programm-Installation
Vor der ownCloud-Installation benötigen wir nun zunächst einmal den Webserver (nginx), MariaDB und PHP.
nginx installieren
In den Paketquellen von Ubuntu 16.04 ist nginx 1.10.0 enthalten, also eine recht aktuelle Version. Um dennoch unabhängig von den Ubuntu-Paketquellen zu sein, empfehle ich, das offizielle nginx-Repository in die Paketquellen mit aufzunehmen. Allerdings ist es auch kein Problem, diesen Schritt zu überspringen und die jeweilige nginx-Version zu verwenden, die in den Ubuntu-Paketquellen enthalten ist. Letzten Endes ist dies Geschmackssache.
Hinweis für Raspberry Pi BenutzerDie nachfolgenden Schritte sind für Benutzer eines Raspberry Pi nicht notwendig. In den offiziellen Paketquellen von nginx ist kein Paket für die ARM-Architektur vorhanden, die für einen Raspberry Pi benötigt wird. Daher wird hier empfohlen, auf die nginx-Version zurück zu greifen, die in den Paketquellen von Raspbian enthalten ist. Hier reichen zur Installation des Webservers folgende Befehle:
apt-get update apt-get install nginx
Um später keine Warnungen bei der Installation des Webservers angezeigt zu bekommen, muss der Schlüssel des nginx-Repositories im System bekannt gemacht werden:
wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -
Anschließend werden die Paketquellen in die sources.list hinzugefügt:
nano /etc/apt/sources.list
Dazu wird am Ende dieser Datei folgender Inhalt eingefügt. Wenn eine andere Distribution/Version zum Einsatz kommt, müssen diese Zeilen angepasst werden (siehe nginx: Linux packages).
# Nginx (Mainline) deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx
Hinweis: Diese Zeilen sorgen dafür, dass die Mainline-Version von nginx genutzt wird. Die Mainline stellt den aktuellen Entwicklungszweig dar und gilt als stabil. Es gibt darüber hinaus noch den Stable-Entwicklungszweig. Dieser ist ein Fork aus dem Mainline-Entwicklungszweig, der aber nicht unbedingt stabiler ist als die Mainline (siehe nginx-Blogbeitrag). 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
Bei der Installation von MariaDB verhält es sich ähnlich wie schon bei nginx zuvor: Man kann die Version nehmen, die in den Paketquellen von Ubuntu enthalten ist (10.0), oder man fügt für größere Flexibilität das MariaDB-Repository manuell den Paketquellen hinzu. Auf diese Weise kann man die neuste Version von MariaDB installieren (10.1).
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 (sonst gibt es im weiteren Verlauf u.U. Warnungen):
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
Dann werden die Paketquellen hinzugefügt:
nano /etc/apt/sources.list
Folgende Zeilen fügen wir am Ende der Datei hinzu. Auch hier muss bei einer anderen Distribution/Version etwas anderes angegeben werden (siehe Repository Configuration Tool weiter oben).
# MariaDB 10.1 repository list # http://mariadb.org/mariadb/repositories/ deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu xenial main deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu xenial main
Nun kann die Datenbank installiert werden:
apt-get update apt-get install mariadb-server
Im Rahmen der Installation wird auch gleich ein Root-Passwort für den Datenbank-Zugriff festgelegt. Aus Sicherheitsgründen sollte man diesen Schritt nicht überspringen und ein ausreichend sicheres Passwort angeben:
PHP installieren
Nun fehlt nur noch die Installation von PHP. Wir nehmen hier die neuste Version von PHP (PHP 7), da diese praktischerweise in den Paketquellen von Ubuntu 16.04 enthalten ist und im Vergleich zu PHP 5 (ja, die Vorgängerversion von PHP 7 war tatsächlich PHP 5) deutliche Performance-Vorteile mit sich bringt.
Die ownCloud-Dokumentation liefert einen Hinweis auf die benötigten Pakete. Aktuell werden noch die Pakete für PHP 5 gelistet, diese sind prinzipiell aber auch für PHP 7 verfügbar. Einige dieser Pakete werden nur benötigt, wenn spezielle Features von ownCloud zum Einsatz kommen sollen.
Es können durchaus noch mehr Pakete notwendig sein, wenn spezielle Features von ownCloud zum Einsatz kommen sollen, aber für den Anfang reicht die Installation folgender Pakete:
apt-get update apt-get install php7.0-fpm php7.0-gd php7.0-mysql php7.0-curl php7.0-xml php7.0-zip php7.0-intl php7.0-mcrypt php7.0-mbstring php7.0-bz2 php-apcu
Wenn später weitere Pakete benötigt werden, können diese jederzeit nachinstalliert werden.
Konfiguration des Servers
Nachdem nun alle benötigten Programm-Pakete installiert sind, müssen diese vor der Installation von ownCloud noch konfiguriert werden.
Konfiguration nginx (Teil 1)
Die meiste Arbeit macht dabei die Konfiguration des Webservers. Ich habe mich bemüht, diesen Abschnitt relativ kompakt zu halten, jedoch ist die nginx-Konfiguration leider etwas komplexerer Natur. Hier macht es durchaus Sinn, sich mit der Funktionsweise von nginx auseinander zu setzen. Gerade wenn es im weiteren Verlauf etwas hakt, ist es nur von Vorteil, wenn man sich ein wenig mit der Materie auskennt.
Virtuelle Hosts und Konfigurations-Dateien von nginx
Mit nginx können (ähnlich wie bei Apache) virtuelle Hosts definiert werden. Ein virtueller Host stellt dabei eine separate Konfiguration für eine Website/Webdienst/Webanwendung dar. Dabei spielen folgende Dateien und Verzeichnisse eine entscheidende Rolle:
- /etc/nginx/nginx.conf: Globale Konfigurations-Datei von nginx. Hier werden die globalen Einstellungen definiert.
- /etc/nginx/conf.d: In diesem Verzeichnis werden die virtuellen Hosts gespeichert. Pro Host wird dazu eine Datei mit der Endung *.conf angelegt. Alle Dateien mit einer anderen Dateiendung werden dabei ignoriert (dies kann genutzt werden, um virtuelle Hosts gezielt an- und abzuschalten).
Dabei arbeiten all diese Konfigurations-Dateien zusammen: Die globale Konfiguration vererbt alle Einstellungen an die Konfigurationen der aktiven virtuellen Hosts. Ein virtueller Host kann dabei eine geerbte Einstellung jederzeit überschreiben.
Sinnvolle Aufteilung in mehrere virtuelle Hosts
Warum sollte man nun mehrere virtuelle Hosts verwenden? Reicht hier nicht ein virtueller Host aus?
In diesem Artikel geht es hauptsächlich um die Einrichtung von ownCloud. Hierfür würde prinzipiell ein einzelner virtueller Host vollkommen ausreichen. Dennoch sollte ein Webserver so flexibel sein, dass auch mehrere Webanwendungen über den gleichen Server gehostet werden können. So könnte beispielsweise später der Wunsch aufkommen, neben ownCloud auch noch einen kleinen WordPress-Blog auf der gleichen Maschine zu betreiben.
Um diese Flexibilität zu erreichen, gibt es nun verschiedene Ansätze:
- Ein einzelner virtueller Host: Hierbei werden alle Webseiten über den gleichen virtuellen Host konfiguriert. Auf den ersten Blick ist dies vermutlich die einfachste Lösung, jedoch wird die Konfigurations-Datei hierbei schnell unübersichtlich und es steigt das Risiko, dass man sich durch einen kleinen Fehler in der Konfiguration alle gehosteten Webanwendungen lahmlegt.
- Ein virtueller Host pro Webanwendung: Hierbei werden die Konfigurationen pro Webseite/Webanwendung strikt getrennt. Damit ist so gut wie ausgeschlossen, dass Änderungen an einem virtuellen Host die jeweils andere Webanwendung beeinflussen kann. Daher ist dieser Ansatz deutlich flexibler und weniger fehleranfällig.
Dennoch gibt es hierbei ein Problem: Ein virtueller Host wird durch einen Server-Namen (die URL) und einen Port definiert. Die Kombination aus Name und Port muss sich dabei von allen anderen virtuellen Hosts unterscheiden. In unserem Fall wird aber immer die gleiche URL (die DynDNS-Adresse) verwendet, da die meisten Router keine Möglichkeit bieten, sich zeitgleich über mehrere DynDNS-Adressen anzumelden. Daher müssen sich hier gezwungenermaßen die Ports der Webanwendungen unterscheiden. Dies ist aber eher unkomfortabel, da zum einen mehrere Ports in der Firewall des Routers geöffnet werden müssen (Sicherheitsrisiko), zum anderen müssen alle Clients die richtigen Ports verwenden (in jeder URL-Eingabe muss der konkrete Port spezifiziert werden). Dies macht diese Lösung nicht sehr benutzerfreundlich und ich rate eher davon ab. - Mehrere virtuelle Hosts + Reverse-Proxy: Es gibt allerdings auch einen weiteren Ansatz, mit dem man die Flexibilität von getrennten virtuellen Hosts und gleichzeitig nicht die oben genannten Nachteile hat. Dabei dient ein zentraler virtueller Host als Gateway (mit der DynDNS-Adresse und den Standard-Ports 80 und 443). Dieser „Gateway-Host“ bedient sich nun den Reverse-Proxy-Fähigkeiten von nginx, um eine Anfrage eines Clients gezielt an weitere virtuelle Hosts weiter zu leiten. Die Hosts der einzelnen Webanwendungen laufen mit dem gleichen Server-Namen (die lokale IP) und auf getrennten Ports. Da dies aber alles lokal auf dem Webserver geschieht, müssen keine weiteren Ports nach außen hin geöffnet werden. Der zentrale Anlaufpunkt für alle Clients ist dabei immer der Gateway-Host, der die Anfragen dann zielgerichtet an andere virtuelle Hosts (oder sogar andere Webanwendungen) weiterleitet.
Die letzte Lösung ist mit Abstand die flexibelste, aber leider auch die komplizierteste. Dennoch habe ich mich dazu entschieden, diesen Ansatz im weiteren Verlauf des Artikels zu verfolgen.
Als praxistaugliches Beispiel soll hier neben ownCloud auch ein virtueller Host speziell für die Erzeugung eines Let’s Encrypt Zertifikats genutzt werden (mehr Informationen zu Let’s Encrypt folgen später). Durch ein konkretes Beispiel sollte das Vorgehen dabei leicht verständlich sein.
Wenn neben ownCloud auch weitere Web-Anwendungen gehostet werden sollen:
Let’s Encrypt ist natürlich keine „echte“ Web-Applikation im eigentlichen Sinne, daher ist das hier gezeigte Beispiel evtl. nicht wirklich repräsentativ. Daher habe ich in einem weiteren Artikel (der auf diesem Tutorial aufbaut) die Einrichtung einer weiteren Web-Anwendung am Beispiel von WordPress durchgespielt und meine Erfahrungen geschildert: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress). Dabei gilt es einiges zu beachten, aber der Beitrag sollte auf jeden Fall einen Anhaltspunkt liefern, auch wenn es sich bei der Anwendung nicht um WordPress handeln sollte.
Leider können nicht einfach alle Konfigurations-Dateien bzw. virtuelle Hosts auf einmal erstellt werden, da zunächst die Erzeugung eines SSL-Zertifikats notwendig ist, um mit den folgenden Schritten fortzufahren. Daher werden sämtliche Konfigurationen des Webservers sukzessive vorgenommen (Reihenfolge ist wichtig!).
Hinweis: Wer kein Let’s Encrypt Zertifikat verwenden möchte, kann auch ein selbst signiertes Zertifikat erzeugen und verwenden. Was dafür zu tun ist, ist im alten Artikel über ownCloud auf Ubuntu Server erklärt (Abschnitt Selbst signiertes Zertifikat erstellen). Man sollte sich nur darüber im Klaren sein, dass ein selbst signiertes Zertifikat auch Nachteile mit sich bringt (z.B. Warnungen in Browsern).
Wenn sein selbst signiertes Zertifikat zum Einsatz kommt, können hier alle Schritte übersprungen werden, die mit der Generierung und Einbindung des Let’s Encrypt Zertifikats zusammenhängen.
Allgemeine nginx-Konfiguration anpassen
Zunächst werfen wir einen Blick auf die globale nginx-Konfiguration:
nano /etc/nginx/nginx.conf
Hier sollten eigentlich keine Anpassungen notwendig sein, da die Standard-Werte in den meisten Fällen bereits passen. Die wichtigsten Einstellungen sind dabei:
- user: Gibt den Benutzer an, unter dem der Webserver läuft. Dies sollte der User www-data sein.
- worker_processes: Gibt die Anzahl der Threads an, die zum Abarbeiten der Verbindungen genutzt werden. Wird hier auto angegeben, wird pro CPU-Kern ein Thread angelegt. Dies ist in den meisten Fällen auch die richtige Einstellung.
- server_tokens: Durch die Angabe off wird verhindert, dass nginx (z.B. auf Fehlerseiten) Versions-Informationen präsentiert. Aus Sicherheitsgründen sollte man dies ausstellen. Dies ist die einzige Variable, die man hier manuell hinzufügen muss (server_tokens off; im HTTP-Block dieser Datei).
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 benennt man einfach die Datei /etc/nginx/conf.d/default.conf um:
mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf_disabled
Durch das Ändern der Dateiendung wird dieser virtuelle Host nicht mehr geladen, jedoch geht die Standard-Konfiguration dadurch auch nicht verloren (man könnte diese Datei auch einfach löschen).
Vorbereitung der Verzeichnisstruktur
Zunächst werden die Verzeichnisse für Let’s Encrypt und ownCloud angelegt. Die Besitzrechte sollten dabei beim Webserver-User (www-data) liegen:
mkdir -p /var/www/letsencrypt mkdir -p /var/www/owncloud mkdir -p /var/owncloud_data chown -R www-data:www-data /var/www chown -R www-data:www-data /var/owncloud_data
Anlegen des „Gateway-Hosts“
Nun gilt es zunächst einmal den virtuellen Host für den Gateway anzulegen. Dieser nimmt zunächst nur die Verbindungen von Clients entgegen und leitet diese an weitere virtuelle Hosts weiter, die dann quasi die Arbeit erledigen.
Zum jetzigen Zeitpunkt soll zunächst nur einmal die Weiterleitung an einen Let’s Encrypt Host stattfinden.
Dazu legen wir im ersten Schritt den Gateway-Host an. Der Name der Datei ist erst einmal unwichtig, ich benenne diese einfach wie die (Haupt-)Domain:
nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf
Hier fügen wir nun folgenden Inhalt ein:
server {
listen 80 default_server;
server_name owncloud9tutorial.goip.de 192.168.178.20;
root /var/www;
location ^~ /.well-known/acme-challenge {
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
}
Dieser virtuelle Host lauscht somit zunächst nur einmal auf Port 80 (HTTP) und hört auf die DynDNS-URL bzw. die lokale IP des Servers. Der einzige location-Block wird später für die Erzeugung des SSL-Zertifikats benötigt und leitet die Anfrage auf einen anderen virtuellen Host weiter (proxy_pass).
Anlegen des Hosts für Let’s Encrypt
Der nächste Schritt besteht nun darin, den virtuellen Host für Let’s Encrypt anzulegen. „Spezialisierte“ Hosts kennzeichne ich mit einem zusätzlichen Unterstrich und dem Namen des Dienstes:
nano /etc/nginx/conf.d/owncloud9tutorial.goip.de_letsencrypt.conf
Dieser Host ist dabei sehr einfach aufgebaut:
server {
listen 127.0.0.1:81;
server_name 127.0.0.1;
location ^~ /.well-known/acme-challenge {
default_type text/plain;
root /var/www/letsencrypt;
}
}
Gelauscht wird auf 127.0.0.1:81. Hier könnte man auch einen anderen beliebigen Port verwenden, dieser muss nur mit dem Port des proxy_pass des Gateway-Hosts übereinstimmen. Dadurch, dass auf der Loopback-Adresse 127.0.0.1 gelauscht wird und mit dem entsprechenden server_name sorgt man dafür, dass dieser virtuelle Host nur auf dem lokalen Rechner aufgerufen werden kann. Dadurch wird es unmöglich, diesen Host direkt anzusprechen, d.h. ohne vorher den Gateway-Host passiert zu haben.
Nach einem Neustart von nginx sind wir nun bereit, das SSL-Zertifikat erzeugen zu lassen:
service nginx restart
SSL-Zertifikat mit Let’s Encrypt erzeugen
Die Konfiguration des Webservers ist nun soweit abgeschlossen, dass zunächst das SSL-Zertifikat generiert werden kann
Port-Forwarding einrichten
Hierfür ist es wichtig, dass der Server auch aus dem Internet aus erreichbar ist. Hierfür muss ein Port-Forwarding für die Ports 80 (HTTP) und 443 (HTTPS) im Router konfiguriert werden, ansonsten ist die VM nur im lokalen Netzwerk erreichbar.
Das Einrichten von Port-Forwarding unterscheidet sich von Router zu Router. Das hier gezeigte Vorgehen bezieht sich auf eine FritzBox:
- Die Erweiterte Ansicht muss aktiv sein (Menü rechts neben den MyFritz! Einstellungen).
- Unter Internet > Freigaben öffnen wir den Reiter Portfreigaben.
- Hier klickt man auf den Button Neue Portfreigabe.
- Portfreigabe aktiv für: Andere Anwendungen.
- Bezeichnung: beliebig (z.B. HTTP).
- Protokoll: TCP
- von Port/bis Port: 80
- an Computer: Name der VM (in diesem Fall UbuntuServerTest) oder IP-Adresse (192.168.178.20)
- an Port: 80
Das gleiche muss noch einmal für Port 443 (HTTPS) wiederholt werden, da ansonsten der verschlüsselte Zugriff per HTTPS nicht möglich ist. Bitte zwei einzelne Portfreigaben einrichten und nicht eine einzige mit Freigabe-Ports 80 bis 443: hier würde man unnötigerweise zu viele Ports öffnen.
Darüber hinaus muss auch DynDNS auf dem Router eingerichtet werden. Das Vorgehen dazu ist abhängig vom verwendeten Router und auch vom DynDNS-Anbieter. Wie man DynDNS mit GoIP auf verschiedenen Routern einrichtet, ist detailliert auf der GoIP-Hilfeseite erklärt.
Erzeugung eines SSL-Zertifikats mittels Let’s Encrypt
Eine gute Anleitung zum Erzeugen von Let’s Encrypt Zertifikate auf verschiedenen Betriebssystemen und Webservern findet man auf der Certbot-Homepage.
Bei Ubuntu 16.04 ist Let’s Encrypt bereits in den Paketquellen enthalten, daher entfällt das manuelle Clonen des Repositories mittels git. Zur Installation reicht ein
apt-get install letsencrypt
Die eigentliche Erzeugung der Zertifikate wird mit folgendem Befehl angestoßen:
letsencrypt certonly --webroot -w /var/www/letsencrypt -d owncloud9tutorial.goip.de --rsa-key-size 4096
Hier wird zunächst nach einer E-Mail-Adresse gefragt. Diese dient in erster Linie dazu, Benachrichtigungen zu bald ablaufenden Zertifikaten zu versenden (Let’s Encrypt Zertifikate sind nur 90 Tage lang gültig, daher müssen diese nach einer gewissen Zeit erneuert werden). Hier sollte man also eine gültige Mail-Adresse angeben.
Nach dem Bestätigen der Nutzungsbedingungen erfolgt die Generierung des Zertifikats automatisch und ohne weiteres Zutun des Benutzers.
Das Programm sollte nun eine Erfolgsmeldung ausgeben, daraufhin findet man die Zertifikate im Verzeichnis /etc/letsencrypt/live/owncloud9tutorial.goip.de:
- 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
Erweiterte Sicherheit: Diffie-Hellman-Parameter
Mit einem SSL-Zertifikat hat man bereits einen großen Schritt für eine verschlüsselte Verbindung zur eigenen ownCloud getan. Um die Sicherheit jedoch noch weiter zu erhöhen, empfiehlt es sich, sog. Diffie-Hellman-Parameter zu generieren. Dieses Thema ist reichlich komplex, sorgt aber einfach ausgedrückt für einen sicheren Schlüsselaustausch beim Verbindungsaufbau.
Die Generierung der Parameter ist dagegen recht einfach und erfolgt über folgenden Befehl:
mkdir -p /etc/nginx/ssl openssl dhparam -out /etc/nginx/ssl/dhparams.pem 2048
Zugriffsberechtigungen für Zertifikat-Dateien setzen
Damit nicht jeder Benutzer freien Zugriff auf die Zertifikat-Dateien hat, sollten hier die Zugriffsberechtigungen eingeschränkt werden, so dass nur noch der Besitzer der Dateien Lese- bzw. Schreibrecht hat:
chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/fullchain.pem chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/privkey.pem chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/chain.pem chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/cert.pem chmod 600 /etc/nginx/ssl/dhparams.pem
Erneuerung der Zertifikate nach 90 Tagen
Wie bereits erwähnt, sind die Let’s Encrypt Zertifikate nur 90 Tage lang gültig. Für den Webserver-Betreiber bedeutet dies, dass die Zertifikate spätestens alle 90 Tage erneuert werden müssen. Wenn ein Zertifikat in einigen Tagen ungültig werden wird, erhält man auch automatisch eine E-Mail von Let’s Encrypt, die einen an die Erneuerung des Zertifikats erinnert.
Dann reicht einfach ein erneuter Aufruf von Let’s Encrypt:
letsencrypt certonly --webroot -w /var/www/letsencrypt -d owncloud9tutorial.goip.de --rsa-key-size 4096
Alle weiteren Schritte (Diffie-Hellman-Parameter erzeugen, Verzeichnisrechte anpassen) sind dann nicht mehr notwendig, da lediglich die eigentlichen Zertifikat-Dateien ausgetauscht werden.
Konfiguration nginx (Teil 2)
Mit dem vorliegenden Zertifikat kann nun die Konfiguration von nginx abgeschlossen werden.
Gateway-Host für ownCloud vorbereiten
Dazu wird der „Gateway-Host“ für ownCloud erweitert. Generell sollten alle Verbindungen zu unserem Webserver verschlüsselt über HTTPS ablaufen, nicht nur die Kommunikation zur ownCloud. Daher enthält der Gateway sämtliche Einstellungen zu verschlüsselten Verbindungen.
nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf
Die hinzugefügten Abschnitte sind markiert:
server {
listen 80 default_server;
server_name owncloud9tutorial.goip.de 192.168.178.20;
root /var/www;
location ^~ /.well-known/acme-challenge {
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
location / {
# Enforce HTTPS
return 301 https://$server_addr$request_uri;
# Use this if you always want to redirect to the DynDNS address (no local access).
#return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2;
server_name owncloud9tutorial.goip.de 192.168.178.20;
#
# Configure SSL
#
ssl on;
# Certificates used
ssl_certificate /etc/letsencrypt/live/owncloud9tutorial.goip.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/owncloud9tutorial.goip.de/privkey.pem;
# Not using TLSv1 will break:
# Android <= 4.4.40
# IE <= 10
# IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
ssl_protocols TLSv1.2;
# 100 % Security
# Low Compatibility
# No Android 2
# No Java
# No IE < 11 (XP)
# No Firefox
# Robust Forward Secrecy
#ssl_ciphers 'AES256+EECDH:AES256+EDH:!aNULL';
# These are the recommended cipher suites from: https://wiki.mozilla.org/Security/Server_Side_TLS
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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
# Nginx for Modern Browsers (uncomment this when the other ssl_ciphers won't work for you)
# Grade A (A+ with HSTS at >= 6 Months)
# 90 % Security
# Medium Compatibility
# No Java 6 (No DH parameters > 1024 bits)
# No IE on XP
# Robust Forward Secrecy
#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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
# Specifies a curve for ECDHE ciphers.
# Remarks: This won't work on Chrome 53 (ERR_SSL_OBSOLETE_CIPHER)
#ssl_ecdh_curve secp521r1;
# Slightly lower security, but will work on
# - Chrome 53
# - Windows phones before 8.1 Update 1
ssl_ecdh_curve secp384r1;
# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;
# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/owncloud9tutorial.goip.de/fullchain.pem;
# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
#
# Add headers to serve security related headers
#
# HSTS (ngx_http_headers_module is required)
# In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Content-Type-Options nosniff;
# Usually this should be "DENY", but when hosting sites using frames, it has to be "SAMEORIGIN"
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
location = / {
# Disable access to the web root, otherwise nginx will show the default site here.
deny all;
}
location ^~ /owncloud {
# Set max. size of a request (important for uploads to ownCloud)
client_max_body_size 1G;
# Besides the timeout values have to be raised in nginx' owncloud config, these values have to be raised for the proxy as well
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
send_timeout 300;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:82;
proxy_redirect off;
}
}
Virtuellen Host für ownCloud anlegen
Nachdem der Gateway-Host für ownCloud vorbereitet wurde, ist es nun an der Zeit einen speziellen virtuellen Host für ownCloud anzulegen:
nano /etc/nginx/conf.d/owncloud9tutorial.goip.de_owncloud.conf
Der komplette Inhalt dieser Datei sieht dann folgendermaßen aus:
upstream php-handler {
server unix:/run/php/php7.0-fpm.sock;
}
server {
listen 127.0.0.1:82;
server_name 127.0.0.1;
# Add headers to serve security related headers
# Use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
proxy_set_header X-Content-Type-Options nosniff;
proxy_set_header X-Frame-Options "SAMEORIGIN";
proxy_set_header X-XSS-Protection "1; mode=block";
proxy_set_header X-Robots-Tag none;
proxy_set_header X-Download-Options noopen;
proxy_set_header X-Permitted-Cross-Domain-Policies none;
# Path to the root of your installation
root /var/www/;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /owncloud/public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /owncloud/public.php?service=host-meta-json last;
location = /.well-known/carddav { return 301 $scheme://$host/owncloud/remote.php/dav; }
location = /.well-known/caldav { return 301 $scheme://$host/owncloud/remote.php/dav; }
location /.well-known/acme-challenge { }
location ^~ /owncloud {
# set max upload size
client_max_body_size 1G;
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;
location /owncloud {
rewrite ^ /owncloud/index.php$uri;
}
location ~ ^/owncloud/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/owncloud/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^/owncloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
include fastcgi_params;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
# Important: disable HTTPS, otherwise no log in will be possible!
#fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
# Raise timeout values.
# This is especially important when the ownCloud setup runs into timeouts (504 gateway errors)
fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_connect_timeout 300;
# Pass PHP variables directly to PHP.
# This is usually done in the php.ini. For more flexibility, these variables are configured in the nginx config.
# All the PHP parameters have to be set in one fastcgi_param. When using more 'fastcgi_param PHP_VALUE' directives, the last one will override all the others.
fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/owncloud_data:/dev/urandom
upload_max_filesize = 1G
post_max_size = 1G
max_execution_time = 3600";
# Make sure that the real IP of the remote host is passed to PHP.
fastcgi_param REMOTE_ADDR $http_x_real_ip;
}
location ~ ^/owncloud/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location ~* \.(?:css|js)$ {
try_files $uri /owncloud/index.php$uri$is_args$args;
proxy_set_header Cache-Control "public, max-age=7200";
# Add headers to serve security related headers
# Again use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
proxy_set_header X-Content-Type-Options nosniff;
proxy_set_header X-Frame-Options "SAMEORIGIN";
proxy_set_header X-XSS-Protection "1; mode=block";
proxy_set_header X-Robots-Tag none;
proxy_set_header X-Download-Options noopen;
proxy_set_header X-Permitted-Cross-Domain-Policies none;
# Optional: Don't log access to assets
access_log off;
}
location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
try_files $uri /owncloud/index.php$uri$is_args$args;
# Optional: Don't log access to other assets
access_log off;
}
}
}
Noch ein paar Erläuterungen zu dieser Konfiguration:
- Es wird hier kein HTTPS-Server definiert. Trotzdem läuft die Verbindung verschlüsselt über HTTPS, da der Gateway-Host für die Verschlüsselung sorgt.
- Gelauscht wird wieder über die Loopback-Adresse (127.0.0.1:82). Zusammen mit dem entsprechenden server_name ist wiederum sicher gestellt, dass keine direkte Verbindung zu diesem virtuellen Host aufgebaut werden kann (ohne den Gateway-Host zu passieren).
- Die proxy_set_header Anweisungen sind für die erhöhte Sicherheit notwendig. Ohne diese Einträge werden später Warnungen im Admin-Bereich von ownCloud angezeigt. In vielen Tutorials werden diese Header per add_header angegeben. In unserem Fall funktioniert dies nicht, da die Zugriffe über einen Proxy (Gateway-Host) ablaufen. Daher werden die Header mittels proxy_set_header angegeben.
- Der PHP-Handler (der in diesem Fall nur für ownCloud zuständig ist) beinhaltet neben den Anweisungen, die für ownCloud wichtig sind, auch noch weitere Parameter, die die Variablen in der php.ini überschreiben (fastcgi_param PHP_VALUE). Dabei darf nur eine fastcgi_param PHP_VALUE Anweisung existieren, da sich diese ansonsten gegenseitig überschreiben. Wenn mehrere Parameter an PHP übergeben werden sollen (wie hier der Fall), müssen diese einfach durch einen Zeilenumbruch getrennt werden.
Nun sollte der 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 PHP
Mit der Konfiguration von nginx ist nun der dickste Brocken geschafft! Bevor es nun zur eigentlichen Installation von ownCloud geht, müssen noch PHP und die Datenbank MariaDB konfiguriert werden.
PHP wird dabei über FPM (FastCGI Process Manager) betrieben. Dabei handelt es sich im eine (performante) Möglichkeit der Kommunikation zwischen Webserver und PHP. FPM definiert dabei einen Pool an Threads, die auf das Abarbeiten von Anfragen bereitgehalten werden. Der Pool wird mittels folgender Datei konfiguriert:
nano /etc/php/7.0/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.
Neben der Pool-Konfiguration gibt es die globale PHP-Konfiguration in der php.ini. Sämtliche hier vorgenommen Änderungen wirken sich auf alle PHP-Anwendungen gleichermaßen aus. Da der Server u.U. verschiedene (PHP-)Webanwendungen hostet, belassen wir große Teile der globalen Konfiguration bei den Standard-Werten. Anpassungen, die für bestimmte Webanwendungen gelten sollen, werden über die Konfigurationen der virtuellen Hosts an PHP weitergegeben (siehe fastcgi_param PHP_VALUE im virtuellen Host von ownCloud).
Daher werden an dieser Stelle nur zwei Variablen geändert, die für erhöhte Sicherheit sorgen:
nano /etc/php/7.0/fpm/php.ini
- cgi.fix_pathinfo = 0: Sorgt für eine sichere Interpretation von Pfadangaben.
- open_basedir = /var/www/:/tmp/:/var/owncloud_data: Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis, sowie das Datenverzeichnis von ownCloud ein. Dadurch kann PHP auf sonst keine Dateien des Systems zugreifen oder diese verändern.
Wichtig: Hier müssen alle Verzeichnisse aufgeführt werden, auf die ownCloud später Zugriff haben soll.
Neben FPM kann PHP auch über die Kommandozeile aufgerufen werden. Dies wird später für ownCloud-Cron-Jobs benötigt. Daher muss neben der FPM-Konfiguration auch die CLI-Konfiguration angepasst werden, da diese Parameter nicht über einen virtuellen Host definiert werden können:
nano /etc/php/7.0/cli/php.ini
- cgi.fix_pathinfo = 0: siehe oben
- open_basedir = /var/www/:/tmp/:/var/owncloud_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.
Wichtig: Hier müssen ebenso alle Verzeichnisse angegeben werden, auf die ownCloud später Zugriff haben soll.
Mit einem Neustart von PHP werden die Änderungen übernommen:
service php7.0-fpm restart
Konfiguration MariaDB
Nun fehlt nur noch die Konfiguration der Datenbank. Diese ist nach der Installation noch nicht auf maximale Sicherheit getrimmt, was man aber mit folgendem Befehl nachholen kann:
mysql_secure_installation
Da das Root-Passwort schon während der Installation vergeben wurde, muss dies nicht geändert werden. Alle anderen Fragen sollte man mit Ja (y) beantworten.
Für ownCloud muss ebenfalls 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
Falls der oben genannte Abschnitt nicht in der Datei my.cnf enthalten ist, findet man diesen für gewöhnlich in einer anderen Konfigurations-Datei: /etc/mysql/conf.d/mariadb.cnf.
Nun fehlt nur noch ein Neustart, dann ist die Konfiguration von MariaDB abgeschlossen:
service mysql restart
Einrichtung ownCloud
Bis hierher war es nun ein ganzes Stück Arbeit, aber nun können wir mit der Einrichtung und Konfiguration von ownCloud beginnen.
Download
Im ersten Schritt benötigen wir die aktuellste Version von ownCloud als gepacktes Archiv. Dazu ruft man am besten die Download-Seite auf der ownCloud-Homepage auf, hier findet man immer die neuste Version. Hier werden Links zu den Archiven als .tar.bz2 und .zip angeboten. Fährt man mit der Maus über einen Link, wird unten im Browser der direkte Download-Link eingeblendet.
Nun kann man (wieder auf der Linux-VM) das entsprechende Archiv herunterladen und entpacken. Anschließend wird die nicht mehr benötigte Archiv-Datei wieder gelöscht:
wget https://download.owncloud.org/community/owncloud-9.0.2.tar.bz2 tar -xjf owncloud-9.0.2.tar.bz2 -C /var/www rm owncloud-9.0.2.tar.bz2
Nach diesem Schritt ist es wichtig, noch einmal die Dateiberechtigungen explizit zu setzen, da das ownCloud-Setup ansonsten später fehlschlägt:
chown -R www-data:www-data /var/www/owncloud chown -R www-data:www-data /var/owncloud_data
Anlegen der ownCloud-Datenbak
Bevor nun das Setup der ownCloud im Browser aufgerufen werden kann, muss noch die Datenbank angelegt werden, die ownCloud nutzen soll. Dies wird am besten in der MariaDB-Kommandozeile erledigt, die mit (DB-)Root-Rechten aufgerufen wird. Das Passwort ist dabei das beim Setup von MariaDB vergebene Passwort:
mysql -u root -p
Nun wird neben der Datenbank gleich noch ein eigener DB-Benutzer für ownCloud angelegt. Die Angabe localhost sorgt dafür, dass der Zugriff auf diese Datenbank auf den lokalen Rechner begrenzt wird. Auch hier sollte man wieder ein sicheres Passwort wählen. Man beachte das Semikolon am Ende jeder Zeile:
create database owncloud_db; create user owncloud_db_user@localhost identified by 'MeInPasSw0rT'; grant all privileges on owncloud_db.* to owncloud_db_user@localhost; flush privileges; exit;
ownCloud-Setup
Nun folgt der Aufruf des ownCloud Setups über den Browser. Dazu wird einfach die Adresse https://owncloud9tutorial.goip.de/owncloud aufgerufen.
Falls an dieser Stelle fehlende Abhängigkeiten entdeckt werden, liefert das Setup einen Hinweis auf die noch fehlenden Pakete. Hier muss man zunächst die fehlenden Pakete nachinstallieren.
Im Zuge der Ersteinrichtung wird ein Administrator-Konto angelegt. Der Benutzername ist dabei frei wählbar. Auch hier sollte man wieder Wert auf ein sicheres Passwort legen, da die ownCloud ja „öffentlich“ über das Internet erreichbar ist. Weitere Punkte bei der ersten Einrichtung sind das ownCloud-Datenverzeichnis (/var/owncloud_data) und die Zugangsdaten für die zuvor angelegte Datenbank. Mit einem Klick auf Installation abschließen wird die Einrichtung nach einem kurzen Moment abgeschlossen.
Hinweis: Besonders auf langsamen Rechnern dauert der Vorgang nach einem Klick auf Installation abschließen mitunter recht lange. Dies führt manchmal zu einem Timeout (504 Gateway Timeout). nginx kappt in diesem Fall die Verbindung zum Client (Browser), das Setup wird aber weiterhin ausgeführt. Dann hilft es, ein paar Minuten warten und die ownCloud-URL nochmals aufrufen. Wenn hier die Login-Maske erscheint, wurde das Setup erfolgreich abgeschlossen. Trotzdem sollte man sich in diesem Fall überlegen, die Timeout-Werte (im virtuellen Host für ownCloud) zu erhöhen.
Warnungen im Admin-Bereich
Nach der Installation ist die ownCloud prinzipiell einsatzbereit. Als erstes sollte man einen Blick in den Admin-Bereich werfen: Benutzername (rechts oben) > Administration. Mit dem Aufruf dieser Seite führt ownCloud ein paar Checks durch und gibt ggf. Warnungen aus, wenn irgendetwas an der Konfiguration oder den Zugriffsrechten nicht passt.
In unserem konkreten Fall sollte hier nur eine Warnung zu sehen sein:
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.
Diese Meldung ist dabei kein Fehler an sich, sondern nur ein Hinweis darauf, dass die Performance der Cloud u.U. verbessert werden kann. Ein Memory Cache sorgt in diesem Fall dafür, dass die PHP-Anweisungen nicht bei jedem Aufruf aufs Neue interpretiert werden müssen, sondern gecached werden. Wenn nur wenige Benutzer die ownCloud (parallel) nutzen, kann man diese Warnung auch getrost ignorieren – hier würde ein Memory Cache nur einen minimalen Effekt haben.
Hinweis: Falls hier weitere Warnungen oder Fehler angezeigt werden, sollten die Schritte zur Einrichtung der ownCloud nochmals kontrolliert werden. Wenn alle Schritte befolgt worden sind, erscheint nur dieser eine Hinweis! Die ownCloud-Dokumentation bietet eine Liste an möglichen Fehlern und wie man diese beseitigen kann.
Anpassung der ownCloud-Konfiguration
Um diese Warnung zu beseitigen, muss die Konfigurations-Datei von ownCloud bearbeitet werden:
nano /var/www/owncloud/config/config.php
Der Memory Cache wird nun einfach durch das Hinzufügen folgender Zeile (ganz am Ende) aktiviert:
'memcache.local' => '\OC\Memcache\APCu',
Wenn man später über über das lokale Netzwerk auf die Cloud zugreifen will, sollte man hier gleich noch die lokale IP als Trusted Domain mit aufnehmen:
array ( 0 => 'owncloud9tutorial.goip.de', 1 => '192.168.178.20', ),
Ich empfehle darüber hinaus noch die Umstellung der Zeitzone für die Log-Datei. Dadurch fällt es leichter, den Zeitpunkt von auftretenden Fehlern zu bestimmen:
'logtimezone' => 'Europe/Berlin',
Mit einem erneuten Aufruf des Admin-Bereichs sollte die zuvor angezeigte Warnung nun verschwunden sein.
Eine komplette Übersicht aller verfügbaren Parameter in der config.php findet man in der ownCloud-Dokumentation.
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/owncloud_data/ chown root:www-data /var/www/owncloud/.htaccess chown root:www-data /var/owncloud_data/.htaccess chmod 0644 /var/www/owncloud/.htaccess chmod 0644 /var/owncloud_data/.htaccess
Dabei kann es sein, dass die Datei /var/owncloud_data/.htaccess nicht existiert und eine entsprechende Fehlermeldung ausgegeben wird. Diese Warnung kann allerdings ignoriert werden, da die .htaccess-Dateien nur für Apache relevant sind.
ownCloud Cronjob einrichten
Standardmäßig werden Hintergrundaufgaben, die in regelmäßigen Abständen erledigt werden müssen, von ownCloud über AJAX ausgeführt. Dies funktioniert prinzipiell ganz gut, hat aber zwei Nachteile: Zum einen wird ein Hintergrund-Job nur dann ausgeführt, wenn ein Benutzer angemeldet ist und eine Seite geladen wird. Wenn nun über längere Zeit kein Benutzer aktiv ist, wird der Hintergrund-Job einfach nicht mehr ausgeführt. Zum anderen ist diese Art der Job-Ausführung weniger performant.
Man kann diese Hintergrundaufgaben allerdings auch per Cron erledigen lassen: Hier wird in regelmäßigen Abständen ein Hintergrund-Dienst gestartet, der dann alle zu erledigenden Hintergrund-Jobs abarbeitet. Das Umstellen auf Cron empfiehlt sich dabei besonders beim Einsatz auf einem Raspberry Pi oder ähnlicher schwacher Hardware, ist aber nicht zwingend erforderlich.
Um die Hintergrundaufgaben durch einen Cronjob erledigen zu lassen, muss zunächst ein neuer Job für den Webserver-Benutzer angelegt werden:
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.
Ob der Cron-Job nun ordnungsgemäß ausgeführt wird, kann man an der Anzeige Letzte Cron-Jon-Ausführung erkennen: Immer nach 15 Minuten sollte die Anzeige wieder zurück gesetzt werden (gerade eben).
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.
Überprüfung der Sicherheit
Qualys SSL Labs
Nachdem wir gesteigerten Wert auf die Sicherheit der ownCloud gelegt haben, sollte man zumindest die SSL-Sicherheit (Verschlüsselung) überprüfen. Ich verwende dazu immer den SSL Server Test von Qualys SSL Labs.
Mit der gezeigten Konfiguration erreicht man eine sehr gute Wertung von A+:
Falls an dieser Stelle eine niedrigere Einstufung erfolgt und/oder Warnungen ausgegeben werden, sollte die SSL-Konfiguration nochmals überprüft werden (Erzeugung und Einbindung der Zertifikate, Verwendung von sicherheitsrelevanten Headern in den virtuellen Hosts).
ownCloud Vulerability Scanner/Nextcloud Security Scan
Neben dem Überprüfen der (SSL-)Sicherheit, gibt es noch ein Tool von ownCloud, mit dem die Cloud-Installation auf eventuelle Verwundbarkeiten geprüft werden kann: Den ownCloud Vulnerability Scanner. Nach dem Check werden evtl. vorhandene Schwachstellen gezeigt.
Etwas umfangreicher arbeitet der Nextcloud Security Scan. Dieses Tool ist zwar spezielle für Nextcloud gedacht, man kann allerdings auch ownCloud-Instanzen damit überprüfen. Hier sollte man auf jeden Fall ein „A-Rating“ erzielen können. Der einzige Punkt, der unter „Hardenings“ als verbesserungswürdig gekennzeichnet wird, ist „__Host-Prefix“. Dies hat allerdings damit zu tun, dass wir unsere Cloud über ein Unterverzeichnis des Webservers ansprechen und stellt kein Sicherheitsrisiko dar.
Zugriff auf die ownCloud über das lokale Netzwerk
Die eigene Cloud ist soweit eingerichtet und wartet nun auf Input. Gerade beim Upload von größeren Dateien kann es sinnvoll sein, dass man diese über das lokale Netzwerk überträgt – also nicht über die DynDNS-Adresse der Cloud, da hier sämtlicher Traffic über das Internet geleitet wird, was definitiv länger dauert als die Übertragung über das lokale Netzwerk.
Dazu greift man einfach über die IP-Adresse auf die ownCloud zu (https://192.168.178.20/owncloud) und nicht über die DynDNS-Adresse (https://owncloud9tutorial.goip.de/owncloud). In diesem Fall bekommt man eine Warnung im Browser angezeigt, da das SSL-Zertifikat ja auch die DynDNS-Domain und nicht auf die lokale IP ausgestellt wurde. Diese Warnung kann man getrost ignorieren, da die übertragenen Daten ja das lokale Netzwerk nicht verlassen und daher nicht unbedingt verschlüsselt werden müssen.
Sollte der lokale Zugriff nicht funktionieren (häufigster Fehler ist dabei, dass nach der Anmeldung automatisch auf die DynDNS-Adresse weitergeleitet wird), dann sollte noch einmal der Gateway-Host kontrolliert werden (/etc/nginx/conf.d/owncloud9tutorial.goip.de). Hier ist folgender Eintrag wichtig:
# Enforce HTTPS return 301 https://$server_addr$request_uri; # Use this if you always want to redirect to the DynDNS address (no local access). #return 301 https://$server_name$request_uri;
Wenn der zweite Redirect verwendet wird (hier auskommentiert), wird immer auf die DynDNS-Adresse weitergeleitet.
Ebenfalls muss die lokale IP als Trusted Domain in der config.php von ownCloud angegeben werden (siehe Abschnitt Anpassung der ownCloud-Konfiguration).
Falls es doch einmal hakt…
Am Ende noch ein wichtiger Hinweis: Die Einrichtung und Konfiguration der ownCloud ist nicht trivial. Wenn nur ein kleines Detail übersehen oder vergessen wurde, hat dies meist zur Folge, dass der Zugriff auf die ownCloud nicht wie erwartet funktioniert.
In diesem Fall liefern die Log-Dateien von nginx bzw. ownCloud aber meist einen Hinweis darauf, wo der Fehler liegen könnte. Im Fehlerfall sollte man daher immer zunächst einmal einen Blick in die Logs werfen:
- /var/log/nginx/error.log: Fehler-Log von nginx.
- /var/owncloud_data/owncloud.log: ownCloud-Log, auch einzusehen in der Admin-Oberfläche der Cloud.
Download Checkliste
Da zur Installation und Einrichtung von ownCloud durchaus viele Schritte erforderlich sind, gibt es hier die Zusammenfassung als Checkliste als PDF. Dieses Dokument verzichtet bewusst auf weitere Erklärungen, sondern listet lediglich die verwendeten Befehle und Eingaben hintereinander auf.
Meine Daten gehören mir!
Nun ist es an der Zeit, sich einfach mal in dem Gewissen zurückzulehnen, dass man ab sofort die Hoheit über die eigenen Daten behält.
Ich muss zugeben, dass der Artikel recht umfangreich geworden ist. Ich musste selbst viel rumtüfteln, damit ownCloud optimal und mit erhöhter Sicherheit läuft. Aber vielleicht hilft das Tutorial dem einen oder anderen, seine eigenen ownCloud aufzusetzen und dabei nicht so viel Zeit mit Suchen und Rumprobieren zu verschwenden.
Falls es dennoch Unklarheiten oder Verbesserungsvorschläge gibt, hinterlasst mir doch einfach einen Kommentar. 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
- ownCloud unter Windows 10 optimal nutzen
- HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx
- ownCloud mit Fail2ban absichern
- Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)
Links
- Offizielle ownCloud Homepage (englisch)
- Offizielle nginx Homepage (englisch)
- nginx Wiki mit Anleitungen und Beispielen (englisch)
- Offizielle MariaDB Homepage (englisch)
- Offizielle PHP Homepage (englisch)
- ownCloud Server Administration Manual (englisch)
- Offizielle Let’s Encrypt Homepage (englisch)
- Certbot-Homepage (englisch)
- ownCloud Vulnerability Scanner
- Nextcloud Security Scan
Ähnliche Artikel:
ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP
Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Ist es in Ordnung, dass die Rechte von 0750 auf 0770 geändert werden müssen, erst dann läuft dieOC?
find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0770
Hi,
bei 0770 würde die Gruppe (des Webserver-Nutzers) auch Vollzugriff erhalten. Wüsste nicht, warum dies notwendig sein sollte.
Läuft OC mit 0750 nicht richtig?
Gruß,
Jan
Bei „0750“ wird angezeigt:
Data directory (/var/www/owncloud/data) not writable by Owncloud
Berechtigungen können normalerweise repariert werden, indem dem Webserver Schreibzugriff auf das Wurzelverzeichnis gegeben wird.
Diese Berechtigung wird ja sicher über s.u. gesetzt:
find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0750
ls -l /var/www/
drwxr-x— 15 root www-data 4096 Mär 6 22:18 owncloud
ls -l /var/www/owncloud/
drwxr-x— 29 root www-data 4096 Feb 1 19:45 3rdparty
drwxr-x— 30 www-data www-data 4096 Mär 7 11:50 apps
-rw-r—– 1 root www-data 8301 Feb 1 19:44 AUTHORS
drwxr-x— 2 www-data www-data 4096 Mär 6 22:44 config
-rw-r—– 1 root www-data 4136 Feb 1 19:44 console.php
-rw-r—– 1 root www-data 34520 Feb 1 19:44 COPYING-AGPL
drwxr-x— 17 root www-data 4096 Feb 1 19:45 core
-rw-r—– 1 root www-data 5141 Feb 1 19:44 cron.php
drwxr-x— 7 root www-data 4096 Mär 7 19:31 data
-rw-r—– 1 root www-data 35830 Feb 1 19:44 db_structure.xml
-rw-r—– 1 root www-data 179 Feb 1 19:44 index.html
-rw-r—– 1 root www-data 3064 Feb 1 19:44 index.php
drwxr-x— 3 root www-data 4096 Feb 1 19:44 l10n
drwxr-x— 6 root www-data 4096 Feb 1 19:44 lib
-rw-r—– 1 root www-data 283 Feb 1 19:44 occ
drwxr-x— 2 root www-data 4096 Feb 1 19:44 ocs
drwxr-x— 2 root www-data 4096 Feb 1 19:44 ocs-provider
-rw-r—– 1 root www-data 3086 Feb 1 19:44 public.php
-rw-r—– 1 root www-data 5428 Feb 1 19:44 remote.php
drwxr-x— 4 root www-data 4096 Feb 1 19:44 resources
-rw-r—– 1 root www-data 26 Feb 1 19:44 robots.txt
drwxr-x— 11 root www-data 4096 Feb 1 19:44 settings
-rw-r—– 1 root www-data 1893 Feb 1 19:44 status.php
drwxr-x— 3 www-data www-data 4096 Feb 1 19:44 themes
drwxr-x— 7 root www-data 4096 Feb 1 19:45 updater
-rw-r—– 1 root www-data 233 Feb 1 19:44 version.php
(Entschuldigung für die sicher simplen Fragen, ich bin ein sehr „junger“ Linuxnutzer)
Hallo Wolfram,
dein Daten-Verzeichnis liegt anscheinend direkt unter dem owncloud-Ordner owncloud/data. Empfohlen wird im Allgemeinen, dass das data-Verzeichnis nicht im owncloud-Ordner liegt (Sicherheits-Feature). Daher liegt es bei mir im Verzeichnis /var/owncloud_data.
Ich würde bei dir erst einmal ein chown -R www-data:www-data /var/www/owncloud/data ausprobieren. Besitzer wäre dann www-data, der dürfte dann auch bei 0750 schreiben.
Unter welchem User läuft nginx bei dir (wird in der Datei /etc/nginx/nginx.conf angegeben)?
Gruß,
Jan
Hallo,
nach dem letzten nextcloud update geht bei mir der cron job nicht mehr :(
wenn ich die cron.php direkt ausführe bekomme ich folgende fehlermeldung ausgegeben:
root@ubuntu-server-nextcloud:/var/www/nextcloud# php -f /var/www/nextcloud/cron.php
PHP Warning: require_once(): open_basedir restriction in effect. File(/var/www/nextcloud/lib/base.php) is not within the allowed path(s): (0) in /var/www/nextcloud/cron.php on line 42
PHP Warning: require_once(/var/www/nextcloud/lib/base.php): failed to open stream: Operation not permitted in /var/www/nextcloud/cron.php on line 42
PHP Fatal error: require_once(): Failed opening required ‚/var/www/nextcloud/lib/base.php‘ (include_path=‘.:/usr/share/php‘) in /var/www/nextcloud/cron.php on line 42
hat jemand eine Ahung wie mann das beheben kann?
Vielen lieben Dank für die Hilfe schon mal
Gruß Bernd
bzw. könnte es auch das letzte php update gewesen sein…
php -i | grep „pdo“
gibt mir folgendes aus:
/etc/php/7.0/cli/conf.d/10-pdo.ini,
/etc/php/7.0/cli/conf.d/20-pdo_mysql.ini,
API Extensions => mysqli,pdo_mysql
pdo_mysql
pdo_mysql.default_socket => /var/run/mysqld/mysqld.sock => /var/run/mysqld/mysqld.sock
php sollte passen oder?
Hi Bernd,
das letzte PHP-Update hat neue Standard-Configs mitgebracht. Er fragt normalerweise nach, ob er diese beim Update überschreiben soll, oder ob er die alten Configs behalten soll. Falls bei die die Standard-Configs genommen wurden: Überprüf doch mal sämtliche im Tutorial gezeigten Änderungen bzgl. PHP, besonderen in der CLI-Config (open_basedir).
Gruß,
Jan
Hi,
habe auch deine schöne Anleitung gefunden, aber leider hängt es bei mir an der Verbindung zwischen Nginx und PHP, es werden einfach keine php Seiten im Browser gezeigt. Die entsprechenden Dateien werden wie ein Download geöffnet.
Habe z.B. den upstream php-handler direkt in die Gateway.conf gepackt auch schon probiert mit dem Path des php7.0-fpm.sock
Wurde ggf. etwas geändert? Da ich eine ganz frische Installation gemacht habe.
Danke und Grüße
René
So habs hinbekommen, irgendwie wurde der Owncloud Host nicht richtig angesprochen, nachdem das behoben war hatte ich noch den Fehler:
unix:/run/php/php7.0-fpm.sock failed (13: Permission denied) while connecting to upstream
Habe dann den Nutzer von nginx zu www-data geändert
Jetzt läufts :)
Hi René,
super, dass du es hinbekommen hast.
Der nginx-Nutzer ist nur ein kleines Zahnrad im ganzen System, aber umso wichtiger. Wenn man das vergisst, läuft der ganze Laden nicht und der Grund ist relativ scher heraus zu finden.
Gruß,
Jan
Hallo, kann ich beim direkten Aufrufen der URL die Meldung 403 Forbiden umgehen, das die Cloud direkt aufgerufen wird?
z.B http://www.meineSeite.de/owbloud
Hallo Stefan,
leider verstehe ich nicht so ganz, wo dein Problem liegt.
Ich will es aber mal versuchen: Du bekommst einen HTTP 403 beim Versuch, auf http://www.meineSeite.de/owncloud zuzugreifen. Dies spricht erst einmal dafür, dass hier etwas an der vHost-Konfiguration nicht so ganz passt. Irgendwo in deiner Config wird vermutlich ein deny all; stehen. Dies wird an dieser Stelle greifen und hier den Zugriff unterbinden.
Gruß,
Jan
Hallo Jan,
habe mich vielleicht falsch ausgedrückt. Ich habe anhand deiner Beschreibungen meherer vHost’s angelegt, die auch alle super funktionieren.
http://www.meineseite.de/nextcloud, /owncloud und /wordepress.
Jetzt wollte ich es so anpassen, dass nach Eingabe von http://www.meineseite.de gleich der Login für z. B. die owncloud erscheint, ohne den Zusatz /owncloud.
Ich weiss nicht ob das so einfach möglich ist.
Schon mal vielen Dank.
Gruss Stefan
Hi Stefan,
ok, jetzt verstehe ich dein Problem.
Ist kein Problem: Such einfach im Gateway-vHost nach der Stelle, an dem der Zugriff auf das Root-Verzeichnis unterbunden wird:
location = / {# Disable access to the web root, otherwise nginx will show the default site here.
deny all;
}
Hier setzt du einfach ein Redirect auf die gewünschte Web-Anwendung (z.B. ownCloud):
location = / {
rewrite ^ /owncloud;
}
Gruß,
Jan
Hi Ja,
TOP, vielen Dank für die schnelle Hilfe.
Gruß
Stefan
Hallo jan,
erst einmal ein großes Lob an dich! Super Anleitung die du hier bereit stellst!
Anfangs hatte ich ein Paar Probleme, doch inzwischen war ich schon in der Owncloud Oberfläche.
Anschließend habe ich allerdings die von dir empfohlenen Zugriffsrechte angepasst, seit dem geht nichts mehr! :(
Dazu habe ich hier schon einen ähnlichen beitrag gesehen, da war wohl die Lösung den User Owncloud zur Gruppe www-data hinzuzufügen.
Ich wüsste aber nicht, dass ich den User owncloud überhaupt erstellt habe.
Wäre super, wenn du auf die schnelle weißt, wie ich mein Rechte-Problem wieder in den Griff kriege!
Zusärtlich werde ich immer auf die intere IP des Raspis weitergeleitet, wenn ich versuche über meine Domain zur connecten :o
Das ist natürlich schlecht, da ich aus dem Internet diese Adresse nicht erreichen kann.
Also so –> https://meineDomain.de –> https://192.168.1.88
Habe mich hiermit noch nicht näher beschäftigt, wäre aber auch super, wenn du da eine Lösung hättest!!!
Gruß und vielen Dank Fixel
Hi Fixel,
zu deinem ersten Problem: Der User, unter dem alles läuft (v.a. nginx), ist nicht „owncloud“, sondern „www-data“. Daher solltest du den User, unter dem nginx läuft, mal kontrollieren. Zu finden ist dies in der Datei /etc/nginx/nginx.conf („user“). Dieser Punkt wird häufig übersehen und ist immer mal wieder die Ursache für verschiedenste Probleme.
Zum Redirect auf die LAN-IP: Wenn ich das richtig sehe, hat das nichts mit der Weiterleitung HTTP > HTTPS zu tun, da du ja bereits die HTTPS-Adresse aufrufst. Ist (im Gateway-Host) unter server_name auch die DynDNS-Adresse angegeben?
Falls ja, wäre es mal interessant, wo dieser Redirect herkommt. Ich nutze dazu gern die Developer-Console von Chrome (F12). Dann einfach die URL aufrufen und Chrome zeigt dir jeden einzelnen Schritt, der bei der Abarbeitung des Requests ausgeführt wird. Vielleicht ist hier ein Hinweis auf das Problem zu finden.
Gruß,
Jan
Hi,
irgendwie ist mein geposteter Beitrag hier nicht zusehen, deswegen schreibe ich nochmal kurz was ich bereits getan habe.
Zum Problem 1.)
nginx läuft bereits mit dem user www-Data.
Wie schon bereits gesagt hatte ich schon zugriff auf OC, bis ich die Rechte nach deiner Anleitung beschrieben erneut angepasst habe.
Deswegen meine Vermutung, dass das wohl mit den zuletzt eingestellten Rechten zusammen hängen muss.
Problem 2.)
Ich muss mich korriegieren, anders als gesagt werde ich auf die Intere IP adresse nur umgeleitet, wenn ich über http mit nginx kommuniziere. Wenn ich über https gehe, kriege ich die Webseite angezeigt, bzw 403 Forbidden. Auch das schöne Gründe Schloss, was sagt das die verbindung sicher ist, ist zu sehen!
So meine Annahme, dass das wohl doch mit dem weiterleiten von HTTP zu HTTPS zusammenhängen muss.
Danke für deine Hilfe und ein schönes Wochenende,
Fixel
Ergänzung:
Auch die DynDns Adresse ist im Gateway Host unter server_name zusammen mit der Internen IP angegeben.
Hi Fixel,
ich war mal so frei und habe deine Kommentare zusammengefügt. Dein erster Kommentar ist leider im Spamfilter hängen geblieben (warum auch immer). Falls so etwas nochmal passieren sollte, einfach etwas abwarten, ich gebe solche Kommentare dann manuell frei.
1. Problem mit den Zugriffsrechten:
Ob es wirklich mit dem Rechten zu tun hat, kannst du überprüfen, wenn du die Anpassungen rückgngig machst:
chown –R www-data:www-data /var/www/owncloud
chown –R www-data:www-data /var/www/oc_data
Wenn es danach immer noch nicht laufen sollte, haben die Rechte mit dem Fehler nichts zu tun.
Wie dem auch sei, das Problem kann man vermutlich nur anhand der Log-Dateien des Webservers nachvollziehen. Dazu könntest du mir mal die Datei /var/log/nginx/error.log schicken, dann schau ich da mal drüber.
2. Fehlerhafte Weiterleitung:
OK, wenn es bei der Weiterleitung HTTP > HTTPS hakt, sieht die Lösung wohl recht einfach aus: Einfach im Gateway-Host (bei der HTTP-Server Definition) die Weiterleitung anpassen (erster Block mit „return 301…“ auskommentiert, den Kommentar beim zweiten entfernt):
location / {# Enforce HTTPS
#return 301 https://$server_addr$request_uri;
# Use this if you always want to redirect to the DynDNS address (no local access).
return 301 https://$server_name$request_uri;
}
Nun sollte er immer auf die DynDNS-Adresse weiterleiten. Ich kann dir leider nicht genau sagen, warum die erste Weiterleitung nicht so funktioniert wie gedacht, da ich dieses Szenario lokal bei mit nicht nachstellen kann. Einziger Nachteil dieser Lösung: Ein Zugriff über die LAN-IP ist nun nicht mehr möglich (außer direkt über HTTPS). Das sollte aber eigentlich auch kein Problem darstellen, da man normalerweise immer über die DynDNS-Adresse gehen sollte, da für diese ja das SSL-Zertifikat ausgestellt wurde. Mit dem Zugriff über die lokale IP erhält man wieder Warnungen im Browser, etc.
Ich wünsche auch ein schönes Wochenende.
Gruß,
Jan
Nach dem Anlegen des „Gateway-Hosts“, kann man nginx nicht neustarten.
Es kommt der Fehler:
root@odroid64:~# service nginx restart
Job for nginx.service failed because the control process exited with error code. See „systemctl status nginx.service“ and „journalctl -xe“ for details.
Problem dabei ist, dass nun nginx nicht mehr erreichbar ist – also auch nicht die default-Seite von ngnix.
Damit ist dann auch gleichzeitig das ausstellen des SSL Zertifikats nicht möglich:
Failed authorization procedure. domain.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to domain.de
IMPORTANT NOTES:
– The following errors were reported by the server:
Domain: domain.de
Type: connection
Detail: Could not connect to domain.de
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
Irgendwelche Ideen dazu?
Lieben Gruß,
Andi
Hi Andi,
das liegt in vielen Fällen an einem Fehler in den virtuellen Hosts. Meistens ist das nur ein Tippfehler und kann schnell beseitigt werden.
Warum nginx nicht mehr startet, findest du mit dem Befehl nginx -t heraus. Hier wird dir die fehlerhafte Config und auch eine genaue Zeilennummer genannt.
Gruß,
Jan
Hallo, eine super Anleitung!
Eine Frage habe ich aber noch: nach dieser Anleitung habe ich alles eingerichtet und es funktioniert auch so weit. Ich muß Owncloud jetzt so aufrufen: meine-lokale-ip/owncloud oder meine-externe-ip/owncloud. Was muß ich tun, damit ich die externe IP ohne Zusatz „/owncloud“ aufrufen kann und trotzdem direkt auf die Owncloud-Seite geleitet werde?
Gruß
Axel
Hi Axel,
da ist nur eine minimale Änderung notwendig:
Such einfach im Gateway-vHost nach der Stelle, an dem der Zugriff auf das Root-Verzeichnis unterbunden wird:
location = / {# Disable access to the web root, otherwise nginx will show the default site here.
deny all;
}
Hier setzt du einfach ein Redirect auf die gewünschte Web-Anwendung (z.B. ownCloud):
location = / {
rewrite ^ /owncloud;
}
Ich denke, ich werde hierzu noch einen Hinweis im Artikel mit aufnehmen, da diese Frage schon häufiger gestellt wurde.
Gruß,
Jan
Hallo Jan, eine super Anleitung!
Ich hatte vor 10-15 Jahren die letzte Befassung mit Linux.
Konnte mich an vieles erinnern.
Deine Ausführungen sind super klasse. Ich habe ca.95% verstanden.
Vielen herzlichen Dank für deine Arbeit und Mühe.
Bei mir läuft jetzt eine ownCloud !!!!!!
Danke. Danke. Danke ……
Hallo Gemeinde
Nutze die oben beschriebene Installation und ich muss sagen läuft super, jedoch stellt sich mir die Frage ob man die letsencrypt aktualisierung der 90 Tage auch automatisieren kann damit man sich darum nicht mehr kümmern muss?
Dafür fehlt mir jedoch das wissen.
Gruß drini
Hi drini,
genau zu diesem Thema gibt’s einen weiteren Artikel. Hier werden die Zertifikate per Cron automatisch erneuert.
Gruß,
Jan
Hammer! Schnurpelt erste Sahne – hätte ich never ever so allein hinbekommen. Fettes *DANKE*!!!
Hallo,
falls jemand Android 7 und z.B. Davdroid zum synchronisieren einsetzt, muss eine kleinigkeit ändern.
und zwar:
im Gateway Host folgende Zeile auskommentieren
ssl_ecdh_curve secp384r1;
und diese dafür einfügen:
ssl_ecdh_curve auto;
Problem ist hier nicht die Serverconfig, sondern ein Bug in Android 7.
evtl hilft es jemandem.
Gruß Bernd
Hi Bernd,
danke für den Hinweis.
Leider macht die Einstellung ssl_ecdh_curve immer mal wieder Probleme. Komisch, dass es gerade hier bei Android 7 einen Bug gibt.
Gruß,
Jan
Hi Jan!
Super Anleitung!
Bis auf eine Sache klappt auch alles. Beim aufrufen von http://www.meineDomäääne.de werde ich auf eine Seite weitergeleitet wo dann steht: Diese vebrindung ist nicht sicher.
Wenn ich https://meinedomäääne.de/ komme ich drauf mit https.
Hast du eine Ahnung woran das liegt?
LG
Elies
Hi Elies,
eigentlich sollte der Aufruf mit HTTP automatisch auf die (sichere) Verbindung mit HTTPS weiterleiten.
Wenn du über HTTP gehst und die Meldung wegklickst: Was für ein Zertifikat wird dir hier angezeigt (z.B. beim IE auf das Schloss-Symbol und auf Zertifikate anzeigen klicken). Ist das dein (Let’s Encrypt) Zertifikat?
Gruß,
Jan
Sorry ich habe mich flasch ausgedrückt. Ich würde gerne auf https://meine domäääne.de kommen auch wenn ich www im web browser eingebe.
Das ist ja eigentlich eine Subdomain…Wenn ich die Seite mit www davor aufrufe kommt : Unsichere Verbindung bla bla.
Ist ja eigentlich auch klar, da das Cert nicht für www ausgestellt wurde. Gibt es dennoch die möglichkeit das man sich vom www direkt weiterleiten lassen kann?
Hi Elies,
ok, verstehe. Das dürfte durch eine kleine Änderung in der HTTP Server-Konfiguration möglich sein:
server {listen 80 default_server;
server_name meineDomäääne.de www.meineDomäääne.de 192.168.178.20;
root /var/www;
...
Dann werden die Domains meineDomäääne.de und www. meineDomäääne.de gleich behandelt, nämlich mit einem Redirect auf die HTTPS-Adresse.
Gruß,
Jan
Das habe ich bereits ausprobiert in meiner meinedomääne.de.conf datei.
Nachdem ich das gemacht habe und mal den cache vom browser gelöscht habe wurde ich tatsächlich korrekt weiter geleitet. Tab geschlossen und ein zweites mal ausprobiert: nicht mehr korrekt weiter geleitet. Das selbe wie vorher: Diese Verbindung ist nicht sicher. Vielleicht sollte ich erwähnen das die www Domäne nicht existiert. Möchte lediglich das man meine Cloud auch mit dem www vorangesetzt erreichen kann.
Hallo Elies,
komisch, dass das nur einmal funktioniert. Die www-Domäne existiert, sobald du diese in einem vHost deklarierst.
In dem Fall wo es nicht klappt: Auf welche HTTPS-Domäne wirst du weitergeleitet (https://meinedomääne.de oder https://www.meinedomääne.de)? Um zu sehen, was hier genau abläuft, kannst du auch die Developer-Console von Chrome verwenden (F12). Hier werden alle Weiter- und Umleitungen visualisiert – hat mir schon öfter geholfen, wenn nicht wirklich klar war, was „unter der Haube“ passiert.
Noch eine Frage: Willst du, dass die Cloud auch über https://www.meinedomääne.de erreichbar ist? In diesem Fall musst du auf jeden Fall ein weiteres Let’s Encrypt Zertifikat für die www-Domäne erzeugen (also pro Subdomain ein Zertifikat). Anschließend müsstest du auch zwei https-server-Blöcke im vHost definieren und die korrekten Zertifikate einbinden. Damit sich der Rest gleich verhält, sollten alle anderen Anweisungen (des https-Blocks) in eine separate conf-Datei ausgelagert werden und in beiden https-server-Blöcken inkludiert werden.
Gruß,
Jan
Ich werde auf https://www.meinedomääne.de weitergeleitet.
Ich möchte meine Website nicht über eine weiter Adresse erreichbar machen. Ich möchte nur das man weitergeleitet wird wenn man www im Browser vorher ein gibt.
Das mit der Developer console probiere ich später Mal aus
Hi Elies,
das sollte eigentlich nicht passieren (die Weiterleitung auf https://www…), hier sollte eigentlich auf https://meineDomäääne.de verwiesen werden. Hintergrund: Die Reihenfolge der Definitionen bei server_name meineDomäääne.de http://www.meineDomäääne.de 192.168.178.20; ist wichtig. Die später verwendete Variable $server_addr sollte immer auf die erste Adresse unter server_name aufgelöst werden (also meineDomäääne.de – ohne www).
Wenn es für dich in Ordnung ist, dass du dann nicht mehr über die lokale IP auf deine Cloud kommst (sondern immer nur über die DynDNS-Adresse), kannst du den redirect auch mal folgendermaßen anpassen:
return 301 https://$server_name$request_uri;Wenn das auch noch nichts bringt, dann hilft wohl nur eine „feste Verdrahtung“:
return 301 https://meineDomäääne.de$request_uri;Dies sollte dann auf jeden Fall klappen.
Gruß,
Jan
Vielleicht noch ganz interessant: Chrome Console:
General:
Request URL:http://www.datafixundfertig.de/
Request Method:GET
Status Code:307 Internal Redirect
Referrer Policy:no-referrer-when-downgrade
Response Header:
Location:https://www.datafixundfertig.de/
Non-Authoritative-Reason:HSTS
Feste Verdrahtung bringt leider auch kein Erfolg.
Hier mal der Ausschnit aus /etc/nginx/conf.d/meinedomääne.de.conf:
server {
listen 80 default_server;
server_name datafixundfertig.de http://www.datafixundfertig.de 192.168.178.44;
root /var/www;
location ^~ /.well-known/acme-challenge {
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
location / {
# Enforce HTTPS
#return 301 https://$server_addr$request_uri;
# Use this if you always want to redirect to the DynDNS address (no local access).
return 301 https://datafixundfertig.de$request_uri;
}
}
Hi Elies,
da hat sich noch ein kleiner Fehler eingeschlichen. Die http-server-Definition muss so aussehen (kein „http://“ im server_name):
server {listen 80 default_server;
server_name datafixundfertig.de www.datafixundfertig.de 192.168.178.44;
...
Also ich war mal so frei und habe auch mal mit Chrome die URL (http://www…) aufgerufen: Bei mir funktioniert es – ich werde auf https://… (ohne www) weitergeleitet. Das Problem kann ich also nicht ganz nachvollziehen.
Gruß,
Jan
Ich fasse mal zusammen:
Chrome developer Console :
Generel:
Request URL:http://www.datafixundfertig.de/
Request Method:GET
Status Code:307 Internal Redirect
Referrer Policy:no-referrer-when-downgrade
Response Header:
Location:https://www.datafixundfertig.de/
Non-Authoritative-Reason:HSTS
Mit dieser Konfiguration funktioniert es nicht:
server {
listen 80 default_server;
server_name meine domääne.de http://www.meinedomääne.de 192.168.x.x;
root /var/www;
location ^~ /.well-known/acme-challenge {
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
location / {
# Enforce HTTPS
#return 301 https://$server_addr$request_uri;
# Use this if you always want to redirect to the DynDNS address (no local access).
return 301 https://meinedomääne$request_uri;
}
}
.
.
.
Server {
listen 443 ssl http2;
.
.
.
Hi,
wie gesagt: hier das „http://“ raus:
listen 80 default_server;server_name meine domääne.de
http://www.meinedomääne.de 192.168.x.x;Und der fest verdrahtete Redirect muss so aussehen (hier fehlt „.de“):
return 301 https://meinedomääne.de$request_uri;Gruß,
Jan
Ja beim ersten Aufruf der Website nachdem ich die Browserdaten gelöscht habe, funktioniert es auch. Bei einem zweiten aufruf über http://www.datafixundfertig.de kommt wieder die unsichere Verbindung.
server {
listen 80 default_server;
server_name datafixundfertig.de http://www.datafixundfertig.de 192.168.x.x;
root /var/www;
location ^~ /.well-known/acme-challenge {
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
location / {
# Enforce HTTPS
#return 301 https://$server_addr$request_uri;
# Use this if you always want to redirect to the DynDNS address (no local access).
return 301 https://datafixundfertig.de$request_uri;
}
}
Kein erfolg beim zweiten aufruf der Seite mit http://www...
Vielleicht setze ich alles nochmal neu auf.
Gruß
Elies
Das „http://“ ist nicht bei Server_name…keine ahnung warum die kommentar Funktion davor ein „http://www“ macht.
In meiner Konfig ist auf jeden fall bei Server_name NUR www ohne http
Hi,
ok, dann ist das wohl ein WordPress-Automatismus mit dem http:// ;)
Das würde vermutlich helfen, auch wenn es wohl ziemlich aufwendig ist.
Du könntest nochmal die nginx-Logs prüfen, vielleicht steht hier was drin, womit wir was anfangen können.
Gruß,
Jan
Hier mal ein auszug vom error.log nach dem Aufruf der Seite:
2017/04/20 10:59:22 [warn] 2036#2036: *842 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/02/0000000026 while reading upstream, client: 217.110.63.164, server: datafixundfertig.de, request: „GET /owncloud/core/vendor/backbone/backbone.js?v=4911ecb4c5f15ca9afe434774bffb338 HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/backbone/backbone.js?v=4911ecb4c5f15ca9afe434774bffb338“, host: „datafixundfertig.de“
2017/04/20 10:59:22 [warn] 2036#2036: *842 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/02/0000000027 while reading upstream, client: 217.110.63.164, server: datafixundfertig.de, request: „GET /owncloud/core/js/js.js?v=4911ecb4c5f15ca9afe434774bffb338 HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/js/js.js?v=4911ecb4c5f15ca9afe434774bffb338“, host: „datafixundfertig.de“
2017/04/20 11:00:28 [warn] 2036#2036: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencrypt/live/datafixundfertig.de/fullchain.pem“
Hi,
alles nichts auffälliges. Zumindest hat das nichts mit dem falschen Redirect zu tun.
Mich wundert nur nach wie vor, dass ich das Problem nicht nachvollziehen kann. Sowohl bei Chrome, als auch bei IE funktioniert der Redirect wie erwünscht.
Gruß,
Jan
Edit: Gerade nochmal probiert: Nun bekomme ich auch die Warnung in Chrome („NET::ERR_CERT_COMMON_NAME_INVALID“). Das liegt wohl daran, dass von http://www… auf https://www… weitergeleitet wird.
Komisch da der Redirect ja nicht auf https://www…weiterleiten soll sondern nur auf https://…
Ich habe eine Lösung gefunden für alle die es Interessiert:
Im HTTPS host gibt es die stelle: add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“;
Wenn man diese auskommentiert, wird man IMMER korrekt weiter geleitet.
Vielleicht muss man diese zeile nicht unbedingt auskommentieren sondern nur die Parameter ändern. Das kann ich aber nicht sagen.
LG
Elies
Hi Elies,
oh, da hat dir HSTS einen Strich durch die Rechnung gemacht. Das hatte ich gar nicht auf dem Schirm. Durch diese Anweisung im vHost wird gesteuert, dass der Server immer einen sog. „Strict-Transport-Security“ Reader mitsendet. Das sagt dem Client (Browser) dann, dass er immer auf die hier angegebene Adresse verbinden soll – egal, ob vom Server noch andere Redirects oder so gesendet werden. Wie lange dieser Zustand angegeben wurde, wird in Sekunden angegeben (die große Zahl).
Soviel zum Hintergrund. Warum das Ganze bei dir nun zum nicht nachvollziehbaren Redirect geführt hat, liegt vermutlich daran, dass beim allerersten Aufruf ein falscher Redirect konfiguriert war. Danach hat der Browser auf die anderen Redirect-Versuche einfach nicht mehr „gehört“.
Aber: Auch wenn es nun scheinbar funktioniert, würde ich diese Zeile nicht einfach auskommentieren. HSTS ist ein wichtiges Sicherheits-Feature des Webservers und sollte auf jeden Fall aktiviert bleiben.
Ich habe aber einen Weg gefunden, das „HSTS-Gedächtnis“ von Chrome zu löschen. Dazu einfach chrome://net-internals/#hsts in die Adresszeile eingeben. Ganz unten unter Query domain kannst du mal deine Domain eintragen. Hier sollte er anschließend „Found“ melden.
Wenn du die Domain nun in das Feld Delete domain einträgst, kannst du alle HSTS-relevanten Infos löschen.
Wenn du nun http://www.datafixundfertig.de aufrufst, sollte der Redirect wie erwartet funktionieren.
Sorry, dass ich da nicht eher draufgekommen bin. Werde es aber mal im Hinterkopf behalten.
Gruß,
Jan
Ja hab ich mir gedacht, dass es nicht ganz unwichtig ist.
Würde es reichen an der stelle include Subdomains raus zu nehmen?
add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“;
Ohne IncludeSubdomains funktioniert es nämlich auch.
LG
Elies
Hi,
Ja, das includeSubdomains kann man notfalls rausnehmen. Ist immerhin noch besser, als HSTS komplett zu deaktiviere.
Hat der Trick mit Chrome nicht geklappt?
Gruß,
Jan
Doch der Trick mit dem Chrome hat geklappt! Nur bin ich eingefleischter Firefox User :P
Vielen vielen Dank für deine Denkanstöße bezüglich redirect etc. Klasse Sache!
LG
Elies
Hi,
Kein Problem, hier gibt’s eine Anleitung, wie man das gleiche bei Firefox machen kann.
Dann kannst du auch wieder includeSubdomains in die Konfiguration mit aufnehmen und bist so auf der sicheren Seite.
Gruß,
Jan
Ah super danke!
Wäre natürlich super wenn auch wer anders ohne diese Browser Konfiguration vernünftig weitergeleitet wird wenn man versucht die Seite mit www auf zu rufen. Irgend eine dauerhafte Lösung muss es ja geben ohne seinen Browser zu modifizieren
LG
Elies
Hi Elies,
diesen „Trick“ mit dem Löschen der HSTS-Daten musst du nur auf den Browsern ausführen, die (ursprünglich) mal durch einen falschen Redirect umgeleitet wurden. Wenn deine Cloud noch nicht „live“ ist, sollten das nur deine Browser sein.
Wenn die Weiterleitung nun korrekt eingerichtet ist, und ein Browser das erste Mal Kontakt mit deiner Website hat, ist nichts weiter zu tun. Hier sollte alles ohne weiteren Eingriff funktionieren.
Gruß,
Jan
Achso dann klappt der redirect return 301 also?
Hab gedacht da gäb es dauerhafte konflikte mit hsts.
Aber gut dann sollte der Redirect ja mit der eintragung http://www.datafixundfertig.de im http host, klappen.
LG
Elies
Also ich hab das jetzt mal mit firefox und chrome gemacht und mein redirect korrekt eingerichtet. Wird weiterhin ein mal korrekt weitergeleitet und ein zweites mal dann wieder nicht. So als würde der redirect einfach ignoriert werden.
Ja hab ich mir gedacht, dass es nicht ganz unwichtig ist.
Würde es reichen an der stelle include Subdomains raus zu nehmen?
add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“;
Ohne IncludeSubdomains funktioniert es nämlich auch.
LG
Elies
Bei der Installation von MariaDB auf einer Raspberry Pi3 mit Ubuntu Mate 16.04.2 LTS stolpere ich über diesen Fehler:
root@raspwa-pi:~# apt-get install mariadb-server
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen…. Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
mariadb-server : Hängt ab von: mariadb-server-10.1 (= 10.1.22+maria-1~xenial) ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
Hat jemand eine Idee?
Hallo Wolfram,
hast du vor der Installation deine sources.list modifiziert? Falls ja, mimm diese Stelle mal wieder raus:
# MariaDB 10.1 repository list# http://mariadb.org/mariadb/repositories/
deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu xenial main
deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu xenial main
Danach nochmal ein apt-get install mariadb-server
Kann sein, dass du hier nicht die aktuellste Version von MariaDB bekommst (welche in den offiziellen Paketquellen enthalten ist), aber die Installation sollte durchlaufen.
Hintergrund: Wie man in der sources.list sieht, fehlt hier unter arch= eine Definition für ARM. Diese wäre beim Raspi allerdings notwendig.
Gruß,
Jan
Danke für ie Hilfe – es funktioniert. Es wurde die Version 10.0.29 installiert.
Hallo Jan,
ich habe Deine Anleitung befolgt und OC läuft.
Leider meckern die Browser über das Sicherheitszertifikat.
Dies ist keine sichere VerbindungDieser Server konnte nicht beweisen, dass er XXX.XXX.XXX.XXX ist. Sein Sicherheitszertifikat stammt von meineURL.goip.de. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der Ihre Verbindung abfängt.
Was muss ich ändern?
Danke und guten Gruß ;)
McG
Hi,
hier stimmt vermutlich etwas an den Redirects nicht. Daher brauche ich etwas mehr Info:
Um besser zu erkennen, was genau abläuft (Redirects, etc.), kannst du die Developer-Console in Chrome verwenden (Shortcut: F12). Hier wird jeder Request und Response aufgelistet. Vermutlich kann man so besser erkennen, wo es hier hakt.
Gruß,
Jan
Hallo Jan!
Habe die Installation auf einer RaspberryPi3 abgeschlossen. Beim Start von Owncloud erschein nun der Fehler:
„Es scheint, dass diese Owncloud-Instanz unter einer 32.bit-PHP-Umgebung läuft und open_basedir in der Datei php.ini konfiguriert worden ist. Von einem solchen Betrieb ist abzuraten, weil es dabei zu Problemen mit Dateien kommt, deren Größe 4 GB übersteigt. Bitte entferne die open_basedir-Einstellung in deiner php.ini oder wechsele zu 64-Bit-PHP.“
Testweise habe ich die „open_basedir“-Def. unter fpm und cli wieder raus genommen und php neu gestartet – der Fehler erscheint trotzdem.
Was sollte ich tun? Das Dateien >4GB unter 32bit nicht funktionieren, damit habe ich gerechnet. Was soll der Hinweis, open_basedir zu entfernen?
Danke für die Hilfe sagt Wolfram
Hi Wolfram,
diese Meldung ist etwas verwirrend und sagt eigentlich nur aus, dass du keine Dateien >4GB hochladen kannst (Beschränkung eines 32 Bit Dateisystems). Dieses „Problem“ ist allerdings unabhängig von open_basedir. Daher kannst du diese Meldung ruhig ignorieren.
Falls du open_basedir dennoch entfernen möchtest, musst du das auch im ownCloud-vHost nachziehen, da hier die Werte aus der php.ini überschrieben werden:
fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/owncloud_data:/dev/urandomupload_max_filesize = 1G
post_max_size = 1G
max_execution_time = 3600";
Gruß,
Jan
Hallo Jan,
wunderbares Tutorial (tatsächlich eines der wenigen, dass sogar ich als Linux-Laie verstehe). Gut geschrieben und recht motivierend, sodass auch ich mich dran versuche.
Allerdings bin ich schon bei der Auswahl des richtigen Images gescheitert. Ich habe für meinen Raspberry 3 das Image „ubuntu-16.04-preinstalled-server-armhf+raspi3.img.xz“ benutzt.
Schon nach „sudo apt-get update && sudo apt-get upgrade“ und dem anschließenden Reboot landet der Pi in einer Schleife und kommt gar nicht erst zum Login.
Weiß nicht, ob Links hier erlaubt sind, falls nicht erwünscht, also bitte löschen –
mein Fehler ist so ziemlich dieser hier:
https://raspberrypi.stackexchange.com/questions/61342/raspberry-pi-3-ubuntu-16-04-server-upgrade-error
Also habe ich versucht das ganze über Raspbian/Debian Jessie („2016-09-23-raspbian-jessie-lite.zip“) versucht. Das hat auch soweit gut funktioniert, bis auf dass ich im weiteren Verlauf wahrscheinlich viele Anpassungen vornehmen müsste.
Das fängt schon an bei der Deaktivierung der default-Site des nginx-Servers „mv /etc/nginx/conf.d/default_disabled“.
Ich denke, es hat was damit zu tun, dass „conf.d“ bei dieser Konstellation gar nicht benutzt wird, sondern die Ordner „sites-available“ etc. . (Und ich denke, deswegen funktionierte der Befehl „mv“ auch nicht so wie er sollte und wollte ein weiteres Argument).
Um nicht jedes Mal bei solchen Stellen gefühlt 15 Tabs zur Recherche öffnen zu müssen, würde ich gerne den ursprünglichen Fehler beseitigen und es nochmals in deiner Konstellation und mit Ubuntu Server Classic 16.04. LTS probieren. Die auf der oben angegebenen Seite vorgeschlagene Lösung der Änderung der config.txt scheint mir eventuell später weitere Probleme auszulösen und nicht das Problem ansich zu beheben.
Gibt es hier eine andere Lösung? Vielen Dank im Voraus für eine Beantwortung.
Grüße,
Carlsson
Hi Carlsson,
also ich nutze momentan keine RasPi und habe hier auch nur Erfahrungen mit dem Standard-Debian-OS für den Pi. Was das Problem mit Ubuntu auf dem RasPi ist, kann ich dir leider nicht sagen.
Wegen dem nicht vorhandenen Verzeichnis mit den vHosts: In verschiedenen nginx Versionen orientiert man sich sehr an Apache: Es gibt zwei Verzeichnisse (/etc/nginx/sites-available/ und /etc/nginx/sites-enabled/). Die vHosts, die geladen werden sollen, befinden sich hier im sites-enabled Ordner, die nicht zu ladenden vHosts in sites-available. Die Dateiendungen spielen hier keine Rolle, deshalb funktioniert an dieser Stelle keine Deaktivierung durch Umbenennung. Um einen vHost zu deaktivieren, darf dieser nicht in /etc/nginx/sites-enabled/ gespeichert sein. Das ist alles.
Gruß,
Jan
Top Anleitung
Als Linux Neuling musste ich mich ganz schön belesen und informieren über die ganzen Befehle doch ich habe es geschafft meine Probleme und Fehler zu finden und jetzt lauft Owncloud sogar mit PHP7 auf denn Raspberry Pi 3 und mit einer Externer Festplatte.
mfg
Robert
Moin Moin, die Anleitung ist super, nur habe ich folgendes Problem. Ich möchte das Datenverzeichniss auslagern. Aber egal, was ich mache, es kommt die Meldung Das Datenverzeichniss /cloud/owncloud_data/ kann nicht erstellt oder es kann darinn nicht geschrieben werden.
Rechte sind gesetzt und der Pfad ist in der php.ini gesetzt. Nu bin ich ratlos
Hi Micheal,
ich denke, dass der Pfad nicht ganz korrekt ist: probier es doch mal mit /var/cloud/owncloud_data oder /var/owncloud_data. Des weiteren braucht der Webserver-User die entsprechenden Rechte (chown -R www-data:www-data /var/owncloud_data/).
Gruß,
Jan
Danke für die schnelle Antwort. Ich habe das jetzt mal umgestellt und Rechte vergeben. Nun kommt
Daten-Verzeichnis (/var/owncloud_data/) ist ungültig
Bitte stelle sicher, dass das Datenverzeichnis auf seiner ersten Ebene eine Datei namens „.ocdata“ enthält.
Die Pfade in der php.ini habe ich auch angebasst und php sowie ngingx neu getartet. Nur die Datei finde ich nicht.
Habe den Fehler gefunden. in der owncloud9tutorial.goip.de_owncloud.conf Zeile 89 ist nochmals die open_basedir vorhanden. Hier mus der Pfad auf das neue Verzeichniss hinzugefügt werden. Nu funktioniert es.
Vielen Dank
Michael
Hi Michael,
ja, in diesem vHost sind nochmal ein paar spezielle PHP-Einstellungen für ownCloud aufgeführt. Die vergisst man gerne mal.
Super, dass es nun bei dir klappt.
Gruß,
Jan
Hi Jan,
zunächst danke für diese super Anleitung, die mit einigen Modifikationen auch unter debian super performant läuft.
Das einzige Problem, das ich nach der vollständigen Einrichtung hatte war, dass der Login zur nextcloud sehr lange dauerte (20 – 30 Sekunden).
Per Zufall habe ich diesen Beitrag gefunden https://wiki.swechsler.de/doku.php?id=software:nextcloud:longlogin
Es ist wohl tatsächlich so, wie dort beschrieben, dass nextcloud versucht eine vermeintliche brute force Attacke zu verhindern.
Nachdem ich die Punkte aus der Anleitung umgesetzt hatte, lief es wieder super schnell.
Vielleicht betrifft das Thema ja noch andere Nutzer und du kannst es hier einbauen.
Gruß
Hendrik
Hi Hendrik,
ja, das mit dem vermeintlichen Brute-Force-Schutz ist meiner Meinung nach etwas suboptimal gelöst.
Wenn häufiger falsche Daten eingegeben werden, dann sind wir hier zeitlich schon im Minuten-Bereich. Wer daher das ganze über fail2ban gelöst hat, kann den Brute-Force-Schutz getrost ausstellen.
Gruß,
Jan
Hi Jan,
ich hoffe ich darf eine Frage off topic stellen.
Auf meinem Server habe ich nach dieser Anleitung (https://github.com/twostairs/paperwork/wiki/Installing-Paperwork-on-Debian-7) Paperwork installiert.
Leider scheitere ich mit der Anpassung der gateway.conf und paperwork.conf Datei.
Auszug gateway.conf (sonst wie oben)
…
location ^~ /paperwork {
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
send_timeout 300;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:84;
proxy_redirect off;
}
…
paperwork.conf
server {
listen 127.0.0.1:84;
server_name 127.0.0.1;
root /var/www/paperwork/frontend/public;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php;
}
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/www;
}
# pass the PHP scripts to FastCGI server listening on the php-fpm socket
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php7.0-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Ich bekomme nur eine 502 bad gateway Meldung.
Kannst du mir da auf die Sprünge helfen?
Danke und Gruß
Hendrik
Hallo Hendrik,
wie man eine zweite Web-Anwendung neben ownCloud/Nextcloud installieren kann, habe ich bereits in diesem Artikel gezeigt. Vielleicht findest du hier noch den einen oder anderen Tipp.
Falls nicht: Ein 502 Fehler ist recht allgemein. Hier sollte ein Blick in nginx‘ error.log helfen, da hier besser dokumentiert wird, was genau schief gelaufen ist. Zumindest sollte man einen Hinweis bekomen, an welcher Stelle man anpacken muss.
Gruß,
Jan
Hallo;
Ich habe mal eine Frage zum externen Zugriff.
Meine Owncloud ist so eingerichtet, dass ich über eine statische, externe IP zugreife.
Der Zugriff an sich geht auch, allerdings switcht die Owncloud im Browser nach aufblenden der Startseite auf die interne IP des Rechners (192.168.xxxx) um.
Das führt dazu, dass man von externen Rechnern keinen Zugriff mehr auf die Owncloud hat.
Wo und was muß man einstellen, dass alle Zugriffe usw. unter der externen IP laufen?
Vielen Dank
Axel
Hi Axel,
das Problem hatten schon mehrere Leute. Hier hat es dann meist geholfen, die Weiterleitung HTTP->HTTPS etwas anzuändern. Dazu einfach im ersten Server-Block im Gateway-Host folgendes abändern (erste Anweisung auskommentiert, dafür die zweite Anweisung aktiviert):
location / {# Enforce HTTPS
#return 301 https://$server_addr$request_uri;
# Use this if you always want to redirect to the DynDNS address (no local access).
return 301 https://$server_name$request_uri;
}
Nun wirst du immer auf die DynDNS-Domain weitergeleitet. Das einzige, was nun nicht mehr geht, ist der Zugriff über die lokale (LAN-)IP. Ist aber nicht weiter wild, da es hier sowieso immer Warnungen auf Grund des Zertifikats gegeben hätte.
Gruß,
Jan
Hallo Jan,
habe nach deiner Anleitung oc seit mehreren Monaten erfolgreich am laufen.
Habe nun eine zweite oc am laufen die auch soweit ohne Probleme funktioniert. Wenn ich nun eine Ferderation einrichte und im Anschluss ein Verzeichnis Freigebe, bekomme ich folgende Meldung:
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf http://webseite.de/owncloud/ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/32 blockiert („connect-src https://webseite.de„).
Ich habe auch schon google befragt, komme aber nicht weiter. Hast Du evtl. einen Tip für mich ?
Gruß und vorab Danke
Stefan
Hi Stefan,
also mit Federation Shares habe ich noch keinerlei Erfahrungen.
Haben die beiden OC-Instanzen unterschiedliche URLs? Dann könnte man sicherlich versuchen, beide URLs unter Trusted Domains (in der config.php von OC) einzutragen. Bin mir aber fast sicher, dass das so nicht funktionieren wird.
Das Thema Content Security Policy ist ziemlich umfangreich (siehe z.B. hier oder auch hier).
Bin mir daher nicht sicher, ob es sich im ein Problem mit der nginx-Config handelt, oder seitens OC. Am besten frag doch mal im OC-Forum nach.
Gruß,
Jan