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

[Stuart Herbert]

Morning, Max,

On Monday 04 August 2003 5:29 am, Max Kalika wrote:
> I don't know if I'm being overly abrasive -- the weather is really hot, and
> I think I ate something that didn't agree with me. Please don't take
> offense at anything I say. :-)

Don't worry - I only take offense at offensive people, not offensive words.  
And I hope nothing in my replies offends you either.

As you can tell ;-) I believe that a good debate is healthy, as it improves 
everyone's understanding of situations beyond their normal experience, and 
helps to identify the common ground.  It's just a shame that so many people 
today seem to have closed, narrow minds, and find discussion more of a threat 
than of value :(

> Quoting Stuart Herbert <stuart@g.o>:
> > 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.
>
> Eh?  Elaborate please.

Apache supports virtual hosting already.  Tools such as phpBB and tikiwiki and 
phpMyAdmin (to give but three examples) don't need explicit virtual host 
support, because Apache handles that.  To run a copy of phpBB under two 
different domains hosted on the same box, you install two copies of phpBB - 
or at least simulate that situation using symlinks or whatever.

I've no experience with Horde, I confess.

> > Problem with that is that it prevents 'emerge -u world' from being
> > something  that you can safely put in cron.
>
> How is that?  Aside from the fact that no sysadmin who values his/her job
> would do this on a production system, I don't see why this would be a
> problem/impediment?

Scary as I find it, one reason why many of my clients run Debian rather than 
Gentoo on their production hardware is because they do that from a cron 
script, and trust the results.  Personally, I've always introduced staging 
platforms in environments where I've been wearing the Release Manager hat.

> Correct, which is what eclasses are for.

Agreed ;-)  And that's what I did ;-)

> Ugh!  Won't this get in the way when we actually try to implement this GLEP

Possibly.  But I really wanted to clear out some outstanding bugs from 
Bugzilla, and adding the eclass made it easy to do.

> (most of which is already done by my eclass).

Okay, here's my personal look at your eclass.  None of my comments are meant 
to be personal, or disrespectful!

1) Your eclass doesn't correctly (as I understand correct usage to be!) 
support the apache2 USE flag.  Easy enough to do - see my webapp-apache 
eclass for an example.
2) Your eclass doesn't specify the permissions that the source files should be 
installed under.  Again, easy enough to fix.
3) Your eclass doesn't provide support for running multiple copies of the same 
app on the same machine.  This is a showstopper.
4) Your eclass requires the admin to stop and start Apache as part of the 
install.  This is a showstopper.  Not every site will want to stop and start 
their web server just because they've installed a new app.  Imagine a site 
hosting hundreds of domains, and having to take them *all* offline at the 
same time just because phpBB's been upgraded (for example!).  Robin's idea of 
creating .htaccess files under the document root deals with this much more 
managably - although I think we're gonna end up using symlinks, as that'll 
make it easy to support multiple web servers.
5) I'm against users having to run 'ebuild /var/.../something.ebuild' after 
installation to then complete the install.  If you're emerging enough 
packages, it's easy to miss the notification that you need to do this.  It's 
personal preference, I guess, but I've been caught out by this in the past.
6) I *like* the idea that check_php() is in this eclass, because that check is 
specific to mod_php under Apache.  I'm gonna steal that and add it to my 
webapp-apache eclass ;-)
7) Your variable names are not generic enough for my liking ;-)  AWEB_CFG, for 
example, might be better off being WEBAPP_CFG.
8) Instead of trying to supply an all-encompasing apache-webapp_src_install(), 
relying as it does on defining global variables, I'd have supplied a number 
of individual functions to do each bit.  Say, a webapp-install-appconfig, 
webapp-install-serverconfig each taking parameters (this is off the top of my 
head here ;-)  This is a personal preference thing.
9) If I'm not mistaken, your eclass does nothing to ensure that the webapp can 
find the configuration files you've moved into /etc/webapps/$PN/.  
Personally, I'm coming to the conclusion that /etc/webapps/$PN/ isn't a good 
idea, because again it doesn't support the idea of running multiple copies of 
the same app on the same machine.
10) I'm coming to the conclusion that 'emerge -u <webapp>' shouldn't overwrite 
the older version, but should always install alongside, in a different slot, 
so that sites can easily run different versions of apps as required.  Perhaps 
this should be configurable somehow?  Your eclass doesn't make this possible.

I'm not saying that my eclass is better.  My eclass isn't trying to address 
this GLEP - it's just trying to make maintenance easier for now.  The show 
must go on.  Especially as this GLEP isn't even showing up on the GLEP list 
yet.

> The way you did it has already been tried and shot down:
>
> <http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/Attic/apache.eclass?hidea
> ttic=0>

That eclass, and the one that I added, are different in important ways.

> Double Ugh!

Lots of laughter.  I'm gonna copyright that phrase, I think ;-)

> See these please:
>
> <http://marc.theaimsgroup.com/?l=gentoo-dev&w=2&r=1&s=apache.eclass&q=b>

Okay, let's knock down those ninepins.  Here's the list of objections from the 
posts in the archive, and here's my responses:

1) Apache1/Apache2 conundrum

My eclass uses the detection technique adopted for mod_php, and no-one has 
complained about that.  If this eclass is invalid, then so's the ebuild for 
mod_php.  And I don't think it is.

2) Support for multiple DocumentRoot configurations, and also
3) Binary packages installing on machines with different DocumentRoot values

Until the GLEP is firmed up and approved, we don't have an agreed solution to 
implement.  

For now, what I've done is backwards-compatible with the situation today, 
while we wait for the GLEP to mature.  Let me say that again.  The *existing 
ebuilds* in Portage already did things this way.  I haven't introduced new 
behaviour - I've just hovered up the duplication.  And that's a worthy thing 
to do.

Please excuse me, but I don't want to put support for existing ebuilds on hold 
while we debate the GLEP.  I believe that we *have* to continue support until 
we're ready and able to switch.  Stopping maintenance activities is *not* an 
option.

4) Which user/group to use

My class uses Robin's suggestion, and assumes that Apache is running with the 
default settings of apache.apache.

5) DocumentRoot pointing to a read-only mount

As far as I'm concerned, that's like trying to do 'make bzlilo' with /boot not 
mounted, or run an 'emerge' with /usr mounted read-only.  It's the sysadmin's 
job to make sure that any necessary filesystems are mounted read/write before 
an installation is attempted.  This is not a problem unique to web 
applications.

6) "it's weak"

That's not an argument, it's an opinion ;-)  Anyway, I've taken 5-10 lines of 
broken and incorrectly duplicated code from a number of ebuilds, and moved 
them all into one place where they can be re-used and maintained for now.  
Reduced defects is a strong argument, not a weak one.

After that, the discussion is more about the Apache 1 / Apache 2 slotting than 
about web apps itself, except for continued discussion about an equivalent of 
/usr/share/webapps/ that made its way into the GLEP.

> See, this GLEP was more about where/how to install these ebuilds and not
> about their place in the tree.

Then I'd argue that the GLEP is incomplete in its scope, and needs expanding.  
Unless you think that we can create the 'web-xxx' categories without a GLEP?  
If so, then fair enough ;-)

Actually, I'd like to see a redrafting of the GLEP, with a clearly defined 
list of requirements for supporting webapps.  We're debating implementation 
issues without a clear list of requirements to address.  This is not the 
right way to go about it ;-)

> I held off including at least 10 ebuilds
> waiting for the outcome of this discussion, but now you jumped the gun.

Not really.  All I've done is moved some duplicated (and broken) code out of 
some ebuilds, and put it into one eclass, so that I could address a number of 
open bugs.  It *was* fix-a-bug weekend ;-)

I am going to be adding a webapp or two that use the new eclass, but the 
situation's no different to before the eclass existed.  The code in the 
eclass would have had to have been duplicated in the new ebuilds.

> Hopefully the transition can be painless.

Agreed that'd be nice ;-)

> Well, perhaps a question in the original GLEP should be readdressed.  I'm
> beginning to strongly agree with:
>
> [snip]
>
> Flexibility is one thing, maintainability with a limited developer time is
> quite another.  The balance between the two is critical.

That's why you get the framework - the eclasses - in place to handle all of 
this.  If it's done right, then maintaining individual packages becomes 
*easier*, and takes *less* time.

Think about it.  Think about having to manually install a package under a 
different web server (a manual process, and therefore error-prone) to 
investigate a bug posted to Bugzilla.  Once you've had to do this a few 
times, it would already have been quicker to code up and test the eclasses 
and tools that we need.

If we *don't* do this, I reckon that the bugs about webapps running under 
Apache'll get addressed, and many of the other bugs won't - because it's too 
much effort.

I agree that most people will just the webapps under Apache, and never care 
about other web servers.  But either we just support webapps under Apache, or 
we do it properly, I'd argue.  And I reckon that doing it properly is 
actually very easy to do.

> I did.  It looks like a trimmed version of the original proposed by Ned
> Ludd.

I'll go back and re-read the posts then.

> But you completely ignored all my work and the GLEP which we're discussing.

See above.  My eclass isn't attempting to solve the GLEP.  It's there to help 
with existing packages for now, until the GLEP moves forward.

> My eclass follows your proposed philosophy, but you basically threw it out
> the window.  I'm confused.

> How is mod_php related to the way applications are installed?

Erm, how about the whole 'do I use Apache 1 or Apache 2' conumdrum?  See the 
mod_php ebuild for details.

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
--