See community thread https://community.ipfire.org/t/location-is-serving-an-outdated-database/5007 from post 14 onwards. People have found that database is not being updated. I have confirmed similar messages on my production machine. location --version gives location 0.9.13 location version gives Fri, 08 Jul 2022 06:17:04 GMT So my last successful update was on 8th Jul, 4 days ago. location --debug update gives HTTP GET Request to location.ipfire.org URL: https://location.ipfire.org/databases/1/location.db.xz Headers: If-modified-since: Tue, 12 Jul 2022 06:14:45 GMT User-agent: location/0.9.13 HTTP Response: 304 Headers: date: Tue, 12 Jul 2022 11:36:12 GMT last-modified: Mon, 11 Jul 2022 06:08:38 GMT etag: "4e5b08-5e381620e757d" accept-ranges: bytes x-content-type-options: nosniff x-frame-options: deny referrer-policy: strict-origin x-xss-protection: 1; mode=block 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 Similar problem occurred earlier in the above community thread in Nov 2021. Not sure if current issue is similar or from a different root cause.
I cannot find any problem here. The database seems to have been generated, and Kerberos authentication works when I manually test it. The script takes a long time to run, so I cannot simulate the entire process right now. Looks like we need to add a check that when the database could not be uploaded, we won't update the DNS record and/or push any changes to the Git repository. However, I don't know what we should do instead? Sending silly emails?
Wait, maybe I have been looking for something else. The database looks like it is up to date: > root@fs01:/pub/mirror/location/databases# ll 1 > total 36 > drwxr-xr-x 2 pakfire people 36864 Jul 13 05:42 archive > lrwxrwxrwx 1 pakfire people 33 Jul 13 05:42 location.db.xz -> archive/location-2022-07-13.db.xz And you are saying the DNS record is up to date, too. What is broken then?
> root@michael:~# location update > Downloaded new database from Wed, 13 Jul 2022 05:39:53 GMT Working fine here - I believe.
Yesterday I had the database version on my system being from Friday 8th July. Running location update always came back saying https://location.ipfire.org/databases/ is serving an outdated database. Trying next mirror... Could not download a new database At least two other people reported the same problem. I also tried it with my vm testbed machines and had the same problem. One of them had the location database with a date of 29th June but still gacve the above error message. Just now, after reading your input in the bug, I tried again with my production ipfire and now the update worked and I got the message Opening downloaded database at /var/lib/location/tmpcdjx1s4_ Downloaded new database from Wed, 13 Jul 2022 05:39:53 GMT and location version now gives that date and not longer Friday 8th July. Not sure what happened between yesterday and today but now it is working again for me. On my production system, the update failed to work since Friday 8th July and looking in the location databases archive there were databases every day. Not sure if we can fault find this anymore. Is the output from the location update command sent to any logs? I did do a quick search with a grep for location in messages but nothing showed up.
The database was created and you are able to get it via browser (tested). At the same time where you can get it via browser IPFIRE reports an error. Now I got it via IPFIRE, too. Maybe a timing problem?
The root cause of this was the fileserver kernel panicking on July 11: https://lists.ipfire.org/pipermail/development/2022-July/013880.html Due to this, the updated database could not be uploaded to the webserver (but the DNS record was updated), so the libloc downloader refused to process any older database. See https://community.ipfire.org/t/location-is-serving-an-outdated-database/5007/20 for a bit more lengthy elaboration.