From: Donny Davies <woodchip@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Mon, 4 Aug 2003 22:30:12 -0400 [thread overview]
Message-ID: <20030805023012.GB10932@breccia.escarpment> (raw)
In-Reply-To: <200308050114.29952.stuart@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 5743 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-08-05 2:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-04 23:16 [gentoo-dev] [GLEP] Web Application Installation Max Kalika
2003-08-05 0:14 ` Stuart Herbert
2003-08-05 2:30 ` Donny Davies [this message]
2003-08-05 10:12 ` Stuart Herbert
2003-08-06 4:01 ` Donny Davies
2003-08-05 3:04 ` Max Kalika
2003-08-05 10:39 ` Stuart Herbert
2003-08-05 9:34 ` Paul de Vrieze
2003-08-05 11:19 ` Stuart Herbert
2003-08-05 11:37 ` Paul de Vrieze
2003-08-05 21:00 ` Max Kalika
2003-08-05 23:43 ` Cal Evans
2003-08-06 1:54 ` Stuart Herbert
2003-08-06 2:16 ` Robin H.Johnson
2003-08-06 2:44 ` Stuart Herbert
2003-08-06 4:37 ` [gentoo-dev] [GLEP] Web Application Installation. Plotting a VHOST config tool Robin H.Johnson
2003-08-06 12:48 ` Stuart Herbert
-- strict thread matches above, loose matches on Subject: below --
2003-08-07 1:08 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
2003-08-04 17:11 Max Kalika
2003-08-04 22:16 ` Stuart Herbert
2003-08-05 9:49 ` Michael Cummings
2003-08-02 16:50 Troy Dack
2003-08-02 20:39 ` Robin H.Johnson
2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
2003-08-02 23:51 ` Stuart Herbert
2003-08-03 2:26 ` [gentoo-dev] " Max Kalika
2003-08-03 14:46 ` Stuart Herbert
2003-08-03 15:20 ` Max Kalika
2003-08-03 17:43 ` Stuart Herbert
2003-08-03 19:03 ` Max Kalika
2003-08-03 19:43 ` Stuart Herbert
2003-08-04 4:29 ` Max Kalika
2003-08-04 10:43 ` Stuart Herbert
2003-08-03 0:30 ` Austin Frank
2003-08-03 7:50 ` Tal Peer
2003-08-03 14:45 ` Don Seiler
2003-08-05 8:12 ` Troy Dack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030805023012.GB10932@breccia.escarpment \
--to=woodchip@gentoo.org \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox