[NGINX] Nginx met PHP-FPM serveert bin files

[wilmardo]

Ha Tweakers!

Zoals de topic titel aangeeft het ik een probleem met Nginx en PHP-FPM, deze serveert alleen 57b bin files in plaats van de php files te executen (see wilmardenouden.nl)
Ik zal even kort beschrijven wat de achtergrond van dit verhaal is. Ik had altijd een VM die alles deed, mail, database, webserver enzovoorts. Nu sinds kort naar een LXC container setup gegaan die ik provision met Ansible. Ook ben ik aan de gang gegaan met het beter scheiden d.m.v users en permissies en met het gebruik van een OTAP (OTP but you het the idea)

Het idee is dat de loadbalancer alle HTTPS regelt en het verkeer achter de loadbalancer over HTTP gaat (mocht dit geen handige aanpak zijn, hoor ik het graag!). Achter de loadbalancer bevinden zich losse containers met alle services zoals webserver, mailserver enzovoort.

Dus begonnen met een Nginx loadbalancer met de volgende config:

code:

server {
    listen              443 ssl http2;
    listen              [::]:443 ssl http2;

    server_name         wilmardenouden.nl;

    ssl                 on;
    ssl_certificate     /etc/letsencrypt/live/wilmardenouden.nl/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/wilmardenouden.nl/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/wilmardenouden.nl/chain.pem;
    ssl_stapling        on;
    ssl_stapling_verify on;
    ssl_session_timeout 1d;
    ssl_session_cache   shared:SSL:50m;
    ssl_session_tickets off;

    add_header          Strict-Transport-Security "max-age=31536000; preload";
    add_header          X-Frame-Options SAMEORIGIN;

    location / {
        proxy_pass      http://192.168.1.106:80;
    }
}

De problematische webserver heeft de volgende Nginx config

code:

server {
    listen              80 http2;

    server_name    wilmardenouden.nl;
    root                /home/production/www/;

    access_log              /home/production/log/nginx/access.log main buffer=16k;
    error_log               /home/production/log/nginx/error.log warn;

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

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

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
    include fastcgi_params;
        fastcgi_intercept_errors on;
        fastcgi_pass unix:/run/php-fpm-production.sock;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
    }
}

En dit is de PHP-FPM pool horende bij de production

code:

[production]
user = production
group = production
listen = /run/php-fpm-production.sock
listen.owner = nginx
listen.group = nginx
listen.mode=0660

pm = dynamic
pm.max_children = 18
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 512
php_admin_value[memory_limit] = {{ webserver_php_memory_limit }}
php_admin_value[post_max_size] = {{ webserver_php_post_max_size }}
php_admin_value[upload_max_filesize] = {{ webserver_php_max_file_size }}
php_admin_value[error_log] = /home/production/log/php-fpm/error.log
rlimit_files = 131072
security.limit_extensions = .php

Wie ziet hier rare dingen? Ik ben al twee dagen aan het zoeken en weet het nu echt niet meer
De loadbalancer logt het volgende, wat mijn vermoeden bevestigd dat het probleem op de webserver ligt.

code:

[error] 10300#10300: *44 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: 182.186.165.175, server: wilmardenouden.nl, request: "GET /wp-login.php HTTP/1.1", upstream: "http://192.168.1.106:80/wp-login.php", host: "wilmardenouden.nl"

Maar de webserver logt niks, geen errors in /var/log/nginx/error.log. Maar ook geen entries in /home/production/logs, nginx maakt wel de error.log en access.log aan maar deze blijven leeg. PHP maakt ook geen logfile aan in de php-fpm folder.

Ik heb intussen zelf al zoveel geprobeerd dat ik het niet allemaal neer kan zetten, ook lijkt het me handig dat jullie er gewoon vanuit gaan dat ik nog helemaal niks heb getest. Wie weet heb ik ergens wat gemist of zie ik iets heel duidelijks over het hoofd.

Alvast bedankt voor het lezen van mijn verhaal!
Ik heb mijn best gedaan alles zo duidelijk mogelijk te omschrijven, mocht er iets niet duidelijk zijn vraag maar raak!

[Hero of Time]

Je backend server heeft niets in z'n access.log staan? Werkt het wel als je zonder SSL de boel doorstuurt? Overigens heb je geen load balancer op deze manier, maar een reverse proxy.

[wilmardo]

En natuurlijk vind je alsnog de oplossing net als je een topic hebt geopend
Het probleem zit hem in dat de proxy module geen http2 ondersteund naar de backend (zie hier). Dus bij de webserver http2 verwijderd bij de listen directive en tada we hebben entries in de access en error log.

Hero of Time schreef op zondag 9 juli 2017 @ 20:13:
Je backend server heeft niets in z'n access.log staan? Werkt het wel als je zonder SSL de boel doorstuurt? Overigens heb je geen load balancer op deze manier, maar een reverse proxy.

Bedankt voor de reactie! Er kwam inderdaad niks in de access log, geen idee waarom Nginx niks registreert terwijl de request er wel aankomt maar borkt.
Op dit moment is het inderdaad geen loadbalancer dat is een eventuele volgende stap

Maar toch nog een vervolg vraag, ik zit nu met een permissie probleem omdat Nginx de files niet kan lezen die production:production als eigenaar hebben. Dit terwijl de permissies op 775 voor de folders en 664 vo?or de files. Hoe kan dit? Nginx hoeft toch alleen maar read access op files en folder te hebben?

[ Voor 16% gewijzigd door wilmardo op 09-07-2017 21:08 . Reden: vervolg vraag toegevoegd ]

[McKaamos]

wilmardo schreef op zondag 9 juli 2017 @ 21:03:
En natuurlijk vind je alsnog de oplossing net als je een topic hebt geopend
Het probleem zit hem in dat de proxy module geen http2 ondersteund naar de backend (zie hier). Dus bij de webserver http2 verwijderd bij de listen directive en tada we hebben entries in de access en error log.


[...]

Bedankt voor de reactie! Er kwam inderdaad niks in de access log, geen idee waarom Nginx niks registreert terwijl de request er wel aankomt maar borkt.
Op dit moment is het inderdaad geen loadbalancer dat is een eventuele volgende stap

Maar toch nog een vervolg vraag, ik zit nu met een permissie probleem omdat Nginx de files niet kan lezen die production:production als eigenaar hebben. Dit terwijl de permissies op 775 voor de folders en 664 vo?or de files. Hoe kan dit? Nginx hoeft toch alleen maar read access op files en folder te hebben?

Welke Linux distro gebruik je?
Toevallig eentje die standaard SELinux aan heeft staan, zoals CentOS of RHEL?
Want dan ligt het aan de context van de files en directories, niet zozeer aan de filesystem permissions.

Even kort uitgelegd is SELinux een access control systeem.
Een daemonproces wat is getagged als webserver proces (zoals nginx en php) mag niet zomaar in elke directory wroeten. Alleen de directories die getagged zijn als httpd_content_t of httpd_content_rw mag het mee werken.
Als je 'ls -alhZ' doet, krijg je naast de standaard file listing met filesystem permissions ook de SELinux context van de dirs/files te zien. Die staan wss op iets anders.

De simpele optie is om SELinux uit te zetten, maar dat zou jammer zijn. Het zit er juist op voor een laagje extra security (b.v. als een website gehacked wordt, dan is de rest van je systeem niet de sjaak)

Voor wat info / kleine spoedcursus:

[wilmardo]

McKaamos schreef op zondag 9 juli 2017 @ 21:14:
[...]

Welke Linux distro gebruik je?
Toevallig eentje die standaard SELinux aan heeft staan, zoals CentOS of RHEL?
Want dan ligt het aan de context van de files en directories, niet zozeer aan de filesystem permissions.

CentOS inderdaad maar SELinux is op dit moment uitgeschakeld, dat gaf al eerder problemen met Nginx. Ik ga het filmpje binnenkort eens kijken, ben benieuwd! SELinux staat op de planning om weer ingeschakeld te worden met oog op de redenen die je inderdaad noemt. Het was ook een van de redenen om voor CentOS te kiezen, alleen is het niet heel eenvoudig in te stellen (vond ik in ieder geval).

Maar helaas dus niet het probleem nu

[ Voor 8% gewijzigd door wilmardo op 09-07-2017 21:27 ]

[McKaamos]

wilmardo schreef op zondag 9 juli 2017 @ 21:27:
[...]

CentOS inderdaad maar SELinux is op dit moment uitgeschakeld, dat gaf al eerder problemen met Nginx. Ik ga het filmpje binnenkort eens kijken, ben benieuwd! SELinux staat op de planning om weer ingeschakeld te worden met oog op de redenen die je inderdaad noemt. Het was ook een van de redenen om voor CentOS te kiezen, alleen is het niet heel eenvoudig in te stellen (vond ik in ieder geval).

Maar helaas dus niet het probleem nu

Zet 'm sowieso weer even aan, anders mist je labeling omdat het proces niet loopt.
Zet 'm van Enforcing naar Permissive ipv Disabled.
Dan houd hij wel alles bij, maar laat ook alles toe zoals bij Disabled.
Anders moet je straks het hele filesystem weer opnieuw labelen, en dat is een kutklus

[Hero of Time]

wilmardo schreef op zondag 9 juli 2017 @ 21:03:
[...]

Bedankt voor de reactie! Er kwam inderdaad niks in de access log, geen idee waarom Nginx niks registreert terwijl de request er wel aankomt maar borkt.

Er komt niets aan op de backend. Dat borkt niet, want als er ook maar een request door zou komen, zie je dat in je log. Niets in log = geen request. Je 'frontend' deed gewoon geen biet.

Op dit moment is het inderdaad geen loadbalancer dat is een eventuele volgende stap

Nginx is niet bedoelt als loadbalander. Heb je de documentatie al gelezen hoe je dat zou moeten doen? HAproxy lijkt mij een veel betere optie. Die kan ook gewoon http2 aan.

Maar toch nog een vervolg vraag, ik zit nu met een permissie probleem omdat Nginx de files niet kan lezen die production:production als eigenaar hebben. Dit terwijl de permissies op 775 voor de folders en 664 vo?or de files. Hoe kan dit? Nginx hoeft toch alleen maar read access op files en folder te hebben?

Tja, als je webserver onder www-data draait, dan mag die niets meer dan lezen. Gezien je OP draai je blijkbaar Wordpress. Lees je even goed in hoe je dat veilig kan gebruiken. Het is leuk dat het zichzelf kan updaten, maar let op de eventuele security implicaties die ermee gepaard gaan.

McKaamos schreef op zondag 9 juli 2017 @ 21:29:
Anders moet je straks het hele filesystem weer opnieuw labelen, en dat is een kutklus

Hoezo is dat een kutklus? Je hoeft dat allemaal niet zelf te doen hoor. Als je van Disabled naar Permissive of Enforcing gaat, wordt er automatisch een relabel uitgevoerd. Je kan deze ook zelf triggeren door een leeg bestand genaamd ".autorelabel" te maken in /.

[McKaamos]

Hero of Time schreef op zondag 9 juli 2017 @ 22:10:
[...]

[snip]


[...]

Hoezo is dat een kutklus? Je hoeft dat allemaal niet zelf te doen hoor. Als je van Disabled naar Permissive of Enforcing gaat, wordt er automatisch een relabel uitgevoerd. Je kan deze ook zelf triggeren door een leeg bestand genaamd ".autorelabel" te maken in /.

True, maar alles wat je niet permanent gemaakt hebt in eerdere pogingen ben je dan wel kwijt en mag je overnieuw gaan doen.

[Hero of Time]

McKaamos schreef op zondag 9 juli 2017 @ 23:07:
[...]

True, maar alles wat je niet permanent gemaakt hebt in eerdere pogingen ben je dan wel kwijt en mag je overnieuw gaan doen.

Klopt, maar elke beheerder die eerst alles netjes gelabeld heeft en daarna SELinux uitschakelt, om 't later weer in te schakelen is een prutser eerste klas en verdient het extra werk. TS heeft niets met SELinux context gedaan, dus alles is dan nog standaard. Geen probleem dus.

[McKaamos]

Hero of Time schreef op zondag 9 juli 2017 @ 23:17:
[...]

Klopt, maar elke beheerder die eerst alles netjes gelabeld heeft en daarna SELinux uitschakelt, om 't later weer in te schakelen is een prutser eerste klas en verdient het extra werk. TS heeft niets met SELinux context gedaan, dus alles is dan nog standaard. Geen probleem dus.

Naja, dat weten we niet Het zou kunnen dattie t wel heeft gedaan, al was t maar onder t mom van een gaar stukje advies ergens op internet.

Maargoed, als t goed is, is het inderdaar nog standaard.
Dan even filmpje kijken en je bent direct een SELinux guru (naja je weet dan genoeg om alles up and running te krijgen.)

[Wouda]

Wat heb je aan troubleshooting op de webserver zelf gedaan? Stappen die je kunt testen zijn:

• Draait nginx überhaupt?
• Heb je de nginx config getest?
• Zie je dat nginx op poort 80 luistert?
• Kun je op de webserver een curl doen? (wel even "192.168.1.106 wilmardenouden.nl" in je hosts file plaatsen)
• Zo ja, zie je dat wel terug in je logs? En,
• Kun je een curl vanaf je loadbalancer naar je webserver doen?

Wat kan helpen is om je logging verbose te zetten.

[ Voor 4% gewijzigd door Wouda op 09-07-2017 23:34 ]

[Hero of Time]

@Wouda, het probleem is al opgelost van de TS. Hij had http2 aan staan op z'n proxy en dat werkte niet goed.

[wilmardo]

Hero of Time schreef op zondag 9 juli 2017 @ 22:10:
Er komt niets aan op de backend. Dat borkt niet, want als er ook maar een request door zou komen, zie je dat in je log. Niets in log = geen request. Je 'frontend' deed gewoon geen biet.

De listen directive van de webserver klopte niet, niet bij de reverse proxy daar kan prima http2 staan. Alleen doordat de webserver met http2 door de reverse proxy probeerde te gaan ging het niet goed. Ik heb niets aangepast aan de proxy configuratie.

Hero of Time schreef op zondag 9 juli 2017 @ 22:10:
Nginx is niet bedoelt als loadbalander. Heb je de documentatie al gelezen hoe je dat zou moeten doen? HAproxy lijkt mij een veel betere optie. Die kan ook gewoon http2 aan.

Nginx heeft aardig wat loadbalancing opties (docs) maar ik heb onderzoek gedaan naar Nginx en HAproxy maar uiteindelijk toch voor Nginx gegaan. Qua performance scheen het niet veel uit te maken en wat mij over de streep trok is dat Nginx ook een webserver is. Hierdoor kan ik eenvoudig mijn Letsencrypt certificaten vernieuwen en regelen op de loadbalancer/reverse proxy.
Wat zou volgens jou het voordeel zijn van HAproxy boven Nginx?

Hero of Time schreef op zondag 9 juli 2017 @ 22:10:
Tja, als je webserver onder www-data draait, dan mag die niets meer dan lezen. Gezien je OP draai je blijkbaar Wordpress. Lees je even goed in hoe je dat veilig kan gebruiken. Het is leuk dat het zichzelf kan updaten, maar let op de eventuele security implicaties die ermee gepaard gaan.

Uiteindelijk werd het permission denied probleem veroorzaakt door de missende x (execute) permissie op de /home. De userhomes staan bij CentOS standaard op 700, dus de permissies stonden wel goed voor de webroot maar niet voor het hele pad (linkje naar het SO antwoord). PHP-FPM mocht dus niks in de webroot uitvoeren omdat hoger in het pad de execute miste.

Ik ben weer een hoop kennis wijzer!

[Hero of Time]

wilmardo schreef op maandag 10 juli 2017 @ 12:38:
[...]

De listen directive van de webserver klopte niet, niet bij de reverse proxy daar kan prima http2 staan. Alleen doordat de webserver met http2 door de reverse proxy probeerde te gaan ging het niet goed. Ik heb niets aangepast aan de proxy configuratie.

Ah, verkeerd begrepen.

[...]

Nginx heeft aardig wat loadbalancing opties (docs) maar ik heb onderzoek gedaan naar Nginx en HAproxy maar uiteindelijk toch voor Nginx gegaan. Qua performance scheen het niet veel uit te maken en wat mij over de streep trok is dat Nginx ook een webserver is. Hierdoor kan ik eenvoudig mijn Letsencrypt certificaten vernieuwen en regelen op de loadbalancer/reverse proxy.
Wat zou volgens jou het voordeel zijn van HAproxy boven Nginx?

Beide ken ik niet door en door, maar met HAproxy was het iig wat eenvoudiger om een server tijdelijk uit te sluiten van verkeer zonder de config te hoeven aanpassen. Daarnaast blijft HAproxy gewoon draaien als de backend er niet is. Op m'n werk hebben we dat als de 'upstream' server niet bereikbaar is, nginx gewoon stopt. Heel fijn als je de backend een herstart geeft, moeten we de proxy (wij gebruiken 't dus als reverse proxy) ook herstarten. Dat heb ik bij HAproxy niet zien gebeuren.

[...]

Uiteindelijk werd het permission denied probleem veroorzaakt door de missende x (execute) permissie op de /home. De userhomes staan bij CentOS standaard op 700, dus de permissies stonden wel goed voor de webroot maar niet voor het hele pad (linkje naar het SO antwoord). PHP-FPM mocht dus niks in de webroot uitvoeren omdat hoger in het pad de execute miste.

Ik ben weer een hoop kennis wijzer!

Handig dat je 't in /home hebt gezet. Als je SELinux gaat toepassen, wordt dat nog een leuk ding. Normaal gesproken worden websites in /var/www gezet. Dan heb je dat probleem niet.