From: Stuart Herbert <stuart@gentoo.org>
To: Max Kalika <max@gentoo.org>, Troy Dack <tad@gentoo.org>,
gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Tue, 5 Aug 2003 01:14:26 +0100 [thread overview]
Message-ID: <200308050114.29952.stuart@gentoo.org> (raw)
In-Reply-To: <86960000.1060038977@valkyrie.lsit.ucsb.edu>
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 8557 bytes --]
'lo Max,
On Tuesday 05 August 2003 12:16 am, Max Kalika wrote:
> > a) A bit of mod_alias magic, and you make the /phpbb/ directories aliases
> > for /usr/share/webapps/phpBB-<version>/files/. If you do this, though,
> > how do you get each copy of phpBB to use a separate set of configuration
> > files? What happens when the app needs write-access to the directories?
> > The directories are on /usr, and we're all agreed that /usr should be
> > mountable read-only. And does every webserver have something like
> > mod_alias in the first place?
>
> If not mod_alias, then symlink to the DocRoot, but then we're back to not
> knowing where the user configured his/her/virtualhosts's DocRoot.
mod_alias provides aliases for URLs. Why would you need to know what DocRoot
is?
> > If I've understood your eclass correctly, this is what it tries to do,
> > yes?
>
> Yes.
Ah good.
> > b) A bit of .htaccess magic, and you have the directory structure of the
> > webapp on /var, but directives telling PHP where to find the .php files
> > by setting the include_path. The config file problem is solved, because
> > you can drop in local config files, and there are real directories that
> > can be made writable. Only problem with this approach is that not every
> > type of web server has the equivalent of .htaccess files - and the PHP
> > SAPI for each type of web server doesn't necessarily support
> > configuration directives in config files either. And that's before we
> > think about Perl, Python and other ways that webapps can be implemented.
>
> Local config files? Where would these be stored? How are these handled
> for virtual hosts?
They would be stored under the virtual DocRoot, for example (using the paths
for my example) in /var/www/www.iammax.com/public_html/phpbb/config.php.
Putting the config file into the virtual DocRoot is where Robin's tools would
come in (Robin, are you following this thread at all?). We could put a
master copy - a skeleton if you like - in /etc/webapps/<app-name>/. It's the
skeleton that gets updated by portage.
> > Because that's what USE flags are there for. If the user puts '-apache2'
> > in their USE flags, it's the job of the ebuild to respect that.
> > Otherwise, the ebuild is broken - and probably in breach of policy too.
>
> Ok, this is debatable, but I'm willing to change the eclass to take
> -apache2 into effect.
[OT, but interesting] How is this debatable?
> We can still achieve flexibility along with smaller ebuilds. If we break
> down the eclass install function into smaller functions and optionally call
> them from install, we've got ourself a nice tidy system.
Good idea - I'll sign up to that.
> 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?
> 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?
> 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.
> I simply don't think portage will ever have
> any way of handling multiple installs of a package in this manner.
Why does Portage have to do *everything*? We use portage to get the app +
dependencies onto the box, and we use additional tools to manage the virtual
domain upgrades.
> How
> about we (Gentoo) just provide single domain/host installs and maybe
> SLOTing different versions so they won't be overwritten on upgrades.
> Beyhond that, we have to let the sysadmins know to cp -l the installed
> files into their vhosts.
Because we can do better?
> AFAIK, no other distro has support for virtual hosting because of this very
> issue.
I have no idea whether other distros support virtual hosting, and if they
don't, why they don't. If you have any threads I can read on this, please
send them my way. Otherwise, your statement is an assumption, and
assumptions are the mother of all screw-ups.
> 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.
> Is the approach currently in the eclass unacceptable? (Check for the
> existance of the directory/configfile)
I think so. See how I determine which version of apache to use in
webapp-apache.eclass (as stolen/morphed from Robin's mod_php ebuild!)
> > b) you need to honour the 'apache2' USE flag
>
> Yup, see above...no higher...no, higher than that. Ok there, stop!
Lol. For now, just make your eclass rely on mine, seeing as mine's already in
Portage ;-) and re-use what's already coded. No offence, but because of the
reasons in one of my earlier emails, I don't think your eclass should go into
Portage until the outcome of this GLEP is determined.
Take care,
Stu
--
Stuart Herbert stuart@gentoo.org
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
--
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-08-05 0:16 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 [this message]
2003-08-05 2:30 ` Donny Davies
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=200308050114.29952.stuart@gentoo.org \
--to=stuart@gentoo.org \
--cc=gentoo-dev@gentoo.org \
--cc=max@gentoo.org \
--cc=tad@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