FHEM hinter Proxy

Begonnen von Engel, 09 November 2016, 22:06:28

Vorheriges Thema - Nächstes Thema

CoolTux

Du erstellst ein Patch und lässt ihn Rudi zukommen.
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

TL

Moin!

Zitat von: Engel am 06 Januar 2017, 16:05:40
...

Ich würde gern meine Weiterentwicklung zurück fließen lassen. Das es sich um eine wichtige Komponente handelt, natürlich nicht ohne Review. Testen konnte ich die Klasse nur eingeschränkt mit meinen Setups mit und ohne Proxy.
Muss ich meine Änderungen nun in ein git einstellen?

Testen würde ich sehr gern - wenn ich helfen kann, sag' bitte Bescheid...  :)

Viele Grüße,
   Thomas
Einen Pi, sie zu knechten, sie alle zu finden,
ins FHEM zu treiben und ewig zu binden.

Sebastian J

Gibt es irgendwo diesen Patch zum Download ?
Oder ist er schon in der Aktuellen Version integriert ?
Wie müssen die Einträge in der fhem.cfg aussehen ?

Vielen Dank im Voraus. :)

CoolTux

Habe gerade mal geschaut. Im Code des aktuellen Modules gibt es keine Proxy Implementierung.
Schnelle Lösung wäre hier wohl ein transparenter Proxy
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

Engel

Meine Implementierung läuft nun seit geraumer Zeit ohne Fehler.

Wo finde ich im Forum eine Anleitung zu "Du erstellst ein Patch und lässt ihn Rudi zukommen"?

CoolTux

Wie man ein Patch erstellt findet man zahllos im Internet. Und dann entweder hier anhängen oder Rudi direkt senden. Natürlich sollte der Patch auf Codebasis des aktuellen HttpUtils Modul basieren.
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

Benni

Zitat von: Engel am 20 April 2017, 23:13:09
Wo finde ich im Forum eine Anleitung zu "Du erstellst ein Patch und lässt ihn Rudi zukommen"?

Nicht im Forum, aber im Wiki: https://wiki.fhem.de/wiki/How_to_write_a_patch

Engel

So, hier mein erster Versuch eines Patches auf Basis der aktuellen Code-Basis.
Ich bin gespannt auf ein Feedback und hoffe, dass es auch anderen Nutzern weiter hilft.

Über eine Info, wie oder wo die zwei neu eingeführten globalen Variablen (proxyHost & proxyPort) eingetragen werden müssen, damit die Warnungen verschwinden, wäre ich dankbar.

michiatlnx

Hallo,

nach dem patchen der HttpUtils, habe ich bei mir noch die fhem.pl erweitert danach war bei mir die Fehlermeldungen weg und die proxyHost proxyPort sind in der global Attr List auswählbar:
/opt/fhem/fhem.pl
my @globalAttrList = qw(
  ...
+  proxyHost
+  proxyPort
  ...

Ein Update check ging aber nicht und bekomme die Meldung HTTP/1.0 400 Bad Request und X-Squid-Error: ERR_INVALID_REQ 0
Den fhem log Ausschnitt habe ich drangehängt.
FHEM Container with mysql on Debian 8 INTEL NUC5PPYB (Celeron N3050) - FTUI on Blackview Tab 8E 10,1" - HMLAN - CCU3 with piVCCU on Raspberry Pi 4B - some HM-Devices - EM 1000-WZ via nanoCUL868 - SIGNALduino - SIGNALESP - AirPurifier3C - MQTT for CO2-Sensor(MH-Z19C), Gosund SP1, XY-WFUSB

Prof. Dr. Peter Henning

Eine Veränderung der fhem.pl  ist vollkommen unnötig.
Globale Attrribute kann jeder mit userAttr setzen, wenn er sie denn benötigt.

Also bitte erst einmal die Dokumentation lesen.

LG

pah

Benni

Zitat von: Prof. Dr. Peter Henning am 12 Mai 2017, 15:11:03
Eine Veränderung der fhem.pl  ist vollkommen unnötig.
Globale Attrribute kann jeder mit userAttr setzen, wenn er sie denn benötigt.

Also bitte erst einmal die Dokumentation lesen.

LG

pah

Wenn ich es richtig sehe, geht es hier aber um device-spezifische Attribute am global-Device, nicht um globale Attribute für alle Devices. Das gäbe in dem Kontext ja auch gar keinen Sinn.

lulatsch66

Um das Thema nochmal aufzugreifen: da ich ebenfalls jemanden habe, der nach extern über einen Proxy "muss"
und aktuell deswegen keine Updates machen kann, habe ich den Patch für die aktuelle HttpUtils.pm angepasst -
scheint bei mir lokal auch prinzipiell zu funktionieren, allerdings nur mit ipv4 getestet.


  • FHEM/HttpUtils.pm gepatcht: cd FHEM ; patch < HttpUtils-14945-proxy.patch
  • fhem.pl habe ich ebenfalls angepasst - das ist ja kein Device Attribut? - jedenfalls klappt es so
  • attr global proxyHost 192.168.x.y
  • attr global proxyPort 3128

... danach laufen alle http Abfragen über den Proxy. Hier fehlt also noch eine Ausschluss-Liste, sprich z.B. alles im lokalen Netz sollte wahrscheinlich nicht über den Proxy, sondern kann den direkten Weg nehmen. Jemand eine Idee, wie man das sauber lösen könnte?

Uns geht es in diesem Fall ja vor allem um's Fhem-Update - was die gepatchten Dateien natürlich wieder überschreibt, solange der Patch nicht integriert wurde ...  :-\

Zum Testen hatte ich mir einen squid proxy so aufgesetzt:


  • apt install squid
  • in /etc/squid/squid.conf aktiviert:  acl localnet src 192.168.0.0/16   und   http_access allow localnet 

LG
Falko

PS: mir ist klar, wenn es nur um's Update ginge, könnte man einfach den svn checkout verwenden ...

rudolfkoenig

Meine Bemerkungen zum Patch:
- die DNS-Aufloesung in HttpUtils_gethostbyname ist nur fuer die blockierende Version implementiert, dafuer aber explizit nochmal. Wuerde eine Zeile wie
  $host = AttrVal("global", "proxyHost", $host);
am Anfang der Routine nicht auch reichen? Damit wuerde IPv6 usw auch funktionieren.
- soweit ich es sehe, funktioniert es nur mit einer IPv4-Adresse als proxyHost.
- falls proxyPort nicht gesetzt ist, wird proxyHost ignoriert.
- das Ergebnis von HttpUtils_gethostbyname wird beim gesetzten proxy-Attributen ignoriert, d.h. der Code in HttpUtils_gethostbyname ist ueberfluessig.
- $hash->{proxyhost} und $hash->{proxyport} werden in HttpUtils_Close nicht entfernt.
- ich faende es sinnvoller auf CONNECT zu verzichten: wenn schon Proxy, dann sollte der doch mitlesen duerfen. Bin aber kein Experte auf diesem Gebiet.

Falls das mehrere Anwender interessiert, werde ich das Problem selbst angehen.

ZitatUns geht es in diesem Fall ja vor allem um's Fhem-Update - was die gepatchten Dateien natürlich wieder überschreibt, solange der Patch nicht integriert wurde ...
attr global exclude_from_update ...

CoolTux

Da ich persönlich mit einem Proxy arbeite wäre Interesse vorhanden.
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

krikan

ZitatDa ich persönlich mit einem Proxy arbeite wäre Interesse vorhanden.
Schließe mich an.  :)