Owncloud 5 Server installieren (nginx Webserver)

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Sinnvoller wäre wohl, dann gleich die owncloud als root anzugeben, also

    Code
    root /var/www/owncloud;
    index index.php;

    Es sei denn, Du verwendest den Server noch für was anderes außerhalb des owncloud-Verzeichnisses, was Du manuell aufrufen willst...

  • Stimmt, hätte ich auch drauf kommen können :blush:

    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

    Code
    location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
    
    
       deny all;
    
    
     }


    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 :D

    Einmal editiert, zuletzt von blumenwiese (31. Mai 2013 um 15:27)

  • 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 ;)

    • Offizieller Beitrag

    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 :/

    <woltlab-metacode data-name="align" data-attributes="WyJjZW50ZXIiXQ=="><p><span style="font-size: 10pt">Ein "Gefällt mir" oder die Bewertung im Profil ist eine nette Geste für die Hilfe die wir hoffentlich waren oder sind.</span></p></woltlab-metacode>

  • 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.

    Einmal editiert, zuletzt von blumenwiese (1. Juni 2013 um 17:57)

  • 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

    Code
    sudo raspi-config
    overclock auf "Medium" 4. "Finish" und danach die Frage nach dem Reboot mit "Yes" beantworten.

    6. nginx Webserver konfigurieren

    Code
    sudo nano /etc/nginx/sites-available/default


    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 konfigurieren

    9. 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

    Code
    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

    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:

    Code
    sudo rm /etc/nginx/sites-enabled/default

    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):

    Code
    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:

    Code
    sudo ln -s /etc/nginx/sites-available/owncloud /etc/nginx/sites-enabled/owncloud

    Überprüfen könnt ihr das Ganze, mit dem Befehl:

    Code
    sudo ls -l /etc/nginx/sites-enabled


    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

    Code
    rewrite ^ https://$server_name$request_uri? permanent; # enforce https

    verwenden wir besser

    Code
    return 301 https://$host$request_uri;

    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:

    Code
    sudo mv owncloud/ /var/www/owncloud

    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:

    Code
    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:

    Code
    sudo vi /etc/nginx/sites-available/owncloud

    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:

    Code
    root /var/www/owncloud;
    
    
    location ~ ^/(data|config|\.ht|db_structure\.xml|README) {

    Abspeichern, den nginx-Server restarten mit

    Code
    sudo /etc/init.d/nginx restart

    und fertig! Viel Erfolg und viel Spaß.

    PS: Wer Rechtschreibfehler findet, darf sie behalten :D

    Einmal editiert, zuletzt von Sloop (3. Juni 2013 um 02:26)

    • Offizieller Beitrag

    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

    Well in my humble opinion, of course without offending anyone who thinks differently from my point of view, but also by looking into this matter in a different way and without fighting and by trying to make it clear and by considering each and every one's opinion, I honestly believe that I completely forgot what I was going to say.

  • 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:

    Code
    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:


    Code
    sudo nano /etc/php5/fpm/pool.d/www.conf


    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

    Code
    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...

    Code
    sudo /etc/init.d/php5-fpm restart && /etc/init.d/nginx restart

    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 ! :D
    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 :)

    Einmal editiert, zuletzt von arndttob (7. Juni 2013 um 13:43)

  • 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:

    owncloud_prob1.png

    Ich denke das Problem liegt wahrscheinlich in der nginx Konfigurationsdatei für Owncloud. Diese sieht so bei mir aus:

    /etc/nginx/sites-available/owncloud:

    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

    Code
    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:

    Code
    location ~ ^/(data|config|\.ht|db_structure\.xml|README|AUTHORS|COPYING-AGPL|COPYING$){
      deny all;
      }

    Vielleicht hilfts ja :)

    Einmal editiert, zuletzt von arndttob (8. Juni 2013 um 11:45)


  • 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

  • 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

    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 :P


    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 ^^

    Einmal editiert, zuletzt von arndttob (8. Juni 2013 um 19:14)

  • 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:

    Was mich dennoch irritiert: Wenn ich nach Sloops Anleitung gehe, wird der Owncloud Unterordner wieder nicht erkannt.

    Zusammenfassend:
    Wenn ich Folgendes eingebe...

    Code
    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...

    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?

    Einmal editiert, zuletzt von DCSH (10. Juni 2013 um 12:36)

  • 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

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!