Hi Peter,

Pleased you were able to find the problem and thank you for your explanation.

I can confirm that the database is now updating as expected.

#location version Fri, 02 Dec 2022 15:17:42 GMT

Rob

On Fri, 2 Dec 2022 18:06:36 +0100, Peter Müller wrote:

Hello Rob,

thanks for reporting this.

This problem was caused by a glitch in the location-importer, a component that is part of libloc and generates a new location database daily (in the early morning, UTC-speaking). The root cause of this glitch is that location-importer would not properly detect gzipped data if no matching MIME header was sent by the database server.

RIPE, apparently, changed their database server infrastructure recently, and now only returns application/octet-stream for gzipped data. While generating the location database, this lead to RIPE data being omitted completely - which then caused sanity checks to fail, since we expect some data points served by RIPE to be present in a defined way.

Michael fixed this in [1], but thanks to the load situation, some chaos the ongoing IPFire 3 "hackathon" caused, and a change we had to undergo in our infrastructure backend, it took us until today to be able to generate proper location databases again.

The latest one was just generated and published shortly before you wrote your e-mail, on Fri, 02 Dec 2022 15:17:42 GMT [2]. You should now observe any and all IPFire installations to fetch this database once, and then behave like they usual do - one update attempt per day.

Apologies for the hassle, and thanks for reaching out, Peter Müller

[1] https://git.ipfire.org/?p=location/

libloc.git;a=commit;h=c39b3b92b0c557fba49a01ec63879189f3db2da1

[2] https://git.ipfire.org/?p=location/location-

database.git;a=commit;h=d2d268a1fb754973a77a9f0c3be03054151edaaf

...

Since the beginning of this month the update-location-database script runs hourly and isn't waiting for the expected next 7 day interval.

I am not getting the expected "The database has been updated recently" message in /var/log/messages since Dec 1 05:06:32

On my development box IPFire 2.27 (x86_64) - Core-Update 170 . . Nov 30 22:38:14 ipfire-dev2 The database has been updated recently Nov 30 23:33:19 ipfire-dev2 The database has been updated recently Dec 1 00:24:50 ipfire-dev2 The database has been updated recently Dec 1 01:30:08 ipfire-dev2 The database has been updated recently Dec 1 02:14:32 ipfire-dev2 The database has been updated recently Dec 1 03:52:51 ipfire-dev2 The database has been updated recently Dec 1 04:09:29 ipfire-dev2 The database has been updated recently Dec 1 05:06:32 ipfire-dev2 The database has been updated recently

and also on my production box IPFire 2.27 (x86_64) - Core Update 168 . . Nov 30 22:45:58 griffith6 The database has been updated recently Nov 30 23:22:58 griffith6 The database has been updated recently Dec 1 00:53:45 griffith6 The database has been updated recently Dec 1 01:53:41 griffith6 The database has been updated recently Dec 1 02:45:16 griffith6 The database has been updated recently Dec 1 03:20:54 griffith6 The database has been updated recently Dec 1 04:34:41 griffith6 The database has been updated recently Dec 1 05:48:56 griffith6 The database has been updated recently Dec 1 06:28:10 griffith6 The database has been updated recently

There doesn't seem to affect performance other than the location ipsets are being updated every hour.

location version is being set to the last update time: # location version Fri, 02 Dec 2022 15:17:42 GMT

Could this be caused by the leading blank space in the day column after the month change from November to December ?

Rob