2012-02-14 - Re: [GRASE-Hotspot] Ubuntu/Debian compatibility

Header Data

From: Tim White <ti***8@gmail.com>
Message Hash: ea7d95d20dc012618d14e4a1da2c01b080b6fa28aabedbc690e4a6991710d510
Message ID: <4F3B1F3A.7010707@gmail.com>
Reply To: <201202150223.07812.solbu@solbu.net>
UTC Datetime: 2012-02-14 19:58:02 UTC
Raw Date: Wed, 15 Feb 2012 12:58:02 +1000

Raw message 

On 15/02/12 11:23, Johnny Solbu wrote:
> On Wednesday 15 February 2012 00:52, Tim White wrote:
>> So, please let me know what distro versions you are running it on, and
>> if you had issues getting it running (satisfying dependencies.)
> If you would start publishing the code as tarballs and not just Debian packages, the chances of it ending up into non debian based distros is bigger. (Such as Redhat, Mandriva, Mageia e.t.c.)
> Then I would at least try to get it into Mandriva and Mageia, where I am a packager. :-)=

You're free to check out the source from bzr. Its available on 
sourceforge as well as mirrored to my own servers.
The biggest issue is that I depend on features of the debian packaging 
to make the system "just work". I originally had written an installer 
script for the admin interface part, that would set that up, but given 
that I could make it all easily done in a debian package, I went down 
that path.

I assume that a similar thing could be done as a rpm, however I don't 
have the time to maintain 2 separate packaging systems.

A quick look at the postinst for the main grase-www-portal package shows 
the following:
* we use db-common stuff to install the database, giving the installer 
the ability to choose a random password or set their own (no hard coded 
passwords in the code). This also is supposed to handle updates and 
such, but most of that is handled internally now. I'll probably be 
writing this in the future to not use db-common stuff.
* We make a wget call to "cron" to get the admin interface to do it's stuff
* We ensure file permissions are set correctly (probably a better way to 
do this in the future)
* We do some house cleaning of template files, logos, favicons
* Ensure the web user can access the proxy logs

We then have the grase-conf-{apache,nginx} packages which setup the 
webserver appropriately for the web interface.

We then have all the other grase-conf packages which often override 
other packages config files. I've done this a variety of ways (i.e. 
squid we add our own file, and then tell squid to use it, but freeradius 
we "divert" the installed config file with our own). Not sure how rpm's 
can do this, but it needs to be handled nicely.

So yes, it could be packaged into rpms if you are willing to do it and 
maintain it. I'm happy to assist with explaining what is happening 
where, and try to rewrite some of it to be more generic. As I said, 
source is in bzr, and the reason I don't tarball it, is each package is 
its own repository, so it would be just as many tarballs as repository 
checkouts!

So the short, if people are willing to do the work to make rpm packages, 
and maintain them, I'll happily have them (and host them).

Tim

Thread