Bug 12514 - location update returns "Could not download a new database" on some systems
Summary: location update returns "Could not download a new database" on some systems
Status: CLOSED FIXED
Alias: None
Product: Location Database
Classification: Unclassified
Component: libloc (show other bugs)
Version: unspecified
Hardware: unspecified Unspecified
: Will affect most users Major Usability
Assignee: Michael Tremer
QA Contact: Peter Müller
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-28 16:15 UTC by Peter Müller
Modified: 2020-12-22 10:22 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2020-10-28 16:15:24 UTC
Triggered by https://community.ipfire.org/t/location-database-does-not-update/3613.

This seems to affect several people, but at the time of writing, I am unable to reproduce this myself.
Comment 1 Michael Tremer 2020-10-28 16:16:30 UTC
LOL what am I supposed to do with this?
Comment 2 Peter Müller 2020-10-28 17:07:45 UTC
The downloader fails (on some systems only?!) to verify the database as it expects it's timestamp to be older than the timestamp published via DNS.

However, as of today, both timestamps are equal to each other:

user@machine:~$ dig +short txt _v1._db.location.ipfire.org
"Wed, 28 Oct 2020 04:27:12 GMT"

[root@maverick ~]# python3
Python 3.8.1 (default, Feb  4 2020, 07:35:44) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import location
>>> d = location.Database("/var/lib/location/database.db")
>>> d.created_at
1603859232
>>> from datetime import datetime
>>> datetime.utcfromtimestamp(d.created_at)
datetime.datetime(2020, 10, 28, 4, 27, 12)

As far as I understand https://git.ipfire.org/?p=location/libloc.git;a=blob;f=src/python/downloader.py;h=87bbb685043677f6a4a21689abd3c34aa3ce6295;hb=HEAD#l198, this is considered invalid.
Comment 3 Michael Tremer 2020-10-29 10:45:49 UTC
What timezone are those systems in? I am very sure that we are treating all timestamps in UTC and so the check should normally work.
Comment 4 paul 2020-10-29 11:48:23 UTC
My system is in MST (Mountain Standard Time), Arizona, US

[root@ipfire ~]# date
Thu Oct 29 04:38:57 AM MST 2020
Comment 5 cbrown 2020-10-29 22:03:56 UTC
Mine is US / Central CDT

[root@ipfire ~]# date; date -u
Thu Oct 29 05:03:24 PM CDT 2020
Thu Oct 29 10:03:24 PM UTC 2020
[root@ipfire ~]#
Comment 6 cbrown 2020-10-29 22:15:54 UTC
From my simple test, the db.created_at value is 5 hours less than the timestamp.  That would tend to indicate that db.created_at is in my CDT local time.
-- but like Jon, I'm no expert :-)
Comment 7 paul 2020-10-30 13:56:16 UTC
I installed (again) a fresh core 151. This time, as timezone I selected Europe/Athens instead of the usual America/Phoenix. Guess what, location update worked, I got a database 30 OCT 2020 04:27:17 GMT
Comment 8 cbrown 2020-10-30 14:14:54 UTC
Ditto Paul's experience: switched my tz to CET and the location update executed successfully; switched back to US CDT and got the failure indication
Comment 9 Peter Müller 2020-10-30 14:40:20 UTC
This is a bug in handling time zones < UTC indeed. :-/

Meanwhile, a fix made it into the libloc repository and will be released with Core Update 153:

https://git.ipfire.org/?p=location/libloc.git;a=commit;h=0c74f6b1a3bdce5ebdc2ee452b9baf3e421dd3d1
https://git.ipfire.org/?p=location/libloc.git;a=commit;h=60c1ac0307312614bd6980d30b44bb59b5a6ab6e

Thanks for your patience and testing effort.