Admin Webinterface nicht mehr erreichbar

[Sipple]

Hi

Auf meinem NUC (Debian Buster) mit SHNG 1.7.2 Master ist plötzlich das Admininterface nicht mehr erreichbar.
Alles andere scheint aber zu funktionieren. Also knxd läuft, SHNG läuft, die smartVISU läuft. Drum kann ich auch nicht sagen seit wann das nun so ist. Habe schon einige Tage oder Wochen nicht mehr rein geschaut. Ich habe noch zwei weiter SHNG Installationen, da habe ich einwandfrei Zugriff auf die Admin Seite.
Ins log habe ich schon reingeschaut. Nichts verdächtiges zu sehen. Neustart hat auch nichts geholfen.
Was kann ich tun um den Fehler weiter einzugrenzen?

Ergänzung:

Auf den beiden Raspis, auf denen das Admin Interface funktioniert, liefert netstat das:

tcp        0      0 192.168.x.x:8383     0.0.0.0:*               LISTEN

Auf dem NUC, wo es nicht klappt:

tcp        0      0 127.0.0.1:8383          0.0.0.0:*               LISTEN

Das kommt mir schon seltsam vor, aber wenn das das Problem ist, wer oder was hat das verstellt??? Ich nicht, zumindest nicht wissentlich.

Gruß, Martin

[Morg]

Was heißt denn "nicht mehr erreichbar"? Welche Fehlermeldung bekommst du?

Wirft shng beim Start ggf. eine Meldung mit 'cannot bind, port in use' oder so aus?

Wenn du die Konfiguration insb. der Module nicht verändert hast, wäre meine Vermutung, dass ein anderer Prozess (eine alte Instanz von shng?) noch den Port (8383) belegt hat... schau doch mal in der Prozessliste, ob da Instanzen von python bzw. shng laufen.

[Sipple]

Hab oben gerade eben noch was ergänzt (netstat Ausgabe).
Je nach Brower "Verbindung Fehlgeschlagen".
Es läuft nur eine smarthome NG Instanz.
Wie gesagt, vom LOG her keine Auffälligkeiten.

[Morg]

Das sieht so aus, als würde das http-Modul nur auf 127.0.0.1 lauschen, also auf localhost. Es wäre damit vom NUC aus erreichbar, aber nicht von anderen Rechnern.

Ich finde aber gerade nicht mal, ob man das überhaupt konfigurieren kann...

[Sipple]

Genauso geht es mir auch und ich wüsste eben beim besten Willen nicht durch was das passiert sein sollte. Das ging bisher einwandfrei und alles was ich gemacht habe war neulich mal ein apt update/upgrade.

[bmx]

Was liefern denn uname -a und wie schaut Deine etc/module.yaml aus?

[Sipple]

Linux newSERV 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux

28.11. deckt sich glaub ich in etwa mit dem letzten apt upgrade

%YAML 1.1
---
# etc/module.yaml
http:
    module_name: http
    starturl: admin
    user: smarthome
    hashed_password: xxx
    service_user: smarthome
    service_hashed_password: xxx
    showservicelist: true

admin:
    module_name: admin

mqtt:
    module_name: mqtt
    broker_monitoring: true

[bmx]

Und per ps ax | grep smarthome hast Du festgestellt, das nur eine Instanz läuft?

[Sipple]

Jepp

smarthome@newSERV:~ $ ps ax | grep smarthome
762 ? Sl 3:14 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py
1747 pts/1 S 0:00 su - smarthome
1760 pts/1 S+ 0:00 grep --color=auto smarthome

smarthome@newSERV:~ $ sudo systemctl status smarthome.service
[sudo] Passwort für smarthome:
● smarthome.service - SmartHomeNG daemon
Loaded: loaded (/lib/systemd/system/smarthome.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-12-27 16:03:22 CET; 1h 59min ago
Process: 428 ExecStart=/usr/bin/python3 /usr/local/smarthome/bin/smarthome.py (code=exited, status=0/SUCCESS)
Main PID: 762 (python3)
Tasks: 26 (limit: 4915)
Memory: 111.2M
CGroup: /system.slice/smarthome.service
└─762 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py

Dez 27 16:03:21 newSERV systemd[1]: Starting SmartHomeNG daemon...
Dez 27 16:03:22 newSERV python3[428]: Daemon PID 762
Dez 27 16:03:22 newSERV systemd[1]: Started SmartHomeNG daemon.

[Msinn]

Das sieht so aus, als hätte der Network Stack per dhcp keine IP Adresse bekommen. Über localhost (also 127.0.0.1] könnte das nur funktioeren wenn Du den Browser auf dem selben Rechner hast.

[bmx]

Dann schau doch mal, was ip addr ergibt

[Sipple]

Also sind wir uns einig, dass die 127.0.0.1:8383 falsch ist und da die normale IP stehen sollte.
ip addr liefert die ganz normale Adresse, so wie sie sein soll.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:ae:ed:72:6b:21 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.31/24 brd 192.168.178.255 scope global dynamic enp0s25
valid_lft 855544sec preferred_lft 855544sec
inet6 2003:d6:2f3a:c400:baae:edff:fe72:6b21/64 scope global dynamic mngtmpaddr
valid_lft 7157sec preferred_lft 1617sec
inet6 fe80::baae:edff:fe72:6b21/64 scope link
valid_lft forever preferred_lft forever

Bin ja auch über Putty auf diese IP auf dem CLI. Die smartVISU über die .31 läuft ja auch völlig normal.
Irgendwas hat ohne Not die IP für den Port 8383 auf die loopback Adresse gesetzt. Nur wer/was und warum?

[Msinn]

Und was passiert wenn Du <normale ip adresse>:8383 eingibst?

Es gab mal eine Change Anforderung, weil 127.0.0.1:8383 nicht ging und jemand das auf einem Standalone Rechner nutzen wollte (lokaler Browser). Evtl. Ist bei dem PR etwas schief gegangen... so dass es zu Problemen wie bei Dir führen kann.

[bmx]

Versuche doch mal testweise den Betrieb als Daemon auszuschalten und starte SHNG von der Kommandozeile aus:

sudo systemctl disable smarthome.service
sudo systemctl stop smarthome.service
sudo systemctl status smarthome.service

cd /usr/local/smarthome
python3 bin/smarthome.py

[Sipple]

And the winner is....

bmx

Das glaub ich jetzt nicht, daran liegt es. Starte ich SHNG manuell klappt alles wieder wie vorher. Starte ich über den systemd, geht es schief.
Auf den beiden Raspis klappt das mit dem systemd Service auch einwandfrei, auf dem NUC nicht. Die Installation und die Versionen sind so identisch wie es die unterschiedlichen Platformen zulassen.

Versteht das wer?

Und um die Zeit, als ich auf dem NUC zum ersten mal den Dienst für systemd eingerichtet habe, war auch mein letzter Login im Admin Interface. Da ging es noch. Danach gab es mal einen Reboot um den Autostart zu testen und ich schätze seitdem bestand das Problem, nur habe ich es erst jetzt bemerkt.