Sinnvoller wäre wohl, dann gleich die owncloud als root anzugeben, also
Es sei denn, Du verwendest den Server noch für was anderes außerhalb des owncloud-Verzeichnisses, was Du manuell aufrufen willst...
Sinnvoller wäre wohl, dann gleich die owncloud als root anzugeben, also
Es sei denn, Du verwendest den Server noch für was anderes außerhalb des owncloud-Verzeichnisses, was Du manuell aufrufen willst...
Owncloud 5 Server installieren (nginx Webserver)? Schau mal ob du hier fündig wirst!
Stimmt, hätte ich auch drauf kommen können
Aber wenn man das macht, meckert Owncloud erstmal (zu recht), dass das Dateiverzeichnis nicht mehr vor Zugriffen geschützt ist. Das löst man, in dem man hier
das "owncloud/" entfernt.
Mir ist aber aufgefallen, dass in Owncloud unter Hilfe die Dokumentation für Benutzer und die Dokumentation für Administratoren sich nicht aufrufen lassen. Stattdessen kommt ein 403. Das Ganze liegt offenbar unter core/doc/. Ich komm jetzt aber nicht drauf, was man an der Konfiguration ändern müsste, um das zu beheben. Es ist jetzt zwar nicht sonderlich schlimm, wenn man da nicht drauf kommt, aber ich hab eigentlich den Anspruch ein System zu haben, das keine Fehlermeldungen ausgeben muss
Mir ist jetzt aufgefallen, dass wenn ich im Browser direkt Server-IP/core/doc/admin/index.html aufrufen kann, wenn ich das index.html weglasse kommt jedoch ein 403.
Meine Vermutung war jetzt, dass es nicht geht, weil er nach einer index.php sucht, es aber nur eine index.html gibt. Da im owncloud-Verzeichnis neben der index.php auch eine index.html liegt, die, wenn ich sie mir mit meinen kaum vorhandenen html-Kenntnissen mal in einen Editor ansehe, so aussieht, als würde sie nur auf die index.php verweisen, dachte ich mir, es wäre mal einen Versuch wert in der /etc/nginx/sites-available/default mal index index.html; anstatt index index.php; zu schreiben.
Und siehe da, es funktioniert. Die html scheint wirklich nur zu verweisen, weil in der Adresszeile vom Browser steht dann nach wie vor wieder index.php
Vielleicht wäre es sogar eine Überlegung wert, das im Tutorial auch anzupassen
Wie kann ich eine Weiterleitung von HTTP zu HTTPS einrichten?
Habe was von .htacces oder so gelesen und folgendes im Internet:
http://raspberrypihelp.net/tutorials/33-raspberry-pi-owncloud
Kann damit aber leider nicht wirklich was anfangen
Also .htacces kanst du, wenn du nginx als Webserver verwendest, gleich mal komplett vergessen, nginx interessiert sich nicht dafür, man hat es aus Sicherheits- und Performance-Gründen anders gelöst.
Die Beispielkonfiguration in dem Link entspricht aber ja im Wesentlichen der hier im Tutorial angegebenen.
Der erste Block sorgt im wesentlichen dafür, dass von http auf https umgeleitet wird, und der zweite konfiguriert den Server dann für https.
Hallo Leute,
danke für die Bemühungen des Thread-Erstellers dieses Tutorials. Da ich jedoch lese, dass einige noch Probleme damit haben, wollte ich ein paar Sachen anmerken, bzw. korrigieren. Vielleicht könnte das ja der Thread-Ersteller im Sinne der Gemeinde anpassen.
1. Installation mit raspi-config vorbereiten
Codesudo raspi-config overclock auf "Medium" 4. "Finish" und danach die Frage nach dem Reboot mit "Yes" beantworten.
6. nginx Webserver konfigurieren
Hier löscht ihr den KOMPLETTEN Inhalt und fügt diesen ein.
Achtet darauf, dass ihr die IP-Adresse "192.168.XXX.XXX" mit der eures Raspberry Pi ersetzt. Ihr findet eure lokale Ip-Adresse mit dem Befehl "ifconfig". Je nachdem wie ihr den Pi verbunden habt, entnehmt ihr den Devices "eth" oder "wlan" eure IP-Adresse aus folgender Zeile: "inet addr:192.168.0.109 Bcast:192.168.0.255 Mask:255.255.255.0".7. PHP konfigurieren9. Owncloud installieren
Als letztes installieren wir Owncloud. Arbeite folgende Befehle nacheinander ab.
Unter anderem Erstellen wir hier das Verzeichnis "/var/www/owncloud", laden und entpacken owncloud, verschieben es in das korrekte Verzeichnis, vergeben die benötigten Rechte und löschen das zuvor herunter geladene Archiv.aktuelle Version beachten. In diesem Tutorial wurde die Version 5.0.5 benutzt
Zu Punkt 1.) Man sollte nicht ohne zusätzliche Info ermutigen, das Overclocking einzuschalten, egal ob Low oder Medium. Diverse Tests und Forenbeiträge aus der gesamten RPi Community zeigen, dass es bei diversen SD-Cards oder instabilen Spannungen aufgrund verschiedener Netzteile zu korrupten SD-cards kommen kann, damit habt ihr eure gesamte RPi-Installation zerschossen! Sicherlich ist es toll den RPi etwas höher takten zu lassen, aber das sollte keine Empfehlung innerhalb eines Tutorials sein, dass sich nicht genau mit dieser Thematik beschäftigt. Wer seinen RPi wirklich übertakten möchte, soll sich entsprechend darüber informieren. Ich würde daher diesen Punkt nicht empfehlen, oder zumindest einen Warnhinweis schreiben !
Zu Punkt 6.) irgendwas löschen ist immer eine schlechte Empfehlung, zumindest sollte man darauf hinweisen mit welcher Begründung das Ganze gewollt ist. Wenn ihr einfach euren default Inhalt der /etc/nginx/sites-available/default löscht, wie kommt ihr dann wieder da dran wenn ich diesen doch mal nutzen wollt oder zumindest als Vorlage verwenden wollt? Es gibt User die nicht nur owncloud auf ihrem RPi-Webserver betreiben, sondern auch andere Webdienste. Richtigerweise würde man die /etc/nginx/sites-available/default nicht löschen (!) sondern einfach deaktivieren. Das machen wir, indem wir den symlink aus /etc/nginx/sites-enabled entfernen mit:
Jetzt erstellen wir eine neue Konfigurationsdatei, die wir owncloud nennen und schreiben in diese Datei den Inhalt rein, der im Tutorial beschrieben wurde (copy & paste):
sudo vi /etc/nginx/sites-available/owncloud
- oder für diejenigen die nano als Editor verwenden -
sudo nano /etc/nginx/sites-available/owncloud
Jetzt aktivieren wir diese Site-Konfiguration, indem wir einen symlink entsprechend setzen:
Überprüfen könnt ihr das Ganze, mit dem Befehl:
Wenn ihr alles richtig gemacht habt, dann seht ihr, dass ein Symlink in diesem Verzeichnis existiert, und zwar namens "owncloud" der auf "/etc/nginx/sites-available/owncloud" zeigt. Das könnte z.B. so aussehen:
Zitat
lrwxrwxrwx 1 root root 35 Jun 3 00:23 owncloud -> /etc/nginx/sites-available/owncloud
Damit haben wir quasi die "default" deaktiviert, und unsere neu erstelle "owncloud" aktiviert.
Nun sollten wir uns die rewrite-Rule näher ansehen, das ist nämlich der Bereich der sämtliche Anfragen mit http:// auf eurem Webserver Nginx zu https:// umlenkt. Der im Tutorial gezeigte Weg ist wegen zwei Punkten nicht so toll:
a.) Wenn ihr eure IP-Adresse als "server_name" verwendet, dann habt ihr das Problem, dass ihr euren Owncloud-Server nicht von extern erreichen könnt. Denn was passiert wenn ihr ausserhalb von zuhause seid und in den Internetbrowser (z.B. im Internetcafé) eingibt: "http://mein-zuhause.dyndns.org/owncloud" als Beispiel??
Der nginx-Webserver würde die angeforderte Adresse einfach umschreiben zu "http://192.168.xxx.xxx/owncloud" und ihr bekommt zu 99,9% Wahrscheinlichkeit eine Fehlermeldung ausgespuckt. Denn im Internetcafé wo ihr euch gerade aufhaltet, kennt der Webbrowser keine 192.168.xxx.xxx IP-Adresse und kann nichts damit anfangen.
b.) einen rewrite sollte man mit dem-Status Code 301 einleiten, so wie es sich "richtigerweise" gehört. Erklärungen hierzu würden den Rahmen sprengen.
Wie machen wir nun also eine richtige Umleitung durch diesen rewrite-Befehl? Ganz einfach:
statt der Zeile
verwenden wir besser
Damit haben wir eine "saubere" Umleitung und sind nicht von "server_name" abhängig. Denn richtigerweise sollte "server_name" immer der Name sein, den ein Besucher der Website in seinem Webbrowser auch eingibt, z.B. "http://www.meinedomain.de" oder "http://www.hosting-service.abc". Wer nämlich mal "richtige" SSL-Zertifikate nutzen möchte oder VPN-Verbindungen, wird nicht drumherum kommen, denn da muss der "common name" eindeutig sein (!)
Zu Punkt 9.) Einige haben sich ja bereits gemeldet, dass Sie eine Fehlermeldung erhalten und nicht auf die Owncloud-Seite zugreifen können, weil in den Logs erscheint dass keine Berechtigung auf /var/www für das Indexing vorhanden sind. Deswegen kann die Seite auch nicht dargestellt werden und man kann mit der abschließenden webbasierten Installation nicht fortfahren. Der Grund hierfür liegt darin, dass durch die im Tutorial gezeigten Befehle dieses Problem entsteht.
In dem Tutorial heißt es:
sudo mkdir -p /var/www/owncloud
sudo wget http://download.owncloud.org/community/owncloud-5.0.5.tar.bz2
sudo tar xvf owncloud-5.0.5.tar.bz2
sudo mv owncloud/ /var/www/
sudo chown -R www-data:www-data /var/www
rm -rf owncloud owncloud-5.0.5.tar.bz2
Das würde aber sämtliche Owncloud-Datein in das Wurzelverzeichnis /var/www hineinkopieren und das sollte man nicht machen. Wie ich bereits zuvor erklärte, gibts User die mehr als nur "owncloud" auf ihrem Nginx-Webserver betreiben. Dafür hat jede "site" seine eigene Konfiguration und auch seinen eigenen "Dateibereich". Richtigerweise sollte alles was mit owncloud zu tun hat, in /var/www/owncloud/ vorhanden sein, und sämtliche Dateien eines anderes Webdienstes (als Beispiel raspcontrol) unter /var/www/raspcontrol/. Durch die oben genutzten Befehle landen aber ALLE Dateien in das Wurzelverzeichnis von /var/www und das sollten wir nicht (!) Der Grund hierfür liegt in dem Slashzeichen hinter dem Wort "owncloud". Zur Erinnerung, die Zeile (der vierte Befehle) lautete so:
sudo mv owncloud/ /var/www/
Richtigerweise sollte das aber so lauten, da der Threadersteller des Tutorials bereits mit einem "mkdir -p /var/www/owncloud" angefangen hat:
Um es nicht zu verkomplizieren, hier zusammengefasst alle richtige Befehle für Punkt 9.) Statt die gezeigten Befehle in Punkt 9.) beschrieben, verwenden wir nun lieber diese hier:
sudo wget http://download.owncloud.org/community/owncloud-5.0.6.tar.bz2
sudo tar xvf owncloud-5.0.6.tar.bz2
sudo mv owncloud /var/www/
sudo chown -R www-data:www-data /var/www/owncloud
sudo rm owncloud-5.0.6.tar.bz2
Wie mancheiner schon bemerkt hat, ich habe gleich den Downloadlink für die aktuellste 5.0.6 Version gepostet. Die aktuellste Version findet man immer unter http://owncloud.org/install dann klick auf den blauen Button "TAR or ZIP file" und dann klick auf den Link "Unix/Mac OS".
Durch die eben gezeigten Befehle laden wir also die Installationsdateien in gepackter Form herunter, extrahieren sie, verschieben daraufhin das komplette owncloud Verzeichnis nach /var/www, setzen anschließend die Rechte auf dieses owncloud-Verzeichnis, damit der nginx auch Zugriff darauf bekommt und zuletzt löschen wir die gepackte .bz2 Datei.
Und jetzt ganz wichtig, wir bearbeiten die Konfigurationsdatei für unsere owncloud site und bringen ihm bei, dass sämtliche Dateien für diese site unter /var/www/owncloud liegen. Wir müssen die folgende Zeile im {server} Block haben:
und dort die Zeile suchen, die mit "root" beginnt und wie folgt editieren, und auch die Zeile die mit "location ~ ^/owncloud(data|config..usw...)" beginnt suchen und abändern:
Abspeichern, den nginx-Server restarten mit
und fertig! Viel Erfolg und viel Spaß.
PS: Wer Rechtschreibfehler findet, darf sie behalten
Hallo sloop,
Danke für deinen ausführlichen Beitrag. Ich werde ihn mir, wenn ich zeit finde, in ruhe zu Gemüte führen und nachbessern.
Danke.
Gruß,
ps915
Gern geschehen Wenn wir schon dabei sind, sollten wir noch den Nginx-Webserver etwas tunen, denn das ist ja eigentlich der Sinn und Zweck dieses threads gewesen --> wir wollten weg vom leistungslastigem Apache2 Webserver und haben uns stattdessen den performanteren nginx installiert. Jedoch erfordert der nginx noch einige Anpassungen, vor allem im Betrieb auf unserem Raspberry Pi. Hier also noch einige Performance-Tips:
Performance-Tuning des nginx Webservers für den Einsatz im Raspberry Pi
(1) Wir öffnen und editieren die Datei /etc/nginx/nginx.conf und ändern folgende Zeilen ab:
die folgenden zwei Zeilen suchen wir...
worker_processes 8;
worker_connection 768;
und ändern diese ab in...
worker_processes 1;
worker_connection 128;
Somit treiben wir den nginx Dienst nicht in den Wahnsinn und lassen ihn schwitzen. Diese Werte sollten für unseren RaspberryPi völlig ausreichen, notfalls kann man auch worker_processes 2; probieren.
(2) Außerdem sollten wir den php5-fpm nicht über Ports abwickeln, sondern über eine Socketdatei. Der Performancegewinn beträgt dabei 15-20% (Google ist dein Freund). Das Tutorial zeigt es gerade andersrum, denn es hieß in dem Tutorial auf der ersten Seite:
und man solle die Zeile "listen = /var/run/php5-fpm.sock" abändern zu "listen = 127.0.0.1:9000". Dies sollten wir aber nicht tun, da wir uns Overhead und Arbeit ersparen, wenn wir die Abwicklung direkt über eine Socketdatei bewerkstelligen, statt über dem TCP/IP Protokoll.
Also mein Vorschlag wäre daher, dass wir die Zeile in der besagten Datei /etc/php5/fpm/pool.d/http://www.conf so belassen wie sie ursprünglich war, also auf:
Zitat
listen = /var/run/php5-fpm.sock
Damit das aber nun so funktioniert, müssen wir diese Änderung auch unserer nginx vHost-Konfiguration mitteilen. Wir editieren also die Datei /etc/nginx/sites-available/default (oder ggf. die /etc/nginx/sites-available/owncloud falls ihr die so benannt habt) mit dem Befehl
sudo nano /etc/nginx/sites-available/default
bzw. "sudo nano /etc/nginx/sites-available/owncloud"
und ändern dort die Zeile:
Zitat
fastcgi_pass 127.0.0.1:9000;
ab nach:
Zitat
fastcgi_pass unix:/var/run/php5-fpm.sock
Dann noch den php5-fpm Dienst und nginx Webserver neu starten...
et-voilá, fertig!
PS: Im Tutorial wurde bei der Paketinstallation auch "varnish" installiert, jedoch nie darauf eingegangen. Wieso?
Hallo,
wie kann man denn nachträglich nocheinmal die Erstkonfiguration aufrufen, bzw. ich habe vergessen meine externe Festplatte als Speicherort zu setzen. Wie hole ich das nach?
Sooo Problem gelöst !
Ich blödel habe das Terminal via XRDP und Remotedesktop bedint, sowas machen auch nur Windows verseuchte User ! Jetzt habe ich das wie sich das gehört über SSH und Putty realisiert, und siehe da in der config (Punkt 6.) haben sich massive fehler eingeschlichen, die man unter remotedesktop nicht sehen konnte !
Hallo zusammen,
gibt es noch eine andere Lösung um diesen Fehler zu beheben? Ich muss mich leider zu diesen Windows verseuchten Benutzern zählen die sich mit ssh und Putty nicht auskennen.
Gruß legion
Hallo zusammen,
gibt es noch eine andere Lösung um diesen Fehler zu beheben? Ich muss mich leider zu diesen Windows verseuchten Benutzern zählen die sich mit ssh und Putty nicht auskennen.
Gruß legion
http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe downloaden und starten.
Bei "Host Name" die IP deines Raspberrys eintragen und auf Enter drücken. Fertig.
Sloop danke für deine Nachbesserung. Habe es bei jetzt auf die Socks umgestellt. Noch läufts sehr holprig (Windows Sync Client verliert dauernd die Verbindung und überm Browser läuft es noch sehr lahm), aber ich lass es mal ein paar Tage so und vielleicht renkt sich das noch ein Ich werde berichten.
edit1: nach einem Neustart des Pis funktioniert alles wieder. Mal schauen wies mit der Performance ist
Hallo Sloop und alle anderen,
ich bin nach oben beschriebener Anleitung vorgegangen. Ich habe nginx installiert und eine Konfigurationsdatei für owncloud unter /etc/nginx/sites-available/owncloud erstellt (von hier)und ebendiese unter /etc/nginx/sites-enabled/ mit einem Softlink aktiviert. Ich habe ein dynamischen DNS Adresse bei noip.com registriert und kann diese auch erreichen (No-IP.com kann man in der Fritz-Box direkt als Dyn-DNS auswählen).
Im Prinzip funktioniert die Owncloud wenn ich http(s)://meinenoipadresse.no-ip.org aufrufe. Da ich aber noch zusätzliche Dienste wie bspw. selfoss nutzen möchte würde ich owncloud gerne unter http(s)://http://meinenoipadresse.no-ip.org/owncloud erreichbar machen und selfoss unter http(s)://http://meinenoipadresse.no-ip.org/selfoss.
Wenn ich nun http(s)://http://meinenoipadresse.no-ip.org/owncloud aufrufe bekomme ich folgendes angezeigt:
Ich denke das Problem liegt wahrscheinlich in der nginx Konfigurationsdatei für Owncloud. Diese sieht so bei mir aus:
/etc/nginx/sites-available/owncloud:
# redirect http to https.
server {
listen 80;
server_name 192.168.178.3;
return 301 https://$host$request_uri;
# rewrite ^ https://$server_name$request_uri? permanent; # enforce https
}
# owncloud (ssl/tls)
server {
listen 443 ssl;
server_name 192.168.178.3;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# Path to the root of your installation
root /var/www/owncloud;
client_max_body_size 2000M; # set max upload size
fastcgi_buffers 64 4K;
rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;
index index.php;
error_page 403 = /core/templates/403.php;
error_page 404 = /core/templates/404.php;
location ~ ^/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING$
deny all;
}
location / {
rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
rewrite ^/apps/calendar/caldav.php /remote.php/caldav/ last;
rewrite ^/apps/contacts/carddav.php /remote.php/carddav/ last;
rewrite ^/apps/([^/]*)/(.*\.(css|php))$ /index.php?app=$1&getfile=$2 last;
rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
try_files $uri $uri/ index.php;
}
location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
try_files $script_name = 404;
include fastcgi_params;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
# Optional: set long EXPIRES header on static assets
location ~* ^.+.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
expires 30d;
# Optional: Don't log access to assets
access_log off;
}
}
Alles anzeigen
Hat jemand eine Idee, warum ich nicht auf den Unterordner /owncloud zugreifen kann?
Gruß, Der-Don
Hey Don,
so wie ich das sehe fehlt bei dir in der obersten Zeile vom Ausschnitt
location ~ ^/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING$
deny all;
}
eine schließende und öffnende Klammer => '){'
also die Zeilen mit folgenden ersetzen:
location ~ ^/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING$){
deny all;
}
Vielleicht hilfts ja
eine schließende und öffnende Klammer => '){'
Hi arndttob,
danke für die schnelle Antwort, da hast du natürlich Recht. Dummerweise liegt das an meinem Unvermögen ein einfaches copy&paste durchzuführen, die Klammern sind nämlich vorhanden ich habe die Konfigurationsdatei nur nicht richtig kopiert.
Wäre schön wenn es so einfach gewesen wäre.
Hier also nochmal die gesamte, nun hoffentlich richtig kopierte Konfigurationsdatei:
/etc/nginx/sites-available/owncloud
redirect http to https.
server {
listen 80;
server_name 192.168.178.3;
return 301 https://$host$request_uri;
# rewrite ^ https://$server_name$request_uri? permanent; # enforce https
}
# owncloud (ssl/tls)
server {
listen 443 ssl;
server_name 192.168.178.3;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# Path to the root of your installation
root /var/www/owncloud;
client_max_body_size 2000M; # set max upload size
fastcgi_buffers 64 4K;
rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;
index index.php;
error_page 403 = /core/templates/403.php;
error_page 404 = /core/templates/404.php;
location ~ ^/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING-README) {
deny all;
}
location / {
rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
rewrite ^/apps/calendar/caldav.php /remote.php/caldav/ last;
rewrite ^/apps/contacts/carddav.php /remote.php/carddav/ last;
rewrite ^/apps/([^/]*)/(.*\.(css|php))$ /index.php?app=$1&getfile=$2 last;
rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
try_files $uri $uri/ index.php;
}
location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
try_files $script_name = 404;
include fastcgi_params;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
# Optional: set long EXPIRES header on static assets
location ~* ^.+.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
expires 30d;
# Optional: Don't log access to assets
access_log off;
}
}
Alles anzeigen
Hm... ich kann da keinen Fehler mehr entdecken.
Hast du schon probiert mittels lokaler IP zu connecten?
https://192.168.178.3/owncloud
Ja, habe ich bereits mit Firefox und Chromium ausprobiert. Beide Male bekomme ich die gleiche Meldung wie oben. (D.h. die No-IP Weiterleitung funktioniert, ebenso die "Weiterleitung" von http zu https)
Kann es vielleicht mit meinem selbst-erstellten SSL-Zertifikat zusammenhängen?
mit dem Zertifikat dürfte das nichts zu tun haben, da du ja schon durch die SSL abfrage kommst und die owncloud-Oberfläche siehst.
Ich hab hier mal meine /etc/nginx/sites-available/default - Datei
server {
listen 80;
server_name 192.168.178.3;
root /var/www;
index index.php index.html;
fastcgi_buffers 64 4K;
client_max_body_size 1000M;
location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
deny all;
}
location / {
try_files $uri $uri/ index.php;
}
location @webdav {
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS on;
include fastcgi_params;
}
location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
try_files $script_name = 404;
include fastcgi_params;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}
server {
listen 443 ssl;
server_name 192.168.178.3;
ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;
root /var/www;
index index.php index.html;
client_max_body_size 1000M; # set maximum upload size
fastcgi_buffers 64 4K;
location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
deny all;
}
location / {
try_files $uri $uri/ index.php;
}
location @webdav {
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS on;
include fastcgi_params;
}
location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
try_files $script_name = 404;
include fastcgi_params;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}
Alles anzeigen
probier sie doch einfach mal aus. Bei mir funktionierts auch mit Unterordnern. (Owncloud liegt in /var/www/owncloud) und da unsere Pi's die gleichen IP's haben kannstes ja 1:1 einfügen vergiss nicht deine /etc/nginx/sites-available/owncloud datei unschädlich zu machen
hoffe doch dass du die Konfiguration und Bearbeitung alles über SSH machst
zu der Sache mit den SOCKS. Einen Geschwindigkeitszuwachs kann ich leider noch nicht feststellen vielleicht liegts daran, dass Owncloud einfach schon seit einem Tag von mir dauerbetankt wird
Hallo arndttop,
ja klar mache ich das über ssh, der Raspi läuft bei mir kopflos (damit ich den gesamten Arbeitsspeicher für die Owncloud nutzen kann ;)). Ich verwende aber Dropbear, da dieser deutlich schlanker als openssh sein soll.
ich habe nun deine Konfigurationsdatei größtenteils übernommen und habe nun /owncloud als Unterordner meiner No-IP Domain. Danke dafür, es funktioniert also.
Hier mal meine aktualisierte Konfigurationsdatei:
# redirect http to https.
server {
listen 80;
server_name 192.168.178.3;
return 301 https://$host$request_uri;
}
# owncloud (ssl/tls)
server {
listen 443 ssl;
server_name 192.168.178.3;
# Own SSL Certification
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# Path to the root of your installation
root /var/www;
#
index index.php index.html;
# Max file size
client_max_body_size 2000M; # set max upload size
fastcgi_buffers 64 4K;
#
location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING-README) {
deny all;
}
#
location / {
try_files $uri $uri/ index.php;
}
#
location @webdav {
fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS on;
include fastcgi_params;
}
#
location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
try_files $script_name = 404;
include fastcgi_params;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}
Alles anzeigen
Was mich dennoch irritiert: Wenn ich nach Sloops Anleitung gehe, wird der Owncloud Unterordner wieder nicht erkannt.
Zusammenfassend:
Wenn ich Folgendes eingebe...
root /var/www;
location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING-README) {
deny all;
}
...dann lässt sich die Seite https://meinenoipadresse.no-ip.org/owncloud aufrufen. Bei https://meinenoipadresse.no-ip.org bekomme ich "nginx 404 not found".
Bei folgendem Code...
root /var/www/owncloud;
location ~ ^/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING-README) {
deny all;
}
...funktioniert wieder nur die Hauptdomain, nicht aber der Unterordner.
Irgendwie erscheint mir das unlogisch. Kennt sich jemand mit nginx so gut aus, dass er mir das erklären kann?
Gruß, Der_Don
Ganz dusselige Frage: Was möchtest Du eigentlich?
Dein root-dir verweiste im ursprünglichen Post nach /var/www/owncloud. D.h., wenn Du http://*.no-ip.org eingibst, wirst Du auf /var/www/owncloud geschleust. Das deckt sich mit Deiner Aussage, dass http://*.no-ip.org/ "mit der owncloud funktioniere". Das heisst aber auch, dass http://*.no-ip.org/owncloud faktisch auf /var/www/owncloud/owncloud zeigt, das kann also nicht gehen.
Wenn Du's im SubDir haben willst - so habe ich das verstanden, dass Du owncloud über http://*.no-ip.org/owncloud aufrufen willst - musst Du als root-dir zwangsläufig /var/www definieren. Das hast Du nun aber auch gemacht. So wie ich Deinen letzten Post verstanden habe, funktioniert ja gerade der Zugriff über http://*.no-ip.org/owncloud. Da Du im root-Verzeichnis /var/www vermutlich keine index-Datei hast, kommst Du zwangsläufig zum 404. Soweit also alles in Ordnung. Die "location ... {deny} Befehle machen nichts anderes, als den Zugriff auf bestimmte Daten zu sperren. Dazu müssen die relativ zur Installation richtig definiert sein - es ändert aber nichts an der Erreichbarkeit des eigentlichen Servers und seiner Seiten. Das config-file sieht dahingehend aber gut aus. Tritt das Problem mit dem "Cloud nicht gefunden" jetzt immer noch an der Stelle auf?
Hallo DCSH,
danke für deine Antwort. Ich denke jetzt habe ich verstanden was ich da mache. Vielleicht habe ich mich nicht verständlich genug ausgedrückt.
Mein eigentliches Ziel ist es unter einer http://*.no-ip.org Adresse verschiedene Dienste in Unterordnern anzubieten (ich glaube Subdomains würden bei no-ip extra kosten). Also z.B.
Owncloud: http://*.no-ip.org/owncloud
Raspbcontrol: http://*.no-ip.org/raspcontrol
RSS: http://*.no-ip.org/selfoss
Pyload: http://*.no-ip.org/pyload -> Weiterleitung auf Pyload Weboberfläche
usw...
Das würde ich gerne alles in Nginx organisieren. Mit Owncloud funktioniert es schon mal danke dafür. Problem gelöst. Für den Rest werde ich mich noch ein bisschen einlesen müssen.
Danke auch für das Tutorial von ps915 und die Ergänzungen von Sloop
Der_Don
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!