public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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 --]

  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