FHEM hinter Proxy

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

Vorheriges Thema - Nächstes Thema

Engel

Moin liebe FHEM-Community,

ich bin zwar neu hier im Forum, aber mit FHEM seit fast 2 Jahren vertraut.
Nun hat sich mir aber ein bislang unüberwindbares Problem aufgetan:

Wie konfiguriere ich FHEM, so dass das System auch hinter einem (Firmen-)Proxy läuft?
D.h. es soll das Update funktionieren und auch Module wie Weather oder HTTPMOD.
Ich habe schon viel im Forum gelesen und leider nur eine Info über Socket-Kommunikation (HTTPUtils) gefunden. Genau diese blockiert der Proxy.

Derzeit habe ich einen RasPi 3 mit Rasbian Jessi lite und FHEM aufgesetzt.
Zudem habe ich CNTLM aufgesetzt und Aptitude mit den nötigen Proxy-Einstellungen versorgt.

Damit funktionieren UPDATE, WEATHER und HTTPMOD leider nicht :-(

Arbeitet FHEM tatsächlich mit Socket-Kommunikation?
Wo kann ich in FHEM Proxy-Einstellungen vornehmen?

Vielen Dank und Gruß,
Engel

rudolfkoenig

Die meisten Module in FHEM verwenden das FHEM-Eigenen HttpUtils.pm, und der kennt sich (noch) mit Proxy nicht aus.

Ich bin bereit das zu aendern, allerdings bin nicht sicher, ob ich ein Proxy zwecks Testen aufstellen will, deswegen waeren mir Patches lieber. Da ich mich bisher mit Proxies nicht beschaeftigt habe: setzt man dabei einen "normalen" HTTP-Request ab, es geht bloss nicht an dem Adressaten, sondern an den Proxy? Muss man sonst was noch ins Header schreiben?

ZitatArbeitet FHEM tatsächlich mit Socket-Kommunikation?
Ja. Was auch immer mit der Frage gemeint war :)

justme1968

was denn sonst ausser sockets? neben sockets und files gibt es nichts mehr das noch relevant ist oder?

auch http ist ein protokoll das über sockets geht. und sogar IPoAC kommt nicht ohne aus :).



hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Was ist das denn für ein Proxy der http oder https blockiert?
Ist das ein reiner Mailproxy?
Ich betreibe selber ein Proxy vorm FHEM. Du gibst einfach im Betriebssystem (Linux) an das Du einen Proxy hast und schon werden die entsprechenden Protokolle über den Proxy geleitet.
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

rudolfkoenig

ZitatDu gibst einfach im Betriebssystem (Linux) an das Du einen Proxy hast und schon werden die entsprechenden Protokolle über den Proxy geleitet.

D.h. entweder connect(2) oder gethostbyname(3) "luegt"? Kommt mir komisch vor, ich haette eine Unterstuetzung vom Programm erwartet. Laeuft bei dir das FHEM-update uebers Proxy?

CoolTux

Ja, wobei ich da sagen muß, dadurch das das Update eine http Anfrage ist kommt die sowieso zum Proxy und damit durch. Ist ein transparenter Proxy. Nur https oder ftp müssen explizit im profile script mit angegeben werden.
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

CoolTux


cat /etc/profile.d/system_proxy.sh



export https_proxy=http://pi-proxy01:3128
export ftp_proxy=http://pi-proxy01:3128
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

justme1968

ganz so einfach ist das nicht :)

es gibt zwei arten von proxy:
- transparent die greifen auf netzwerk/firewall/... ebene ein und sind (mehr oder weniger) unsichtbar
- 'normale' proxies konfiguriert werden müssen und für die der client unterstützung explizit implementieren muss weil er aktiv
  die verbindung zum proxy statt zum eigentlichen ziel aufbauen muss.
  wie diese konfiguration genau passiert hängt vom client ab.

  im http rfc steht etwas zu proxies.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Engel

Vielen Dank für die Rückckmeldungen  :)

Es ist ein aktiver Proxy, der Zugriffe auf bestimmte Seiten sperrt wie z.B. private Mail oder auch indizierte Seiten.

Die Einstellungen, die CoolTux in die system_proxy.sh geschrieben hat, habe ich schon gesetzt.

Ohne diese Einstellungen funktioniert wget nur mit dem Zusatz "-e use_proxy=yes" und der Angabe des Proxy "-e http_proxy=127.0.0.1:3128".
Hinter "127.0.0.1:3128" verbirgt sich CNTLM. CNTLM "ergänzt" für den eigentlichen Proxy die Credentials (Username und Passwort)

Ein Update in FHEM funktioniert nicht  :(
Resultat: http://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: Bad hostname 'fhem.de:80'

Ein wget auf die Datei funktioniert.

TL

#9
Moin!

Zitat von: rudolfkoenig am 10 November 2016, 10:14:49
Die meisten Module in FHEM verwenden das FHEM-Eigenen HttpUtils.pm, und der kennt sich (noch) mit Proxy nicht aus.

Ich bin bereit das zu aendern, allerdings bin nicht sicher, ob ich ein Proxy zwecks Testen aufstellen will, deswegen waeren mir Patches lieber. Da ich mich bisher mit Proxies nicht beschaeftigt habe: setzt man dabei einen "normalen" HTTP-Request ab, es geht bloss nicht an dem Adressaten, sondern an den Proxy? Muss man sonst was noch ins Header schreiben?

Ich habe auch das Problem, dass hinter meinem Proxy (Squid) leider im Bezug auf FHEM einiges nicht funktioniert. Daher wäre es wirklich toll, wenn sich das ändern würde!

Habe daher gerade mal mit dem Wireshark nachgeschaut - es ist genau, wie Du schreibst: Der Header ändert sich nicht, Du musst nur die Pakete an die Adresse und den Port schicken, die z.B. in den Environment-Variablen http_proxy / https_proxy / ftp_proxy hinterlegt sind. Das müsste eigentlich schon alles sein. Falls der proxy eine Authentifizierung mit Username/Passwort verlangt, wird wohl komplizierter, aber das habe ich zumindest nicht eingerichtet. Für die meisten würde das oben beschriebene vermutlich ausreichen.


Edit: Die Env-Variable "no_proxy" müsste wohl auch noch berücksichtigt werden.

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

Prof. Dr. Peter Henning

Der bessere Weg ist, vom lokalen Rechner einen SSH-Tunnel auf die Firewall aufzumachen - damit ist der Proxy in der Regel auch umgangen. Mit diesem SSH-Tunnel können beliebige Ports externer Rechner auf den internen Rechner gemappt werden. Nicht nur zum Update von FHEM, sondern auch für andere Zwecke sehr hilfreich.

LG

pah

TL

Moin!

Zitat von: Prof. Dr. Peter Henning am 19 November 2016, 20:35:12
Der bessere Weg ist, vom lokalen Rechner einen SSH-Tunnel auf die Firewall aufzumachen - damit ist der Proxy in der Regel auch umgangen. Mit diesem SSH-Tunnel können beliebige Ports externer Rechner auf den internen Rechner gemappt werden. Nicht nur zum Update von FHEM, sondern auch für andere Zwecke sehr hilfreich.

Könntest Du das bitte für mich einmal genauer ausführen? Meine Netzwerkumgebung sieht grob ungefähr so aus:


   FHEM-
   Update- ______Internet_____Router_____Firewall_____Proxy_____Lokales FHEM
   Server

(Router, Firewall,Proxy und lokales FHEM sind jew. eigenständige Rechner. Mindestens der Proxy-Server macht kein IP-Forwarding von IP-Paketen.)

Wie sollte mir jetzt ein SSH-Tunnel dabei helfen, vom lokalen FHEM aus den FHEM-internen Update-Befehl durch den Proxy zu bringen? Wie müsste der ssh-Befehl dafür genau aussehen?

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

Engel

Moin zusammen,

zunächst möchte ich allen FHEM-Entwicklern und -Usern ein frohes neues Jahr wünschen.

Nachdem ich die Arbeit letztes Jahr unterbrechen musste, habe ich mich nun weiter an die Analyse gemacht.

Zunächst habe ich exemplarisch ein wget auf query.yahooapis.com gemacht. Alles in Ordnung, da (wie im Browser auf einem anderen Rechner) HTTP 400 zurück geliefert werden. Ein wget auf fhem.de funktioniert auch ohne Probleme.

Dann habe ich via fhem eine Anfrage an query.yahooapis.com ausgelöst. Der Proxy antwortet auf eine DNS-Anfrage mit einer Antwort (A Record), die einen Authoritative Nameserver als SOA enthält. Ferner wird sofort versucht die Adresse durch Anhängen einer erweiteren Adresse aufzulösen.

Im Log von FHEM stehen die Einträge "gethostbyname query.yahooapis.com failed". Mir ist noch unklar, warum die Methode "gethostbyname" fehl schlägt ...

Leider fehlt mir ein wenig Handwerkszeug zum Debuggen der HttpUtils. Ich bin mit perldebug nicht vertraut und google hat auf die Schnelle nicht weiter helfen können.
Könnte mir jemand eine kurze Erläuterung geben, wie ich im Umfeld von FHEM einzelne Module oder speziell HttpUtils mit gethostbyname debuggen kann?

Vielen Dank für die Unterstützung
Engel

rudolfkoenig

Die einfachste Version ist "attr global verbose 5".
Etwas aufwendiger: an strategischen Stellen in HttpUtils.pm eine
Log 1, "XXX: $XXX";
Zeile einstreuen. Dabei kann man fuer komplexe Datenstrukturen auch
Log 1, "XXX: ".Dumper($XXX);
verwenden, muss man aber einmal oben
use Data::Dumper;
dazupacken.

Achtung: falls man die Variable "attr global dnsServer a.b.c.d" setzt, dann verwendet HttpUtils statt gethostbyname die eigene, nicht blockierende Implementierung.

Engel

So, nun habe ich mich ausführlich mit HttpUtils beschäftigt.
@Rudolf: Vielen Dank für den Support

Inzwischen habe ich eine Version erstellt, die mit und ohne Proxy eingesetzt werden kann. Unterstützt werden http- und https-Anfragen.
Der Proxy wird nur angesprochen, wenn er in der fhem.cfg eingerichtet ist. Zusätzlich wird CNTLM benötigt.

Probleme habe ich noch mit zwei neu eingeführten globalen Variablen (proxyHost & proxyPort): Wo müssen diese eingetragen werden, damit die Warnungen verschwinden?

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?

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.  :)

CoolTux

Zitat von: Engel am 06 Januar 2017, 16:05:40
So, nun habe ich mich ausführlich mit HttpUtils beschäftigt.
@Rudolf: Vielen Dank für den Support

Inzwischen habe ich eine Version erstellt, die mit und ohne Proxy eingesetzt werden kann. Unterstützt werden http- und https-Anfragen.
Der Proxy wird nur angesprochen, wenn er in der fhem.cfg eingerichtet ist. Zusätzlich wird CNTLM benötigt.

Probleme habe ich noch mit zwei neu eingeführten globalen Variablen (proxyHost & proxyPort): Wo müssen diese eingetragen werden, damit die Warnungen verschwinden?

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?

Ich würde mal behaupten daß die beiden Attribute nur Sinn im Device global machen.
Es würde mich sehr freuen wenn wir nicht über fhem.cfg editieren reden. Sämtliche Einstellungen sollten vom User über das FHEMWEB getätigt werden.
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

Zitat von: rudolfkoenig am 03 September 2017, 15:30:32
Falls das mehrere Anwender interessiert, werde ich das Problem selbst angehen.

Moin!

Ich hätte sehr großes Interesse daran. Es wäre auch gut, wenn es eine Option wie "no_proxy" gäbe für das lokale Netz, so ähnlich wie z.B. im Browser (Firefox) auch.

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

rudolfkoenig

#32
Ich habe das proxy global Attribut eingefuehrt, muss als host:port spezifiziert werden.
Es gibt auch ein proxyExclude, was als Regexp geprueft wird.

Ich habe es mit squid3 getestet, ein FHEM update funktioniert sowohl ueber HTTP als auch ueber HTTPS.
Auch http://fhem.de/ oder https://fhem.de/ (inklusive redirects) scheint zu funktionieren, sowohl Blocking als auch NonBlocking.

Achtung: SSL Verbindungen koennen selbst beim Aufruf der Nonblocking-Routine blockieren, da ich zu faul war die CONNECT Phase mit dem Proxy nonblocking zu realisieren. Evtl. spaeter, wenn Bedarf da ist.

amenomade

Es fehlt nur noch die Möglichkeit, proxyUser und proxyPasswort zu setzen ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Per

Zitat von: rudolfkoenig am 03 September 2017, 15:30:32Falls das mehrere Anwender interessiert, werde ich das Problem selbst angehen.
Zwar nicht das selbe Problem, aber vllt. fällt eine Lösung für das DSLite-Thema dabei mit ab...

rudolfkoenig

ZitatZwar nicht das selbe Problem, aber vllt. fällt eine Lösung für das DSLite-Thema dabei mit ab...
Bin heute vielleicht schwer vom Begriff, aber:
- was ist das "DSLite-Thema"?
- und was hat das mit einem Proxy zu tun?

CoolTux

Möchte mich den Fragen gerne anschließen. Danke
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

rudolfkoenig

 
ZitatEs fehlt nur noch die Möglichkeit, proxyUser und proxyPasswort zu setzen
Habe proxyAuth hinzugefuegt, und kurz mit http/https getestet.
Auf squid3 war es mit
  auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/passwords
aktiviert. proxyAuth muss als Base64 von Benutzername:Passwort angegegen werden:% echo -n Benutzername:Passwort | base64
QmVudXR6ZXJuYW1lOlBhc3N3b3J0
fhem> attr global proxyAuth QmVudXR6ZXJuYW1lOlBhc3N3b3J0

amenomade

Geht!
Funktioniert hinter meinem Firmenproxy.

Danke dir :)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

koef2

#39
HAllo zusammen,

funktioniert das auch in der Version 5.8?

Ich habe mal gerade mittells svn aktualisiert auf Revision 15152.

Da steht unter den attr zu GLOBAL noch kein proxy.

Viele Grüße
Kai
Koef2 

rudolfkoenig

Version 5.8 ist "nur" ein Snapshot, nach einem update ist man auf den aktuellen Stand, egal von welchem man gestartet ist.
proxyAuth ist seit SVN Version 15033 aktiv.

koef2

Danke,

dann hat mein Update über SVN nicht funktioniert. In der CommandRef auf meinem Raspi taucht es nicht auf. Aber in der CommandRef auf fhem.de wohl. Dann gehe ich mal suchen, was ich falsch gemacht habe.

Viele Grüße
Kai
Koef2

koef2

#42
Hallo zusammen,

muss leider nochmal nachfragen, da mein update wohl über svn nicht richtig funktioniert.


svn co https://svn.fhem.de/fhem/trunk/fhem /opt/fhem
svn update


Da hat er rumgemeckert:
Zitat
Konflikt in »trallalla« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei
         (s) alle Optionen anzeigen: p

Habe das mit MC bestätigt.
Allerdings hat das nichts geändert, in commandref steht bei mir nichts zu proxy oder proxyAuth und "attr global proxy 192.168.1.3:3128" kann ich nicht setzen. Er sagt "define proxy first".

Dann habe ich im neuen Verzeichnis Repository neu geholt und die Dateien in des /opt/fhem kopiert und Dateiowner auf fhem:dialout gesetzt.

Leider immer noch kein Erfolg, Commandref zeigt unter global kein attr proxy.

Wenn es hier flasch gepostet ist, bitte kurze Info, wo ich es besser posten soll.

Viele Grüße
Kai
Koef2

amenomade

Warum machst Du dein update über svn, und nicht über FHEM ?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

koef2

Hallo Amenomade,

weil ich einen Proxy dazwischen habe und das update aus fhem dann nicht funktioniert. Und eine Lösung dann svn ist, weil bei svn kann ich den Proxy angeben.

Viele Grüße und schönen Sonntag
Kai
Koef2

rudolfkoenig

Zitatweil ich einen Proxy dazwischen habe und das update aus fhem dann nicht funktioniert.
Inzwischen sollte das kein Problem sein: https://fhem.de/commandref.html#proxy

koef2

#46
Hallo zusammen,

Problem gelöst. Lösung aus dem Kopf

Ich hatte die svn Arbeitskopie auf dem Raspi zerschossen. Hatte nicht aufgepasst, wenn man lokal editiert, dass dann Konflikte entstehen und die in svn aufgelöst werden müssen.

service fhem stop

Eintrag zu fhem aus /var/lib/dpkg/status Einträge zu fhem löschen

Dazu alles neu installiert gemäß fhem.de mittels Einträgen in /etc/apt/sourceslist, apt-get update, apt-get install fhem

Dann über svn eingespielt und update (siehe fhem.de).

Rechte user gesetzt auf fhem:dialout

attr global proxy gesetzt

update check ging

Update funktioniert auch.

Viele Grüße
Kai
Koef


koef2

Guten MOrgen,

Nachtrag: wenn ein Proxy eingetragen ist unter "global" und "fhem2fhem" genutzt wird und diese im gleichen LAN vorhandenen Rechner aber keinen Proxy erfordern, bitte auf dem Rechner, auf dem fhem2fhem konfiguriert wird, den Remote-Rechner in "proxyExclude" angeben. Sonst versucht fhem wohl, auch dafür den angegeben Proxy zu nutzen. Ich habe es bei beiden Rechnern angegeben.

FHEM ist eine tolle Software und danke für die Integration der Proxyfunktion.

Viele Grüße
Kai
Koef2

TL

Moin!

Ich wollte mich gern bei allen Beteiligten, allen voran natürlich Rudi, für die Implementierung des Proxys bedanken! Endlich geht bei mir Update und Pushover und mal sehen, was mir noch einfällt. Was lange währt...  :)

Eine Frage habe ich aber noch: wie ist die genaue Syntax für das ProxyExclude-Attribut? In der Beschreibung steht "Regexp", aber es gibt leider keine Beispiele. Ich habe z.B. "..., 192.168.1.0, ..." und "..., *.test.intranet, ..." ausprobiert, aber das scheint nicht zu funktionieren. Mit IP-Adressen und Full-Qulified-Hostnames funktioniert es wunderbar, aber die Liste kann beliebig lang werden und muß vor allem eben auch gepflegt werden. Ich würde gern das ganze lokale Class-C Netz komplett vom Proxy ausnehmen. Hat jemand einen Tip für mich, wie der entsprechende Eintrag aussehen müsste?

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

rudolfkoenig

ZitatIch würde gern das ganze lokale Class-C Netz komplett vom Proxy ausnehmen. Hat jemand einen Tip für mich, wie der entsprechende Eintrag aussehen müsste?

Die Pruefung gegen proxyExclude passiert vor der Namensaufloesung, d.h. der Regexp wird gegen den String geprueft, was man HttpUtils als host uebergeben hat. Falls man sich auf IP-Adressen beschraenkt, dann waere fuer den 192.168.1.255-er C-Netz
attr global proxyExclude ^192.168.*
einzusetzen (ja, etwas ungenau, sollte aber tun). Ein Regexp fuer alle "Intranet" Adressen (auch IPv6) findet man bei der Pruefung von allowedFrom:
^(::ffff:)?(127|192.168|172.(1[6-9]|2[0-9]|3[01])|10|169.254)\\.|^(f[cde]|::1)
Wenn man in FHEM Hostnamen in Klartext verwendet, dann muessen diese zusaetzlich spezifiziert werden.

TL

#50
Moin!

Zitat von: rudolfkoenig am 09 Oktober 2017, 19:16:46
Die Pruefung gegen proxyExclude passiert vor der Namensaufloesung, d.h. der Regexp wird gegen den String geprueft, was man HttpUtils als host uebergeben hat. Falls man sich auf IP-Adressen beschraenkt, dann waere fuer den 192.168.1.255-er C-Netz
attr global proxyExclude ^192.168.*
einzusetzen (ja, etwas ungenau, sollte aber tun).
...

Ich glaube, der .* am Ende ist nicht gut...

Ich habe jetzt folgenden String bei mir drin, das funktioniert bei mir anscheinend:

attr global proxyExclude ^192\.168\.1\.*|.*\.test\.intranet$

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

rudolfkoenig

ZitatIch glaube, der .* am Ende ist nicht gut...
Wie geschrieben, etwas ungenau, weil es auch 192.16890.1.1 matcht, aber das sollte selten ein Problem sein.