seit ein paar Tagen bekomme ich bei Webtrees die Meldung:
Der GOV-Server scheint zeitweise nicht erreichbar zu sein.
GOV IDs kann ich ermitteln und denke, dass der Server ja doch aktiv sein müsste.
Allerdings kann ich keine Eingabe der GOV-IDs bei Neuanlage von Orten machen. Immer, so lange diese Meldung aktiv ist oder Webtrees meint, den GOV Server nicht erreichen zu können, kann man die Eingaben nicht speichern.
Ist ein solches Verhalten schon mal beobachtet worden? Oder finden eventuell doch Arbeiten an den Servern statt?
ich bin auch bei Strato (Webtrees und Vesta-Module 2.2.5). Bei der Neuanlage von Orten wird die passende GOV-Seite problemlos gefunden. Will man die GOV-Kennung dann eintragen, erscheint im Auswahlfeld neben der Kennung die Meldung ‘GOV-Server scheint nicht erreichbar zu sein’. Die GOV-Kennung kann aber trotzdem eingegeben werden und der Ort kann angelegt werden. Von daher denke ich, dass die Ursache nicht bei Strato liegt.
Das hat nichts zu bedeuten, da diese GOV-Webseite (über einen normalen HTML-Link) direkt vom Browser des Benutzers aus aufgerufen wird. Die eigentlichen Daten werden danach über die GOV-API vom (in diesem Fall bei Strato gehosteten) webtrees-Server aus abgerufen.
Das verstehe ich nicht ganz - Das GOV-Modul müßte doch in diesem Fall insgesamt unbenutzbar sein? Die GOV-API wird ja nicht nur beim Anlegen von GOV-IDs angesprochen, sondern auch zum Abruf der eigentichen Daten (z.B. zur Darstellung der Ortshierarchien).
irgendwie habe ich das ganze Zusammenspiel wohl auch nach nunmehr mehreren Jahren nicht vollständig verstanden. Fakt ist, dass im Laufe der Updates in den letzten Wochen diese Fehlermeldung auftaucht: Den genauen Zeitpunkt kann ich leider nicht sagen.
Man kann die GOV-Kennung eintragen und den Ort anlegen:
Diese GOV-Hierarchien werden über die API abgerufen - aber nicht jedesmal wieder, sondern für einen bestimmten Zeitraum dann intern gespeichert.
Hattest Du diese GOV-ID schon vor den Problemen im System? Dann sind das “alte” Daten. Anders gefragt: Funktioniert der beschriebene Prozeß für beliebige, zuvor nie verwendete GOV-IDs?
Alternativ: Du kannst auch mal den Reset probieren über das “G“-Icon unter “Wohnsitz”. Wenn die Hierarchien danach angezeigt werden, klappt dieser Request über die GOV-API (unerwarteterweise), und nur ein spezieller anderer Request wird geblockt.
Ok, das mit dem G-Icon hat die meisten (warum nicht alle?) GOV-Hierarchien gelöscht, obwohl unmittelbar danach die Meldung kam: Die GOV-Ortshierarchie für Nebringen, Gäufelden, Kr. Böblingen, BW, DE wurde vom GOV-Server geladen. Und danach wieder ‘scheint zeitweise nicht erreichbar zu sein’. Was tun?
Das bestätigt erstmal, daß das Problem alle API-Requests betrifft (wie erwartet).
Wie in der GOV-Liste nach langem hin & her bestätigt, wird die Strato-IP-Adresse 81.169.144.135 vom GOV-Server blockiert. Solange das der Fall ist, gibt es für dort gehostete Instanzen keine Lösung.
Das hoffe ich nicht. Denn ich befasse mich gedanklich damit, auf eine Linux V-Server Lösung bei Strato zu wechseln. Damit verbunden ist die Hoffnung, dass man eine feste IPv4- Adresse hat und aus diesem IP sharing raus kommt.
nachdem ja nun alle meine GOV-Daten nicht mehr sichtbar sind: Ich habe gesehen, dass die GOV-IDs ja auch alle lokal gespeichert sind. Gibt es einen Weg diese Daten wieder bei Ereignissen sichtbar zu machen?
Wäre eine generelle Speicherung in Gedcom in Zukunft besser um bei solchen live-Blockaden gerüstet zu sein?
Das eigentliche Problem ist, dass die Beobachtung und Sperrung von IPs in Zeiten des Shared Webhosting nicht treffsicher und deshalb wirkungslos ist. Wenn ich in meinen Logfiles die Großangriffe der - mutmaßlich - AI-Bots verfolge, habe die bei jedem Hit eine andere IP, teilweise über die Grenzen einer ASN hinaus. Mt dem simplen Konzept einer Abuse DB bewirkt man allenfalls, dass irgendwann alle Ipv4-Nummern verbrannt und alle Nutzer gesperrt sind.
Und was spräche dagegen, eine ‘white list’ mit den IPs der bekannten GOV Nutzer anzulegen, um ihnen ein störungsfreies Arbeiten zu ermöglichen? Wenn man durch eine ‘black list’ die Bösen aussortiert, könnte man doch über das Gegenteil die Guten durchlassen. Oder ist das zu einfach gedacht?
Eine white list funktioniert nicht, weil vmtl. etliche/viele GOV-Nutzer keine permanente/öffentliche IP-Adr. haben. Damit ist es m.E. nicht möglich eine white list aktuell zu halten.
U.A. bei jedem Router Boot bekommt der Router vom Provider eine neue öffentliche IP-Adr. zugewiesen.
Permanente/öffentliche IP-Adr. kosten Geld und müssen administriert werden.
Mechanismen wie DynDNS kämen auch in Betracht, ob sie genutzt werden weiß ich nicht.
