Moin,
seit ungefähr einer Woche gibt es hier
https://forum.fhem.de/index.php?board=57.0
keine Aktualisierung mehr.
Ist das so gewollt oder hat das Problem schon jemand in Bearbeitung?
Moin,
kann ja nur mit der Umstellung des Proxy zu tun haben. Wenn ich wüsste wie der Vorgang eigentlich funktioniert könnte ich nach dem Problem suchen. Ich mach mich mal auf die Suche, Hilfe ist aber gerne willkommen.
Der Update Prozess vom fhem update Pfad läuft ordentlich jedem Morgen 7:45 Uhr - daran ist das wohl nicht gekoppelt?
Edit: Mist das läuft doch nicht, bzw. nicht bis zu Ende?
Zitatsvn: E170013: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem'
svn: E000110: Error running context: Connection timed out
fhemupdate.pl END: Fri Nov 28 07:47:28 2025
@Rudi kannst Du Dir bitte den Prozess auf dem wiki Server anschauen? Der Zugriff auf den Pfad im svn funktioniert eigentlich. Sag Bescheid wenn ich da noch was am Proxy ändern muss.
Gruß Otto
Danke fürs Kümmern, es ist ja nix wirklich Weltbewegendes.
Zitat@Rudi kannst Du Dir bitte den Prozess auf dem wiki Server anschauen?
Ich sehe in ~/fhemupdate/log:
Zitatsvn: E170013: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem'
Fuer Folgendes habe ich noch keine Erklaerung:
> telnet svn.fhem.de 443
telnet: could not resolve svn.fhem.de/443: Temporary failure in name resolution
Exit 1
> ping svn.fhem.de
PING svn.fhem.de (188.40.131.57) 56(84) bytes of data.
64 bytes from fhem2-host (188.40.131.57): icmp_seq=1 ttl=64 time=0.371 ms
64 bytes from fhem2-host (188.40.131.57): icmp_seq=2 ttl=64 time=0.140 ms
64 bytes from fhem2-host (188.40.131.57): icmp_seq=3 ttl=64 time=0.126 ms
^C
> telnet svn.fhem.de 443
Trying 188.40.131.57...
^C
ich kann dem später mal nachgehen.
Spontan fällt mit auf, dass (vom vmhost.fhem.de)
ping -6 svn.fhem.de reagiert im 8 sekunden Takt (mit guten response zeiten)
ping -4 svn.fhem.de reagiert im sekunden Takt
Zitatping -6 svn.fhem.de reagiert im 8 sekunden Takt (mit guten response zeiten)
Hast einen komischen ping.
Bei mir macht es keinen Unterschied, beides ist 1 Sekunden Takt.
Zitat von: Otto123 am 28 November 2025, 11:25:37ping -6 svn.fhem.de reagiert im 8 sekunden Takt (mit guten response zeiten)
Das muss der Ottiping, frei nach Otto Waalkes, sein. Bei mir auch indentisch zum ping -4.
Grüße Jörg
naja, hab aber gesagt: ich mache das ping vom der konsole vmhost.fhem.de. Da ist das nachvollziehbar immer noch so.
Also irgendetwas ist komisch innerhalb unserer virtuellen Server Umgebung.
Auch das hier ist komisch
okl@fhem2-wiki:~$ ping -6 svn.fhem.de
ping: svn.fhem.de: Temporary failure in name resolution
okl@fhem2-wiki:~$ ping -4 svn.fhem.de
ping: svn.fhem.de: Temporary failure in name resolution
okl@fhem2-wiki:~$ resolvectl
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp1s0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.124.1
DNS Servers: 192.168.124.1
okl@fhem2-wiki:~$ ping google.de
PING google.de (142.250.185.195) 56(84) bytes of data.
^C64 bytes from 142.250.185.195: icmp_seq=1 ttl=118 time=5.26 ms
--- google.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.258/5.258/5.258/0.000 ms
Insofern bin ich bei Dir Rudi: ich habe noch keine Erklärung ;)
ich habe jetzt auf dem vmhost.fhem.de mal noch die zwei neuen virtuellen Maschinen mit interner IPv4 Adressen hinterlegt.
Jetzt sieht das alles besser aus. Rudi, kannst Du bitte nochmal testen.
ZitatJetzt sieht das alles besser aus. Rudi, kannst Du bitte nochmal testen.
Ich konnte keinen Unterschied feststellen.
Habe fhemupdate.pl nochmal gestartet, musste 2 Minuten warten, und dann kam die Fehlermeldung von oben.
Das hat offenbar mit der Portumleitung (iptables) für IPv4 Port 443 zu tun.
Mit IPv6 gibt es keine Umleitung da funktioniert es, allerdings haben die meistens VMs keine IPv6 Adresse.
Wenn ich wget https://svn.fhem.de auf fhem2-wiki ausführe gibt es Fehler, wenn ich das auf fhem2-va ausführe funktioniert es.
Hat da jemand einen Tipp? Was ich ausführe:
/sbin/iptables -t nat -I PREROUTING -p tcp -d 188.40.131.57 --dport 443 -j DNAT --to 192.168.124.63:443
/sbin/iptables -I FORWARD -d 192.168.124.63 -p tcp --dport 443 -j ACCEPT
was daraus wird
sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere fhem2-host tcp dpt:https to:192.168.124.63:443
DNAT tcp -- anywhere fhem2-host tcp dpt:http to:192.168.124.63:80Edit:
Lösung mit KI :) zumindest mein Test funktioniert jetzt
Zitat🛠� Lösung: Hairpin NAT aktivieren
Du musst zusätzlich eine SNAT/MASQUERADE-Regel setzen, damit interne Clients (VM2) über die öffentliche IP den Dienst in VM1 erreichen können.
Beispiel (ergänzend zu deinen Regeln):
# DNAT hast du schon:
iptables -t nat -I PREROUTING -p tcp -d 188.40.131.57 --dport 443 -j DNAT --to-destination 192.168.124.63:443
iptables -I FORWARD -d 192.168.124.63 -p tcp --dport 443 -j ACCEPT
# Jetzt Hairpin NAT hinzufügen:
iptables -t nat -A POSTROUTING -s 192.168.124.0/24 -d 192.168.124.63 -p tcp --dport 443 -j MASQUERADE
��
✨ Wirkung
- Externe Clients: gehen wie bisher über DNAT → VM1.
- Interne Clients (VM2): wenn sie die öffentliche IP des Hosts nutzen, werden ihre Pakete durch die MASQUERADE-Regel so umgeschrieben, dass VM1 sie akzeptiert und die Antwort wieder korrekt zurückgeht.
Eine Alternative waere (gewesen), in mksvnlog.sh
REPO=https://svn.fhem.de/fhem/trunk/fhem
gegen
REPO=http://fhem2-svn/fhem/trunk/fhem
auszutauschen.
Danke für die Korrektur!
Moin,
schraubt Ihr gerade wieder am SVN Server rum?
svn: E170013: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem'
svn: E175002: Unexpected HTTP status 503 'Service Unavailable' on '/fhem/trunk/fhem'
Ich weiss von nix, und ich habe auch kein Problem gerade mit einem svn update.
Inzwischen hatte es auch hier schon wieder funktioniert.
Leider nein, wir schrauben nicht - aber irgendwie "andere".
Ich kann nachvollziehen, dass svn.fhem.de zeitweise nicht antwortet. Er ist einfach überlastet, irgendwelche Crawler brauchen tausende Kopien um unseren Code zu verstehen :)
Und ich kann auch nachvollziehen, dass der neue Proxy seinen Job gut macht: die restlichen Server sind, während der svn "aufgibt", ziemlich unbeeindruckt. ;)
hab ich gestern was böses geschrieben? :-\ - "irgendwelche Crawler" ist doch keine Beleidigung, oder? ;) ;D
Seit ca. 16:00 Uhr gestern nachmittag steht das svn unter Dauerstress. Ich muss mal schauen ob ich da was machen kann.
Zumindest im Browser geht derzeit nix. svn und ssh scheint zu gehen.
Und im Gegensatz zu gestern bekomme ich heute nichtmal mehr eine Fehlermeldung zurück.
Zitat von: Otto123 am 09 Dezember 2025, 11:16:36Zumindest im Browser geht derzeit nix. svn und ssh scheint zu gehen.
'svn update' auf der CLI geht auch nicht. Aber Du meinst, wenn ich es mit meinem Developer-Account probiere, könnte es klappen? Werde ich gleich testen...
Zitat von: betateilchen am 09 Dezember 2025, 11:31:08Aber Du meinst, wenn ich es mit meinem Developer-Account probiere, könnte es klappen? Werde ich gleich testen...
Funktioniert perfekt, danke für den Tipp.
Die Verfügbarkeit der svn http Schnittstelle geht derzeit quasi gegen null
Können wir die IP Adressen oder den Bereich der Crawler blockieren?
365 IP Adressen, 450.000 Besucher, 2.000.000 hits - heute bis jetzt
Wir können jemanden suchen der uns die "klicks" bezahlt ;D
ZitatKönnen wir die IP Adressen oder den Bereich der Crawler blockieren?
Beim letzten (vor paar Monaten) Mal waren es ca 100k an unterschiedlichen IP Adressen, die jeweils eine Datei abgeholt haben.
Angeblich bietet CloudFlare einen kostenlosen DDOS Schutz an.
Bin (aus unterschiedlichen Gruenden) noch unsicher, ob wir uns das antun sollten.
Zitat von: rudolfkoenig am 09 Dezember 2025, 15:06:18Angeblich bietet CloudFlare einen kostenlosen DDOS Schutz an.
Das ist mir momentan zu diffus.
Ich würde erstmal gern verstehen was eigentlich passiert und schauen ob ich das durch Servereinstellungen verhindern kann.
Falls einer zu dem Report im Anhang eine Idee hat :)
Wir haben ja Apache. Könnten wir da nicht mit .htaccess arbeiten?
Ja :) sag was ich tun kann
<IfModule mod_headers.c>
Header set X-Robots-Tag "noindex, nofollow"
</IfModule>
In das Dokumentenverzeichnis für die gewünschte Domäne oberen Inhalt in eine .htaccess- Datei schreiben.
Diese Methode sollte das Crawling vollständig blockieren.
ZitatDiese Methode sollte das Crawling vollständig blockieren.
Bin gespannt, ob die KI-Crawler sich daran halten.
Laut Nachrichtenseiten ist das nicht der Fall, aber wir koennen es ja selbst ueberpruefen :)
wollte ich auch gerade schreiben :) aber ich weiß ja gar nicht wer/was es ist. Die IP Adressen zeigen fast alle in MS Rechenzentren.
Ich habe es mal in die /etc/apache2/sites-enabled/fhem-svn.conf eingebaut, das ist doch auch ok - oder?
Also eigentlich müsste das in eine .htaccess Datei geschrieben werden und diese Datei kommt dann in das webroot der Subdomaine
aber .htaccess ist doch nur die "Hilfe" wenn man die site Datei nicht bearbeiten kann? Zumindest habe ich das bisher immer so gesehen. Und eine subdomain gibt es ja auf dem Server nicht, der steht für sich allein.
Habs aber noch so gemacht wie Du gesagt hast. Kann ich irgendwo im Log sehen das es greift?
Irgendetwas wirkt zumindest jetzt, ich habe noch eine Begrenzung der Anfragen pro IP im Proxy eingebaut.
man könnte noch den Chrome 125 aussperren, der macht den meisten Verkehr
Zitat1.983.265 (90.23%) 288.311 (64.35%) 11.75 GiB (79.40%) Chrome/125.0.0.0
Im Log sollte etwas zu sehen sein.
Hallöchen,
nur mal 5ct von mir.
Der mirror im git lief einige Zeit nicht, leider so lange dass auch der cache weg war.
Ich habe den Workflow repariert und den Workflow etliche male laufen lassen.
Bis r30600 ist der Job gestern gekommen, seit dem hängt er an dem HTTP Status 503.
Mein erster Gedanke war, dass vielleicht die Workflows Schuld an den vielen Anfragen sind.
Die hohe Last aus dem Screenshot passt aber nicht richtig zu den runs.
Als Abgleich:
Der reparierte Workflow lief erstmalig "Dec 6, 3:01 AM" für eine Stunde.
Der Workflow lief heute 3:17 AM und 11:37 AM je unter 2 Minuten. (Abbruch wegen http 503)
An welchem Tag haben die Probleme denn angefangen?
Grüße Sidey
Zitat von: Sidey am 09 Dezember 2025, 19:37:46An welchem Tag haben die Probleme denn angefangen?
Immer mal geht das seit ein paar Tagen so, in der Regel waren es aber nur Minuten bis ein halbe Stunde.
Seit gestern 16:30 Uhr lief dann fast Dauerlast, sieht man doch in dem Bild (https://forum.fhem.de/index.php?action=dlattach;attach=186737)ganz gut. Alles was über 150 ms ist, ist quasi aus dem normalen Rahmen. Also im Bild sind auch die grünen Peaks lediglich "Seite erreicht" innerhalb eines Timeouts von 25 sec.
Am 6.12. gab es keine hohe Belastung, ich denke Du bist nicht Schuld :)
Aber ob Du derzeit eine Fehlerfreie Runde drehen kannst, kann ich nicht vorhersagen. Die Belastung ist derzeit nicht von Dauer sondern eher in Impulsen. welche IP initiert das?
ich habe jetzt noch den Chrome User Agenten 125.x.x.x und leere Agenten (die wohl bots gerne setzen) im proxy nur für svn.fhem.de geblockt.
Chrome 125 hatte heute mit 2,7 Mio Hits die Spitze. :)
Ich hoffe das keine Nebeneffekte. Eigentlich wollte ich heute was vernünftiges machen ;)
Zitat von: Otto123 am 09 Dezember 2025, 20:02:56Aber ob Du derzeit eine Fehlerfreie Runde drehen kannst, kann ich nicht vorhersagen. Die Belastung ist derzeit nicht von Dauer sondern eher in Impulsen. welche IP initiert das?
Ja, hat dann gestern Abend wieder funktioniert. Es waren ja auch nur 8 commits oder so um den dreh :)
Die IP Adresse kenne ich leider nicht. Wenn der Workflow startet, dann wird eine Azure VM mit dem Job beauftragt. Die läuft dann maximal 1 Stunde.
Beim nächsten Lauf, wird dann eine andere VM beauftragt, da ich glaube dass die VM nach dem Job zerstört wird.
Wenn es aber weiterhilft, kann ich in den Job eine Abfrage für die Adresse einbauen.
Grüße Sidey
@Sidey nein brauchst Du nicht. Dein Workflow wird keine nennenswerte Last verursachen.
Gestern 19:00 Uhr und 20:00 gab es noch zwei kurze Lastwellen. Seit dem ist wieder Stille eingekehrt.