Location is serving an outdated database

Hi.

I get this:

[root@bs ~]# location version
Sat, 20 Mar 2021 05:06:06 GMT
[root@bs ~]# location update
https://location.ipfire.org/databases/ is serving an outdated database. Trying next mirror...
Could not download a new database
[root@bs ~]#

Someone else ?.

Greetings.

4 Likes

Hi,

thank you for capturing that - I can confirm something is wrong here:

[root@firewall ~]# location version
Thu, 25 Mar 2021 05:05:40 GMT
[root@maverick ~]# location update
https://location.ipfire.org/databases/ is serving an outdated database. Trying next mirror...
Could not download a new database
[root@maverick ~]# 

Zut alors. :expressionless: Will report back.

EDIT: Our location01 node is indeed experiencing trouble while trying to mount the filesystems required for an update of the location database. Working on a fix…

EDIT #2: It was DNS. Waiting for negative TTL to expire so location01 will find fs01's SSHFP records again…

Thanks, and best regards,
Peter MĂĽller

3 Likes

Hi all,

I have been waiting some time to update to core 155 and today, after the update, I immediately wanted to test the update of the location database. The old one was created back in November 2020.

But this is what I got:

[root@ipfire ~]# cd /var/lib/location ; ls -la ; date -u ; location --debug update
total 43868
drwxr-xr-x  2 root root     4096 Mar 28 19:44 .
drwxr-xr-x 15 root root     4096 Mar 28 19:01 ..
-r--r--r--  1 root root 44906418 Nov 20 06:15 database.db
-rw-r--r--  1 root root      374 Mar 28 15:45 signing-key.pem
Sun Mar 28 05:49:51 PM UTC 2021
HTTP GET Request to location.ipfire.org
	URL: https://location.ipfire.org/databases/1/location.db.xz
	Headers:
		If-modified-since: Sun, 28 Mar 2021 05:07:04 GMT
		User-agent: location/0.9.5
HTTP Response: 304
	Headers:
		date: Sun, 28 Mar 2021 17:49:52 GMT
		etag: "43fd8c-5be5564591cb8"
		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 location]#

I was, however, able to download the new database with wget, unxz it und do a location verify.
I’m missing some sort of switch to reset everything and perform an initial download of the database and signing-key.pem.

Thanks.

[EDIT:] The date of the pem file got updated today after I tried to remove and move back the file in order to provoke an “initial situation”.

Hello all,
Updated to 155 a couple of days ago.
Just checked the Location version:

[root@****** ~]# location version
Thu, 25 Mar 2021 05:05:40 GMT

which seems OK. But then tried a location update and got this:

[root@****** ~ ]# location update
libloc: loc_discover_latest_version: Could not query _v1._db.location.ipfire.org:
Traceback (most recent call last):
File “/usr/lib/python3.8/urllib/request.py”, line 1350, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
File “/usr/lib/python3.8/http/client.py”, line 1255, in request
self._send_request(method, url, body, headers, encode_chunked)
File “/usr/lib/python3.8/http/client.py”, line 1301, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File “/usr/lib/python3.8/http/client.py”, line 1250, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File “/usr/lib/python3.8/http/client.py”, line 1010, in _send_output
self.send(msg)
File “/usr/lib/python3.8/http/client.py”, line 950, in send
self.connect()
File “/usr/lib/python3.8/http/client.py”, line 1417, in connect
super().connect()
File “/usr/lib/python3.8/http/client.py”, line 921, in connect
self.sock = self._create_connection(
File “/usr/lib/python3.8/socket.py”, line 787, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
File “/usr/lib/python3.8/socket.py”, line 918, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/bin/location”, line 608, in
main()
File “/usr/bin/location”, line 606, in main
c.run()
File “/usr/bin/location”, line 222, in run
ret = args.func(db, args)
File “/usr/bin/location”, line 436, in handle_update
t = d.download(public_key=ns.public_key, timestamp=t, tmpdir=tmpdir)
File “/usr/lib/python3.8/site-packages/location/downloader.py”, line 134, in download
with self._send_request(req) as res:
File “/usr/lib/python3.8/site-packages/location/downloader.py”, line 97, in _send_request
res = urllib.request.urlopen(req, **kwargs)
File “/usr/lib/python3.8/urllib/request.py”, line 222, in urlopen
return opener.open(url, data, timeout)
File “/usr/lib/python3.8/urllib/request.py”, line 525, in open
response = self._open(req, data)
File “/usr/lib/python3.8/urllib/request.py”, line 542, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
File “/usr/lib/python3.8/urllib/request.py”, line 502, in _call_chain
result = func(*args)
File “/usr/lib/python3.8/urllib/request.py”, line 1393, in https_open
return self.do_open(http.client.HTTPSConnection, req,
File “/usr/lib/python3.8/urllib/request.py”, line 1353, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [Errno -2] Name or service not known>

which made me worry a little. Then tried also “cd /var/lib/location ; ls -la ; date -u ; location --debug update”:

[root@*****]# cd /var/lib/location ; ls -la ; date -u ; location --debug update
total 46872
drwxr-xr-x 2 root root 4096 Mar 29 12:12 .
drwxr-xr-x 11 root root 4096 Mar 29 12:01 …
-r–r–r-- 1 root root 47982308 Mar 29 11:53 database.db
-rw-r–r-- 1 root root 374 Feb 22 23:45 signing-key.pem
-rw------- 1 root root 0 Mar 27 06:53 tmp36d2_v9g
-rw------- 1 root root 0 Mar 29 11:45 tmpbxrefeb6
Mon Mar 29 10:19:08 AM UTC 2021
libloc: loc_discover_latest_version: Could not query _v1._db.location.ipfire.org:
HTTP GET Request to location.ipfire.org
URL: https://location.ipfire.org/databases/1/location.db.xz
Headers:
User-agent: location/0.9.5
HTTP Response: 200
Headers:
date: Mon, 29 Mar 2021 10:19:18 GMT
last-modified: Thu, 25 Mar 2021 05:07:28 GMT
etag: “43fd8c-5be5564591cb8”
accept-ranges: bytes
content-length: 4455820
x-content-type-options: nosniff
x-frame-options: deny
referrer-policy: strict-origin
x-xss-protection: 1; mode=block
content-type: application/x-xz
strict-transport-security: max-age=31536000; includeSubDomains; preload
connection: close
Opening downloaded database at /var/lib/location/tmp34c5_cps
Downloaded new database from Thu, 25 Mar 2021 05:05:40 GMT

and then an update again:

[root@****** location]# location --debug update
HTTP GET Request to location.ipfire.org
URL: https://location.ipfire.org/databases/1/location.db.xz
Headers:
If-modified-since: Mon, 29 Mar 2021 05:06:06 GMT
User-agent: location/0.9.5
HTTP Response: 304
Headers:
date: Mon, 29 Mar 2021 10:20:16 GMT
etag: “43fd8c-5be5564591cb8”
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

Not sure what to make of that expect that there may by some amount/connection issues?
Just posted in case the first update error I got may give som clues.

Version and verify queries looks OK now:

[root@***** location]# location --debug version
Thu, 25 Mar 2021 05:05:40 GMT
[root@***** location]# location --debug verify
Database successfully verified

Best regards
Willy Sejr

1 Like

@roberto

I’ve tried several times since your posting, without success.

But the last time few minutes ago i give it another go.

location update works for me again.

location version

Mon, 29 Mar 2021 18:13:02 GMT

Thank you @pmueller

Yes, you are right. Now works Ok.

[root@bs ~]# location update
Downloaded new database from Tue, 30 Mar 2021 05:04:14 GMT
[root@bs ~]# location version
Tue, 30 Mar 2021 05:04:14 GMT
[root@bs ~]#

Regards.

Hi,

first: Thanks again for noticing this.

Second, as already mentioned, the location database is now being properly compiled again every night. A typetransparent DNS configuration on our primary firewall caused SSHFP records of our file server not to resolve anymore, and since we do not rely on TOFU when it comes to SSH, the location update script stopped working.

This should not happen again, as the DNS configuration was a temporary solution back when we had to rebuild our entire infrastructure, and needed to connect to our file server without having a nameserver in place. Chicken-and-egg-problem, so to say. :slight_smile:

Thanks, and best regards,
Peter MĂĽller

5 Likes

This issue seems to have resurfaced …

[root@ipfire ~]# location update
Index of /databases is serving an outdated database. Trying next mirror…
Could not download a new database

location version gives me Mon, 01 Nov 2021 05:58:15 GMT

1 Like

No update.

My log:

[root@bs ~]# location version
Wed, 03 Nov 2021 05:59:51 GMT
[root@bs ~]#
[root@bs ~]# location --debug update
HTTP GET Request to location.ipfire.org
        URL: https://location.ipfire.org/databases/1/location.db.xz
        Headers:
                If-modified-since: Mon, 08 Nov 2021 05:58:03 GMT
                User-agent: location/0.9.7
HTTP Response: 304
        Headers:
                date: Mon, 08 Nov 2021 15:12:24 GMT
                last-modified: Thu, 04 Nov 2021 05:47:15 GMT
                etag: "4ad568-5cff00f11946e"
                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

Regards.

@roberto

Try again, just got the 09 Nov 2021 db update.

[root@ipfire ~]# location version
Tue, 09 Nov 2021 11:03:42 GMT
[root@ipfire ~]#
1 Like

Fixed it.

The databases were generated correctly, but could not be uploaded to the fileserver that is serving them to the internet.

4 Likes

Yes, now working fine.

Thanks to all.

Regards.

I have the problem since a week - nobody else?

date
Tue Jul 12 12:43:52 PM CEST 2022

location --debug update
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 10:42:59 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
Index of /databases is serving an outdated database. Trying next mirror…
Could not download a new database

1 Like

I just tested my production system and it is having the same issue.

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
2 Likes

Same here!

[root@bs ~]# location --debug update
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 16:24:14 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
[root@bs ~]#

BR

Bug raised on IPFire Bugzilla

https://bugzilla.ipfire.org/show_bug.cgi?id=12901

2 Likes

@ms looked at the bug today and was not able to find anything wrong.

Running the location update command on my system also now came up with a successful download, so whatever the problem was it seems to have been fixed. Unfortunately not the best result in terms of understanding the root cause but good that it is working for me again.

Can @roberto and @ralph please run the update command and confirm if it is now also working for them.

3 Likes

got it. Now it works.

Hi all,

thank you for flagging this issue.

Its root cause was an infrastructure hiccup we experienced on July 11. Due to this issue, a new location database was generated, and the correspondent DNS record updated accordingly, but it could not be uploaded to the file server.

Thus, the libloc updater compared the DNS request content with the latest database version available from the HTTPS server - which was dated July 10. Therefore, updating was refused.

Since @ms resolved the infrastructure issue early on July 12, you should now all see location database updates working fine again. No manual interaction is required whatsoever, as the updater will periodically retry to fetch an up-to-date database itself.

I will update bug #12901 accordingly, and close it as being fixed.

Apologies for the inconvenience, and best regards,
Peter MĂĽller

5 Likes