[Gelöst] FHEM wpad ausliefern lassen

Begonnen von Ralli, 11 Februar 2025, 07:23:04

Vorheriges Thema - Nächstes Thema

Ralli

Hallo Rudi,

ich würde gerne FHEM "missbrauchen", um über dessen Webserver, am liebsten über einen virtuellen Host auf Port 80, die wpad.dat ausliefern zu lassen. Damit eine solche Auslieferung überhaupt ordentlich funktionert, müssste dafür aber m.W. in den HttpUtils zumindest noch der MIME-Typ "application/x-ns-proxy-autoconfig" ergänzt werden.

Siehe https://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol .

Wäre es dir möglich, das einzubauen?

Was für einen Aufwand es bedeuten würde, virtuelle Hosts abzubilden, kann ich in keiner Weise überblicken.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

CoolTux

Ich bin absolute gegen solch einen Missbrauch. FHEM ist nicht dafür entwickelt worden. Es wäre etwas anderes wenn man keine Klimmzüge dafür machen müsste.

Was spricht denn dagegen einfach ein Apache oder ein NGINX zum ausliefern zu verwenden?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Zitat von: CoolTux am 11 Februar 2025, 08:17:40Ich bin absolute gegen solch einen Missbrauch. FHEM ist nicht dafür entwickelt worden.

*unterschreib*

Noch dazu, wo FHEM gar keinen eigenen "Webserver" hat. Das was FHEMWEB für eine Darstellung im Browser bereitstellt, ist von einem Webserver im eigentlichen Sinn weit entfernt und optional. Deshalb kann man FHEM ja auch völlig ohne FHEMWEB betreiben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Ralli

Zitat von: CoolTux am 11 Februar 2025, 08:17:40Ich bin absolute gegen solch einen Missbrauch. FHEM ist nicht dafür entwickelt worden. Es wäre etwas anderes wenn man keine Klimmzüge dafür machen müsste.

Das kann ich eben nicht einschätzen, ob wirklich "Klimmzüge" erforderlich sind.

ZitatWas spricht denn dagegen einfach ein Apache oder ein NGINX zum ausliefern zu verwenden?

Dass ich nirgends einen Webserver lokal laufen habe und auch grds. keinen benötige. Ich würde also lediglich für die Auslieferung dieser einen Datei einen Webserver aufsetzen müssen. Dabei ist mir bewusst, dass ich dies auch in einem lxc bzw. in einer VM machen kann, in der sowieso schon etwas anderes läuft, aber es ist halt ein zusätzlicher Dienst, der konfiguriert werden muss und gepflegt sein will.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

betateilchen

Zitat von: Ralli am 11 Februar 2025, 10:48:06Ich würde also lediglich für die Auslieferung dieser einen Datei einen Webserver aufsetzen müssen.

Hast Du eigentlich schon jemals einen Blick in die Dokumentation zu FHEM geworfen?

Wenn es nur darum geht, eine Datei auszuliefern, kannst Du das jetzt schon mit einem device vom Typ HTTPSRV umsetzen.
Das ist sogar mit Beispiel in der commandref beschrieben.

https://commandref.fhem.de/#HTTPSRV
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Ralli

#5
Liebes Betateilchen,

ja, das habe ich. Und ja, das mache ich bereits mit MP3-Dateien für meine Sonos. Aber der Punkt ist eben genau dieser:

ZitatMIME-Typ "application/x-ns-proxy-autoconfig"

Siehe https://wiki.fhem.de/wiki/HTTPSRV#Fallstricke
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

betateilchen

Dann geht es doch aber tatsächlich gar nicht darum, einen Webserver zu "missbrauchen" oder virtuelle Hosts zu erzeugen, sondern letztlich nur darum, eine Liste mit Dateiendungen zu erweitern?

Hast Du mal getestet, ob mit einer bei Dir lokal geänderten HttpUtils.pm Dein Vorhaben so funktioniert, wie Du es Dir vorstellst? Wenn ja, schlage doch die Erweiterung der Tabelle einfach ganz regulär als patch vor.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ich habe %ext2MIMEType in HttpUtils.pm global zur Verfuegung gestellt (my => use vars), damit sollte man mit Folgendes sich behelfen koennen:

define addExt notify global:INITIALIZED { $ext2MIMEType{dat} = "application/x-ns-proxy-autoconfig";; undef }

Ralli

#8
Vielen lieben Dank dafür.

Ich teste und berichte - ein einfacher Browser-Aufruf zeigt schon mal, dass die Auslieferung der wpad.dat so nun "als Download" funktioniert statt als Anzeige im Browserfenster.

Edit:

Es klappt! Das folgende Log zeigt, dass zwei ausschließlich per DHCP-Option 252 auf FHEM als Lieferant für wpad.dat konfigurierte Clients bei FHEM brav die Datei abholen.

2025.02.12 11:29:53.780 4: Connection accepted from WEB_10.0.0.69_50017
2025.02.12 11:29:53.782 4: WEB_10.0.0.69_50017 GET /fhem/wpad/wpad.dat; BUFLEN:0
2025.02.12 11:29:53.782 4: WEB: /fhem/wpad/wpad.dat / RL:58 / application/x-ns-proxy-autoconfig; charset=utf-8 /  / Cache-Control: no-cache, no-store, must-revalidate

2025.02.12 11:29:53.794 4: Connection closed for WEB_10.0.0.69_50017: EOF
[...]
2025.02.12 11:34:33.899 4: Connection accepted from WEB_10.0.0.175_51647
2025.02.12 11:34:33.899 4: WEB_10.0.0.175_51647 GET /fhem/wpad/wpad.dat; BUFLEN:0
2025.02.12 11:34:33.899 4: WEB: /fhem/wpad/wpad.dat / RL:58 / application/x-ns-proxy-autoconfig; charset=utf-8 /  / Cache-Control: no-cache, no-store, must-revalidate

2025.02.12 11:34:33.914 4: Connection closed for WEB_10.0.0.175_51647: EOF
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

passibe

Mal aus Neugierde: Wieso setzt du einen Proxy ein, bzw. was für Geräte sind das, die du über den Proxy laufen lässt?
Mir ist irgendwie noch nie ein richtiger usecase dafür eingefallen, deshalb bin ich neugierig:D

Ralli

Wenn du kein Directrouting möchtest sondern das Kommunikationsverhalten von Clients ins Internet aus Gründen von Datenschutz und IT-Sicherheit etwas eingrenzen oder kanalisieren aber nicht komplett abschalten willst, ist das das Mittel der Wahl. Und mit einer wpad.dat bist du viel flexibler in der Defintion von Regeln, wofür welcher Proxy wie zu nutzen ist.

Aber auch wenn du überhaupt keinen Proxy nutzt, schauen die Windows-Clients in der Standardeinstellung trotzdem alle Nase lang nach, ob es irgendwo eine wpad.dat zu finden gibt. Also entweder automatische Proxy-Konfiguration auf jedem Client deaktivieren oder von zentraler Stelle aus verwalten.
Gruß,
Ralli

Proxmox 8.3 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.79.6.20250220) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa