[Gelöst]Pihole

[Sebastian84]

Seid Heute kann ich Pihol über web nicht mehr erreichen.
Er Funktioniert aber und blockt alles.
Habe wenn ich jetzt 192.168.0.115 eingebe
Die Phoscon Oberfläche drann.
192.168.0.115/admin geht auch nicht.
Oder 192.168.0.115/24
Woran kann das liegen

[Borkk]

Schau mal in

Code Auswählen Erweitern

sudo nano /lib/systemd/system/deconz.service

Ob Phoscon auf Port 80 läuft

Code Auswählen Erweitern

ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80

falls ja, solltest du das ändern z.B. auf 8090

Code Auswählen Erweitern

ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8090

dann

Code Auswählen Erweitern

sudo systemctl daemon-reload
sudo systemctl restart deconz


danach erreichst du Phoscon unter 192.168.0.115:8090

[Knallkopp_02]

Das Problem habe ich momentan auch, aktueller "Workarround" versuch mal den Raspberry neu zu starten, danach ging es bei mir wieder:

Problem ist bei mir seit dem Update auf Version 5 und immer nachdem Pihole die die Listen aktuallisiert hat. Bin grade am testen, was das genau auslöst, ein alleiniger Neustart von Pihole selbst hat bei mir keinen Erfolg gebracht, dabei ist mir auch aufgefallen, dass die History mit den Daten anscheinen nicht gespeichert wird, oder ist das normal?

Phoscon habe ich nicht

Gruß Knallkopp_02

[MadMax-FHEM]

Wenn wirklich beides (und das ist Standard!) auf Port 80 läuft, dann hilft ein Reboot genau GAR NICHTS!

Bzw. ist es halt zufall "wer" gerade den Port 80 noch frei findet, der "schnappt" ihn sich ihn und ist erreichbar...
...der andere Dienst mit sicherheit NICHT!

Lösung wie von Borkk angesprochen: einen der Dienste auf einen anderen Port...

Evtl. aber überlegen piHole umzubiegen, weil da schaut man ja nur ab und an drauf (oder!?)...
...bei deCONZ hängt ja evtl. ein HUEBridge-Modul "dahinter": nicht vergessen da den neuen Port ebenfalls anzugeben!

EDIT: Oder 192.168.0.115/24 geht nicht... Klar! Das ist ja KEINE IP-Adresse sondern ein IP-Bereich!

EDIT: @Knallkopp_02: hast du weitere Dienste laufen!? Wie beispielsweise deCONZ!? Also Dienste die auch (standardmässig) Port 80 nutzen!? Wenn nicht, dann ist dein Problem mit Sicherheit was anderes! Und verm. sogar unabhängig von fhem. Daher evtl. sogar eher mal in einem piHole-Forum suchen/fragen...

Gruß, Joachim

[Knallkopp_02]

@MadMax-Fhem,

Eigentlich hast du Recht, es hat nichts mit FHEM zu tun, außer einem Ubiquity-Controller und PiHole läuft nichts weiter auf dem Raspberry. Ich dachte nur, da mir der Fehler bekannt vorkam, poste ich es mal. Wie gesagt, Verstehen tu ich das Problem auch nicht, weil es reproduzierbar mit einem Neustart beseitigt ist. Ich kann nur sagen, das es seit Version 5 passiert, und wenn die Updates für die Listen gemacht worden sind ist pünktlich die History leer und es ist kein Internet mehr für alle Geräte im Netzwerk vorhanden.

Gruss Knallkopp

[Borkk]

Wartet mal bis sich Sebastian meldet. Ich hatte einen ähnlichen Effekt. Ich hatte Phoscon auf 8090 laufen und auf einmal war die Seite nicht mehr erreichbar, auch nach einem Reboot nicht. Nach etwas Suchen habe ich festgestellt, das in der Datei deconz.service der Eintrag wieder auf Default Port 80 vorhanden war. Ich vermute das über ein Update die Date überschrieben wurde. Evtl. ist das schon das Problem von Sebastian.

[MadMax-FHEM]

@MadMax-Fhem,

Eigentlich hast du Recht, es hat nichts mit FHEM zu tun, außer einem Ubiquity-Controller und PiHole läuft nichts weiter auf dem Raspberry. Ich dachte nur, da mir der Fehler bekannt vorkam, poste ich es mal. Wie gesagt, Verstehen tu ich das Problem auch nicht, weil es reproduzierbar mit einem Neustart beseitigt ist. Ich kann nur sagen, das es seit Version 5 passiert, und wenn die Updates für die Listen gemacht worden sind ist pünktlich die History leer und es ist kein Internet mehr für alle Geräte im Netzwerk vorhanden.

Gruss Knallkopp

Also ich habe auch einen PI (vorher PI3 jetzt PI4) auf dem läuft piHole 5 (vorher 4) und UnifiController und Samba und piVPN und: es läuft.

Was ich immer mache: pi-Start -> warten auf Netzwerk (raspi-config)

und er hängt per LAN am Netz...

Und bei (genauerem) Lesen klingt es eben nicht (mal annähernd) ähnlich
Weil der TE eben von 2 Diensten berichtet, die standardmässig auf DEMSELBEN Port (80) laufen.
Da ist klar, dass das nicht geht/gehen kann und wo (verm.) das Problem iiegt und damit auch die Lösung...

@Borkk/Sebastian84: klar, warten was da kommt... Aber verm. muss einer der Dienste dauerhaft auf einen anderen Port (oder Rechner   )...

Gruß, Joachim

[Sebastian84]

Super genau das wahrs. Der Port hat sich nach den Update wieder auf 80 gestellt. Jetzt ist er auf 8090.
Kann mann den auch festsetzen das das beim nächsten
Update nicht mehr passiert?

[schwatter]

Ja das geht. Ich hatte auch das Problem mit debmatic und deconz.
@volschin gab mir dann den Tip, das ich systemd besser verstehen soll.
Ende vom Lied, die angepasste deconz.service kommt nach /etc/systemd/system.
Danach überlebt sie das Update von deconz.

[Sebastian84]

Und dann muss ich nach den update nix mehr machen und er bezieht die Datei aus den Ordner,
Oder muss ich die Datei dann wieder kopieren?
Muss die Datei dann aus den vorhandenen Ordner gelöscht werden?

[schwatter]

Ja genau. /lib/systemd/system wird ignoriert, wenn das servicefile in /etc/systemd/system liegt.

Siehe hier:
https://wiki.debian.org/systemd
Absatz: Creating or altering services

[Sebastian84]

Ich wollte die datei dahin kopieren aber ich hab keine Berechtigung.
Die datei wollte ich dann noch im lib.. Unterordner löschen.
Es geht aber beides nicht

[MadMax-FHEM]

Ich wollte die datei dahin kopieren aber ich hab keine Berechtigung.
Die datei wollte ich dann noch im lib.. Unterordner löschen.
Es geht aber beides nicht

sudo cp AlterPfadName NeuerPfadName

oder wenn sie an der Originalposition nicht mehr benötigt wird:

sudo mv AlterPfadName NeuerPfadName

Gruß, Joachim

[Sebastian84]

Danke hat geklappt