8:38 a.m.
When installing Fedora 31 on a system, I noticed that anaconda defaulted
to US/Pacific for the time zone, rather than the correct US/Central.
I'm on a Google Fiber connection, and when I check Fedora's service at
https://geoip.fedoraproject.org/city I get the info for their HQ in
Mountain View. I'm pretty sure I got my proper location in the past.
What geoIP service is Fedora using for this? When I check MaxMind's
site, they give the correct info for both my IPv4 and IPv6 addresses
(which BTW the Fedora geoIP lookup doesn't have a v6 address so only
checks v4).
I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
and that DB has the correct info.
--
Chris Adams <linux(a)cmadams.net>
10:41 a.m.
On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:
When installing Fedora 31 on a system, I noticed that anaconda
defaulted
to US/Pacific for the time zone, rather than the correct US/Central.
I'm on a Google Fiber connection, and when I check Fedora's service at
https://geoip.fedoraproject.org/city I get the info for their HQ in
Mountain View. I'm pretty sure I got my proper location in the past.
What geoIP service is Fedora using for this?
AFAIK the service is run as part of
the Fedora infrastrucuture, due to
its potentially sensitive nature (every manual installation that has
network access will try to reach this API). It is not a third party provided
API.
When I check MaxMind's
site, they give the correct info for both my IPv4 and IPv6 addresses
(which BTW the Fedora geoIP lookup doesn't have a v6 address so only
checks v4).
I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
and that DB has the correct info.
IIRC the infra team mentioned some issues with
the new geoip database
being incompatible with how the service is currently implemented,
resulting in being stuck with an outdated database until this is resolved.
But I'm sure the people actually running this will know more, so CCing the Fedora
infra list.
--
Chris Adams <linux(a)cmadams.net>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:49 a.m.
On 06/12/2019 16:41, Martin Kolman wrote:
On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:
> I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
> and that DB has the correct info.
IIRC the infra team mentioned some issues with the new geoip database
being incompatible with how the service is currently implemented,
resulting in being stuck with an outdated database until this is resolved.
Sounds like it maybe doesn't have support for GeoLite2 and is using the
old MaxMind GeoLite Legacy databases which haven't been updated since
the start of this year.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
5:38 p.m.
On Fri, Dec 06, 2019 at 04:49:15PM +0000, Tom Hughes wrote:
On 06/12/2019 16:41, Martin Kolman wrote:
> On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:
>
> > I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
> > and that DB has the correct info.
>
> IIRC the infra team mentioned some issues with the new geoip database
> being incompatible with how the service is currently implemented,
> resulting in being stuck with an outdated database until this is resolved.
Sounds like it maybe doesn't have support for GeoLite2 and is using the
old MaxMind GeoLite Legacy databases which haven't been updated since
the start of this year.
Yes, that is exactly the case.
We recently looked at this to see if we could retire the service, but it
looks like it's still needed, so we need to figure out how to get cycles
to update it.
If someone wants to work on this, let us know!
kevin
11:43 a.m.
Once upon a time, Kevin Fenzi <kevin(a)scrye.com> said:
On Fri, Dec 06, 2019 at 04:49:15PM +0000, Tom Hughes wrote:
> On 06/12/2019 16:41, Martin Kolman wrote:
> > On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote:
> >
> > > I also installed the Fedora 31 GeoIP packages and ran the geoipupdate,
> > > and that DB has the correct info.
> >
> > IIRC the infra team mentioned some issues with the new geoip database
> > being incompatible with how the service is currently implemented,
> > resulting in being stuck with an outdated database until this is resolved.
>
> Sounds like it maybe doesn't have support for GeoLite2 and is using the
> old MaxMind GeoLite Legacy databases which haven't been updated since
> the start of this year.
Yes, that is exactly the case.
We recently looked at this to see if we could retire the service, but it
looks like it's still needed, so we need to figure out how to get cycles
to update it.
If someone wants to work on this, let us know!
I'm at best a hack at python (sorry, my scripting skills were honed in
the days of yore, when the Patholgoically Eclectic Rubbish Lister was
king :) ), but looking at this:
https://github.com/fedora-infra/geoip-city-wsgi
and the anaconda source code (which appears to only care about
country_code and time_zone), it seems reasonably straight forward. F31
and EPEL (if the site runs on RHEL/CentOS 7) already have the GeoIP2
python library (I had to build the perl modules myself, and haven't
gotten around to submitting them). I could take a stab, let someone
laugh at my hideous code, but then have a base to knock into shape. :)
Does anything other than anaconda use it? Only returning country_code
and time_zone would be pretty trivial if not.
Looking at IPv6... as bad as IPv4 geolocation data can be sometimes,
IPv6 is just incomplete (in MaxMind, my home LAN subnet is correct, but
the WAN subnet is located to "the US" (so useless for time zone
selection), so probably best to stick to IPv4
--
Chris Adams <linux(a)cmadams.net>
1601
days inactive
1602
days old
4 comments
4 participants
participants (4)
-
Chris Adams -
Kevin Fenzi -
Martin Kolman -
Tom Hughes