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