DB version number?

DB version number?

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hi,

I use the location database for OrNetStats [1]
a website that shows information about the tor network and
it's operators and relays.

[1] https://nusenu.github.io/OrNetStats/

For transparency and archive purposes I'd like to show the location database version
that has been used for the AS number and name lookups on the website.

Is there a versioning scheme of the DB? if so: How do I retrieve the version of the db file?
Or is this timestamp the best bet?

location update
libloc: loc_discover_latest_version: Could not query _v1._db.location.ipfire.org:
Downloaded new database from Sun, 26 Sep 2021 05:52:59 GMT

I'm not looking for the version of the tool itself (which is shown via
location --version ).

kind regards,
nusenu

-- 
https://nusenu.github.io

Re: DB version number?

[Gisle Vanem]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

nusenu wrote:

> Is there a versioning scheme of the DB? if so: How do I retrieve the version of the db file?
> Or is this timestamp the best bet?

Yes; no version-info AFAICS. You can use the function
'loc_discover_latest_version()' which does the same as
this command:
   dig -t txt _v1._db.location.ipfire.org

giving:
   ;; ANSWER SECTION:
   _v1._db.location.ipfire.org. 284 IN     TXT     "Mon, 27 Sep 2021 05:47:57 GMT"


> location update
> libloc: loc_discover_latest_version: Could not query _v1._db.location.ipfire.org:

Why does this fail?

-- 
--gv

Re: DB version number?

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

Hi nusenu,

> For transparency and archive purposes I'd like to show the location database version
> that has been used for the AS number and name lookups on the website. 

that's a good idea. Actually, I am missing this information on https://metrics.torproject.org/rs.html
as well - it appears as they still use an outdated location database there, but I don't know which one.

> Is there a versioning scheme of the DB? if so: How do I retrieve the version of the db file?
> Or is this timestamp the best bet? 

Yes, there is a scheme for the database _format_ (currently set to "1"), in case we need to change that
somewhere in the future. The versioning scheme for the database _contents_ is a simple timestamp, and
the output of "location version" is based on the database on your filesystem (not the most recent one
on the servers):

> $ location version
> Mon, 27 Sep 2021 05:47:57 GMT


> I'm not looking for the version of the tool itself (which is shown via location --version ). 

Yes, that is unfortunately kinda confusing... :-)

Thanks, and best regards,
Peter Müller

Re: DB version number?

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

Hi Gisle,

>> location update
>> libloc: loc_discover_latest_version: Could not query _v1._db.location.ipfire.org:
> 
> Why does this fail? 

just guessing: nusenu might have ran this command inside a Tor-ified environment, and Tor
does not support resolving TXT records, just A and AAAA.

Thanks, and best regards,
Peter Müller

Re: DB version number?

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

>> $ location version
>> Mon, 27 Sep 2021 05:47:57 GMT

Oh, I didn't know about this feature since it is not documented in the man page, but great
to see that it exists. It fits my use-case very well!

thanks,
nusenu


-- 
https://nusenu.github.io

Re: DB version number?

[nusenu]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

>>> location update
>>> libloc: loc_discover_latest_version: Could not query _v1._db.location.ipfire.org:
>>
>> Why does this fail? 
> 
> just guessing: nusenu might have ran this command inside a Tor-ified environment, and Tor
> does not support resolving TXT records, just A and AAAA.

correct :)

Re: DB version number?

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

Hi nusenu,

> Oh, I didn't know about this feature since it is not documented in the man page, but great
> to see that it exists. It fits my use-case very well!

*sigh* this is undocumented indeed. Bug #12698 (https://bugzilla.ipfire.org/show_bug.cgi?id=12698)
has been raised for fixing this.

Thanks, and best regards,
Peter Müller