Re: [gentoo-dev] [GLEP] Web Application Installation

[Stuart Herbert]

On Sunday 03 August 2003 8:03 pm, Max Kalika wrote:
> Chugga chugga chugga! :-)

Lots of laughter.

> You're absolutely right, and in fact this is what the eclass does right now
> (as shown by the example I posted earlier).

;-)

> > Thanks for the example - it helps a great deal.  Now, how would you deal
> > with  a site needing to run two copies of horde under the one web server?
>
> Hmm.  This depends on the app.  Some apps have virtual hosting built-in
> others do not.  Those that do not, may need some sysadmin intervention,
> doing some parallel installs, symlinking, what-have-you.  I think we need
> to have a limit to how much we can do at install time and how much we can
> configure for the user out-of-the-box.  For example, we don't have any way
> of having two postfix instances installed and running on the same box with
> the ebuild, but the sysadmin can go ahead and configure the installed
> product to achieve the needed functionality.

True.  But most webapps will rely on the webserver to handle the virtual 
hosting side of things - and that's something we *can* support through 
user-space tools.

> > Yeah - but how do you handle sites (like ISPs) that need to run multiple
> > installations of the same app on the same box?  You can't have a single
> > globla configuration file for that.  Makes sense for the home user, but
> > not  for ISPs.
>
> Continuing from above, it seems best left to the systems admin in designing
> how to implement virtual hosting.  For example, horde has built-in virtual
> hosting where you specify multiple servers and the specific one gets chosen
> based on the server hostname.  Of course this isn't foolproof as things
> like SSL will break it, but in any case, this decision has to be left to
> the person installing it. It seems like the gentoo philosophy is to install
> the necessary minimum to have a running product and leave the major
> tinkering to the admin.

Quoting www.gentoo.org again, the phrase 'automatically configured' can be 
found.  Where we can do a sensible minimum, I think we should.

> Going back to the postfix example, although the
> package has support for delivering mail to LMTP through a content filter
> that will scan for spam and viruses, it doesn't do it out of the box and
> takes a bit of tinkering to get right.  I'm of the opinion that if someone
> wants to set up an ISP, they better know what they're doing and will be
> able to figure out how to virtualize the necessary packages they want to
> offer to their clients.

Problem with that is that it prevents 'emerge -u world' from being something 
that you can safely put in cron.

> Ok.  If there's a lot of language-specific work that needs to be done, then
> breaking it up into separate eclasses makes sense, otherwise, I'm worried
> about clutter. :)

Yeah, clutter is a problem - but so is ten ebuilds each with their own way of 
achieving the same piece of testing.

And on that note ... (drum roll please) ... take a look at the new 
webapp-apache.eclass file that I've just committed to CVS.  All it does (for 
now) is provide a standardised way of determine where HTDOCSDIR is, and which 
Apache version to install support for.

I admit it's a stop-gap solution; it's not enough on its own to make ebuilds 
webserver-neutral.  But at least we can move all the apache-specific crud 
into the one place, as a starter for ten.

Yeah, okay, I'm jumping ahead of the GLEP being approved perhaps, but I needed 
this to close two outstanding bugs this afternoon, so that's my justification 
<grin>.  Not exactly like I've gone and moved stuff into the proposed 
'web-???' categories yet ;-)

> Fair enough.  So something like "webapp-config <application> <webserver>" ?

I think so, yeah.  Robin's the best person to talk about this, as he had very 
firm ideas about what he wanted to implement.

> > How do you make an app install on (say) Zeus or (say) iPlanet or (say)
> > n.e.other web server if the ebuild itself is server-specific?  We're
> > boxing  ourselves in, for no good reason.
>
> No idea.  :-)

Exactly ;-)  This is the problem that I think we should be solving.

Anyway, take a look at the eclass, and let's talk about what else needs adding 
to it - and let's get it added.  

A word of warning - although the eclass is called 'webapp-apache', it's 
designed to *hide* apache-specificness as much as possible behind its 
interface.  If you add anything to the eclass, I'd appreciate it if you 
followed this design idea ;-)

Robin (if you're following this!) I think you could make mod_php inherit this 
class safely too, to reduce duplication still further.

Take care,
Stu
-- 
Stuart Herbert                                              stuart@g.o
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--