It seems there is an issue getting location database updates.
[root@ipfire location]# /usr/bin/location --debug update
HTTP GET Request to location.ipfire.org
URL: https://location.ipfire.org/databases/1/location.db.xz
Headers:
If-modified-since: Sat, 17 Jul 2021 05:57:01 GMT
User-agent: location/0.9.6
HTTP Response: 304
Headers:
date: Sun, 18 Jul 2021 00:08:23 GMT
etag: “4803f4-5c74b5b76eb81”
strict-transport-security: max-age=31536000; includeSubDomains; preload
connection: close Index of /databases is serving an outdated database. Trying next mirror…
Could not download a new database
[root@ipfire location]#
um, this looks like a temporary glitch somewhere, as we catches some quirks on the machine building the location database the other day. On my machine, everything looks fine by now:
[root@maverick ~]# location --debug update
Already on the latest version
[root@maverick ~]# location version
Sun, 18 Jul 2021 05:53:57 GMT
May I ask you to try it again? If this error persists, we will have to take a more closer look…
HTTP GET Request to location.ipfire.org
URL: https://location.ipfire.org/databases/1/location.db.xz
Headers:
If-modified-since: Sun, 18 Jul 2021 05:53:57 GMT
User-agent: location/0.9.6
HTTP Response: 304
Headers:
date: Sun, 18 Jul 2021 09:51:05 GMT
etag: “47e640-5c75f6ec9b54a”
strict-transport-security: max-age=31536000; includeSubDomains; preload
connection: close Index of /databases is serving an outdated database. Trying next mirror…
Could not download a new database
[root@ipfire location]#
I noticed my version was several days older than the file at https://location.ipfire.org/databases/
When I tried running location --debug update, I would get: Already on the latest version
So, I deleted /var/lib/database.db and tried updating again. That is when I started getting:
Index of /databases is serving an outdated database. Trying next mirror…
Could not download a new database
[Edit] It was probably the message: The database has been updated recently that led me to delete my /var/lib/database.db file
[Edit 2] Anyway, it was after deleting my database.db file that I started getting the Could not download a new database condition
indeed, this is reproducible: As soon as there is no database file, location update fails:
[root@maverick ~]# mv /var/lib/location/database.db .
[root@maverick ~]# location version
location: Could not open database /var/lib/location/database.db: [Errno 2] No such file or directory
[root@maverick ~]# location update
https://location.ipfire.org/databases/ is serving an outdated database. Trying next mirror...
Could not download a new database
iMac:~ jcm$ ssh -p '222' root@192.168.60.1
Last login: Sat Jul 17 14:42:33 2021 from 192.168.60.105
The date now is Sun Jul 18 11:18:27 AM CDT 2021
[root@ipfire ~]# /usr/bin/location --debug update
HTTP GET Request to location.ipfire.org
URL: https://location.ipfire.org/databases/1/location.db.xz
Headers:
If-modified-since: Sun, 18 Jul 2021 05:53:57 GMT
User-agent: location/0.9.6
HTTP Response: 304
Headers:
date: Sun, 18 Jul 2021 16:18:37 GMT
etag: "47e640-5c75f6ec9b54a"
strict-transport-security: max-age=31536000; includeSubDomains; preload
connection: close
https://location.ipfire.org/databases/ is serving an outdated database. Trying next mirror...
Could not download a new database
[root@ipfire ~]#
[root@ipfire ~]# location version
Mon, 12 Jul 2021 05:58:18 GMT
The reason I deleted /var/lib/location/database.db was because the normal location update stopped working several days ago. I noticed location version was reporting a version several days older than the latest version at: https://location.ipfire.org/databases/1/location.db.xz.
Attempts to get the latest version via: location update --cron=daily failed to fetch a newer version.
This reminded me of an issue we had in the past where the update process was failing for us poor unfortunates in timezones west of UTC. I’m in US Central Time.
thanks for the confirmations. So this is not a timezone-related problem, but rather looks like we enumerate the current timestamp of the location database we have at hand, and assume some bogus value if there is no database.
Looks like we never really assumed bootstrapping would be necessary at this level…
While I have not yet found some spare time to investigate into #12662 - thanks for raising it, again - please just leave the location databases on your file systems as they are.
