Update check per ssh geht nicht mehr wie zuvor

[xenos1984]

Wenn man als Parameter noch ein -U Firefox übergibt, geht es auch mit wget - ohne den bekomme ich ebenfalls HTTP 403 Forbidden. Anscheinend mag der Server den User Agent von wget nicht.

[Christoph Morrison]

Wenn man als Parameter noch ein -U Firefox übergibt, geht es auch mit wget - ohne den bekomme ich ebenfalls HTTP 403 Forbidden. Anscheinend mag der Server den User Agent von wget nicht.

Das ist des Pudels Kern. Ich hab 'ne .wgetrc auf meinem System:

Code Auswählen Erweitern


$ grep -i user .wgetrc
user_agent = Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)


Ohne config, gleiches Problem wie bei euch:

Code Auswählen Erweitern


$ wget --no-config -O /dev/null https://fhem.de/fhemupdate/controls_fhem.txt
--2020-06-11 14:46:43--  https://fhem.de/fhemupdate/controls_fhem.txt
Resolving fhem.de (fhem.de)... 88.99.31.202, 2a01:4f8:10a:806::2
Connecting to fhem.de (fhem.de)|88.99.31.202|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2020-06-11 14:46:43 ERROR 403: Forbidden.


wtf

[rudolfkoenig]

Ich habe vor Jahren wget controls_fhem.txt per Apache-Regel untersagt, da etliche Zeitgenossen minuetlich die Datei abgeholt haben, was pro Zeitgenosse 150MB an sinnlosen taeglichen Traffic gekostet hat: die Datei wird ja nur einmal am Tag generiert.

Ein Zeitgenosse holt jetzt die Datei per curl minuetlich ab. Per curl wurde die Datei gestern 5277-mal abgeholt, macht 800MB an (nicht beabsichtigten) Traffic. Weiterhin 981-mal (vergeblich) von wget, und 2289 mal von FHEM selbst. Verhaeltnis Beabsichtigt vs. Missbrauch ist 1:3

Ich denke darueber nach in update-Modul was einzubauen, was per shell nicht ganz trivial nachzustellen ist.

[Christoph Morrison]

Ich habe vor Jahren wget controls_fhem.txt per Apache-Regel untersagt, da etliche Zeitgenossen minuetlich die Datei abgeholt haben, was pro Zeitgenosse 150MB an sinnlosen taeglichen Traffic gekostet hat: die Datei wird ja nur einmal am Tag generiert.

Ein Zeitgenosse holt jetzt die Datei per curl minuetlich ab. Per curl wurde die Datei gestern 5277-mal abgeholt, macht 800MB an (nicht beabsichtigten) Traffic. Weiterhin 981-mal (vergeblich) von wget, und 2289 mal von FHEM selbst. Verhaeltnis Beabsichtigt vs. Missbrauch ist 1:3

Ich denke darueber nach in update-Modul was einzubauen, was per shell nicht ganz trivial nachzustellen ist.

Ich verstehe das Problem und verstehe auch nicht, warum man das so häufig macht. Aber wäre es nicht eher eine Idee, stattdessen ein rate limit einzubauen? Du siehst (und weißt ja eh, vermute ich), wie trivial sich die Sperre mit einem geriggten User-Agent umgehen lässt - wechselnde IP sind deutlich aufwändiger. Dann können die curl und wgetler weiter laden, dauert dann halt nur ein paar Minuten

[Guybrush]

ist 1:3
Ich denke darueber nach in update-Modul was einzubauen, was per shell nicht ganz trivial nachzustellen ist.

wieso nicht einfach über fail2ban oder mod_evasive vom apache? da kannst du jeweils ein erlaubtes rate limit für die datei angeben - z.b. 5 requests auf 60 min/20 auf 24h. damit sollte man die ,,poweruser" alleine aussperren können ohne normale nutzer zu beeinträchtigen. ginge jedenfalls schnell/einfach umzusetzen. wenn man lust hat, kann man das alternativ auch übern captcha dann schicken

[rudolfkoenig]

Kann mir jemand erklaeren, _wozu_ das "manuelle" abholen dieser Datei gut ist?

[Guybrush]

Kann mir jemand erklaeren, _wozu_ das "manuelle" abholen dieser Datei gut ist?

das kann vermutlich nur der, der es verursacht

ist aber auch so eine Sache. wenn mans komplett sperrt, dann sperrt man ggf. auch mal nutzer aus, die es - warum auch immer - fürs debugging brauchen.

[Christoph Morrison]

Kann mir jemand erklaeren, _wozu_ das "manuelle" abholen dieser Datei gut ist?

heizfo hat unten ja erklärt, warum er das macht. Er lässt sich die ausstehenden Updates per Telegram schicken:

Ich lese aus welche Updates es gibt vs. zu meinem letzten FHEM update und sende es mir per Telegram zu.

Per se finde ich auch nicht völlig sinnlos das zu tun, auch wenn man einfach svn nehmen und mit svn status -u auch eine Liste der updates bekommen könnte.

[rudolfkoenig]

Oder "update check" in FHEM.

[Christoph Morrison]

Oder "update check" in FHEM.

Nicht jeder Prozess kann auf eine laufende Instanz von FHEM zurückgreifen und der Output von update check ist nicht trivial weiterzuverarbeiten, oder?

[Guybrush]

das ist trotzdem sinnfrei, wegen eines update checks sowas minütlich abzufragen. selbst tools wie apt-cron aktualisieren sich per default nur einmal täglich, was auch für fhem locker ausreichend wäre. damit wäre die trafficlast schon mal nur noch bei 1/3600. deswegen ja der Vorschlag zur Nutzung von mod_evasive/fail2ban

[Christoph Morrison]

das ist trotzdem sinnfrei, wegen eines update checks sowas minütlich abzufragen. selbst tools wie apt-cron aktualisieren sich per default nur einmal täglich, was auch für fhem locker ausreichend wäre. damit wäre die trafficlast schon mal nur noch bei 1/3600. deswegen ja der Vorschlag zur Nutzung von mod_evasive/fail2ban

Also es ist erstmal nur eine Spekulation (nicht meine, um da klar zu sein), dass heizfo das ist und deshalb ist die Verknüpfung minütliche Downloads && Check auf Updates so erstmal nicht haltbar. Wir wissen nicht wer es ist und warum er es tut und ob er nicht einen guten Grund hat. Trotzdem hatte ich ja schon ein rate limit vorgeschlagen. Dann dauert es halt ein bisschen länger für Mr. Unknown.

Hat jemand mal die verschiedenen Github-Mirrors abgeklappert? Wäre jetzt meine spontane Vermutung.

[heinzfo]

Hallo

Ich rufe es einmal am Tag ab, künftig zwei mal pro Woche.

Zum testen nehme ich die Github Adresse, das kann ich nur jedem empfehlen

Hätte ich geahnt was ich da lostrete 

Beste Grüße
Heinz

[rudolfkoenig]

Ich habe gar kein Problem mit eimal am Tag, das ist ja 1/1440-mal weniger als einmal die Minute.