After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 706886 - Setup geoip server for geoclue (geolocation)
Setup geoip server for geoclue (geolocation)
Status: VERIFIED OBSOLETE
Product: sysadmin
Classification: Infrastructure
Component: Other
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
Depends on:
Blocks:
 
 
Reported: 2013-08-27 13:05 UTC by Zeeshan Ali
Modified: 2014-01-23 16:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Zeeshan Ali 2013-08-27 13:05:43 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.
Comment 1 Patrick Uiterwijk 2013-08-27 13:08:58 UTC
All of our servers are RHEL6, so we will need a package for EPEL6.
Please ping back when you have those available.
Comment 2 Kalev Lember 2013-08-27 13:11:21 UTC
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?
Comment 3 Zeeshan Ali 2013-08-27 13:36:19 UTC
(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.
Comment 4 Kevin Fenzi 2013-08-27 15:36:01 UTC
Yeah, ours is very simple: 

https://github.com/mdomsch/geoip-city-wsgi

It's just using ip and the geoip lite city db.
Comment 5 Zeeshan Ali 2013-08-28 15:42:14 UTC
(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. :(
Comment 6 Zeeshan Ali 2013-08-28 15:57:36 UTC
(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?
Comment 7 Andrea Veri 2013-08-28 20:18:36 UTC
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 :-)
Comment 8 Zeeshan Ali 2013-08-28 20:35:15 UTC
(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?
Comment 9 Andrea Veri 2013-08-28 20:42:00 UTC
I guess that's a question for Kalev. :-)
Comment 10 Zeeshan Ali 2013-09-07 02:58:16 UTC
(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?
Comment 11 Jeff Schroeder 2013-09-07 03:52:30 UTC
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/
Comment 12 Colin Walters 2013-09-07 07:26:33 UTC
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.
Comment 13 Andrea Veri 2013-09-07 13:18:38 UTC
Software Collections is definitely reasonable for this case, Zeeshan, does that work for you?
Comment 14 Zeeshan Ali 2013-09-08 15:45:51 UTC
(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?
Comment 15 Andrea Veri 2013-09-09 14:47:49 UTC
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.
Comment 16 Zeeshan Ali 2013-09-09 15:53:46 UTC
(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?
Comment 17 Zeeshan Ali 2013-09-09 16:27:48 UTC
(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
Comment 18 Andrea Veri 2013-09-16 14:40:11 UTC
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.
Comment 19 Andrea Veri 2013-11-21 14:56:54 UTC
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
Comment 20 Zeeshan Ali 2013-11-21 15:16:13 UTC
Same here.
Comment 21 Andrés G. Aragoneses (IRC: knocte) 2014-01-23 16:50:04 UTC
FYI this has been moved to RT here: https://rt.gnome.org/Ticket/Display.html?id=14111