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

[Donny Davies]

On Tue, Aug 05, 2003 at 01:14:26AM +0100, Stuart Herbert wrote:
[...]
>On Tuesday 05 August 2003 12:16 am, Max Kalika wrote:
[...]
>> Ok, this is debatable, but I'm willing to change the eclass to take
>> -apache2 into effect.
>
>[OT, but interesting] How is this debatable?

I think it's clear distinct support for both Apache-1.x and Apache-2.x
is needed as the software is just so pervasively deployed on so many
different sites and configurations.  I think we can support both.

>> Here's the problem.  First of all, SLOTing won't help that because it
>> assumes that the versions of the packages *and* the files you are
>> installing are _different_. I.e. db4 and db3 are SLOTted: they install
>> libdb-4.so and libdb-3.so respectively and thus can run simultaneously.
>
>I must be missing something.  Why won't SLOTing help?  The behaviour you've
>described is *exactly* the behaviour that I want.  Why can't phpBB-2.0.4 and
>phpBB-2.0.5 run at the same time on the same box, but under different virtual
>domains?

SLOT was certainly forseen to be destined primarily for use in the ebuilds
of shared libraries although it's now used in many different places
including the Apache ebuilds.  SLOTing webapps sounds great to me.

>> Now, wrt to the whole virtual server thing.  Personally if I was running a
>> server with, as you say, a non-trivial number of virtual domains who have
>> different needs, I probably wouldn't use a package management system to
>> begin with, or truly virtualize everything and use something like
>> user-mode-linux in which case we're back to single-domain installs.
>
>UML is one solution, but the overhead is not insignificant.
>
>If the package management system provided a viable solution, don't you think
>that people would use it?

Sure they will.  The #1 reason it seems to me people would change --datadir
and/or DocumentRoot from their defaults isnt because you really want
them to be floating around, is it?  I'd say it's because /home/httpd
simply doesn't work for them.

This discussion has come a fair ways now, and proposes some very cool
or should I say "strong" ideas for solving a much richer variety of
problems and scenarios.  You'll recall I asked for what other highly
desirable features developers wanted to see supported were.  I'm pleased
to see the discussion of the *-config toolset approach, I foresaw
multiple instances and mass virtual hosting as eventually going to
be discussed.

>
>> Going along with your example, how can you do an 'emerge -u phpBB' _for a
>> particular domain_?
>
>Like this.
>
>a) emerge -u 'webapp' installs the master copy of 'webapp' in /usr/webapps.
>If the webapp is SLOT'ed, none of the domains are upgraded at this point.
>b) Then, run 'webapp-config --upgrade <webapp> /path/to/domain/directories' to
>upgrade the specific domain.
>
>Two stage process.  Finally, once all domains are upgraded, you can simply do
>an 'emerge -C webapp-old-version' to remove the old SLOT'ed version that is
>no longer required.
>
>What's wrong with this as a solution?
>
>> You're telling portage to maintain a package, and
>> upgrade parts of it randomly.
>
>Nope.  I'm telling Portage to maintain the master copy of a package, and to
>upgrade that master copy only.

It looks to me as if he's exactly answered the question.  The *-config
toolset is if you ask me, a perfectly natural progression here.  Pretty
slick for webapps, which if this work continues to persist in the
direction of solving easily for everybody, would be maybe the
best out-of-the-box setup I've seen anyway.

[...]

>> The most robust solution would be to create a new group (web?) and make all
>> the webserver users be a part of that group and make these directory
>> group-owned by said group.  (Similar to the "mail" group for many
>> mail-related services)
>
>Why is that robust?
>
>> Which takes me back to
>> wanting to support a single instance install of an app that an admin has to
>> copy in place if the default location is unacceptable.
>
>It's one solution, sure.  I think we can do better, and I'm willing to write
>the code to do it if necessary.
>
>> > * /usr/webapps/<app-name> as the main directory.
>> > * /usr/webapps/<app-name>/public_html/ for files served by the web server
>> > * /usr/webapps/<app-name>/cgi-bin/ for CGI-BIN files
>> > * /etc/webapps/<app-name>/ to hold the box-default config files
>> > * <app-name> is ${PN} for non-slotted packages
>> > * <app-name> is ${P} for slotted packages
>>
>> I'd say <app-name> should just be ${PF} for both and not worry about what
>> is SLOTed and what is not -- it works itself out.
>
>(thinks about this)  I'd want to test it to be sure, but I think ${PF} would
>work out okay.  Depends whether having the -rX part of the package name is
>really important or not.
>
>> Otherwise, this seems ok to me and is easy to implement in the eclass.
>
>Good-o.  So the two of us (ominously quiet in here ;-) are in agreement then?
>Oh, thought it was too good to be true ;-)
>
>>  The only thing I would
>> change is the names public_html and cgi-bin.  There may be no html and not
>> binary files in them (respectively).  How's about 'public' and 'cgi'?  (I
>> know, I know, nitpicking).
>
>Shrugs.  I just picked 'public_html' because it's a recognised convention
>(although not the only one I'm sure).  'public' is too generic for my liking.
>'cgi-bin' *is* a recognised convention, and one we shouldn't break.

Please, public_html and cgi-bin are very fine suggestions I think.

[...]

Cool developments here, I'm of course following and enjoying; Good Work.

Donny