[PATCH 0/4] Add the geolocation module

Martin Kolman mkolman at redhat.com
Wed Apr 10 10:52:39 UTC 2013


Brian C. Lane píše v Pá 05. 04. 2013 v 11:11 -0700:
> On Wed, Apr 03, 2013 at 05:45:57PM +0200, Martin Kolman wrote:
> > This patch-set adds the geolocation module and hooks it up to Anaconda.
> 
> I think this generally looks good, here are some general thoughts on it:
>  * We need to be able to disable this via a cmdline flag, and possibly
>    kickstart command. There will be users who just don't want it, or who
>    will be in environments where they don't want to expose themselves.
> 
>    inst.geoloc=0 maybe?
OK
> 
>  * It also needs to be disabled during image and directory installs. You
>    can check flags.imageInstall and flags.dirInstall
Good point, thanks ! I've changed it to skip both initialization &
refresh in this case.
> 
>  * I'm not sure about the whole singleton thing. I dislike globals,
>    although you do have it only setup when explicitly calling the
>    initializer.
I though about various possibilities (the thread setting the values
directly, using queues, etc), but they seemed to be worse than having a
singleton. 

Like this, other modules and spokes can just ask for the code, without
having to worry about state of the lookup or the thread overwriting the
value set by the user, etc.

BTW, I've based the design of the singleton on how the Anaconda thread
manager is implemented.

> 
>  * Instead of raising exceptions we should fall back to behaving like it
>    was turned off. This is an optional enhancement, not something that
>    is essential to the install.
I have replaced all exceptions with warnings and also converted any
exceptions that might come up from the backends to warnings.
> 
>  * Log entries shouldn't be translated.
OK
> 
>  * I think we're moving to Sphinx style docstrings. :param <name>: etc.
when I started working on the module, I looked through the other modules
in pyanaconda what docstring notation is used and most of them used the
@ notation at that time, so I used it too. Since it looks like consensus
has been reached, I'll convert the module to the sphinx docstrings. :)

> 
>  * What is the legality of using these 3rd party geoloc services? I'd
>    sure hate to have them annoyed at us for DoSing their system.
The MirrorManager should not be a problem - it is apart of the Fedora
infrastructure and the module is using only the public API that gets you
the closest mirror. It also does only a single API call per
installation, so a DOS should be quite unlikely.

This is an interim solution though, the plan is to contact the mirror
manager people once the geolocation code is merged to Anaconda, point
them to it and ask them for a dedicated location API for Anaconda.

The current MM API returns returns a list of nearest mirrors and
territory codes, but we really need just the nearest territory code.
As they already have the territory data available, this should not be
and issue. IIRC Vratislav even already talked with them about it earlier
and they were fine with it.


Regarding the Hostip provider, I've only found this:

"If you're going to be doing a lot of Geotargeting or IP Address
Lookups, please take a feed instead which will preserve both our
bandwidth and your bandwidth."
(on http://www.hostip.info/use.html)

As it is really just a single call per install and this provider is not
even on by default, I would say it should be fine.


Regarding the Google Wifi provider, I have not been able to find any
official documentation, only third party info like the article where I
found about its existence:
http://www.andygup.net/?p=600
It seems to be the API used by Firefox and Chrome to implement the HTML5
location API. But as it really isn't official documented anywhere, I
would say we should not expose it through the CLI/boot option, but leave
it here for any adventurous tester to enable it at his own risk by
modifying the source. Or should we rather remove it ?

BTW, I've yesterday found a possible open alternative to the Google wifi
location API:
http://www.openwlanmap.org/?lang=en
The project seems to be in an early state and unlike the Google API I
was not able to get my position based on the MAC addresses of the nearby
access points. But I think this should improve in time and unlike
google, they provide database dumps for download.
This would make it possible to run a WiFi location server on the Fedora
infrastructure, without leaking the location of users to third parties.

To sum it up, I would recommend:
* exposing the mirror manager and Hostip through the "geoloc" option
* not exposing the the Google wifi location through the option


> 
>  * It would be nice to have a cmdline switch to select which backend to
>    use. inst.geoloc=NAME and have it parsed down in the module so that
>    changes only need to be made in one place.
> 
>  * What's the target for this code? F19?
Yes, I think so.
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches




More information about the anaconda-patches mailing list