[Mint / Flawless Server] Nginx sites niet bereikbaar

[Mystic Spirit]

Deze week ben ik een "remix" van Linux Mint op het spoor gekomen, waarbij alle pakketten die ik regelmatig gebruik (en nog een paar meer) zijn ingebakken. De remix heet Flawless Server (zie http://flawless-server.com). Bij mij verloopt het echter niet helemaal flawless

De meeste pakketten die ingebakken zitten doen het out of the box. Het probleem begint bij de pakketten die worden aangeboden via Nginx. Die zijn niet zoals de website omschrijft bereikbaar via de url die wordt opgegeven. In deze post gaat het om owncloud.

Ik heb al van alles geprobeerd maar ben niet echt thuis in Nginx en weet niet zo goed waar ik moet beginnen met trouble shooten.

Wat ik weet:

• Nginx werkt. Als ik naar de localhost surf krijg ik het welcome to nginx scherm te zien
• Volgens de site moet owncloud bereikbaar zijn op https://cloud.yourdomain.org (waarbij yourdomain natuurlijk een domein is dat je zelf moet instellen)
• Ik heb geen domein gedefinieerd in linux maar gebruik localhost (dus https://cloud.localhost)
• In onderstaande config file is de vhost als cloud.example.com gedefinieerd, maar ik heb ook al cloud.localhost geprobeerd (geen resultaat)

De vhost (of block) die gedifinieerd is in Nginx ziet er zo uit:

code:

server {
       listen 80;
       listen 443 ssl;
       server_name cloud.example.com;
       root /var/www/owncloud/web;

       #enforce https
       if ($ssl_protocol = "") {
            rewrite ^   https://$server_name$request_uri? permanent;
       }

       access_log /var/www/owncloud/log/access.log;
       error_log /var/www/owncloud/log/error.log;

       index index.php index.html;
       error_page 403 /core/templates/403.php;
       error_page 404 /core/templates/404.php;

       location = /favicon.ico {
                log_not_found off;
                access_log off;
       }

       location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
       }

       # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
       location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
       }

        client_max_body_size 10G; # set max upload size

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;
        

        location ~ ^/(data|config|\.ht|db_structure\.xml|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 ^(/core/doc/[^\/]+/)$ $1/index.html;

                        try_files $uri $uri/ /index.php;
        }

        location ~ ^(.+?\.php)(/.*)?$ {
                        try_files $1 =404;
                        include fastcgi_params;
                        fastcgi_param SCRIPT_FILENAME $document_root$1;
                        fastcgi_param PATH_INFO $2;
                        fastcgi_param HTTPS $https;
                        fastcgi_pass unix:/var/run/php5-fpm.sock;
                        fastcgi_intercept_errors on;
                        fastcgi_index index.php;
                        fastcgi_buffers 64 4K;
        }

        location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                        expires 30d;
                        access_log off;
        }
}

Kortom: Ik ben al een heel aantal uren aan het klooien en zoeken, maar kom er niet uit. Iemand die mij een zetje in de goede richting kan geven?
Zou de owncloud server bijvoorbeeld ook op een URL beschikbaar moeten zijn zonder de vhost (zoiets als localhost/owncloud/web/)?

[FREAKJAM]

Totaal geen idee of deze distro op basis van systemd werkt en SELinux, maar wellicht moet je de boel openzetten in de firewall (Uncomplicated Firewall (ufw)) en SELinux op permissive zetten.

Je kunt ook nog eventueel mijn blog spieken en daar een werkende config jatten, ik heb vrij recent ownCloud geinstalleerd in Ubuntu 14.04 met Nginx.

[ Voor 18% gewijzigd door FREAKJAM op 22-12-2014 16:00 ]

[Hero of Time]

Wat als je pingt naar de betreffende hostnaam die je in je nginx config hebt gezet? Wat krijg je terug? Dit is gewoon troubleshooting 101, het eerste wat je doet is zorgen dat de boel wel netjes resolved.

[FREAKJAM]

Je kunt bij server_name in de config in Nginx trouwens ook meerdere entries plaatsen. Zet er anders het ip-adres even bij van je server en herstart nginx en test dan nog eens op basis van je ip.

bijvoorbeeld:
server_name 192.168.1.10 cloud.domain.com;

[Demo]

Als de domeinnaam die jij probeert te openen niet in de server_name staat, dan ga je ownCloud niet te zien krijgen.
Daarnaast zou ik liever een listener maken op poort 80 met een redirect en die laten verwijzen naar poort 443:

code:

server {
        listen 80;
        server_name cloud.example.com cloud.localdomain cloud;
        return 301 https://$host$request_uri;  # enforce https
}

server {
        listen 443 ssl;
        server_name cloud.example.com cloud.localdomain cloud;
        access_log /var/www/owncloud/log/access.log;
        error_log /var/www/owncloud/log/error.log;

Is /var/www/owncloud/log/ trouwens schrijfbaar voor nginx? Wat geven de logfiles aan?

[Mystic Spirit]

Het is voor mij allemaal behoorlijk nieuw, maar volgens mij komen we in de richting

@FREAKJAM
Als ik het ip en localhost toevoeg aan de config (dus: server_name 192.168.xxx.xxx localhost cloud.example.com;) kom ik met http://localhost uit op de owncloudserver. cloud.example.com werkt echter niet het het ip ook niet.
Zodra ik er cloud.localhost van maak, loopt de boel weer dood.
Ook als ik het IP weg laat (dus: server_name localhost cloud.example.com;) loopt de boel dood.

Enig inzicht hoe dat kan komen?

@Demoniac
Je bent voor mij abracadabra aan het praten ik heb (nog) geen idee wat het verschil is tussen listener en wat ik nu in de config heb staan... en weet ook niet wat het effect daarvan is op de andere service die er nog naast draait ook op port 80.

@Hero of Time
Het kan zijn dat ik nu een super noob opmerking maak, maar ik ben nu alleen nog aan het testen op de machine zelf. Pingen van dezelfde machine waar alles op draait naar de machine waar alles op draait kan toch niet?

[ Voor 40% gewijzigd door Mystic Spirit op 22-12-2014 16:47 ]

[Mijzelf]

Wat bedoel je met 'doodlopen'? Als ik dit verhaal lees verwacht ik dat je browser gewoon een 'domein niet gevonden' fout geeft.

cloud.example.com is een (sub)domein, en moet dus door je dns systeem worden geresolved. (via je dns server of via je hosts file). Dan heeft je browser een ip adres, en pas dan kan nginx in actie komen met zijn virtuele domeinen.

Dus zolang 'ping cloud.example.com' niets oplevert, kan dit niet werken. (Hele vreemde browsers daargelaten).

Ik vind dit trouwens een vreemde setup. Om dit vanbuiten te kunnen gebruiken moet je al een eigen domein met subdomeinen hebben.

[Mystic Spirit]

De informatie op de site van Flawless Server gaat inderdaad uit van een eigen domein en subdomeinen. Nu heb ik wel een domein (en daar kan ik uiteraard ook subdomeinen in aanmaken), maar het is niet mijn intentie om de boel nu van buiten benaderbaar te maken, voor ik eruit ben hoe het werkt.

Ik heb nu cloud.example.com toegevoed aan /etc/hosts en dan kom ik inderdaad wel uit bij de owncloud server.
Hoe kan ik de config veranderen zodat het gewoon werkt voor mijn interne netwerk? Het moet misschien op termijn wel van buiten benaderbaar zijn, maar eerste doel is van binnen en over VPN.

[ Voor 29% gewijzigd door Mystic Spirit op 22-12-2014 17:15 ]

[Demo]

Wat ik bedoel: je configuratie luistert nu op poort 80 en 443. In regel 8 t/m 10 wordt er gekeken of de communicatie over HTTPS verloopt en zo niet dan word je naar de https-pagina verwezen.

nginx doet aan virtualhosts, op basis van een domeinnaam laat hij een bepaalde pagina zien. Ik heb zelf ownCloud, Roundcube en nog wat web-meuk draaien op dezelfde server, afhankelijk van de domeinnaam die naar die server verwijst krijg je verschillende pagina's te zien. Als je een server_name foo.bar.com hebt staan in je conf, dan krijg je de pagina alleen te zien als je hem via die domeinnaam oproept. Als jij cloud.example.com wil gebruiken, dan zal je die ofwel als DNS-record moeten maken, of in de hosts-file zetten van ieder device dat je met ownCloud wil connecten.

Er staat nergens een SSL-certificaat genoemd, dus ik vraag me af of dit überhaupt gaat werken over HTTPS.

De eerste stap bij Linux-EHBO is altijd logfiles checken. Het kan haast niet anders dan dat in /var/www/owncloud/log/error.log een hoop informatie staat.

[Mystic Spirit]

Ik heb de log er even bijgepakt en dit is de inhoud:

code:

2014/12/22 16:16:00 [error] 8522#0: *6 access forbidden by rule, client: 192.168.124.68, server: 192.168.124.68, request: "GET /data/htaccesstest.txt HTTP/1$
2014/12/22 16:16:01 [error] 8522#0: *14 access forbidden by rule, client: 192.168.124.68, server: 192.168.124.68, request: "GET /data/htaccesstest.txt HTTP/$
2014/12/22 16:28:20 [error] 9223#0: *5 access forbidden by rule, client: 192.168.124.68, server: 192.168.124.68, request: "GET /data/htaccesstest.txt HTTP/1$
2014/12/22 16:28:20 [error] 9223#0: *13 access forbidden by rule, client: 192.168.124.68, server: 192.168.124.68, request: "GET /data/htaccesstest.txt HTTP/$
2014/12/22 16:28:59 [error] 9223#0: *17 access forbidden by rule, client: 192.168.124.68, server: 192.168.124.68, request: "GET /data/htaccesstest.txt HTTP/$
2014/12/22 16:28:59 [error] 9223#0: *20 access forbidden by rule, client: 192.168.124.68, server: 192.168.124.68, request: "GET /data/htaccesstest.txt HTTP/$
2014/12/22 17:08:28 [error] 9415#0: *13 access forbidden by rule, client: 127.0.0.1, server: localhost, request: "GET /data/htaccesstest.txt HTTP/1.0", host$
2014/12/22 17:08:28 [error] 9415#0: *20 access forbidden by rule, client: 127.0.0.1, server: localhost, request: "GET /data/htaccesstest.txt HTTP/1.0", host$
2014/12/22 17:23:28 [error] 9415#0: *34 access forbidden by rule, client: 127.0.0.1, server: localhost, request: "GET /data/htaccesstest.txt HTTP/1.0", host$
2014/12/22 17:38:28 [error] 9415#0: *40 access forbidden by rule, client: 127.0.0.1, server: localhost, request: "GET /data/htaccesstest.txt HTTP/1.0", host$
2014/12/22 17:53:29 [error] 9415#0: *45 access forbidden by rule, client: 127.0.0.1, server: localhost, request: "GET /data/htaccesstest.txt HTTP/1.0", host$
2014/12/22 18:08:28 [error] 11724#0: *3 access forbidden by rule, client: 127.0.0.1, server: cloud.flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP$
2014/12/22 18:12:10 [error] 11895#0: *5 access forbidden by rule, client: 192.168.124.68, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP/$
2014/12/22 18:12:11 [error] 11895#0: *13 access forbidden by rule, client: 192.168.124.68, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP$
2014/12/22 18:23:28 [error] 11895#0: *18 access forbidden by rule, client: 127.0.0.1, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP/1.0"$
2014/12/22 18:27:11 [error] 11895#0: *22 access forbidden by rule, client: 192.168.124.68, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP$
2014/12/22 18:38:28 [error] 11895#0: *28 access forbidden by rule, client: 127.0.0.1, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP/1.0"$
2014/12/22 18:42:11 [error] 11895#0: *32 access forbidden by rule, client: 192.168.124.68, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP$

zoals je aan de log kan zien heb ik aardig wat combinaties geprobeerd en snap ik er duidelijk nog weinig van....

[Cor453]

Volgens mij probeer je met deze rule:

code:

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

iedereen te weren die een locatie opvraagt waar iets inzit dat lijkt op data, config .ht*, db_structure, .xml en README. Als jij dan /data/htaccesstest.txt op gaat vragen gaat dat niet werken, want daar zit "data" in.

[ Voor 10% gewijzigd door Cor453 op 22-12-2014 18:55 ]

[Mystic Spirit]

Ik vraag niet bewust /data op. dat is kennelijk het gevolg van het intoetsen van url die op de een of andere manier niet werkt.

Hoe zou ik de config het beste aan kunnen passen voor intern (eigen etwerk) gebruik?

[Cor453]

Hmm. Intoetsen van een URL die op een of andere manier niet werkt. Kun je die URL eens posten? Kunnen we kijken waar het fout gaat.

[Mystic Spirit]

Tot nog toe is het allemaal op mijn lokale netwerk, maar je kan aan de laatste log regel zien wat er gebeurd.

Ik toets in mijn browser (niet op de server machine) de url flawless.ac87u in en dit is wat er dan in de log terecht komt:
2014/12/22 18:42:11 [error] 11895#0: *32 access forbidden by rule, client: 192.168.124.68, server: flawless.ac87u, request: "GET /data/htaccesstest.txt HTTP$

flawless is de hostnaam van de server en de .ac87u heb ik er even achter gezet om te proberen of het hielp om de domeinnaam van mijn router erbij te zetten. Dat hielp, want met flawless.ac87u in de nginx config komt hij wel op de site, maar dan krijg je dus deze errors. Als ik een URL pak die helemaal geen connectie maakt gebeurd er ook niks in de log.

[ Voor 15% gewijzigd door Mystic Spirit op 22-12-2014 19:39 ]

[Mystic Spirit]

Heel wat leeswerk verder, probeer ik nu maar eens bij de basis te beginnen, maar ook hier lijk ik niet uit te komen. Het doel is om niet met een subdomein te werken, maar te luisteren naar een specifiek poortnummer. Om alle variabelen uit te sluiten heb ik de standaard config die nginx aangeeft gebruikt.

de vhost ziet er nu zo uit:

code:

server {
    server_name_;
       access_log /var/www/owncloud/log/access.log;
       error_log /var/www/owncloud/log/error.log;

    listen 8080;

    location / {
        root /var/www/owncloud/web;
    }

    location ~ \.lang$ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:port;
        fastcgi_split_path_info ^()(.*)$;
    }
}

Echter deze config werkt ook niet. Als ik nu de url 192.168.124.68 in mijn browser zet krijg ik een "unable to connect" melding. De poort zit echter niet dicht, want als ik de poort check met nmap -p 8080 192.168.124.68 krijg ik wel reactie.

Omdat ik een unable to connect krijg in de browser, is de errorlog en de acceslog leeg, dus daar haal ik geen info uit..

Iemand die iets kan toevoegen aan mijn config waardoor het mogelijk wel werkt?

offtopic:
Ondertussen heb ik mijn eiegen DNS opgezet en daar een paar URL's in geconfigureerd. Die toegevoegd aan de eerdere nginx config en dat werkt prima. Ik weet dus zeker dat het kan werken, maar vind het een beetje onzinnig om een DNS in de lucht te houden om een paar webservices voor mijn lokale netwerk te kunnen bereiken.

[ Voor 17% gewijzigd door Mystic Spirit op 23-12-2014 17:07 ]

[Blokker_1999]

wat staat server_name; daar te doen? is dat wel geldig in de config?

En je kan bij listen natuurlijk ook aangeven dat dit de default server is:

code:

listen 8080 default_server;

[Mystic Spirit]

ik heb het ook zonder server_name; geprobeerd, maar las ergens anders dat het gebruikelijk is om server_name_; te gebruiken. Het effect is echter hetzelfde. Het werkt niet.

Ook het toevoegen van default_server heeft geen effect op de uitkomst. Ik blijf een unable to connect krijgen in mijn browser.

Zelfs op de server zelf krijg ik een uanble to connect als ik localhost:8080 doe en ook als ik 127.0.0.1:8080 doe. Het probleem zit dus niet in het van buiten naar binnen, maar ergens anders.

[ Voor 24% gewijzigd door Mystic Spirit op 23-12-2014 18:24 ]