GNOME Bugzilla – Bug 706886
Setup geoip server for geoclue (geolocation)
Last modified: 2014-01-23 16:50:04 UTC
While geoclue is theoretically on fdo infra, its very much gnome project (especially since KDE doesn't make use of it). Currently geoclue uses freegeoip.net but that has usage restrictions that are not feasible for gnome. We better have our own geoip server and for that we need to setup the server side of geoclue on gnome.org, preferably geolocation.gnome.org or geoip.gnome.org. I talked to Andrea Veri about this already during GUADEC (among other people) and he was fine with it and asked if you could provide a rpms for the server. Thanks to Kalev, the packages are now available in F20 repositories. Let me know if you need direct links and I'll get those for you.
All of our servers are RHEL6, so we will need a package for EPEL6. Please ping back when you have those available.
Adding Kevin Fenzi to CC. Kevin, what does Fedora use for https://geoip.fedoraproject.org/city and is it something that could be used on GNOME servers as well?
(In reply to comment #2) > Adding Kevin Fenzi to CC. > > Kevin, what does Fedora use for https://geoip.fedoraproject.org/city and is it > something that could be used on GNOME servers as well? Kalev, we don't want that one. We intend to add WiFi geolocation etc to geoclue server so we want exactly that one.
Yeah, ours is very simple: https://github.com/mdomsch/geoip-city-wsgi It's just using ip and the geoip lite city db.
(In reply to comment #1) > All of our servers are RHEL6, so we will need a package for EPEL6. > Please ping back when you have those available. That might be very difficult or even impossible as RHEL6's glib packages are ancient AFAIK. I was not informed of this requirement by Andrea at GUADEC. :(
(In reply to comment #5) > (In reply to comment #1) > > All of our servers are RHEL6, so we will need a package for EPEL6. > > Please ping back when you have those available. > > That might be very difficult or even impossible as RHEL6's glib packages are > ancient AFAIK. I was not informed of this requirement by Andrea at GUADEC. :( We'll still check if we could lower requirements of libs in the server to make this happen though. Its RHEL 6.4?
I recall speaking about this for a very fast minute at GUADEC, we didn't get deeply into details though. Which requirements this service would need in terms of RAM / CPU? and yeah, we're on RHEL 6.4 for most of the machines but can eventually request a VM at OSU OSL with Debian or Ubuntu if we need a newer glib package. This will indeed take longer :-)
(In reply to comment #7) > I recall speaking about this for a very fast minute at GUADEC, we didn't get > deeply into details though. True, pordon me. Its has been a long day that I wasn't expecting to hit this snag while being so late in the release cycle. :( > Which requirements this service would need in terms of RAM / CPU? Not much actually. Its a very simple lightweight service. I haven't done actual measurements though but for starters it can go on a low-end machine and it should work just fine. > and yeah, we're on RHEL 6.4 for most of the machines but can > eventually request a VM at OSU OSL with Debian or Ubuntu if we need a newer > glib package. This will indeed take longer :-) Oh cool. That makes me feel so much better. Although before going for that option, I was hoping if someone can do a bit of digging as to whether we really need newer glib. Both server binaries and json-glib (that we require), require a newer version of glib than the one on RHEL6. Perhaps both of them can do with the version of glib in RHEL6?
I guess that's a question for Kalev. :-)
(In reply to comment #8) > (In reply to comment #7) > > > and yeah, we're on RHEL 6.4 for most of the machines but can > > eventually request a VM at OSU OSL with Debian or Ubuntu if we need a newer > > glib package. This will indeed take longer :-) > > Oh cool. That makes me feel so much better. > > Although before going for that option, I was hoping if someone can do a bit of > digging as to whether we really need newer glib. Both server binaries and > json-glib (that we require), require a newer version of glib than the one on > RHEL6. Perhaps both of them can do with the version of glib in RHEL6? I did a bit of digging.. I first tried to build glib 2.22.5 but that would complain about some tools being too new. Then I tried to build geoclue in a RHEL 6 VM and even configure script was needing something from newer glib. :( So I'm afraid we'll have to go with the debian/ubuntu VM approach. How long would that take?
It might be entirely possible to build a new glib and make it parallel installable using software[1] collections[2]. [1] https://fedorahosted.org/SoftwareCollections [2] http://developerblog.redhat.com/2013/01/28/software-collections-on-red-hat-enterprise-linux/
build.gnome.org uses glib (from gnome-3-8, but i could easily track git master too), inside jhbuild. Running a system daemon inside jhbuild is mildly ugly...but not that different from what Software Collections does. The Software Collections approach is also OK.
Software Collections is definitely reasonable for this case, Zeeshan, does that work for you?
(In reply to comment #13) > Software Collections is definitely reasonable for this case, Zeeshan, does that > work for you? Sure thing, whatever works. :) What do I need to do?
We still need an RPM package theoretically built against the libraries we'll be installing through Software Collections on the server. Then we'll just configure Software Collections to run the daemon by grabbing the needed libraries from /opt instead of the default /usr/lib directory.
(In reply to comment #15) > We still need an RPM package theoretically built against the libraries we'll be > installing through Software Collections on the server. And by that I assume you mean EPEL package and the ones from Fedora won't do?
(In reply to comment #16) > (In reply to comment #15) > > We still need an RPM package theoretically built against the libraries we'll be > > installing through Software Collections on the server. > > And by that I assume you mean EPEL package and the ones from Fedora won't do? In which case, we probably need a bit of guidance: <zeenix> kalev: have you found any easy docs to follow to create an EPEL package? <zeenix> or i just pass '--target epel6' to rpmbuild <kalev> the process for EPEL packages should be pretty much the same as for Fedora, it would only be a different branch in the git repo <kalev> not just that, they'd need to be built against the RHEL libraries <zeenix> http://fedoraproject.org/wiki/EPEL/FAQ <kalev> if you just pass --target epel6 or something to rpmbuild in your Fedora installation, it won't do much good -- just redefines this one macro, but the package would still be built against the libraries in your Fedora system <kalev> it would have to be built in an RHEL chroot to make sure it picks up the RHEL libs <kalev> to make that easy there's the "mock" tool that sets up the chroot <kalev> it's the standard thing for preparing a clean environment to build in, koji uses mock as well <kalev> but I've no idea how the Software Collections fit in there <kalev> the hard thing is the dependencies, building for EPEL is otherwise easy <kalev> if the dependencies were all there, you'd just: <kalev> 1) request a new branch for the package <kalev> 2) git checkout the new epel6 branch <kalev> 3) fedpkg build
You can make use of 'mockchain', a python script which now lives into the mock package itself. What it does is combining mock builds with createrepo for the packages you've just finished building. That way you can make custom builds of the dependencies you need and have them pulled when building the relevant RPM package.
The GNOME Infrastructure Team is currently migrating its bug / issue tracker away from Bugzilla to Request Tracker and therefore all the currently open bugs have been closed and marked as OBSOLETE. The following move will also act as a cleanup for very old and ancient tickets that were still living on Bugzilla. If your issue still hasn't been fixed as of today please report it again on the relevant RT queue. More details about the available queues you can report the bug against can be found at https://wiki.gnome.org/Sysadmin/RequestTracker. Thanks for your patience, the GNOME Infrastructure Team
Same here.
FYI this has been moved to RT here: https://rt.gnome.org/Ticket/Display.html?id=14111