| Summary: | location update returns "Could not download a new database" on some systems | ||
|---|---|---|---|
| Product: | Location Database | Reporter: | Peter Müller <peter.mueller> |
| Component: | libloc | Assignee: | Michael Tremer <michael.tremer> |
| Status: | CLOSED FIXED | QA Contact: | Peter Müller <peter.mueller> |
| Severity: | Major Usability | ||
| Priority: | Will affect most users | CC: | cab_77573, kairis |
| Version: | unspecified | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
|
Description
Peter Müller
2020-10-28 16:15:24 UTC
LOL what am I supposed to do with this? 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. 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. My system is in MST (Mountain Standard Time), Arizona, US [root@ipfire ~]# date Thu Oct 29 04:38:57 AM MST 2020 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 ~]# 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 :-) 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 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 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. |