Moin,
eigentlich wollte ich ein Knoten “wiederbeleben”, der seit Update auf 0.7.5~72 der Site “zzz” zugeordnet ist.
Das geht leider nicht … Wizard meldet :
Lokalisierung des Knotens erfolgreich; bitte Daten überprüfen:
Adresse: FEHLER_ADDR, 00000 XML-error
Koordinaten: 53.514559 12.689112
Community: Freifunk Gütersloh (Außenbezirk)
Selbst ein frisch geflashten Knoten mit 0.7.5~6 hat den XML-error.
Wo ist der Wurm?
Gruß
Matthias
Vermutlich ist der Free Tier bei MapQuest übergelaufen … Yepp: »16,014 total transactions
this period« bei »15,000 transactions/month«.
Einerseits: »This plan will renew on June 21, 2016«.
Andererseits werden wir »really soon now« eine eigene Nominatim-Instanz laufen haben (analog http://carrot.uu.org:8080/, was aber nur Bremen indiziert hat): dank einer leistungsstarken Serverspende (2x 6 Cores + HT => 24 Threads) läuft – seit heute morgen – eine Indizierung von Deutschland mittlerweile in den letzten Zügen – auf dem i7-Server bei Hetzner läuft das seit ca. 4 Tagen und braucht noch ca. 0.5 Tage …
Sprich: sorry for the inconvenience. Im Laufe der Woche können wir auf eigene Services schwenken und sind dann nicht mehr von externen Limits abhängig. Die 24-vCPU-Box habe ich halt leider zwei, drei Tage zu spät fertig bekommen (bzw. braucht der Job auf dem 8-vCore-i7 mittlerweile 3 Tage länger als erwartet).
BTW: das ist ein schönes Beispiel dafür, daß wir nicht nur trafficschaufelnde Server gebrauchen können. Für Software-Bau und ähnliches können wir auch denzentrale Server sehr gut nutzen. Heißt: wenn jemand einen potenten Server (viiiiel RAM (>32 GB) und viiiiiile Cores (>16) ›über‹ hat: wir würden den gerne übernehmen und unsere Build-Prozesse dorthin auslagern: »ssh-key on request« 
Was es nicht alles gibt … noch zwei Bier trinken und 00:01 nochmal versuchen?
wusel, schöne Erklärung, nur ich befürchte, da kommt nicht jeder mit.
Hmm, jein, werden wohl mehr Biere, 00:00 GMT == 02:00 MESZ 
Äh, ja. Sorry.
(@Cord, schreibste mit für’s Wiki?)
Also: unsere Firmware ist »geo-aware«. Das bedeutet, daß die Firmware etwas mit Positionen auf dem Erdball anfangen kann. Leider ist der Speicher mancher unterstützter Router ziemlich begrenzt, sodaß wir auf Server »in da Cloud«/im Internet ausweichen müssen.
Konkret bedeutet dies, daß unsere Firmware über den Rechner »setup.4830.org« z. B. versuchen kann, sich anhand von WLAN-Netzen in der Umgebung zu positionieren. Klappt, bei 5 WLANs pro Meter wie in Berlin super — weniger gut klappt das auf dem flachen Land mit 1 WLAN pro Kilometer, wie @m.bitterlich wahrscheinlich bestätigen kann.
Ebenfalls über »setup.4830.org« kann die Firmware aber auch eine sog. »RGeo«-Anfrage stellen (»Reverse-Geo«, d. h. »gib’ mal Adresse zu Koordinate«). Dies nutzen wir, um von einer Koordinate auf einen Ort, und damit auch auf einen sogenannten UN/LOCODE (DE) zu kommen. Bislang nutz(t)en wir dafür den Service der Firma MapQuest.com, die für bis zu 15.000 Anfragen im Monat einen kostenlosen Account anbietet. Mittlerweile reißen wir dieses Limit (bislang: drohten, es zu reißen), also heißt es entweder zahlen — oder die OSM-Datenbasis lokal abrufbar zu machen. Genau dies ist möglich mit »Nominatim«, nur leider benötigt die Indizierung der Daten »etwas« Rechenleistung: Seit Ende letzter Woche lief ein entsprechender Job auf einem 8-HT-Core-System bei Hetzner, der im Laufe des Dienstags fertig geworden wäre. Durch eine Hardwarespende (eines 24-HT-Core-Systems) allerdings sind wir nun in der Lage, ein solches System mit dem Datensatz von Deutschland in <24 neu aufzusetzen: Aktuell läuft ein entsprechender Container unter http://colosses.4830.org:8080/search.php — und bis auf die Reihenfolge der Daten sehen die Tests gut aus:
wusel@ponder:~$ wget -q -O - 'http://colosses.4830.org:8080/reverse.php?format=json&lat=53.7412971935348&lon=8.931297361850739&zoom=' | json_pp
{
"display_name" : "Dreihausendorf, Ihlienworth, Samtgemeinde Land Hadeln, Landkreis Cuxhaven, Niedersachsen, 21775, Deutschland",
"lon" : "8.9266569",
"boundingbox" : [
"53.739074",
"53.7492497",
"8.9204858",
"8.931265"
],
"place_id" : "7221835",
"address" : {
"village" : "Ihlienworth",
"country" : "Deutschland",
"county" : "Samtgemeinde Land Hadeln",
"state" : "Niedersachsen",
"postcode" : "21775",
"road" : "Dreihausendorf",
"country_code" : "de"
},
"osm_type" : "way",
"osm_id" : "47403498",
"licence" : "Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright",
"lat" : "53.746077"
} | wusel@ponder:~$ wget -q -O - 'https://nominatim.openstreetmap.org/reverse.php?format=json&lat=53.7412971935348&lon=8.931297361850739&zoom=' | json_pp
{
"lat" : "53.746077",
"display_name" : "Dreihausendorf, Ihlienworth, Samtgemeinde Land Hadeln, Landkreis Cuxhaven, Niedersachsen, 21775, Deutschland",
"address" : {
"county" : "Samtgemeinde Land Hadeln",
"postcode" : "21775",
"state" : "Niedersachsen",
"country_code" : "de",
"village" : "Ihlienworth",
"country" : "Deutschland",
"road" : "Dreihausendorf"
},
"place_id" : "73803581",
"licence" : "Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright",
"lon" : "8.9266569",
"osm_type" : "way",
"osm_id" : "47403498",
"boundingbox" : [
"53.739074",
"53.7492497",
"8.9204858",
"8.931265"
]
} |
Sprich: wir sind nun in der Lage, einen eigenen »Nominatim«-Service zu betreiben und werden entsprechend demnächst die Anfrageziele auf »setup.4830.org« ändern. Für die Nutzer sollte sicht nichts ändern, abgesehen von Fehlermeldungen wie »FEHLER_ADDR, 00000 XML-error«, die dann nicht mehr auftreten sollten.
Sowas ähnliches habe ich mir schon gedacht … nur mit dem Text ist das ‘Ähnliche’ jetzt geordneter. 
Status nach einer Mütze Schlaf und einem Kafee … gegen 06:35 Uhr MESZ:
»FEHLER_ADDR, 00000 XML-error«
Ich werde heute vorerst ein Gerät umstellen, da es schon am WE Anrufe beim Haus-des-Gastes gab, dass das WLAN nicht geht. Heute ist schlechtes Wetter, da sind bestimmt wieder vieleTouristen in der Stadt.
Wo ist der Wurm?
Seit heute vormittag wird die eigene Nominatim-Instanz verwendet, bitte Bescheid geben, falls Probleme weiterbestehen.
Bescheid!
Lokalisierung des Knotens erfolgreich; bitte Daten überprüfen:
Adresse: FEHLER_ADDR, 00000 XML-error
Koordinaten: 53.627597 12.670267
Community: FFGT-Außengebiete
Das Problem waren vermutlich alte gespeicherte XML-Fragmente.
Nachdem ich die zwei TestKnoten mit ‘frischer’ Firmware ohne Datenübernahme geflasht habe, wurden sie in die richtige Schublade gesteckt.
Vielen Dank.
Jau, das ist ein FW-, kein Backend-Thema:
quoth:~# wget -q -O - 'http://setup.4830.org/geoloc.php?rgeo=me&node=e8:94:f6:90:c5:8e&lat=53.627597099032&lon=12.670267224312'
Content-Type: text/plain; charset=UTF-8
MAC: e8:94:f6:90:c5:8e
LAT: 53.627597099032
LON: 12.670267224312
ADR: Kastanienallee
CTY: Moltzow
ZIP: 17194
LOC: wrz
Sorry for that; ich gucke mir den Ablauf im Code der Firmware nochmal genauer an.
Positiv hervorzuheben ist, daß die Antworten jetzt von eigenen Services kommen, wir also auch dort unabhängiger werden. (Latent wäre jetzt noch ein Tile-Server (Grafik-Quadrate für die Karten) wünschenswert, um die Ladezeiten zu reduzieren. Kommt Zeit, … ;-))
Hi,
ich wollte einen neuen Knoten in Betrieb nehmen, und bekomme auch besagte Fehlermeldung 
Lokalisierung des Knotens erfolgreich; bitte Daten überprüfen: Adresse: FEHLER_ADDR, 00000 XML-error Koordinaten: 51.xxx 8.yyy Community: Freifunk Gütersloh (Außenbezirk)
Ein manuelles Update über die Config Gui hat auch keine Besserung gebracht. Hat noch jemand einen Tipp für mich?
Gruß
René
Bei Wartungsarbeiten (Security-Updates) hat’s den Docker-Container mit der zur Geolokalisierung benötigten Softwarekomponente zerlegt
Im Laufe des Abends wird ein Workaround eingespielt, der in einem solchen Fall auf die OpenStreetMap-Server ausweicht, ferner soll versucht werden, den Container wieder an den Start zu bringen.
Update dann hier; sorry for any inconvenience.
Hi Kai,
danke für die Info. Ich versuche es dann später noch mal.
Kein Stress. Es ist Sonntag
Gruß
René
Genau — und einer der sommerlicheren Tage 
Okay, hat etwas gedauert, die postgresql wächst beim Restart, aus welchen Gründen auch immer, quasi unendlich — naja, nicht unendlich, aber jedenfalls über die Grenzen des 295 GB-Docker-Volumes.
Aus 2,8 GB werden 65+ GB Datenbank
root@bf2cca862770:/app/nominatim# ls -lah /app/data.pbf
-rw-r--r-- 1 root root 2.8G Jun 20 05:24 /app/data.pbf
root@bf2cca862770:/app/nominatim# du -sh /var/lib/postgresql/9.3/main/*
4.0K /var/lib/postgresql/9.3/main/PG_VERSION
65G /var/lib/postgresql/9.3/main/base
728K /var/lib/postgresql/9.3/main/global
4.5M /var/lib/postgresql/9.3/main/pg_clog
12K /var/lib/postgresql/9.3/main/pg_multixact
12K /var/lib/postgresql/9.3/main/pg_notify
4.0K /var/lib/postgresql/9.3/main/pg_serial
4.0K /var/lib/postgresql/9.3/main/pg_snapshots
4.0K /var/lib/postgresql/9.3/main/pg_stat
24K /var/lib/postgresql/9.3/main/pg_stat_tmp
4.0K /var/lib/postgresql/9.3/main/pg_subtrans
4.0K /var/lib/postgresql/9.3/main/pg_tblspc
4.0K /var/lib/postgresql/9.3/main/pg_twophase
177M /var/lib/postgresql/9.3/main/pg_xlog
4.0K /var/lib/postgresql/9.3/main/postmaster.opts
4.0K /var/lib/postgresql/9.3/main/postmaster.pid
Naja, immerhin haben wir zum Glück noch etwas Plattenplatz:
root@colosses:/data/docker-stuff# lvresize -L +100G /dev/mapper/colosses--vg-data
Size of logical volume colosses-vg/data changed from 300.00 GiB (76800 extents) to 400.00 GiB (102400 extents).
Logical volume data successfully resized.
root@colosses:/data/docker-stuff# resize2fs /dev/mapper/colosses--vg-data
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mapper/colosses--vg-data is mounted on /data; on-line resizing required
old_desc_blocks = 19, new_desc_blocks = 25
The filesystem on /dev/mapper/colosses--vg-data is now 104857600 (4k) blocks long.
root@colosses:/data/docker-stuff# pvs
PV VG Fmt Attr PSize PFree
/dev/sda5 colosses-vg lvm2 a-- 931.00g 297.48g
Langer Rede Quintessenz: http://colosses.4830.org:8080/search.php?q=g%C3%BCtersloh&polygon=1&viewbox= tut wieder. Und damit sollte auch setup.4830.org wieder funktional sein.
Guten Morgen,
ein neuer Knoten wurde hinzugefügt
Liebe Grüße
René
Hallo,
wir haben jetzt auch einen Router und ebenfalls die Meldung “Adresse: FEHLER_ADDR, 00000 XML-error” bei der Lokalisierung.
Was können wir da tun?
Beste Grüße aus dem Dorf Laden Häger
Aktuell nichts, leider. Un-technische Kurzfassung: Maschine kaputt, Techniker ist informiert.
(Technische Details: Die Containervirtualisierung auf Basis von »Docker« hat sich verabschiedet — genauer gesagt ist der Teil, der für die Netzwerkanbindung sorgt – docker-proxy – spurlos verschwunden. Das Setup wird voraussichtlich am Wochenende auf traditionelle virtuelle Maschinen umgebaut, bis dahin funktioniert eine Neuregistrierung von Knoten leider nicht.)
Okay, schade.
Wenn sich was tut, wäre es schön, wenn das hier kundgetan werden könnte. Danke!
Ooops. Sorry, das Problem sollte eigentlich seit ca. 2 Wochen behoben sein (vgl. https://forum.freifunk-kreisgt.de/t/admintagebuch-dokumentation-von-admintaetigkeiten/79/220, https://blog.guetersloh.freifunk.net/?p=5285)? Falls nicht, bitte nochmal melden.
(Ja, Info hätte hier kommen können; wir arbeiten dran.)