Kein Zugriff auf Pihole Panel mit nginx

tim11 · January 4, 2022, 1:52pm

Hallo,

ich habe einen Server mit Debian11 und php8, alles tagesaktuell. Drauf wollte ich auch Pihole installieren. Laut diversen Seiten wird nginx zwar nicht offiziell unterstützt, aber läuft trotzdem. Unter /etc/nginx/conf.d/ liegt jetzt eine pihole.conf, aber der Zugriff aufs Webpanel will nicht klappen. Port habe ich auf 8080 gelegt, kein Zugriff, weder über die interne IP (Server steht bei mir und hängt damit im LAN) noch über http://pi.hole. Natürlich habe den Port in der IP mit :8080 angegeben. Habe auch testtechnisch den Port von pihole auf die 80 gelegt, dann erhalte dann eine Umleitung auf ssl und lange auf meiner Indexseite. An fail2ban und ufw liegt es nicht, alles entsprechend konfiguriert, aber auch hier testweise beides deaktiviert, keine Veränderung. Auch habe ich alles mögliche mit der pihole.conf versucht, die eigentlich eine kopierte default mit geänderten Port und root + index ist, sollte eigentlich reichen.

Das beste was ich mal hinbekommen habe ist die Möglichkeit, einen application/octet-stream (9,4 KB) zu speichern. Dazu gibt es im Netz auch ein paar Threads, aber die Lösung, dass man dann eben über http://pi.hole/ gehen soll, geht bei mir nicht. Aktuell erhalte ich nur eine leere weiße Seite, der Quelltext der Seite zeigt nur eine 1 an. Das Log zu nginx spuckt dazu nichts aus. Die anderen Dienste auf 443 laufen jedoch ohne Probleme, die sind jedoch in einer anderen conf gespeichert, die jedoch die gleiche default.conf als Basis haben. Rufe ich die interne IP des Servers auf dem Port 80 auf, erhalte ich wie gewünscht eine Umweitung auf die 443 und komme auf meine Index. Auf Port 8080 geht jedoch nix.

pihole -d ergab keine Auffälligkeiten, Netz ist da, Schnittstelle wird erkannt, und das übliche halt.
Status sagt

[✓] DNS service is listening
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)

[✓] Pi-hole blocking is enabled

Laufen muss er also, nur das Interface fehlt jetzt noch.

Danke im voraus für die Hilfe

yubiuser · January 4, 2022, 7:33pm

Konkret kann ich dir mangels eigener Erfahrung mit nginx leider nicht weiterhelfen, dich nur auf unsere Community Anleitung verweisen (kennst du vielleicht schon)
https://docs.pi-hole.net/guides/webserver/nginx/

tim11 · January 5, 2022, 2:09pm

Bin ich natürlich schon komplett durchgegangen, habe die conf auch mal getestet, aber bringt alles nicht, ich komme nicht auf das Interface. php Pakete bin ich nochmals durchgegangen, sind alle drauf. pihole läuft laut Status, aber ich komme halt nicht drauf. Habe nochmals die Ports durchgetauscht, gleiches Problem, 8080 geht nicht, bei 80 lande ich per ssl wieder auf meiner index.

yubiuser · January 5, 2022, 7:08pm

Sorry, dann muss jemand mit nginx Erfahrung jetzt einspringen. Viel Erfolg.

tim11 · January 6, 2022, 3:03pm

Danke, aber da mir scheinbar keiner helfen kann und ich durch testen viel Zeit verloren habe, gebe ich nun auf. Manchmal soll es einfach nicht sein.

Danke für Deine Hilfe

MichaIng · January 7, 2022, 1:57am

Kannst du mal die relevanten Teile deiner Nginx config posten?

Und ist denn eine Test HTML und PHP Datei über Nginx erreichbar? E.g.:

<?php phpinfo(); ?>

Du nutzt PHP-FPM?

Logs welche Aufschluss geben könnten:

journalctl -u nginx -u php8.0-fpm
tail -20 /var/log/nginx/error.log
tail -20 /var/log/php8.0-fpm.log

tim11 · January 7, 2022, 9:26am

die conf:

server {
listen 80;
listen [::]:80;
server_name 192.168.178.111;

root /var/www/html;
autoindex off;

index pihole/index.php index.php index.html index.htm;

access_log /var/log/nginx/pihole-nginx.access.log;
error_log /var/log/nginx/pihole-nginx.error.log;

location / {
expires max;
try_files $uri $uri/ =404;
}

location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.0-fpm.sock;
fastcgi_param FQDN true;
}
location /*.js {
index pihole/index.js;
}

location /admin {
root /var/www/html;
index index.php index.html index.htm;
}

location ~ /.ht {
deny all;
}
}

Normale Vorlage aus einem Tutorial. Aktuell habe ich es auf 80 laufen, vorher wie schon erwähnt auf 8080. Hatte auch schon ssl über einen anderen Port als 443 getestet, auch keinen Erfolg

php geht, weil ich auch Nextcloud auf dem Server laufen habe, der lässt sich über die interne IP über 443 problemlos erreichen.

fmp:

php8.0-fpm ist schon die neueste Version (8.0.14-1+0~20211220.28+debian11~1.gbpad68c7).

journalctl -u nginx -u php8.0-fpm gibt nur allgemeine Infos zu restart, ein paar Fehlereinträge als ich versucht habe auf ssl umzustellen

Jan 07 08:28:51 *** systemd[1]: Started nginx - high performance web server.
Jan 07 08:28:52 *** systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
Jan 07 08:36:00 *** systemd[1]: Stopping nginx - high performance web server...
Jan 07 08:36:00 *** systemd[1]: nginx.service: Succeeded.
Jan 07 08:36:00 *** systemd[1]: Stopped nginx - high performance web server.
Jan 07 08:36:00 *** systemd[1]: nginx.service: Consumed 3.487s CPU time.
Jan 07 08:36:00 *** systemd[1]: Starting nginx - high performance web server...

beim Versuch den Servername auf die Domain laufen zu lassen erhalte ich

Jan 07 08:36:50 *** nginx[2062]: nginx: [warn] conflicting server name "XXX.de" on 0.0.0.0:80, ignored
Jan 07 08:36:50 *** nginx[2062]: nginx: [warn] conflicting server name "XXX.de" on [::]:80, ignored
Jan 07 08:36:50 *** systemd[1]: nginx.service: Can't open PID file /run/nginx.pid (yet?) after start: Operation not permitted

und werde auf meine index auf ssl umgeleitet

Portfreigabe für 80 existiert aber

[ 1] 80/tcp ALLOW IN Anywhere

Errorlog meckert auch wegen dem conflicting server name rum, php log sagt

06-Jan-2022 17:18:51] NOTICE: Terminating ...
[06-Jan-2022 17:18:51] NOTICE: exiting, bye-bye!
[06-Jan-2022 17:19:26] NOTICE: fpm is running, pid 452
[06-Jan-2022 17:19:27] NOTICE: ready to handle connections
[06-Jan-2022 17:19:27] NOTICE: systemd monitor interval set to 10000ms
[06-Jan-2022 18:37:27] NOTICE: Terminating ...
[06-Jan-2022 18:37:28] NOTICE: exiting, bye-bye!
[06-Jan-2022 18:38:03] NOTICE: fpm is running, pid 524
[06-Jan-2022 18:38:03] NOTICE: ready to handle connections
[06-Jan-2022 18:38:03] NOTICE: systemd monitor interval set to 10000ms
[06-Jan-2022 19:02:51] NOTICE: Terminating ...
[06-Jan-2022 19:02:51] NOTICE: exiting, bye-bye!
[06-Jan-2022 19:03:27] NOTICE: fpm is running, pid 516
[06-Jan-2022 19:03:27] NOTICE: ready to handle connections
[06-Jan-2022 19:03:27] NOTICE: systemd monitor interval set to 10000ms
[06-Jan-2022 23:59:01] NOTICE: Terminating ...
[06-Jan-2022 23:59:02] NOTICE: exiting, bye-bye!
[07-Jan-2022 08:28:52] NOTICE: fpm is running, pid 542
[07-Jan-2022 08:28:52] NOTICE: ready to handle connections
[07-Jan-2022 08:28:52] NOTICE: systemd monitor interval set to 10000ms

Auch an dieser Stelle an Dich vielen Dank für die Hilfe

MichaIng · January 7, 2022, 11:11am

PHP-FPM scheint ja schonmal zu laufen, ich nehme an die Terminating ... logs sind wegen absichtlicher Server/Service Neustarts.

Wegen Nginx: Der server name conflict ist merkwürdig, da diese Direktive ja explizit dafür gedacht ist, verschiedene vhosts auf demselben port zu unterscheiden. Schau mal ob du das an irgendeiner weiteren Stelle definiert hast welche irgendwie included ist:

grep -r 'server_name' /etc/nginx

Ist ja aber nicht die lokale IP welche du für Pi-hole nutzt, sollte insofern nicht verantwortlich sein.

Du greifst auch über diese IP 192.168.178.111 auf Pi-hole zu, richtig? Wie hast du HTTPS für Nextcloud eingerichtet? Greifst du auf Nextcloud lokal über dieselbe IP zu (nur halt über port 443/HTTPS)? Gibt es da einen automatischen redirect auf port 443/HTTPS, möglicherweise HSTS, sodass der Browser selbstständig auf port 443 wechselt?

ls /run/nginx.pid existiert letztlich, oder?

root /var/www/html; im location /admin block dürfte nicht nötig sein, da es für den gesamten vhost ja bereits (und korrekt wie es sein soll) definiert ist.

Da fehlen außerdem einige Pi-hole spezifische Direktiven. Schau mal unsere Config: DietPi/.conf/dps_93/nginx.pihole.conf at 6a6e683924cb03e5bf6a0686dda7810f07474ecf · MichaIng/DietPi · GitHub
Das ist bei uns nicht über einen eigenen vhost, sondern über den Pfad geregelt, deshalb die bei Nginx leider nötigen wiederholten PHP Blöcke. Außerdem mit root /var/www und den Pi-hole Ordnern auf den übergeordneten Pfad verlinkt, wodurch dieser ^(?:/html|) Prefix zustande kommt. Aber das folgende solltest du übernehmen können:

# Block . files from being served, such as .git, .github, .gitignore
location ~ ^/admin/\. {
	deny all;
}

# Create response header for Pi-hole debugger
add_header X-Pi-hole "The Pi-hole Web interface is working!";
add_header X-Frame-Options "DENY";

# Allow teleporter and API QR code iframes on settings page
location ~ ^/admin/scripts/pi-hole/php/(?:teleporter|api_token)\.php$ {
	# PHP handler block
	include snippets/fastcgi-php.conf;
	fastcgi_pass unix:/run/php/php8.0-fpm.sock;;
	fastcgi_param FQDN true;

	if ($http_referer !~ /admin/settings\.php) {
		add_header X-Frame-Options "DENY";
	}
	if ($http_referer ~ /admin/settings\.php) {
		add_header X-Frame-Options "SAMEORIGIN";
	}
}

Der generelle Zugriff auf die Pi-hole Webseite sollte ohne diese jedoch nicht verhindert werden. In Kombination sind das ja nur Direktiven welche die Sicherheit/Privatsphäre erhöhen und der Header welche im Pi-hole debugger geprüft wird.

Da du explizit einen log Dateipfad für den vhost angegeben hast, schau dort mal rein:

tail -20 /var/log/nginx/pihole-nginx.error.log
tail -20 /var/log/nginx/pihole-nginx.access.log

tim11 · January 7, 2022, 12:56pm

Jetzt kommt aber Bewegung in die Sache

Ich mach das mal blockweise.

PHP-FPM scheint ja schonmal zu laufen, ich nehme an die Terminating ... logs sind wegen absichtlicher Server/Service Neustarts.

Korrekt

grep -r 'server_name' /etc/nginx

Es gibt insgesamt 3 conf im conf.d Verzeichnis. Ein Nextcloud auf 443, der problemlos läuft. Ein http auf 80, der einen redirect auf 443 macht. Und die Pihole auf eigentlich 8080, die nicht funktioniert. Die ersten beiden hatten als server_name meine Domain, die Pihole zeitweise auch, weil ich sehen wollte ob ich ihn über einen zweiten ssl Port (über 10000) mit bereits existierenden Zertifikaten von draußen erreichen kann, habe den Namen allerdings dann auf die interne IP gelegt. Für den Zeitraum, wo ich die Pi.conf auf 80 gelegt habe, habe ich natürlich die http.conf deaktiviert, nicht dass es sich beisst, hat aber nichts gebracht. Aktuell ist die pi wieder auf 8080 und der http wieder normal auf 80

Du greifst auch über diese IP 192.168.178.111 auf Pi-hole zu, richtig?

Entweder das oder über http://pi.hole/admin, beides geht nicht.

Wie hast du HTTPS für Nextcloud eingerichtet?

Letsencrypt, funktioniert ohne Probleme. Die nextcloud.conf hat die Zertifikate hinterlegt, klappt wunderbar.

Greifst du auf Nextcloud lokal über dieselbe IP zu (nur halt über port 443/HTTPS)?

Nein, über meine Domain, denn der Zugriff muss auch von Außen vorhanden sein.

Gibt es da einen automatischen redirect auf port 443/HTTPS, möglicherweise HSTS, sodass der Browser selbstständig auf port 443 wechselt?

Ja, der funktioniert auch wunderbar

Da fehlen außerdem einige Pi-hole spezifische Direktiven.

Danke, teste ich nachher gleich mal aus.

Da du explizit einen log Dateipfad für den vhost angegeben hast, schau dort mal rein:

error existiert noch nicht, somit noch keiner vorhanden, und die normale access:

192.168.178.212 - - [07/Jan/2022:13:32:56 +0100] "GET / HTTP/1.1" 502 150 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
192.168.178.212 - - [07/Jan/2022:13:32:56 +0100] "GET /favicon.ico HTTP/1.1" 404 146 "http://192.168.178.111/" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
192.168.178.212 - - [07/Jan/2022:13:33:05 +0100] "GET /admin HTTP/1.1" 301 162 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"
192.168.178.212 - - [07/Jan/2022:13:33:05 +0100] "GET /admin/ HTTP/1.1" 502 150 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0"

Noch als Update: wenn ich über die IP und den vergebenen Port das Interface aufrufen will, bekomme ich nur die Meldung "File not found."

Das root Verzeichnis sollte aber passen. Die Meldung habe ich aber auch bekommen als ich den Port auf 80 gelegt habe. Benutzerrechte sind entsprechend auf www-data vergeben, www-data ist auch in der pihole Gruppe.

tim11 · January 7, 2022, 1:16pm

Ich mach das mal in einem eigenen Post, nicht dass es überlesen wird, falls Du im anderen Post schon angefangen hast

Habe schon festgestellt dass bei nginx ein manuelles stop und start sinnvoller ist als ein restart. Jedenfalls hat es mir jetzt nach einem manuellen Start einen Eintrag in der error gegeben:

2022/01/07 14:08:31 [error] 9144#9144: 1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.178.212, server: 192.168.178.111, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.0-fpm.sock:", host: "192.168.178.111:"
2022/01/07 14:08:37 [error] 9144#9144: 1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.178.212, server: 192.168.178.111, request: "GET /admin/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.0-fpm.sock:", host: "192.168.178.111:"

tim11 · January 7, 2022, 1:28pm

Die Direktiven habe ich eingefügt. nginx hat kurz über das zweite Semikolon gemeckert in

fastcgi_pass unix:/run/php/php8.0-fpm.sock;;

nachdem ich das entfernt habe ging es, allerdings ändert es nichts am aktuellen Zustand, immer noch "File not found. "

MichaIng · January 7, 2022, 2:54pm

Unterschiedliche vhosts (also configs mit server { block) werden üblicherweise über /etc/nginx/sites-available => /etc/nginx/sites-enabled eingebunden, während conf.d für Nginx-weite snippets gedacht ist, aber in der Praxis spielt es meist keine Rolle da beide Verzeichnisse direkt nacheinander auf dieselbe Weise eingebunden werden.

Wenn du wirklich HSTS aktiviert hast (grep -r 'Strict-Transport-Security' /etc/nginx), dann wechselt der Browser möglicherweise selbstständig auf HTTPS/443, sodass mit Nextcloud webroot dann das Pi-hole admin panel nicht existiert. Was wird denn im Browser angezeigt, also Inhalt, Addressleiste und Browserkonsole?

Die Vermutung mit HSTS passt allerdings nicht so ganze zu dem vhost log, wo es ja offensichtlich einen Zugriff gab, mit Favicon, /admin => /admin/ Weiterleitung, wie es sein soll, am Ende halt 502 .

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

Ich bin gerade nicht sicher ob das quasi die Nginx Ausgabe für eine "file not found" Antwort von PHP ist. Um es ganz auszuschließen: Wir definieren in der nginx.conf den upstream mit:

upstream php {
	server unix:/run/php/php8.0-fpm.sock;
}

Dann im vhost die etwas verkürzte PHP Weiterleitung:

location ~ \.php(?:$|/) {
	include snippets/fastcgi-php.conf;
	fastcgi_pass php;
}

Sollte eigentlich keinen Unterschied machen, außer dass man bei einem PHP upgrade nur eine Config ändern muss, aber um es auszuschließen kannst du es ja mal damit versuchen. Oder hat sich die obige Fehlermeldung durch entfernen es Semikolons behoben? "File not found." sieht für mich tatsächlich danach aus, dass ein falscher vhost ausgewählt wird, z.B. durch einen Redirect, aber das müsste man im Browser sehen können.

tim11 · January 7, 2022, 3:21pm

Im Browser wird nichts umgeleitet, gebe ich so ein, bleibt auch so bestehen.

http://192.168.178.111:8080/admin/

GEThttp://192.168.178.111:8080/admin/
[HTTP/1.1 404 Not Found 7ms]

GEThttp://192.168.178.111:8080/favicon.ico

 <html><head></head><body>File not found.
 </body></html>

https:

/etc/nginx/conf.d/nextcloud.conf:add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;

Deine Anleitung habe ich befolgt, conf geändert, keine Veränderung.

Wird wohl eine ähnlich schwere Geburt wie bei meinem Kleinsten, der wollte auch nicht raus

tim11 · January 7, 2022, 3:53pm

Google spuckt jede Menge Treffer zu dem script aus, habe mal die eine oder andere Lösung versucht, aber außer einem bad gateway hat sich nichts geändert. Das Ganze übersteigt mein rudimentäres IT Wissen

und viele mehr.

tim11 · January 7, 2022, 4:48pm

Und das nächste Update. Die Fehlermeldung scheint weg zu sein, habe dieses Post im Netz gefunden und getestet, kein neuer Eintrag in der error:

nginx configuration file config in
fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
To replace it
fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
Otherwise php fastcgi Unable to resolve directories

Jetzt allerdings bekomme ich wieder die Möglichkeit, application/octet-stream (9,4 KB) zu speichern.
http://pi.hole:8080/admin geht immer noch nicht.

Testweise den Port der conf auf einen zweiten ssl Port gelegt, als Servername meine Domain eingetragen und auf mein Letsencrypt Zertifikat verwiesen, ich komme dann mit

https://********.de:3****:/admin

wieder den octet-stream zum Download angeboten.

tim11 · January 7, 2022, 8:49pm

Zuerst die Gute, ich habe die Seite am Laufen. Ich kann gar nicht mehr sagen wie, habe in der Zwischenzeit so viel hin und her probiert, und auf ein Mal ging es. Zwischenzeitlich hat es die Seite als Art Quelltext angezeigt mit

<?php /* * Pi-hole: A black hole for Internet advertisements * (c) 2017 Pi-hole, LLC (https://pi-hole.net) * Network-wide ad blocking via your own hardware.

usw, irgendwann hat es aber dann doch geklappt. Daher erst mal 1000 Mal danke an MichaIng für Deine Hilfe.

Nun das Schlechte. Ich komme zwar auf das Interface, kann mich aber nicht einloggen. Hatte auf meinem alten Server auch Pihole aufgesetzt, daher weiß ich dass nach Eingabe des PW mehr Menüpunkte links erscheinen. Dieses Mal nichts. Es kommt auch kein Hinweis, dass das PW falsch ist. Es passiert einfach nichts. Also per pihole -a -p ein neues PW vergeben, gleiches Spiel. Nochmal ein neues PW vergeben, dieses Mal ein Baustellenpasswort mit copy and paste, wieder nichts.

Kurz gegoogelt, Problem ist schon ein paar Mal aufgetaucht, habe aber keine Lösung gefunden. Also pihole -r laufen lassen, hat auch nichts gebracht.

system · January 28, 2022, 8:50pm

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.