public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-02 16:50 Troy Dack
  2003-08-02 20:39 ` Robin H.Johnson
                   ` (3 more replies)
  0 siblings, 4 replies; 38+ messages in thread
From: Troy Dack @ 2003-08-02 16:50 UTC (permalink / raw
  To: gentoo-dev; +Cc: Gentoo Core


[-- Attachment #1.1: Type: text/plain, Size: 979 bytes --]

Recently there was a thread on where web apps should be placed
(inside/outside of the htdocs tree), where their config files should be
placed and what category they should be in.

Please review the attached GLEP and comment on my attempt to formalise
and summarise this discussion.

I'll submit this GLEP on 08 AUG 03 @ 0200 UTC (1200 .au EDT) with any
additions or suggestions that I receive.

This message has been CC'd to -core for those that may not keep up with
-dev.

Please post all replies to the gentoo-dev mailing list.

Thankyou

-- 
Troy Dack           "Yes, yes, I know that, Sydney ... Everybody knows that!
tad@gentoo.org    ... But look: Four wrongs squared, minus two wrongs to 
                  the fourth power, divided by this formula, do make a
                  right." -- Gary Larson

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C
 

[-- Attachment #1.2: glep-webapps.txt --]
[-- Type: text/plain, Size: 5987 bytes --]

GLEP: xx
Title: Web Application Installation
Version: $Revision: 1.0 $
Last-Modified: $Date: 2003/08/03 00:30:0 $
Author:	Troy Dack <tad@gentoo.org>
Discussions-To: gentoo-dev@gentoo.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 02 August 2003
Post-History:


Credits
=======

Based on comments posted to gentoo-dev mailing list [#WebAppPost]_ by Stuart
Herbert <stuart@gentoo.org> and Max Kalika <max@gentoo.org>.

Definitions
===========

	*Web Application*
		an application that requires a web server to function and interacts with
		the user via a browser

	*Document Root*
		a location in the file system that forms the main document tree visible from
		the web

Conventions
===========

	When describing the location of a directory in the file system it
	wil be shown *with* a trailing, eg::

		/foo/bar/

	When describing the location of a specific file (irrespective of any
	file extention) it will shown *with out* a trailing slash, eg::

		/foo/blah

Abstract
========

To define where and how web based applications should be installed by Gentoo.

Motivation
==========

Currently there is no standard defined regarding the installation of web
based applicaitons in Gentoo.  This leads to ebuild authors creating a
variety of methods to determine:

	* where the application should be installed
	* what user and permissions the application should be given
	* where any configuration files related to the application should be
	  installed.

Due to a lack of standard install method configuration files are at
risk of being overwritten during upgrade, potentially causing system
administrators down tine as they have to reconfigure web applications
after an upgrade.

Rationale
=========

A discussion on the gentoo-dev mailing list [#WebAppPost]_ raised the
following points regarding how Gentoo handles the installation of web based
applications:

	1. Gentoo installed web applications (eg: horde, phpbb, cacti,
	   phpmysql) should not be installed in the Document Root of a web server.
	2. Web applications should not have their configuration files installed
	   under the Document Root of a web server.
	3. Web applications should not be owned by the same user as the web server.

1. Default Web Server
---------------------

A common default web server will have to be selected and ebuild authors should
ensure that their applications contain configuration directives suitable for
that server.  Given the popularity of the Apache web server it is suggested that
Apache be selected as the Gentoo default web server.

Whilst it is acknowledged that other web servers do exist and are used, there
has to be an assumption made somewhere that people who choose to use something
other than a default have enough knowledge to adapt configurations accordingly.

2. Application Location
-----------------------

The current accepted standard Document Root in Gentoo is /home/httpd.  The
discussion suggest that this is not the best location to install web based
applications.

A suggested alternative installation location for web applications, outside of 
the Document:

	* for files to be served to clients::

		/usr/share/webapps/<application>/files/

	* for documentation files (not served to clients)::

		/usr/share/doc/webapps/<application>/

3. Application Configuration
----------------------------

Having application configuration files in the Document Root of a web
server is a potential security risk.  Additionally given the way that many
ebuilds currently install web applications it can also lead to the
overwriting of important configuration files.

A suggested alternative is:

	* install configuration files in::

		/etc/webapps/<application>/
		
	* Apache configuration directives:
	
		- install a sample file in::

			/usr/share/doc/webapps/<application>/conf/

		  the ebuild should inform the user how to include this 
		  information in their Apache configuration.

	  	- alternatively the configuration directives could be placed in::

			/etc/apache{1,2}/conf/webapps/<application>

		  this directory and the files in it should be included by the
		  main Apache configuration file.

By installing application configuration files in /etc Portage CONFIG_PROTECT
features can be used to ensure that configuration files are not overwritten.

4. Application Permissions
--------------------------

Installing web applications and giving the web server ownership of the files
is a security risk.  This can possibly lead to application configuration files 
being accessed by unwanted third parties.

All web applications should be owned by *root* unless the application absolutely
requires write access to its installation directories at execution time.

Implementation
==============

Max Kalika <max@gentoo.org> stated that he has a preliminary eclass that
implements a good deal of this GLEP.

Acceptance of the eclass into the portage tree will enable ebuild authors and
maintainers to transition the web applications to the new installation method
and locations.

Backwards Compatibility
=======================

There may be some issues regarding compatibility with existing installs of
web applications.  This is particularly true if the default Document Root is
moved from what is accepted as the current standard (/home/httpd).

The main issues are:
	* transition of existing configuration files to the 
	  /etc/webapps/<application>/ directory.
	* modification/reconfiguration of applications so that they
	  are aware of the location of configuration files.
	* creating approriate Apache configuration snippets for inclusion
	  in the Apache configuration files.

References
==========

.. [#WebAppPost] http://article.gmane.org/gmane.linux.gentoo.devel/10411

Copyright
=========

This document has been placed in the public domain.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
@ 2003-08-02 20:39 ` Robin H.Johnson
  2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 38+ messages in thread
From: Robin H.Johnson @ 2003-08-02 20:39 UTC (permalink / raw
  To: Troy Dack; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 5483 bytes --]

On Sun, Aug 03, 2003 at 02:50:11AM +1000, Troy Dack wrote:
> Definitions
> ===========
*Web Application Instance*
  An apparent install of the Web Application that is served up via the
  webserver. There may be any number of instances per Web Application.
  This is a major use for web applications. Our Gentoo Zope setup
  already provides instances and can be used for some concepts on this
  matter.
*Web Application Setup Program*
  A script similar in function to zope-config that sets up instances.

> Rationale
> =========
2b. Web Application must be slotted by their major version numbers to
   further avoid downtime when true configuration changes are required.
6. It should be easily possible to have multiple instances of a web
   application without any duplication of source files.
7. It should be immediately apparent how to control instances of a web
   application.

> 2. Application Location
> -----------------------
> 	* for files to be served to clients::
> 		/usr/share/webapps/<application>/files/
Why the /files/ on the end, why not just leave it out?
Also, for compatibility and ease of upgrade (stay with me on this until
later) the actual install location should have several symlinks to it,
so that instances can change their version by updating a symlink,
instead of having to re-write their .htaccess files.
As such, we have the package actually installed at with it's full
version string, and a symlink with it's major version as the SLOT value
present.
/usr/share/webapps/${PF}
/usr/share/webapps/${PN}-${SLOT}

> 	* for documentation files (not served to clients)::
> 		/usr/share/doc/webapps/<application>/
What is different about this documentation compared to any existing
package documentation in /usr/share/doc/${PF}/ ?
Care must also be taken here as many web-apps ship documentation that is
referenced from inside the application as help, so should be installed
in such a location that it is still accessible.

> 3. Application Configuration
> ----------------------------
> 	* install configuration files in::
> 		/etc/webapps/<application>/
First the initial copy of the configuration files, eg their base setup
for Gentoo should be installed to a directory (the _default name could
be changed):
/etc/webapps/${PN}-${SLOT}/_default/

As needed, the webapp setup program copies and modifies the contents of
the default settings for each instance.
/etc/webapps/${PN}-${SLOT}/${INSTANCENAME}/

> 	* Apache configuration directives:
> 		- install a sample file in::
> 			/usr/share/doc/webapps/<application>/conf/
> 		  the ebuild should inform the user how to include this 
> 		  information in their Apache configuration.
See my notes about documentation install location on this.

> 	  	- alternatively the configuration directives could be placed in::
> 			/etc/apache{1,2}/conf/webapps/<application>
> 		  this directory and the files in it should be included by the
> 		  main Apache configuration file.
The webapp setup program should create these as needed, possibly:
/etc/apache{1,2}/conf/webapps/${PN}-${SLOT}/${INSTANCENAME}.conf

> 4. Application Permissions
> --------------------------
No changes needed here at all.

5. Instances of Web Applications
--------------------------------
In a similar vein to Gentoo's Zope scripts, namely zope-config, we
should be able to have multiple instances of a single web application
without duplicating all of the files.

This also allows system administrators to control where web applications
will appear on their system, as well as to customize a file in a single
instance of a web application without effecting the original material.

webapp-config ${PN}-${SLOT} ${INSTANCENAME} \
/home/httpd/htdocs/..some-path-where-admin-wants-it.. (more options)
(or zope-config has a ncurses interface for this IIRC)

This is easily acheived thru use of Apache configuration directivies and symlinks.
For PHP instances, see http://tavi.sourceforge.net/VirtualHosts as for
some details.

The primary details here is that to the web-application, it appears that
all of it's configuration and files are in the instance directory, but
the files are physicalled located elsewhere.

> Implementation
> ==============
> Max Kalika <max@gentoo.org> stated that he has a preliminary eclass that
> implements a good deal of this GLEP.
I've also got some experience with setting up instances of web
applications already as I have needed them for work. Previously I was
doing it by hand, but I am willing to be the main author of the tools
needed.

> Backwards Compatibility
> =======================
> There may be some issues regarding compatibility with existing installs of
> web applications.  This is particularly true if the default Document Root is
> moved from what is accepted as the current standard (/home/httpd).
There will with a doubt be very little backwards compatibility between
installs, however as the old /home/httpd/htdocs/${PN} is not being
overwritten, this allows admins time to migrate.

> Credits
> =======
Robin Johnson <robbat2@gentoo.org> also make several initial comments on
the mailing lists as to web applications and instancing.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [gentoo-dev] Re: [gentoo-core] [GLEP] Web Application Installation
  2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
  2003-08-02 20:39 ` Robin H.Johnson
@ 2003-08-02 23:11 ` Max Kalika
  2003-08-02 23:51   ` Stuart Herbert
  2003-08-03  0:30 ` Austin Frank
  2003-08-05  8:12 ` Troy Dack
  3 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-02 23:11 UTC (permalink / raw
  To: Troy Dack, gentoo-dev

> ...
> Due to a lack of standard install method configuration files are at
> risk of being overwritten during upgrade, potentially causing system
> administrators down tine as they have to reconfigure web applications
> after an upgrade.

(typo) down time.  Also how about say "after each upgrade."

> 2. Application Location
> -----------------------
> ... 
> A suggested alternative installation location for web applications, 
> outside of the Document:

outside Document Root?

>	* for files to be served to clients::
>
>		/usr/share/webapps/<application>/files/

I think this should just be /usr/share/webapps/<application>/

>	* for documentation files (not served to clients)::
>
>		/usr/share/doc/webapps/<application>/

Perhaps keep things consistant and put docs in /usr/share/doc/${PF}.  This
way the current dodoc() and dohtml() utility functions can continue to be
used without extra effort on behalf of the ebuild writers.

> 3. Application Configuration
> ----------------------------
> ...
>	* Apache configuration directives:
>	
>	   - install a sample file in::
>
>			/usr/share/doc/webapps/<application>/conf/
>
>	   the ebuild should inform the user how to include this 
>	   information in their Apache configuration.
> 
>	   - alternatively the configuration directives could be placed in::
>
>			/etc/apache{1,2}/conf/webapps/<application>
>
>	   this directory and the files in it should be included by the
>	   main Apache configuration file.
>
> By installing application configuration files in /etc Portage 
> CONFIG_PROTECT features can be used to ensure that configuration files
are 
> not overwritten.

The eclass currently puts them as /etc/webapps/<application>.conf.  This
way they are parallel to the application configuration files and are also
web-server independent, all while being protected by CONFIG_PROTECT.  The
ebuild informs the user to how to activate the installed app which, when
executed,
just creates a link into the already-configured apache directory.


Some other difficulty I came across while installing various webapps that
we may want to address (perhaps not in this GLEP, but definitely sometime
down the road) are:

 - Determining what modules mod_php has built into it.  Currently, I have
   a quick and dirty function in the webapp eclass called check_php() which
   looks for a particular USE flag in /var/db/pkg/dev-php/mod_php*/USE.
   This probably needs to be a bit cleaner.
 - Certain web applications need to have write access to the directory where
   they are installed (curse them!) :-)
 - Great care must be taken to properly prepare the configuration files.
   For example, Horde config files have paths defined relative to the config
   file itself so some sed magic was used to fix a lot of it.

Otherwise I am thrilled to see all this progress.  Thank you!
Standardization should always be applauded. :-)

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] Re: [gentoo-core] [GLEP] Web Application Installation
  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
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-02 23:51 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 4962 bytes --]

First off - thank you Troy for getting this moving.  Nice one ;-)

On Sunday 03 August 2003 12:11 am, Max Kalika wrote:
> >	* for files to be served to clients::
> >
> >		/usr/share/webapps/<application>/files/
>
> I think this should just be /usr/share/webapps/<application>/

Sorry, but I very strongly disagree.  Not every web application needs all its 
files to be accessable via a web browser.

/usr/share/webapps/htdocs/ for files that should be accessable via a web 
browser.  This leaves room for any other files (PHP scripts are the one that 
comes to mind for me) to go into other sub-directories if required.

(Confession: I do have a personal interest.  I write web apps professionally, 
and none of them have the PHP files available for serving out via the web 
browser.)

> The eclass currently puts them as /etc/webapps/<application>.conf.  This
> way they are parallel to the application configuration files and are also
> web-server independent, all while being protected by CONFIG_PROTECT.  The
> ebuild informs the user to how to activate the installed app which, when
> executed,
> just creates a link into the already-configured apache directory.

I'd prefer /etc/webapps/<application>/, again for future flexibility where a 
web application has more than one configuration file.  I don't mind frigging 
apps to look in more than one place for a config file.  I do mind patching 
apps to use just the one file.

The less we have to patch an app, the less work we're going to make for 
ourselves - especially on the support side.

>  - Determining what modules mod_php has built into it.  Currently, I have
>    a quick and dirty function in the webapp eclass called check_php() which
>    looks for a particular USE flag in /var/db/pkg/dev-php/mod_php*/USE.
>    This probably needs to be a bit cleaner.

If Robin doesn't beat me to it, I'll write a script that we can add to Portage 
to standardise getting this information.

W.r.t. PHP detection, we have two other problems:

a) Depending on virtual/php is useless, because it doesn't guarantee that 
mod_php is installed (could be that PHP/CLI is installed) - unless you've 
already fixed this Robin?  Anyway, it doesn't tell you what version of PHP is 
installed - and some apps need specific versions of PHP (yes, they're broken, 
but that doesn't mean we shouldn't support them).
b) Depending on mod_php will break once PHP/CGI is added to Portage.  Again, 
maybe Robin's already put something in place to deal with this (we've 
discussed it off-list in the past).

What shape are other languages in for their dependencies?  Not every webapp is 
going to be written in PHP ...

>  - Certain web applications need to have write access to the directory
> where they are installed (curse them!) :-)

Well, write access to directories under htdocs at any rate.  TikiWiki - which 
we're looking to use for a Gentoo website - has this annoying feature.

>  - Great care must be taken to properly prepare the configuration files.
>    For example, Horde config files have paths defined relative to the
> config file itself so some sed magic was used to fix a lot of it.

You use sed, I'd apply patches, and I'm sure there's other ways too that 
people would like to use.  So long as they get the right result, I don't 
think we need to standardise on the approach.

> Standardization should always be applauded. :-)

Urgh ;-)  If everything in life was standardised, we'd be running RedHat, not 
busy upsetting the apple-cart with this upstart project ;-)

Two other things I want to chuck in, if I can.

First off, where are webapp ebuilds going to live in Portage?  I'd like to see 
a set of 'web-???' categories myself, so that web apps are clearly visible 
and easy to find.  I don't think they should disappear under 'net-www' or 
into various 'app-???' directories.

Secondly, are we going to establish a webapps herd to look after the packages 
that will be added?  If so, feel free to add me to the list of maintainers.  
If not, then what solution do you suggest?

I think the ebuilds for web apps should be ENTIRELY webserver neutral.  This 
is why I've done nothing with Max's eclass myself.  There should be userland 
tools for creating an instance of an app under Apache or whatever.  Yes, I 
know that most people will run Apache, and not care about this, but Gentoo's 
supposed to be about configurability.  We have a chance to get some solid 
foundations in - I say let's get digging.

Best regards,
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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
  2003-08-02 20:39 ` Robin H.Johnson
  2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
@ 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
  3 siblings, 2 replies; 38+ messages in thread
From: Austin Frank @ 2003-08-03  0:30 UTC (permalink / raw
  To: Troy Dack; +Cc: gentoo-dev, Gentoo Core

Max just offered to be a maintainer of the webapps herd, if one starts.  I'd
like to offer to join the herd as well, though I'm not a dev yet.  As soon
as Max sends me a version of his eclass or commits it to portage, I'm going
to do ebuilds for a few blogging suites and submit them.  I guess this is
just mostly a heads up that you've got an interested party if you do start
the webapps herd.

/au

-- 
"Your reality, sir, is lies and balderdash; and I am
 delighted to say I have no grasp of it whatsoever."
		*Baron Munchausen*
phone: (212) 853-6346	email: aufrank@columbia.edu

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-02 23:51   ` Stuart Herbert
@ 2003-08-03  2:26     ` Max Kalika
  2003-08-03 14:46       ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-03  2:26 UTC (permalink / raw
  To: stuart, Troy Dack, gentoo-dev

Quoting Stuart Herbert <stuart@gentoo.org>:

> First off - thank you Troy for getting this moving.  Nice one ;-)

+1 :-)

> I think this should just be /usr/share/webapps/<application>/
> 
> Sorry, but I very strongly disagree.  Not every web application needs all
> its  files to be accessible via a web browser.

Granted, but this means more changing in the core or config files of the
particular application.

> /usr/share/webapps/htdocs/ for files that should be accessible via a web 
> browser.  This leaves room for any other files (PHP scripts are the one
> that  comes to mind for me) to go into other sub-directories if required.
> 
> (Confession: I do have a personal interest.  I write web apps
> professionally,  and none of them have the PHP files available for
> serving out via the web  browser.)

Same here.

> I'd prefer /etc/webapps/<application>/, again for future flexibility
> where a  web application has more than one configuration file.  I don't
> mind frigging  apps to look in more than one place for a config file.  I
> do mind patching  apps to use just the one file.

You want to mix the apache config block with other configuration files that
come with the application?  Seems messy to me.  Especially if we're going
to be supporting multiple webservers (creating server-specific config
files).  Perhaps another directory where you can separate the
application-specific config files from server-specific ones.  Ideas?

> The less we have to patch an app, the less work we're going to make for 
> ourselves - especially on the support side.

Yes!  Which is why a patch is probably not always appropriate -- sed is
more resilient to pieces of configuration moving around upstream.

> If Robin doesn't beat me to it, I'll write a script that we can add to
> Portage  to standardise getting this information.

What did you have in mind to achieve this?

> W.r.t. PHP detection, we have two other problems:
> 
> a) Depending on virtual/php is useless, because it doesn't guarantee that 
> mod_php is installed (could be that PHP/CLI is installed) - unless you've 
> already fixed this Robin?  Anyway, it doesn't tell you what version of
> PHP is  installed - and some apps need specific versions of PHP (yes,

I'll leave this to you all as you seem to have hashed this out already
between you.

> What shape are other languages in for their dependencies?  Not every
> webapp is  going to be written in PHP ...

Many apps are CGIs.  Others can of course be mod_perl, mod_python, java,
you name it.  I see no problems using the eclass with these because it was
written with flexibility in mind.  Like I've said in the past.  My initial
idea for this was to fix nut and apcuspd to cleanly install their CGI
components.

> Well, write access to directories under htdocs at any rate.  TikiWiki -
> which  we're looking to use for a Gentoo website - has this annoying
> feature.

What bothers me though, is that having any directory under /usr writeable
is really bad form (I made a policy at work for all servers -- configure a
system where /usr can be mounted read-only).  If at all possible, I'd like
to have these directories created under something like /var/lib/ and
symlinked back to where the app needs to write.  If not symlinked then an
Apache alias (or whatever is equivalent to other servers). 

> You use sed, I'd apply patches, and I'm sure there's other ways too that 
> people would like to use.  So long as they get the right result, I don't 
> think we need to standardise on the approach.

See above.  But I agree, we _can't_ standardize on the approach simply
because it depends on what needs to be done.  I imagine that there will be
some apps where we would just have complete config files living in
${FILESDIR} that get installed over the ones that come with the package.
Having said that, I say we _should_ standardize on installation of packages
from the same family (i.e. Horde).

>> Standardization should always be applauded. :-)
> 
> Urgh ;-)  If everything in life was standardised, we'd be running RedHat,
> not  busy upsetting the apple-cart with this upstart project ;-)

Having run redhat for the past 4 years, I can safely say that that pile of
stuff strewn loosely together with twine and masking tape into a
nightmarish  packaging system is far from standardized.

> First off, where are webapp ebuilds going to live in Portage?  I'd like
> to see  a set of 'web-???' categories myself, so that web apps are
> clearly visible  and easy to find.  I don't think they should disappear
> under 'net-www' or  into various 'app-???' directories.

Forgot to bring this up.  Can't agree more.  Web-* makes sense to me.
There's a slew of things that can go into web-mail and web-net just to
start.

> Secondly, are we going to establish a webapps herd to look after the
> packages  that will be added?  If so, feel free to add me to the list of
> maintainers.   If not, then what solution do you suggest?

A herd makes sense.  I'll leave this to the higher-ups thought. :-)

> I think the ebuilds for web apps should be ENTIRELY webserver neutral.
> This  is why I've done nothing with Max's eclass myself.  There should be
> userland  tools for creating an instance of an app under Apache or
> whatever.  Yes, I  know that most people will run Apache, and not care
> about this, but Gentoo's  supposed to be about configurability.  We have
> a chance to get some solid  foundations in - I say let's get digging.

As I've said before many times, I'd like to see the eclass grow into
something that can be used with all the webservers we have in portage.  I
don't know if userland tools can be flexible enough to create config blocks
for all the apps that we're going to have.  An ebuild knows enough of the
application to pass the necessary information to the eclass to create
whatever config is needed.  At the same time, we have to be careful to not
balloon this into something unmaintainable. Which is why it may be best to
start this as apache-only (as it is the more popular of the webservers).
Get everything converted over and working and only then add support for
others. 

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03  0:30 ` Austin Frank
@ 2003-08-03  7:50   ` Tal Peer
  2003-08-03 14:45   ` Don Seiler
  1 sibling, 0 replies; 38+ messages in thread
From: Tal Peer @ 2003-08-03  7:50 UTC (permalink / raw
  To: gentoo-dev

On Sat, 2 Aug 2003, Austin Frank wrote:

> Max just offered to be a maintainer of the webapps herd, if one starts.  I'd
> like to offer to join the herd as well, though I'm not a dev yet.  As soon
> as Max sends me a version of his eclass or commits it to portage, I'm going
> to do ebuilds for a few blogging suites and submit them.  I guess this is
> just mostly a heads up that you've got an interested party if you do start
> the webapps herd.
> 

Regarding the webapps herd, i think it will be nice to have webapps as a 
primary herd for web applications and the language/technology they use as 
a secondary herd, fex: phpMyAdmin will have primary herds set to webapps 
and secondary herd set to php. Bugzilla will have perl as secondary herd, 
etc. etc. 

--
Tal Peer
Gentoo Developer

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x253D2947
Key Fingerprint: C0B1 D91D 7323 6C0F 227A CBD6 D635 E53D 253D 2947


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03  0:30 ` Austin Frank
  2003-08-03  7:50   ` Tal Peer
@ 2003-08-03 14:45   ` Don Seiler
  2003-08-03 14:49     ` [gentoo-dev] Re: [gentoo-core] " Stuart Herbert
  1 sibling, 1 reply; 38+ messages in thread
From: Don Seiler @ 2003-08-03 14:45 UTC (permalink / raw
  To: Austin Frank; +Cc: Troy Dack, gentoo-dev, Gentoo Core

I'd like to be in this herd as well.

Don.

On Sat, Aug 02, 2003 at 08:30:39PM -0400, Austin Frank wrote:
> Max just offered to be a maintainer of the webapps herd, if one starts.  I'd
> like to offer to join the herd as well, though I'm not a dev yet.  As soon
> as Max sends me a version of his eclass or commits it to portage, I'm going
> to do ebuilds for a few blogging suites and submit them.  I guess this is
> just mostly a heads up that you've got an interested party if you do start
> the webapps herd.
> 
> /au
> 
> -- 
> "Your reality, sir, is lies and balderdash; and I am
>  delighted to say I have no grasp of it whatsoever."
> 		*Baron Munchausen*
> phone: (212) 853-6346	email: aufrank@columbia.edu
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03  2:26     ` [gentoo-dev] " Max Kalika
@ 2003-08-03 14:46       ` Stuart Herbert
  2003-08-03 15:20         ` Max Kalika
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-03 14:46 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 6399 bytes --]

Hi Max,

On Sunday 03 August 2003 3:26 am, Max Kalika wrote:
> > I'd prefer /etc/webapps/<application>/, again for future flexibility
> > where a  web application has more than one configuration file.  I don't
> > mind frigging  apps to look in more than one place for a config file.  I
> > do mind patching  apps to use just the one file.
>
> You want to mix the apache config block with other configuration files that
> come with the application?  

/etc/webapps/<application>/ is the directory for the *application's* config 
files.  Nothing to do with Apache per se.

There is an alternative that should be considered.  Maybe there shouldn't be 
an /etc/webapps directory at all, and the config files should live under the 
Document Root.  Yes, this might be better.  How would you support multiple 
installations of phpMyAdmin using a /etc/webapps/ scheme?

> Yes!  Which is why a patch is probably not always appropriate -- sed is
> more resilient to pieces of configuration moving around upstream.

Not sure I understand you here.  A patch is applied against a known set of 
files.  Portage only installs known sets of files.  So a patch is no less 
appropriate than sed.

> > If Robin doesn't beat me to it, I'll write a script that we can add to
> > Portage  to standardise getting this information.
>
> What did you have in mind to achieve this?

Last night, I thought I was sure.  Unfortunately, waking up today I've 
forgotten ;-)  I'll go back and re-read the thread.

> > What shape are other languages in for their dependencies?  Not every
> > webapp is  going to be written in PHP ...
>
> Many apps are CGIs.  Others can of course be mod_perl, mod_python, java,
> you name it.  I see no problems using the eclass with these because it was
> written with flexibility in mind.  Like I've said in the past.  My initial
> idea for this was to fix nut and apcuspd to cleanly install their CGI
> components.

We're going to use the one eclass for CGIs, mod_perl-dependent, 
mod_python-dependent, and so on?  Mmmm.  That way lies pain and misery me 
thinks.

I think we'll need a webapps-base eclass, and then a webapps-<language> set of 
eclasses.  All the language-neutral stuff goes in the base, and everything 
else goes into each specific language eclass.

> > Well, write access to directories under htdocs at any rate.  TikiWiki -
> > which  we're looking to use for a Gentoo website - has this annoying
> > feature.
>
> What bothers me though, is that having any directory under /usr writeable
> is really bad form (I made a policy at work for all servers -- configure a
> system where /usr can be mounted read-only).  If at all possible, I'd like
> to have these directories created under something like /var/lib/ and
> symlinked back to where the app needs to write.  If not symlinked then an
> Apache alias (or whatever is equivalent to other servers).

Writable /usr is something I'll have no part in.

I thought Robin's idea was this.  The master copy of the app goes in 
/usr/webapps.  Then we have a script that symlinks in the app under the 
Document Root as required by the local admin, or uses .htaccess tricks as 
appropriate.

Robin - can you explain your idea again plz?

> See above.  But I agree, we _can't_ standardize on the approach simply
> because it depends on what needs to be done.  I imagine that there will be
> some apps where we would just have complete config files living in
> ${FILESDIR} that get installed over the ones that come with the package.

Urgh.  Only if the patch is larger than the replacement file, I'd hope ;-)

> Having said that, I say we _should_ standardize on installation of packages
> from the same family (i.e. Horde).

Well, that'd be up to the maintainer of the packages I'd hope.

> >> Standardization should always be applauded. :-)
> >
> > Urgh ;-)  If everything in life was standardised, we'd be running RedHat,
> > not  busy upsetting the apple-cart with this upstart project ;-)
>
> Having run redhat for the past 4 years, I can safely say that that pile of
> stuff strewn loosely together with twine and masking tape into a
> nightmarish  packaging system is far from standardized.

Lots of laughter.  My intention wasn't to start a RedHat flame war ;-)

> Forgot to bring this up.  Can't agree more.  Web-* makes sense to me.
> There's a slew of things that can go into web-mail and web-net just to
> start.

Definitely.

> > Secondly, are we going to establish a webapps herd to look after the
> > packages  that will be added?  If so, feel free to add me to the list of
> > maintainers.   If not, then what solution do you suggest?
>
> A herd makes sense.  I'll leave this to the higher-ups thought. :-)

As I understand it, if there's a group of us want a herd, then it's up to us 
to put it in place and make it a success.

> As I've said before many times, I'd like to see the eclass grow into
> something that can be used with all the webservers we have in portage.  I
> don't know if userland tools can be flexible enough to create config blocks
> for all the apps that we're going to have.  An ebuild knows enough of the
> application to pass the necessary information to the eclass to create
> whatever config is needed.  At the same time, we have to be careful to not
> balloon this into something unmaintainable. Which is why it may be best to
> start this as apache-only (as it is the more popular of the webservers).
> Get everything converted over and working and only then add support for
> others.

Just what webserver-specific configuration do these apps need?  I'd hope that, 
for the vast majority of apps, it's little to none.

If we start down the apache-only route now, it's something that'll probably 
never get fixed.  Let's identify just what apache config stuff you think is 
needed, and let's generalise it now.  It can't be that difficult - it's only 
a web server.

Best regards,
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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [gentoo-dev] Re: [gentoo-core] Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 14:45   ` Don Seiler
@ 2003-08-03 14:49     ` Stuart Herbert
  2003-08-05  3:46       ` Robin H.Johnson
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-03 14:49 UTC (permalink / raw
  To: Don Seiler, Austin Frank; +Cc: Troy Dack, gentoo-dev, Gentoo Core

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 808 bytes --]

On Sunday 03 August 2003 3:45 pm, Don Seiler wrote:
> I'd like to be in this herd as well.
>
> Don.

Excellent.  So, trying to keep count, that gives us these people so far in the 
herd:

* kalika (max)
* coredumb (tal)
* stuart (me ;-)
* rizzo (don)

+ Austin Frank's volunteered to become a developer and join the herd.  Hey - 
that's a nice number of people.

Have I missed anyone?  Robin?

Best regards,
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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 14:46       ` Stuart Herbert
@ 2003-08-03 15:20         ` Max Kalika
  2003-08-03 17:43           ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-03 15:20 UTC (permalink / raw
  To: stuart, Max Kalika, Troy Dack, gentoo-dev

Howdy Stuart!

Quoting Stuart Herbert <stuart@gentoo.org>:

>> You want to mix the apache config block with other configuration files
>> that come with the application?  
> 
> /etc/webapps/<application>/ is the directory for the *application's*
> config  files.  Nothing to do with Apache per se.

Correct.  I also create an apache config block as

  /etc/webapps/<application>.conf

This is what gets included into the apache config if a user activates the
specific application.  For example, the horde config block looks like this:

max@ike webapps $ cat horde-apache.conf 
Alias /horde /usr/share/webapps/horde/
<Directory /usr/share/webapps/horde>
  Allow from all
  AllowOverride Limit
  Options Indexes FollowSymLinks 
  php_flag safe_mode off
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag file_uploads on
  php_value upload_max_filesize 50M
  php_value include_path /usr/lib/horde-pear
</Directory>

> There is an alternative that should be considered.  Maybe there shouldn't
> be  an /etc/webapps directory at all, and the config files should live
> under the  Document Root.  Yes, this might be better.  How would you
> support multiple  installations of phpMyAdmin using a /etc/webapps/
> scheme?

The whole reason for keeping config files under /etc is for CONFIG_PROTECT.
Multiple versions of any app would be handled the same way as all other
packages on Gentoo -- core files get overwritten in an upgrade and the
config files are updated through dispatch-conf/etc-update/manually.

>> Yes!  Which is why a patch is probably not always appropriate -- sed is
>> more resilient to pieces of configuration moving around upstream.
> 
> Not sure I understand you here.  A patch is applied against a known set
> of  files.  Portage only installs known sets of files.  So a patch is no
> less  appropriate than sed.

Right, but if the file itself gets rearranged constantly (as some apps do),
it may be difficult to maintain the patch.  But again, this all depends on
the package at hand -- as stands right now everywhere else in gentoo, lets
do what is easier/more maintainable.

> Last night, I thought I was sure.  Unfortunately, waking up today I've 
> forgotten ;-)  I'll go back and re-read the thread.

Don't you just hate when that happens :-)

> We're going to use the one eclass for CGIs, mod_perl-dependent, 
> mod_python-dependent, and so on?  Mmmm.  That way lies pain and misery me 
> thinks.

Currently there's nothing in the eclass that is language specific other
than that check_php function (which, as I said before, I'd like to find a
replacement for).

> I think we'll need a webapps-base eclass, and then a webapps-<language>
> set of  eclasses.  All the language-neutral stuff goes in the base, and
> everything  else goes into each specific language eclass.

Certainly.  Perhaps if we don't find anything that is language specific
(which I have yet to see), we can take a different approach and do
webapp-<webservertype>

> Just what webserver-specific configuration do these apps need?  I'd hope
> that,  for the vast majority of apps, it's little to none.

See above.

> It can't be that difficult - it's only  a web server.

Isn't that on the list of "Famous Last Words" ? :-)

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 15:20         ` Max Kalika
@ 2003-08-03 17:43           ` Stuart Herbert
  2003-08-03 19:03             ` Max Kalika
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-03 17:43 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 3903 bytes --]

'lo Max,

Keep it comming.  I think we're really getting this thrashed out ;-)

On Sunday 03 August 2003 4:20 pm, Max Kalika wrote:
> Correct.  I also create an apache config block as
>
>   /etc/webapps/<application>.conf

If it's apache-specific, can't we at least call it <application>-apache.conf?

> This is what gets included into the apache config if a user activates the
> specific application.  For example, the horde config block looks like this:
>
> max@ike webapps $ cat horde-apache.conf
> Alias /horde /usr/share/webapps/horde/
> <Directory /usr/share/webapps/horde>
>   Allow from all
>   AllowOverride Limit
>   Options Indexes FollowSymLinks
>   php_flag safe_mode off
>   php_flag magic_quotes_gpc off
>   php_flag magic_quotes_runtime off
>   php_flag register_globals off
>   php_flag file_uploads on
>   php_value upload_max_filesize 50M
>   php_value include_path /usr/lib/horde-pear
> </Directory>

Thanks for the example - it helps a great deal.  Now, how would you deal with 
a site needing to run two copies of horde under the one web server?

> The whole reason for keeping config files under /etc is for CONFIG_PROTECT.
> Multiple versions of any app would be handled the same way as all other
> packages on Gentoo -- core files get overwritten in an upgrade and the
> config files are updated through dispatch-conf/etc-update/manually.

Yeah - but how do you handle sites (like ISPs) that need to run multiple 
installations of the same app on the same box?  You can't have a single 
globla configuration file for that.  Makes sense for the home user, but not 
for ISPs.

> Right, but if the file itself gets rearranged constantly (as some apps do),
> it may be difficult to maintain the patch.  

In ten years of maintaining apps, I've never found it a problem myself.  But 
hey - it's not important ;-)

> But again, this all depends on
> the package at hand -- as stands right now everywhere else in gentoo, lets
> do what is easier/more maintainable.

Absolutely.  Gentoo works *because* it is anarchy ;-)

> > Last night, I thought I was sure.  Unfortunately, waking up today I've
> > forgotten ;-)  I'll go back and re-read the thread.
>
> Don't you just hate when that happens :-)

Yeah ;-)

> Currently there's nothing in the eclass that is language specific other
> than that check_php function (which, as I said before, I'd like to find a
> replacement for).

Well, PHP apps'll need to check for which PHP extensions are active from time 
to time.

> Certainly.  Perhaps if we don't find anything that is language specific
> (which I have yet to see), we can take a different approach and do
> webapp-<webservertype>

See previous emails.  I *really* don't support making any of this stuff 
webserver-specific in the ebuilds or eclasses ;-)  A two-stage install - 
ebuilds to get apps onto the machine, user-space tools to install an app for 
a specific web server - are the way to go, imho.

How do you make an app install on (say) Zeus or (say) iPlanet or (say) 
n.e.other web server if the ebuild itself is server-specific?  We're boxing 
ourselves in, for no good reason.

Gentoo's supposed to be about configurability.  It even says so right at the 
top of www.gentoo.org.  Let's not throw that out of the window just yet ;-)

> > It can't be that difficult - it's only  a web server.
>
> Isn't that on the list of "Famous Last Words" ? :-)

Lots of laughter ;-)  I hope not!

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 17:43           ` Stuart Herbert
@ 2003-08-03 19:03             ` Max Kalika
  2003-08-03 19:43               ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-03 19:03 UTC (permalink / raw
  To: stuart, Max Kalika, Troy Dack, gentoo-dev

Chugga chugga chugga! :-)

Quoting Stuart Herbert <stuart@gentoo.org>:

> On Sunday 03 August 2003 4:20 pm, Max Kalika wrote:
>> Correct.  I also create an apache config block as
>> 
>>   /etc/webapps/<application>.conf
> 
> If it's apache-specific, can't we at least call it
> <application>-apache.conf?

You're absolutely right, and in fact this is what the eclass does right now
(as shown by the example I posted earlier).

> Thanks for the example - it helps a great deal.  Now, how would you deal
> with  a site needing to run two copies of horde under the one web server?

Hmm.  This depends on the app.  Some apps have virtual hosting built-in
others do not.  Those that do not, may need some sysadmin intervention,
doing some parallel installs, symlinking, what-have-you.  I think we need
to have a limit to how much we can do at install time and how much we can
configure for the user out-of-the-box.  For example, we don't have any way
of having two postfix instances installed and running on the same box with
the ebuild, but the sysadmin can go ahead and configure the installed
product to achieve the needed functionality. 

> Yeah - but how do you handle sites (like ISPs) that need to run multiple 
> installations of the same app on the same box?  You can't have a single 
> globla configuration file for that.  Makes sense for the home user, but
> not  for ISPs.

Continuing from above, it seems best left to the systems admin in designing
how to implement virtual hosting.  For example, horde has built-in virtual
hosting where you specify multiple servers and the specific one gets chosen
based on the server hostname.  Of course this isn't foolproof as things
like SSL will break it, but in any case, this decision has to be left to
the person installing it. It seems like the gentoo philosophy is to install
the necessary minimum to have a running product and leave the major
tinkering to the admin.  Going back to the postfix example, although the
package has support for delivering mail to LMTP through a content filter
that will scan for spam and viruses, it doesn't do it out of the box and
takes a bit of tinkering to get right.  I'm of the opinion that if someone
wants to set up an ISP, they better know what they're doing and will be
able to figure out how to virtualize the necessary packages they want to
offer to their clients.

> Well, PHP apps'll need to check for which PHP extensions are active from
> time  to time.

Ok.  If there's a lot of language-specific work that needs to be done, then
breaking it up into separate eclasses makes sense, otherwise, I'm worried
about clutter. :)

>> Certainly.  Perhaps if we don't find anything that is language specific
>> (which I have yet to see), we can take a different approach and do
>> webapp-<webservertype>
> 
> See previous emails.  I *really* don't support making any of this stuff 
> webserver-specific in the ebuilds or eclasses ;-)  A two-stage install - 
> ebuilds to get apps onto the machine, user-space tools to install an app
> for  a specific web server - are the way to go, imho.

Fair enough.  So something like "webapp-config <application> <webserver>" ?

> How do you make an app install on (say) Zeus or (say) iPlanet or (say) 
> n.e.other web server if the ebuild itself is server-specific?  We're
> boxing  ourselves in, for no good reason.

No idea.  :-)

> Gentoo's supposed to be about configurability.  It even says so right at
> the  top of www.gentoo.org.  Let's not throw that out of the window just
> yet ;-)

I wouldn't consider it! :-)

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 19:03             ` Max Kalika
@ 2003-08-03 19:43               ` Stuart Herbert
  2003-08-04  4:29                 ` Max Kalika
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-03 19:43 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 5130 bytes --]

On Sunday 03 August 2003 8:03 pm, Max Kalika wrote:
> Chugga chugga chugga! :-)

Lots of laughter.

> You're absolutely right, and in fact this is what the eclass does right now
> (as shown by the example I posted earlier).

;-)

> > Thanks for the example - it helps a great deal.  Now, how would you deal
> > with  a site needing to run two copies of horde under the one web server?
>
> Hmm.  This depends on the app.  Some apps have virtual hosting built-in
> others do not.  Those that do not, may need some sysadmin intervention,
> doing some parallel installs, symlinking, what-have-you.  I think we need
> to have a limit to how much we can do at install time and how much we can
> configure for the user out-of-the-box.  For example, we don't have any way
> of having two postfix instances installed and running on the same box with
> the ebuild, but the sysadmin can go ahead and configure the installed
> product to achieve the needed functionality.

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.

> > Yeah - but how do you handle sites (like ISPs) that need to run multiple
> > installations of the same app on the same box?  You can't have a single
> > globla configuration file for that.  Makes sense for the home user, but
> > not  for ISPs.
>
> Continuing from above, it seems best left to the systems admin in designing
> how to implement virtual hosting.  For example, horde has built-in virtual
> hosting where you specify multiple servers and the specific one gets chosen
> based on the server hostname.  Of course this isn't foolproof as things
> like SSL will break it, but in any case, this decision has to be left to
> the person installing it. It seems like the gentoo philosophy is to install
> the necessary minimum to have a running product and leave the major
> tinkering to the admin.  

Quoting www.gentoo.org again, the phrase 'automatically configured' can be 
found.  Where we can do a sensible minimum, I think we should.

> Going back to the postfix example, although the
> package has support for delivering mail to LMTP through a content filter
> that will scan for spam and viruses, it doesn't do it out of the box and
> takes a bit of tinkering to get right.  I'm of the opinion that if someone
> wants to set up an ISP, they better know what they're doing and will be
> able to figure out how to virtualize the necessary packages they want to
> offer to their clients.

Problem with that is that it prevents 'emerge -u world' from being something 
that you can safely put in cron.

> Ok.  If there's a lot of language-specific work that needs to be done, then
> breaking it up into separate eclasses makes sense, otherwise, I'm worried
> about clutter. :)

Yeah, clutter is a problem - but so is ten ebuilds each with their own way of 
achieving the same piece of testing.

And on that note ... (drum roll please) ... take a look at the new 
webapp-apache.eclass file that I've just committed to CVS.  All it does (for 
now) is provide a standardised way of determine where HTDOCSDIR is, and which 
Apache version to install support for.

I admit it's a stop-gap solution; it's not enough on its own to make ebuilds 
webserver-neutral.  But at least we can move all the apache-specific crud 
into the one place, as a starter for ten.

Yeah, okay, I'm jumping ahead of the GLEP being approved perhaps, but I needed 
this to close two outstanding bugs this afternoon, so that's my justification 
<grin>.  Not exactly like I've gone and moved stuff into the proposed 
'web-???' categories yet ;-)

> Fair enough.  So something like "webapp-config <application> <webserver>" ?

I think so, yeah.  Robin's the best person to talk about this, as he had very 
firm ideas about what he wanted to implement.

> > How do you make an app install on (say) Zeus or (say) iPlanet or (say)
> > n.e.other web server if the ebuild itself is server-specific?  We're
> > boxing  ourselves in, for no good reason.
>
> No idea.  :-)

Exactly ;-)  This is the problem that I think we should be solving.

Anyway, take a look at the eclass, and let's talk about what else needs adding 
to it - and let's get it added.  

A word of warning - although the eclass is called 'webapp-apache', it's 
designed to *hide* apache-specificness as much as possible behind its 
interface.  If you add anything to the eclass, I'd appreciate it if you 
followed this design idea ;-)

Robin (if you're following this!) I think you could make mod_php inherit this 
class safely too, to reduce duplication still further.

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 19:43               ` Stuart Herbert
@ 2003-08-04  4:29                 ` Max Kalika
  2003-08-04 10:43                   ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-04  4:29 UTC (permalink / raw
  To: stuart, Max Kalika, Troy Dack, gentoo-dev

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. :-)

Quoting Stuart Herbert <stuart@gentoo.org>:

> On Sunday 03 August 2003 8:03 pm, Max Kalika wrote:

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

>> Going back to the postfix example, although the
>> package has support for delivering mail to LMTP through a content filter
>> that will scan for spam and viruses, it doesn't do it out of the box and
>> takes a bit of tinkering to get right.  I'm of the opinion that if
>> someone wants to set up an ISP, they better know what they're doing and
>> will be able to figure out how to virtualize the necessary packages they
>> want to offer to their clients.
> 
> 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?

>> Ok.  If there's a lot of language-specific work that needs to be done,
>> then breaking it up into separate eclasses makes sense, otherwise, I'm
>> worried about clutter. :)
> 
> Yeah, clutter is a problem - but so is ten ebuilds each with their own
> way of  achieving the same piece of testing.

Correct, which is what eclasses are for.

> And on that note ... (drum roll please) ... take a look at the new 
> webapp-apache.eclass file that I've just committed to CVS.  All it does
> (for  now) is provide a standardised way of determine where HTDOCSDIR is,
> and which  Apache version to install support for.

Ugh!  Won't this get in the way when we actually try to implement this GLEP
(most of which is already done by my eclass).  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>

> I admit it's a stop-gap solution; it's not enough on its own to make
> ebuilds  webserver-neutral.  But at least we can move all the
> apache-specific crud  into the one place, as a starter for ten.

Double Ugh!  See these please:

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

> Yeah, okay, I'm jumping ahead of the GLEP being approved perhaps, but I
> needed  this to close two outstanding bugs this afternoon, so that's my
> justification  <grin>.  Not exactly like I've gone and moved stuff into
> the proposed  'web-???' categories yet ;-)

See, this GLEP was more about where/how to install these ebuilds and not
about their place in the tree.  I held off including at least 10 ebuilds
waiting for the outcome of this discussion, but now you jumped the gun.
Hopefully the transition can be painless.

>> Fair enough.  So something like "webapp-config <application>
>> <webserver>" ?
> 
> I think so, yeah.  Robin's the best person to talk about this, as he had
> very  firm ideas about what he wanted to implement.

Will wait for Robin's response.
 
> Exactly ;-)  This is the problem that I think we should be solving.

Well, perhaps a question in the original GLEP should be readdressed.  I'm
beginning to strongly agree with:

# 1. Default Web Server
# ---------------------

# A common default web server will have to be selected and ebuild authors
# should ensure that their applications contain configuration directives 
# suitable for that server.  Given the popularity of the Apache web server 
# it is suggested that Apache be selected as the Gentoo default web server.

# Whilst it is acknowledged that other web servers do exist and are used, 
# there has to be an assumption made somewhere that people who choose to
use 
# something other than a default have enough knowledge to adapt 
# configurations accordingly.

Flexibility is one thing, maintainability with a limited developer time is
quite another.  The balance between the two is critical.

> Anyway, take a look at the eclass, and let's talk about what else needs
> adding  to it - and let's get it added.  

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

> A word of warning - although the eclass is called 'webapp-apache', it's 
> designed to *hide* apache-specificness as much as possible behind its 
> interface.  If you add anything to the eclass, I'd appreciate it if you 
> followed this design idea ;-)

But you completely ignored all my work and the GLEP which we're discussing.
My eclass follows your proposed philosophy, but you basically threw it out
the window.  I'm confused.

> Robin (if you're following this!) I think you could make mod_php inherit
> this  class safely too, to reduce duplication still further.

How is mod_php related to the way applications are installed?

--mk


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-04  4:29                 ` Max Kalika
@ 2003-08-04 10:43                   ` Stuart Herbert
  0 siblings, 0 replies; 38+ messages in thread
From: Stuart Herbert @ 2003-08-04 10:43 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 11455 bytes --]

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@gentoo.org>:
> > 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@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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-04 17:11 Max Kalika
  2003-08-04 22:16 ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-04 17:11 UTC (permalink / raw
  To: stuart, Max Kalika, Troy Dack, gentoo-dev

Good morning!

Quoting Stuart Herbert <stuart@gentoo.org>:

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

See, I don't think that running two (or more) copies of an application is
supporting virtual hosts.  Upgrading all the files is a pain.  Why not have
one installation of the core files and multiple installations of the config
files?  This is, of course, very application specific -- most of them will
still need database upgrades, but that has to be done by the sysadmin.

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

How do they handle db updates?  How do they handle config file updates?

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

Fair enough.

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

Why base it on the flag?  If the webserver is installed and is supported,
configure for it.

> 2) Your eclass doesn't specify the permissions that the source files
> should be  installed under.  Again, easy enough to fix.

This is very straightforward to add.

> 3) Your eclass doesn't provide support for running multiple copies of the
> same  app on the same machine.  This is a showstopper.

This whole thing needs a separate discussion.  There's no portage support
for dealing with more than one installation of the same version of the same
package.

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

..htaccess files only work in already web-accessable directories (in your
case, DocumentRoot).  If we're putting applications in /usr/share/webapps,
the webserver has no idea to look there. Which is what the Alias directive
does in all the .conf files that are generated.  However, Alias is not
allowed in .htaccess AFAIK.

http://httpd.apache.org/docs-2.0/mod/mod_alias.html#alias

Besides that, the server doesn't have to be restarted -- just HUPed.

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

Ok, if we can achieve the same thing without the post-install intervention,
all for the better.

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

Steal away!  Keep in mind it is not completely accurate if the per-package
USE flags goes into portage (http://bugs.gentoo.org/show_bug.cgi?id=13616).
Things in PUSE will also have to be taken into account.  But this is a
completely different matter and will be easy to integrate.

> 7) Your variable names are not generic enough for my liking ;-)
> AWEB_CFG, for  example, might be better off being WEBAPP_CFG.

Hey!  I originally had them as WEBAPP_* but was told to change the eclass
to apache-webapp to distinguish from other servers so I wanted the
variables to reflect the name of the eclass.  I'm as flexible on this as
playdoh. :-)

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

Thats just more to call from the ebuild.  My goal was to have very small
ebuilds -- just declare a few variables and inherit the eclass.

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

I'd say we should be shooting for an easy upgrade path first.  If config
files aren't stored in /etc/webapps/${PN}, then we need to have a way of
generating an env.d/${PN} which contains a CONFIG_PROTECT line, otherwise
we're forcing sysadins to reconfigure the application at every upgrade.
And as I mentioned before, there's no way for portage to handle
multiple-copy installs, so I'm not sure the best way to go about achieving
this goal.

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

Why should this be handled any different then the rest of apps handled by
portage?  If a sysadmin doesn't want older versions removed, just add
AUTOCLEAN=no to make.conf.  Granted, the current eclass doesn't use the
full ${PF} in the target directory, but that is easily changed.

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

Ok.  Hopefully we can get this thing hashed out and out the door so things
can start getting into shape soon.

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

I have my moments. ;-)

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

Ok, this one is a keeper.

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

Ah!  Ok, so before we have this issues ironed out, the current status-quo
will just be maintained.  Fair enough.

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

Since I'm the laziest person I know, I didn't want to do the work twice.
I'll just hold off on introducing more ebuilds which will have to be
converted later. :-)

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

Right, but as we already agreed, not all apps need to have their files
owned by apache:apache.  This should be configurable in the eclass.
Correct?

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

The issue is not whether DocumentRoot is a read-only mount during the
install, but during the day-to-day operations.  Running 'emerge' with /usr
mounted read-only is not the same as having apache running a webapp that
needs to write to /usr -- one is done seldomly, the other is all the time. 

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

I never made the "weak" argument -- I don't believe in it myself.  Things
need to be justified a bit better than that, so I'm completely with you on
this one.

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

Ok, agreed.  Troy, is there any chance for another draft with some of these
things incorporated?  (Thanks a bezillion, btw, for putting up with me) :-)

> It *was* fix-a-bug weekend ;-)

And a successful one at that from what I saw in my emerge --sync this
morning. :-)  Thanks!

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

All you! :-)

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

If you say it is very easy to do, I'm on board.  I can't personally speak
for other webservers, so I'll leave the decision of whether/how to support
others to those with the experience.  So in any case, we have to pull the
apache-specific things out into a separate framework.  Therefore things
like DocumentRoot can't even be considered.  So a central location for
webapps must be once again taken into account.  And from here stems the
problem of how to tell the webserver where to look for a specific
applications.  The .htaccess approach isn't viable.  For apache the .conf
system works, but yes, it requires the server to be HUPed after an upgrade
to an install of an application (not an upgrade -- once the app is
installed and running, upgrading doesn't require the server to be touched).

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

ok, I didn't realize that it wasn't a permanent solution.  All is ok.

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

Whichever is installed gets configured.  Either or both get touched,
depending on what is detected.  It is up to the sysadmin to start one or
the either automatically with rc-update.  I don't see a problem if both are
configured (if detected), but only one is running.

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-04 17:11 Max Kalika
@ 2003-08-04 22:16 ` Stuart Herbert
  2003-08-05  9:49   ` Michael Cummings
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-04 22:16 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 17150 bytes --]

On Monday 04 August 2003 6:11 pm, Max Kalika wrote:
> Good morning!

Evening, Max.

> See, I don't think that running two (or more) copies of an application is
> supporting virtual hosts.  Upgrading all the files is a pain.  Why not have
> one installation of the core files and multiple installations of the config
> files?  This is, of course, very application specific -- most of them will
> still need database upgrades, but that has to be done by the sysadmin.

Because that won't quite work, unless the app is aware of virtual hosting - 
and many (if not most) aren't.  Think about it.

Here's an example.  Imagine hosting (oh, I don't know) www.iammax.com and 
www.maxisgreat.com on the same physical box.  Document roots for each are 
/var/www/<host>/public_html/ for arguments sake.

Now imagine running phpBB on both domains, to provide separate forums.  As far 
as phpBB is concerned, when it accesses, say, login.php on www.iammax.com, 
the URL is http://www.iammax.com/phpbb/login.php, which translates through as 
/var/www/www.iammax.com/public_html/phpbb/login.php.  Similarly, login.php on 
www.maxisgreat.com translates through as 
/var/www/www.maxisgreat.com/public_html/phpbb/login.php

Given this scenario, how do you make these two sites share the same phpBB code 
files?  Here's a few possible ways, and the problems that they cause.  Chip 
in with others - because this is the core problem.

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 I've understood your eclass correctly, this is what it tries to do, yes?

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.

I believe that this is Robin's basic idea, if I've understood correctly.  It's 
a neat solution, but perhaps not a universal one.

c) A bit of find and cp -l, and you've got the directory structure of the 
webapp on /var, plus links back to the original on /usr.  Again, the config 
file problem is solved, because local copies can be parachuted in, and again 
there are real directories that can be made writable.  No webserver-specific 
tricks are required - as far as the web server is concerned, each domain has 
its own installation of phpBB.

d) ?? There must be other solutions to the problem that haven't been discussed 
in this thread.  Please - contribute!

> How do they handle db updates?  How do they handle config file updates?

I've never asked, and I don't want to know ;-)  Maybe Debian just doesn't 
change that much from year to year <grin>.

> > 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.
>
> Why base it on the flag?  If the webserver is installed and is supported,
> configure for it.

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.

> > 2) Your eclass doesn't specify the permissions that the source files
> > should be  installed under.  Again, easy enough to fix.
>
> This is very straightforward to add.

Agreed.

> > 3) Your eclass doesn't provide support for running multiple copies of the
> > same  app on the same machine.  This is a showstopper.
>
> This whole thing needs a separate discussion.  There's no portage support
> for dealing with more than one installation of the same version of the same
> package.

Why a separate discussion?  If this GLEP isn't here to address this 
fundamental issue, then I'd say that the GLEP has the wrong scope.

You're right - Portage currently can't do all of this on its own.  Perhaps it 
never will be able to.  As I understand it, that's why Robin's volunteered to 
write and maintain additional tools to bridge the gap.

> > 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.
>
> ..htaccess files only work in already web-accessable directories (in your
> case, DocumentRoot).  If we're putting applications in /usr/share/webapps,
> the webserver has no idea to look there. Which is what the Alias directive
> does in all the .conf files that are generated.  However, Alias is not
> allowed in .htaccess AFAIK.

See about for why I think .htaccess isn't the way to go anyway ;-)

> http://httpd.apache.org/docs-2.0/mod/mod_alias.html#alias
>
> Besides that, the server doesn't have to be restarted -- just HUPed.

Fair enough ;-)

> > 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 ;-)
>
> Steal away!  

Done ;-)

> Keep in mind it is not completely accurate if the per-package
> USE flags goes into portage (http://bugs.gentoo.org/show_bug.cgi?id=13616).
> Things in PUSE will also have to be taken into account.  But this is a
> completely different matter and will be easy to integrate.

It's a nice start though.  Ideally, we need a programatic interface to 
portage, an API we can use to handle these types of queries.  karltk is 
working on one ;-)

> > 7) Your variable names are not generic enough for my liking ;-)
> > AWEB_CFG, for  example, might be better off being WEBAPP_CFG.
>
> Hey!  I originally had them as WEBAPP_* but was told to change the eclass
> to apache-webapp to distinguish from other servers so I wanted the
> variables to reflect the name of the eclass.  I'm as flexible on this as
> playdoh. :-)

/me bites back his comment about the person who told you to do that ;-)

> > 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.
>
> Thats just more to call from the ebuild.  My goal was to have very small
> ebuilds -- just declare a few variables and inherit the eclass.

Hmm ... there's a tradeoff here.  Smaller ebuilds and less flexible (and 
re-usable) eclasses.  Or larger ebuilds, but more re-usable eclasses.  I 
guess I prefer the latter.

> > 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.
>
> I'd say we should be shooting for an easy upgrade path first.  

Good point ;-)  But what's the point of installing and upgrading configuration 
files that the application is never going to look at? ;-) (Sorry, it's 22:30, 
and still ridiculously hot here)

> If config
> files aren't stored in /etc/webapps/${PN}, then we need to have a way of
> generating an env.d/${PN} which contains a CONFIG_PROTECT line, otherwise
> we're forcing sysadins to reconfigure the application at every upgrade.

Yeah, but if each instance of the installed app has its own config files, then 
what's the relevance of /etc/webapps at all?

> And as I mentioned before, there's no way for portage to handle
> multiple-copy installs, so I'm not sure the best way to go about achieving
> this goal.

This is the problem that I think we should be solving - how to support the 
installation, configuration, and upgrading of multiple-copy installs.

> > 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.
>
> Why should this be handled any different then the rest of apps handled by
> portage?  

Because most of the rest of the apps handled by portage don't run in a virtual 
domain environment.  Webapps really are a different beast.

> If a sysadmin doesn't want older versions removed, just add
> AUTOCLEAN=no to make.conf.  Granted, the current eclass doesn't use the
> full ${PF} in the target directory, but that is easily changed.

Here's an example.  Imagine you're running your own hosting firm, and you have 
a non-trivial number of customers using the same webapp (say, phpBB for 
arguments sake).  A new version of phpBB comes out.  Some customers will ask 
for the upgrade, and some explicitly will ask you not to upgrade.  So, in 
this situation, you need to have two copies of phpBB installed on the same 
box at the same time.

Now let's look at what happens when you run 'emerge -u phpBB', with the 
appropriate ACCEPT_KEYWORDS of course.  Portage goes and installs the new 
version of phpBB over the top of the old phpBB files.  The old version of 
phpBB gets overwritten, yes?  I don't see how AUTOCLEAN will prevent that 
from happening.

The whole point of SLOTing apps (as I understand it) is to allow you to have 
multiple versions installed alongside each other.  This is the mechanism that 
Portage offers us.  

> Ok.  Hopefully we can get this thing hashed out and out the door so things
> can start getting into shape soon.

Hell yes.

> > 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.
>
> Ok, this one is a keeper.

Kudos to Robin - it's his algorithm.

> > 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.
>
> Ah!  Ok, so before we have this issues ironed out, the current status-quo
> will just be maintained.  Fair enough.

Agreed.

> > 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.
>
> Since I'm the laziest person I know, I didn't want to do the work twice.
> I'll just hold off on introducing more ebuilds which will have to be
> converted later. :-)

That's up to you.  If you're maintaining webapp ebuilds currently in portage, 
though, I'd urge you not to stop maintaining them just because you're waiting 
for a design solution via this GLEP.

> > 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.
>
> Right, but as we already agreed, not all apps need to have their files
> owned by apache:apache.  This should be configurable in the eclass.
> Correct?

Do we need a new user/group to own most of the files?  And then we just make 
the files that need write-access owned by the webserver?

> > 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.
>
> The issue is not whether DocumentRoot is a read-only mount during the
> install, but during the day-to-day operations.  Running 'emerge' with /usr
> mounted read-only is not the same as having apache running a webapp that
> needs to write to /usr -- one is done seldomly, the other is all the time.

In his email in that thread you pointed me at, Robin was explicitly talking 
about /var being a read-only NFS mount at install time.

> > 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.
>
> I never made the "weak" argument 

Again, this is in response to the comments in the archived thread - not this 
one ;-)  You didn't make the comment - someone else did.

> -- I don't believe in it myself.  Things
> need to be justified a bit better than that, so I'm completely with you on
> this one.

:)

> Ok, agreed.  Troy, is there any chance for another draft with some of these
> things incorporated?  (Thanks a bezillion, btw, for putting up with me) :-)

Who's "putting up" with you?  I don't feel like I am!  I'm just grateful that 
we're both interested in finding a solution to this problem.  Now, if just a 
few more people would chip in and help these discussions ... ;-)

> And a successful one at that from what I saw in my emerge --sync this
> morning. :-)  Thanks!

By the time I got Saturday evening, it was all but over.  Didn't see a single 
person in #gentoo-bugs who I could help :(

> If you say it is very easy to do, I'm on board.  

If it's not easy to do, then we'll scrap it and come up with something better.

> I can't personally speak
> for other webservers, so I'll leave the decision of whether/how to support
> others to those with the experience.  

Fair enough.

> So in any case, we have to pull the
> apache-specific things out into a separate framework.  Therefore things
> like DocumentRoot can't even be considered.  So a central location for
> webapps must be once again taken into account.  

Yep.  How does this sound as the design of the central layout?  Let's agree a 
design, so that it can be added to the GLEP.

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

> ok, I didn't realize that it wasn't a permanent solution.  All is ok.

Neat.

> >> 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.
>
> Whichever is installed gets configured.  Either or both get touched,
> depending on what is detected.  It is up to the sysadmin to start one or
> the either automatically with rc-update.  I don't see a problem if both are
> configured (if detected), but only one is running.

Yeah, but as discussed earlier: 

a) you need a standard way of detecting which one is installed, and 
b) you need to honour the 'apache2' USE flag

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-04 23:16 Max Kalika
  2003-08-05  0:14 ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-04 23:16 UTC (permalink / raw
  To: stuart, Max Kalika, Troy Dack, gentoo-dev

Quoting Stuart Herbert <stuart@gentoo.org>:

> Here's an example.  Imagine hosting (oh, I don't know) www.iammax.com and 
> www.maxisgreat.com on the same physical box.  Document roots for each are 
> /var/www/<host>/public_html/ for arguments sake.

Love those names.  I wonder if they're taken? ;-)

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

> If I've understood your eclass correctly, this is what it tries to do,
> yes?

Yes.

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

> c) A bit of find and cp -l, and you've got the directory structure of the 
> webapp on /var, plus links back to the original on /usr.  Again, the
> config  file problem is solved, because local copies can be parachuted
> in, and again  there are real directories that can be made writable.  No
> webserver-specific  tricks are required - as far as the web server is
> concerned, each domain has  its own installation of phpBB.

Ok, I'll pool some replies below...

>> Why base it on the flag?  If the webserver is installed and is supported,
>> configure for it.
> 
> 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.

>> This whole thing needs a separate discussion.  There's no portage support
>> for dealing with more than one installation of the same version of the
>> same package.
> 
> Why a separate discussion?  If this GLEP isn't here to address this 
> fundamental issue, then I'd say that the GLEP has the wrong scope.
> 
> You're right - Portage currently can't do all of this on its own.
> Perhaps it  never will be able to.  As I understand it, that's why
> Robin's volunteered to  write and maintain additional tools to bridge the
> gap.

Keep reading, going to answer this below. :-)

>> Keep in mind it is not completely accurate if the per-package
>> USE flags goes into portage
>> (http://bugs.gentoo.org/show_bug.cgi?id=13616). Things in PUSE will also
>> have to be taken into account.  But this is a completely different
>> matter and will be easy to integrate.
> 
> It's a nice start though.  Ideally, we need a programatic interface to 
> portage, an API we can use to handle these types of queries.  karltk is 
> working on one ;-)

Cool!

>> Thats just more to call from the ebuild.  My goal was to have very small
>> ebuilds -- just declare a few variables and inherit the eclass.
> 
> Hmm ... there's a tradeoff here.  Smaller ebuilds and less flexible (and 
> re-usable) eclasses.  Or larger ebuilds, but more re-usable eclasses.  I 
> guess I prefer the latter.

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.

>> If config
>> files aren't stored in /etc/webapps/${PN}, then we need to have a way of
>> generating an env.d/${PN} which contains a CONFIG_PROTECT line, otherwise
>> we're forcing sysadins to reconfigure the application at every upgrade.
> 
> Yeah, but if each instance of the installed app has its own config files,
> then  what's the relevance of /etc/webapps at all?
> 
>> And as I mentioned before, there's no way for portage to handle
>> multiple-copy installs, so I'm not sure the best way to go about
>> achieving this goal.
> 
> This is the problem that I think we should be solving - how to support
> the  installation, configuration, and upgrading of multiple-copy installs.

There's nothing I can think of that will make this work, but see below for
some arguments...

>> Why should this be handled any different then the rest of apps handled by
>> portage?  
> 
> Because most of the rest of the apps handled by portage don't run in a
> virtual  domain environment.  Webapps really are a different beast.

They certainly are. :-)

> Here's an example.  Imagine you're running your own hosting firm, and you
> have  a non-trivial number of customers using the same webapp (say, phpBB
> for  arguments sake).  A new version of phpBB comes out.  Some customers
> will ask  for the upgrade, and some explicitly will ask you not to
> upgrade.  So, in  this situation, you need to have two copies of phpBB
> installed on the same  box at the same time.
> 
> Now let's look at what happens when you run 'emerge -u phpBB', with the 
> appropriate ACCEPT_KEYWORDS of course.  Portage goes and installs the new 
> version of phpBB over the top of the old phpBB files.  The old version of 
> phpBB gets overwritten, yes?  I don't see how AUTOCLEAN will prevent that 
> from happening.
> 
> The whole point of SLOTing apps (as I understand it) is to allow you to
> have  multiple versions installed alongside each other.  This is the
> mechanism that  Portage offers us.  

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

Going along with your example, how can you do an 'emerge -u phpBB' _for a
particular domain_?  You're telling portage to maintain a package, and
upgrade parts of it randomly.  I simply don't think portage will ever have
any way of handling multiple installs of a package in this manner.  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.

AFAIK, no other distro has support for virtual hosting because of this very
issue.

> That's up to you.  If you're maintaining webapp ebuilds currently in
> portage,  though, I'd urge you not to stop maintaining them just because
> you're waiting  for a design solution via this GLEP.

Not in charge of anything else in portage.  Though I'd like to help out
with Horde down the road (seeing as I'm on the horde dev team as well).

>> Right, but as we already agreed, not all apps need to have their files
>> owned by apache:apache.  This should be configurable in the eclass.
>> Correct?
> 
> Do we need a new user/group to own most of the files?  And then we just
> make  the files that need write-access owned by the webserver?

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)

> In his email in that thread you pointed me at, Robin was explicitly
> talking  about /var being a read-only NFS mount at install time.

Ok, install-time aside, the installed, writeable directories cannot exist
on a readonly mount for day-to-day operations.  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.

>> So in any case, we have to pull the
>> apache-specific things out into a separate framework.  Therefore things
>> like DocumentRoot can't even be considered.  So a central location for
>> webapps must be once again taken into account.  
> 
> Yep.  How does this sound as the design of the central layout?  Let's
> agree a  design, so that it can be added to the GLEP.
> 
> * /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.  Otherwise, this seems ok
to me and is easy to implement in the eclass.  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).

> a) you need a standard way of detecting which one is installed, and 

Is the approach currently in the eclass unacceptable? (Check for the
existance of the directory/configfile)

> b) you need to honour the 'apache2' USE flag

Yup, see above...no higher...no, higher than that.  Ok there, stop!

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-04 23:16 Max Kalika
@ 2003-08-05  0:14 ` Stuart Herbert
  2003-08-05  2:30   ` Donny Davies
                     ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Stuart Herbert @ 2003-08-05  0:14 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05  0:14 ` Stuart Herbert
@ 2003-08-05  2:30   ` Donny Davies
  2003-08-05 10:12     ` Stuart Herbert
  2003-08-05  3:04   ` Max Kalika
  2003-08-05  9:34   ` Paul de Vrieze
  2 siblings, 1 reply; 38+ messages in thread
From: Donny Davies @ 2003-08-05  2:30 UTC (permalink / raw
  To: gentoo-dev

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05  0:14 ` Stuart Herbert
  2003-08-05  2:30   ` Donny Davies
@ 2003-08-05  3:04   ` Max Kalika
  2003-08-05 10:39     ` Stuart Herbert
  2003-08-05  9:34   ` Paul de Vrieze
  2 siblings, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-05  3:04 UTC (permalink / raw
  To: stuart, Max Kalika, Troy Dack, gentoo-dev

Uh oh.  I think we are talking about the same thing.  It seems to me that
we're going towards the same ends but by a different means.  I think we're
getting really close.  I know you're dying of anticipation so ... read on!

Quoting Stuart Herbert <stuart@gentoo.org>:

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

Lets skip this...see below.

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

Ok, I'm following now.

>> Ok, this is debatable, but I'm willing to change the eclass to take
>> -apache2 into effect.
> 
> [OT, but interesting] How is this debatable?

Seems to me that if the server is installed, it should be taken into
account.  But that's entirely personal opinion.  USE flags are more correct
for the general public.

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

Right-o. I'll make a note to do this in the eclass.

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

I think I missed something.  I thought you wanted to use SLOTs for somehow
maintaining the same version of the same package.  I think we are on the
same page, now.  In the eclass we can go ahead and do something similar to
the kernel ebuilds -- make SLOT="${PV}" or even SLOT="${PV}-${PR}".

> If the package management system provided a viable solution, don't you
> think  that people would use it?

Certainly.

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

This is where I misunderstood.  I thought you wanted portage to take care
of everything -- i.e. emerge -u 'webapp' would somehow magically upgrade
all the copies.  This is actually a more elegant version of the cp -a thing
that I mentioned in the previous post.  I think we have our answer.  Next
step would be to write up the necessary functionality for the webapp-config
utility.

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

Nothing.  It just took 16 posts to get it through my dense skull. :-)

> Nope.  I'm telling Portage to maintain the master copy of a package, and
> to  upgrade that master copy only.

Ding Ding Ding!

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

It doesn't and can't.  The one instance/configure is definitely the way to
go.

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

Well then, lets the the first.  :-)

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

Because we have the one group that we know all webservers are going to run
as (yes yes, the sysadmin can change what group the server runs as, and if
he/she does, then he/she can also change the ownership of the directory).
If we assume that all webservers will run as the same group, then
configuring those apps which need a writeable directory becomes easy indeed.

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

Yup.  We were talking about the same thing.  Just a different way of doing
the post-install config.  I'd like to help with the design/code of the
webapp-config utility.

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

I'd say it is important because -rX releases may have added
functionality/features that some may not want, etc.

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

It could happen!

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

I thought those were apache conventions.  It really doesn't matter one way
or another. :-)

>> Is the approach currently in the eclass unacceptable? (Check for the
>> existence 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!)

checking...still checking...done!  It could probably be simplified to
something like the following: (I'm just the nitpick mongrel, aren't I?)

if [ "`has_version '=net-www/apache-2*'`" -a "`use apache2`" ] ; then
	APACHEVER=2
elif [ "`has_version '=net-www/apache-1*'`" ] ; then
	APACHEVER=1
else
	# no apache version detected
	return 1
fi

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

No offense taken of course.  Lets just evolve yours overtime to do
everything that's needed because, as you say, it is already in portage. :-)

--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] Re: [gentoo-core] Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-03 14:49     ` [gentoo-dev] Re: [gentoo-core] " Stuart Herbert
@ 2003-08-05  3:46       ` Robin H.Johnson
  2003-08-05 10:21         ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Robin H.Johnson @ 2003-08-05  3:46 UTC (permalink / raw
  To: Stuart Herbert, Max; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Sun, Aug 03, 2003 at 03:49:20PM +0100, Stuart Herbert wrote:
> Have I missed anyone?  Robin?
Put me on the list as well, I've spent long enough writing PHP webapps
that I know what is going on, and I'm hoping to spear-head the
webapp-config tool once the debate it all settled.

Also, so that Max and you know, I have definetly been following your
discussion about the GLEP, eclass and webapp-config, and I am pleased to
see it being very productive. I have little additional input to what you
have come up with, as this is generally what I intended anyway.
There have been a few minor bumps and blips but things appear to be
smooth now. All of the web-apps will definetly be slotted. I originally
noted by their major version numbers as those are used to show
incompatibilities in most cases, but from some of the other comments,
slotting them fully by the complete version number is looking better
now. One clarification however, multiple instances of webapps are NOT
nessicarily across vhosts, in several cases, you may want multiple
instances of a webapp on a single vhost or many other variants of that.
The administrator would be telling us exactly where he wants us placed,
and we can ask for more information as needed if we can't figure it out.

Part of this could possibly also be aided by a later config tool to
create virtual hosts. I already have one that I use for my own setup,
but it would need quite a bit of work for Gentoo purposes.

I'm still very busy with work but things are looking up now (plus today
was a public holiday here), so while I'm not on IRC much anymore, I'm
certainly around on email and CVS.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
                   ` (2 preceding siblings ...)
  2003-08-03  0:30 ` Austin Frank
@ 2003-08-05  8:12 ` Troy Dack
  3 siblings, 0 replies; 38+ messages in thread
From: Troy Dack @ 2003-08-05  8:12 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

On Sun, 2003-08-03 at 02:50, Troy Dack wrote:
> Please review the attached GLEP and comment on my attempt to formalise
> and summarise this discussion.

WOW!
	I really didn't expect this level of discussion, seems I threw the cat
into the fire with this.

I'll attempt to integrate the comments into the GLEP in the next 24
hours and have a revision up by about 0400 UTC 06 AUG.  

From there I will also submit it to glep@gentoo.org so that those who
will be implementing it can fine tune it.

Thanks for the positive responses :)

-- 
Troy Dack        "Yes, yes, I know that, Sydney ... Everybody knows that!
tad@gentoo.org    ... But look: Four wrongs squared, minus two wrongs to 
                  the fourth power, divided by this formula, do make a
                  right." -- Gary Larson

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C
 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05  0:14 ` Stuart Herbert
  2003-08-05  2:30   ` Donny Davies
  2003-08-05  3:04   ` Max Kalika
@ 2003-08-05  9:34   ` Paul de Vrieze
  2003-08-05 11:19     ` Stuart Herbert
  2 siblings, 1 reply; 38+ messages in thread
From: Paul de Vrieze @ 2003-08-05  9:34 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1587 bytes --]


Ok what about the following.

The problem that is most existent in this case is the fact that you want the 
eclass to support almost every kind of use. That is nice indeed. But making 
things easy for single hostname smalltime servers, and for extensive virtual 
hosting supports with customized webservers etc. is complicated. Also in that 
case default apache configuration snippets don't make that much sense. I 
think a solution could be to introduce a "local" useflag that selects 
behaviour.

If you have a simple webserver for personal use, you can just leave things as 
they are and you can just run the config script or take some simple actions 
and everything works. For the other case the configuration tool can be used 
to create instances of a webapp for different virtual servers. That tool 
would probably need some configuration file etc. and it might even perform 
changes to the CONTENTS file to make the instances being included in the 
ebuild (when removing). It could then also automatically change the slot of 
the installed package so that it does not automatically get removed.

I think that should be able to keep both sides happy.

Paul

ps. one thing I want to add though is that for a simple installation I think 
the configuration files should be config-protected (how that is aranged I 
don't care), and for complex setups the instance configurations should also 
be protected in some way (but that might be handled by the tool)

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-04 22:16 ` Stuart Herbert
@ 2003-08-05  9:49   ` Michael Cummings
  0 siblings, 0 replies; 38+ messages in thread
From: Michael Cummings @ 2003-08-05  9:49 UTC (permalink / raw
  To: gentoo-dev

To chime in...

On Mon, Aug 04, 2003 at 11:16:15PM +0100, Stuart Herbert wrote:
Content-Description: signed data
> On Monday 04 August 2003 6:11 pm, Max Kalika wrote:
> > Good morning!
> 
> Evening, Max.
> 
> > See, I don't think that running two (or more) copies of an application is
> > supporting virtual hosts.  Upgrading all the files is a pain.  Why not have
> > one installation of the core files and multiple installations of the config
> > files?  This is, of course, very application specific -- most of them will
> > still need database upgrades, but that has to be done by the sysadmin.
> 
> Because that won't quite work, unless the app is aware of virtual hosting - 
> and many (if not most) aren't.  Think about it.
> 
> Here's an example.  Imagine hosting (oh, I don't know) www.iammax.com and 
> www.maxisgreat.com on the same physical box.  Document roots for each are 
> /var/www/<host>/public_html/ for arguments sake.
> 
> Now imagine running phpBB on both domains, to provide separate forums.  As far 
To take this one step further, where I work we host about 300+ domains plus
subdomains. We may install an app but expect to be able to customize the
interface for each customer - so I have to side with Stu on this one.


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


for what it's worth, i like this break out as well


Just wanted to add another voice to the fray - another lurker stepping
forward
-- 


-----o()o---------------------------------------------
              |  http://www.gentoo.org/
              |  #gentoo-dev  on irc.freenode.net
Gentoo Dev    |  #gentoo-perl on irc.freenode.net
Perl Guy      |
              |  GnuPG Key ID:       AB5CED4E9E7F4E2E
-----o()o---------------------------------------------


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05  2:30   ` Donny Davies
@ 2003-08-05 10:12     ` Stuart Herbert
  2003-08-06  4:01       ` Donny Davies
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-05 10:12 UTC (permalink / raw
  To: Donny Davies, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1026 bytes --]

Hi Donny, everyone,

Let me float a follow-on suggestion, after thinking about some of Donny's 
comments.

How do you feel about making /var/www the "official" Gentoo home for dynamic 
vhosts?  So we'd have something like

	/var/www/<host>/public_html/

as the docroot for the virtual host.

At the same time, how would you feel if, for single-domain installs, we made 
/var/www/localhost/public_html the default docroot, instead of /home/httpd. 

If the box ever needs to move to dynamic vhosts, the admin or config-toolset 
just has to drop in a symlink in /var/wwww to expose the site as a virtual 
domain.

Best regards,
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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] Re: [gentoo-core] Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05  3:46       ` Robin H.Johnson
@ 2003-08-05 10:21         ` Stuart Herbert
  0 siblings, 0 replies; 38+ messages in thread
From: Stuart Herbert @ 2003-08-05 10:21 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2144 bytes --]

On Tuesday 05 August 2003 4:46 am, Robin H.Johnson wrote:
> Put me on the list as well, I've spent long enough writing PHP webapps
> that I know what is going on, and I'm hoping to spear-head the
> webapp-config tool once the debate it all settled.

Excellent.  Anyone else feel like hacking webapps at all?  How well covered 
are we for supporting mod_perl and mod_python based apps right now?

> Also, so that Max and you know, I have definetly been following your
> discussion about the GLEP, eclass and webapp-config, 

Good.  You've got a lot of first-hand experience that I think's important to 
ensuring that what we put in really hits the mark.

> One clarification however, multiple instances of webapps are NOT
> nessicarily across vhosts, in several cases, you may want multiple
> instances of a webapp on a single vhost or many other variants of that.
> The administrator would be telling us exactly where he wants us placed,
> and we can ask for more information as needed if we can't figure it out.

Good point.  We'd need to test each webapp to make sure that it doesn't expect 
to at a hard-coded place relative to the docroot.  Some webapps, for example, 
are hard coded to expect to be at the url http://<vhost>/, and break badly if 
they're (say) placed at http://<vhost>/people/stu/.

> Part of this could possibly also be aided by a later config tool to
> create virtual hosts. I already have one that I use for my own setup,
> but it would need quite a bit of work for Gentoo purposes.

Maybe it's off-topic, but you'll probably have an answer that I don't.  On my 
boxes, I always use Apache's dynamic vhost support.  Are there times/reasons 
when dynamic vhost support isn't the way to go?

Best regards,
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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05  3:04   ` Max Kalika
@ 2003-08-05 10:39     ` Stuart Herbert
  0 siblings, 0 replies; 38+ messages in thread
From: Stuart Herbert @ 2003-08-05 10:39 UTC (permalink / raw
  To: Max Kalika, Troy Dack, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 3692 bytes --]

Hi Max,

Looks like we're almost there, doesn't it? ;-)

On Tuesday 05 August 2003 4:04 am, Max Kalika wrote:
> >> 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?
>
> Because we have the one group that we know all webservers are going to run
> as (yes yes, the sysadmin can change what group the server runs as, and if
> he/she does, then he/she can also change the ownership of the directory).
> If we assume that all webservers will run as the same group, then
> configuring those apps which need a writeable directory becomes easy
> indeed.

We'd need to get Donnie on board to make this happen.

I'd just assumed that the webapp-config toolset would automagically take care 
of this for us (see my earlier post about what assumptions are ;-)

> > (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.
>
> I'd say it is important because -rX releases may have added
> functionality/features that some may not want, etc.

Then let's ask Tad to put ${PF} into the GLEP.

> >> 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 ;-)
>
> It could happen!

Lots of laughter.

> > 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.
>
> I thought those were apache conventions.  It really doesn't matter one way
> or another. :-)

Let's stick with 'public_html' and 'cgi-bin' then.

> checking...still checking...done!  It could probably be simplified to
> something like the following: (I'm just the nitpick mongrel, aren't I?)
>
> if [ "`has_version '=net-www/apache-2*'`" -a "`use apache2`" ] ; then
> 	APACHEVER=2
> elif [ "`has_version '=net-www/apache-1*'`" ] ; then
> 	APACHEVER=1
> else
> 	# no apache version detected
> 	return 1
> fi

According to the description in profiles/use.desc ...

	"apache2 - Chooses Apache2 support when a package supports both Apache1
	 and Apache2"

With your version, if the user has Apache2 support, but doesn't have 'apache2' 
in the USE flags, no apache version will be detected.  That doesn't seem to 
match the description in profiles/use.desc.

> No offense taken of course.  Lets just evolve yours overtime to do
> everything that's needed because, as you say, it is already in portage. :-)

Tbh, I wouldn't be surprised (or upset - I'm not the possessive type) if the 
eclass I've added to portage has to go when we implement this GLEP.

Last night on IRC, I offered to TaD to code up a new eclass to provide a 
demonstration implementation of that part of the GLEP.  Very earliest I could 
do this would be sometime next week, as I'm away for a long weekend from 
Thursday.

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  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
  0 siblings, 2 replies; 38+ messages in thread
From: Stuart Herbert @ 2003-08-05 11:19 UTC (permalink / raw
  To: Paul de Vrieze, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 4706 bytes --]

Hi Paul,

Thanks for joining in.  I was getting worried that this was turning into the 
'Max & Stuart Show' ;-)

Here's my rambling thoughts about how the 'local' USE flag (can we call it 
'-vhosts' instead? 'local' feels a bit non-descript to me) could work, and 
what problems might occur.  I'm sure that my thoughts here aren't the only 
possible solution.

Under the '+vhosts' approach, webapps would be SLOT'd, and would go into

	/usr/share/webapps/${PF}/

and users would have to use the -config toolset to then make the app available 
inside one or more vhosts.

What would happen in the '-vhosts' world?

I think it all pivots around one crucial design decision.  In the '-vhosts' 
world, do we want 'emerge -u' to be all that the user has to do (i.e. no need 
for the -config toolset)?  If not, then I can't see what '-vhosts' would 
actually do, and I'd suggest dropping it.

Let's explore what changes the 'emerge -u' objective might have to bring into 
the design.

I think that SLOT'ing webapps would have to be switched off when '-vhosts' is 
in effect.  Can we dynamically change the SLOT value inside an ebuild without 
upsetting Portage?  Let's assume we can for the moment.

I think the webapp would have to be installed directly under the 
'DocumentRoot' (/home/httpd/htdocs currently for Apache), instead of 
/usr/share/webapps/.  Would this create support hell if a user then wanted to 
move to vhosting on the same box?  emerge -C <webapp> will clean up 
correctly, so I'm not worried about that.  I think we could live with this.

As for config-protecting a webapp's configuration files, I'd do it by making 
the eclass add the config files to the CONFIG_PROTECT mask somehow.  The 
webapp ebuild needs to be able to identify the package's config files as part 
of the '+vhosts' solution, so the information would be available.  But I 
wonder if we'd need a change to Portage to allow the eclass to dynamically 
add these files to the CONFIG_PROTECT mask.  It wouldn't need to be a 
permanent addition - in fact, I'd argue against it.

(Lots of laughter.  Just listening to the radio, and apparently the heatwave 
we're having right now is causing parts of one of our busiest motorways to 
melt).

Speaking of eclasses, one way to hide the differences of the +/-vhosts world 
from the ebuild is to handle the differences entirely in the eclasses.

	# webapp.ebuild
	inhert webapp-proxy

	# webapp-proxy.eclass
	use 'vhosts' && inherit webapp-vhosts || inherit webapp-simple

webapp-vhosts.eclass (or whatever it's called) would have to present the same 
interface (same functions w/ same parameters in) as webapp-simple.eclass.

Just some thoughts,
Stu
--
On Tuesday 05 August 2003 10:34 am, Paul de Vrieze wrote:
> Ok what about the following.
>
> The problem that is most existent in this case is the fact that you want
> the eclass to support almost every kind of use. That is nice indeed. But
> making things easy for single hostname smalltime servers, and for extensive
> virtual hosting supports with customized webservers etc. is complicated.
> Also in that case default apache configuration snippets don't make that
> much sense. I think a solution could be to introduce a "local" useflag that
> selects behaviour.
>
> If you have a simple webserver for personal use, you can just leave things
> as they are and you can just run the config script or take some simple
> actions and everything works. For the other case the configuration tool can
> be used to create instances of a webapp for different virtual servers. That
> tool would probably need some configuration file etc. and it might even
> perform changes to the CONTENTS file to make the instances being included
> in the ebuild (when removing). It could then also automatically change the
> slot of the installed package so that it does not automatically get
> removed.
>
> I think that should be able to keep both sides happy.
>
> Paul
>
> ps. one thing I want to add though is that for a simple installation I
> think the configuration files should be config-protected (how that is
> aranged I don't care), and for complex setups the instance configurations
> should also be protected in some way (but that might be handled by the
> tool)

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05 11:19     ` Stuart Herbert
@ 2003-08-05 11:37       ` Paul de Vrieze
  2003-08-05 21:00       ` Max Kalika
  1 sibling, 0 replies; 38+ messages in thread
From: Paul de Vrieze @ 2003-08-05 11:37 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 730 bytes --]

On Tuesday 05 August 2003 13:19, Stuart Herbert wrote:
> Hi Paul,
>
> Thanks for joining in.  I was getting worried that this was turning into
> the 'Max & Stuart Show' ;-)
>
> Here's my rambling thoughts about how the 'local' USE flag (can we call it
> '-vhosts' instead? 'local' feels a bit non-descript to me) could work, and
> what problems might occur.  I'm sure that my thoughts here aren't the only
> possible solution.

'Local' was meant as local use flag in comparision with global use flag. Not 
the name. It probably needs to be global anyway, because you would want it 
for all packages using the eclass.

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  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
  1 sibling, 1 reply; 38+ messages in thread
From: Max Kalika @ 2003-08-05 21:00 UTC (permalink / raw
  To: stuart, Paul de Vrieze, gentoo-dev

Quoting Stuart Herbert <stuart@gentoo.org>:

> Thanks for joining in.  I was getting worried that this was turning into
> the  'Max & Stuart Show' ;-)

Can we get a time slot on FOX?  I'm thinking 9:12AM. :-)

> Under the '+vhosts' approach, webapps would be SLOT'd, and would go into
> 
> 	/usr/share/webapps/${PF}/

Just the SLOTed? Or all the webapps?  Why not all?

> and users would have to use the -config toolset to then make the app
> available  inside one or more vhosts.
> 
> What would happen in the '-vhosts' world?
> 
> I think it all pivots around one crucial design decision.  In the
> '-vhosts'  world, do we want 'emerge -u' to be all that the user has to
> do (i.e. no need  for the -config toolset)?  If not, then I can't see
> what '-vhosts' would  actually do, and I'd suggest dropping it.

I don't think we want emerge -u to touch anything other than the central
install.

> I think the webapp would have to be installed directly under the 
> 'DocumentRoot' (/home/httpd/htdocs currently for Apache), instead of 
> /usr/share/webapps/.  Would this create support hell if a user then
> wanted to  move to vhosting on the same box?  emerge -C <webapp> will
> clean up  correctly, so I'm not worried about that.  I think we could
> live with this.
> 
> As for config-protecting a webapp's configuration files, I'd do it by
> making  the eclass add the config files to the CONFIG_PROTECT mask
> somehow.  The  webapp ebuild needs to be able to identify the package's
> config files as part  of the '+vhosts' solution, so the information would
> be available.  But I  wonder if we'd need a change to Portage to allow
> the eclass to dynamically  add these files to the CONFIG_PROTECT mask.
> It wouldn't need to be a  permanent addition - in fact, I'd argue against
> it.

Is it really necessary to separate the whole virtual/local?  Can we develop
the -config tool to take the following syntax?

  # webapp-config <application> <destination_dir>

The application can be specified by the currently supported portage syntax,
i.e. =web-dev/horde-2* or >=web-mail/imp-3 or simply web-db/phpmyadmin.
The tool then looks for a list of installed apps that match.  If more than
one is found it either bombs out or presents a choice menu.

Otherwise it goes ahead and configures the destination_dir to contain the
specified app.  First it checks for existence of the app already in the
destination.  If nothing exists, we create the directory, and copy the core
and conf files in.  If the app already exists, we switch to "upgrade" mode
where we overwrite all the core files and do dispatch-conf-type work to
protect the config files.

How do we know which files are config files and which are core files, I
hear you asking?  How about this:  Either use the Portage API or look at
the /var/db/pkg/$CATEGORY/$PF/CONTENTS file ourselves.  'obj' types stored
in '/usr/share/webapp' (or $WEBAPP_DEST or whatever) are "core" files;
'obj' types stored in '/etc/webapps' (or $WEBAPP_ETC) are "conf" files.
Everything else (docs, etc) doesn't need to go into the webserver space.

So if this is how things work, there's no need to worry about what is a
vhost and what is a single install.  Also we don't have to be concerned
where the DocRoot is -- the user just specifies the destination directory.

I guess this is a very rough first-draft proposal for the webapp-config.  I
am probably missing major chunks, but this is a braindump of what I thought
of so far.  Flog me for anything blatantly erroneous.


--mk

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05 21:00       ` Max Kalika
@ 2003-08-05 23:43         ` Cal Evans
  2003-08-06  1:54           ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Cal Evans @ 2003-08-05 23:43 UTC (permalink / raw
  To: Max Kalika; +Cc: stuart, Paul de Vrieze, gentoo-dev

Max & Stuart,

Personally, As someone who runs both types of servers, I would prefer a
separate behavior.

My server here at the house hosts 1 domain and I like the default way
gentoo handles that. It's easy for me to test things out etc.  But on my
production servers, I like the idea of being able to set +vhosts and have
it work as described.

Just chiming in on a very interesting thread.

My $0.02 worth, take it for what it's worth.
=C=
*
* Cal Evans
* http://www.christianperformer.com
* Stay plugged in to your audience!
*

Max Kalika said:
> Quoting Stuart Herbert <stuart@gentoo.org>:
> Is it really necessary to separate the whole virtual/local?

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05 23:43         ` Cal Evans
@ 2003-08-06  1:54           ` Stuart Herbert
  2003-08-06  2:16             ` Robin H.Johnson
  0 siblings, 1 reply; 38+ messages in thread
From: Stuart Herbert @ 2003-08-06  1:54 UTC (permalink / raw
  To: Cal Evans, Max Kalika; +Cc: Paul de Vrieze, gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1984 bytes --]

Hi Cal!

On Wednesday 06 August 2003 12:43 am, Cal Evans wrote:
> Max & Stuart,
>
> Personally, As someone who runs both types of servers, I would prefer a
> separate behavior.
>
> My server here at the house hosts 1 domain and I like the default way
> gentoo handles that. It's easy for me to test things out etc.  But on my
> production servers, I like the idea of being able to set +vhosts and have
> it work as described.

Yeah.  I think we can make -vhosts be the equivalent of what we have today, 
and +vhosts do the whole virtual server thing.  I'm willing to code it up and 
trial it, to see how well it works in practice.

Which leads me onto another TonyTangent(tm).  Once we have something 
implemented, I don't think it should go into Portage straight away.  I think 
we should recruit a small team of knowledgable testers, and roll it out to 
them first for a whole cycle or two of release/test/scratch head/try again.  
It'll take a bit longer, sure, but it'll mean that what goes into Portage and 
into general use will already be bedded in.

Btw, talked to Woodchip on IRC tonight, and he seemed happy enough with us 
moving the default -vhosts DocRoot from /home/httpd.  So I'm gonna strongly 
advocate that the default -vhosts DocRoot moves to 
/var/www/localhost/public_html in the near future.

> Just chiming in on a very interesting thread.

Glad you have.  The more feedback we can get, the better the final solution 
will be.  I'd hate us to implement something that we devs found acceptable, 
but no-one else wanted to use ;-)

Best regards,
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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-06  1:54           ` Stuart Herbert
@ 2003-08-06  2:16             ` Robin H.Johnson
  2003-08-06  2:44               ` Stuart Herbert
  0 siblings, 1 reply; 38+ messages in thread
From: Robin H.Johnson @ 2003-08-06  2:16 UTC (permalink / raw
  To: Stuart Herbert; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

On Wed, Aug 06, 2003 at 02:54:19AM +0100, Stuart Herbert wrote:
Content-Description: signed data
> Yeah.  I think we can make -vhosts be the equivalent of what we have
> today, and +vhosts do the whole virtual server thing.  I'm willing to
> code it up and trial it, to see how well it works in practice.
Where do you see -vhosts fiting into having multiple instances of a
webapp on a single host ?

> Which leads me onto another TonyTangent(tm).  Once we have something
> implemented, I don't think it should go into Portage straight away.  I
> think we should recruit a small team of knowledgable testers, and roll
> it out to them first for a whole cycle or two of release/test/scratch
> head/try again.  It'll take a bit longer, sure, but it'll mean that
> what goes into Portage and into general use will already be bedded in.
On the experience I gained from working on the php eclass and ufed,
Portage is a very good distribution mechanism, even if it is only for
initial testing. Just keep it hardmasked while testing with a few big
warnings. This also enables us to get a very wide test base including
outside users if we so desire. The concept of an initial testing run is
definetly worthwhile, but also a strong warning that what you intend as
a testing round has a hard habit of sticking around a lot longer than
expected no matter what form it is in.

> Btw, talked to Woodchip on IRC tonight, and he seemed happy enough
> with us moving the default -vhosts DocRoot from /home/httpd.  So I'm
> gonna strongly advocate that the default -vhosts DocRoot moves to
> /var/www/localhost/public_html in the near future.
Sounds good.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-06  2:16             ` Robin H.Johnson
@ 2003-08-06  2:44               ` Stuart Herbert
  0 siblings, 0 replies; 38+ messages in thread
From: Stuart Herbert @ 2003-08-06  2:44 UTC (permalink / raw
  To: Robin H.Johnson; +Cc: gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1642 bytes --]

On Wednesday 06 August 2003 3:16 am, Robin H.Johnson wrote:
> Where do you see -vhosts fiting into having multiple instances of a
> webapp on a single host ?

Personally, I don't.  If you want multiple instances of a webapp on a single 
host, the webapps need to be installed with +vhosts.

-vhosts would be strictly single copy single domain scenario.

> On the experience I gained from working on the php eclass and ufed,
> Portage is a very good distribution mechanism, even if it is only for
> initial testing. Just keep it hardmasked while testing with a few big
> warnings. This also enables us to get a very wide test base including
> outside users if we so desire. The concept of an initial testing run is
> definetly worthwhile, but also a strong warning that what you intend as
> a testing round has a hard habit of sticking around a lot longer than
> expected no matter what form it is in.

Okay, I'll go with that.

> > Btw, talked to Woodchip on IRC tonight, and he seemed happy enough
> > with us moving the default -vhosts DocRoot from /home/httpd.  So I'm
> > gonna strongly advocate that the default -vhosts DocRoot moves to
> > /var/www/localhost/public_html in the near future.
>
> Sounds good.

;-)

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [gentoo-dev] [GLEP] Web Application Installation
  2003-08-05 10:12     ` Stuart Herbert
@ 2003-08-06  4:01       ` Donny Davies
  0 siblings, 0 replies; 38+ messages in thread
From: Donny Davies @ 2003-08-06  4:01 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

Hi Stuart

On Tue, Aug 05, 2003 at 11:12:05AM +0100, Stuart Herbert wrote:
>How do you feel about making /var/www the "official" Gentoo home for dynamic 
>vhosts?  So we'd have something like
>
>	/var/www/<host>/public_html/
>
>as the docroot for the virtual host.
>
>At the same time, how would you feel if, for single-domain installs, we made 
>/var/www/localhost/public_html the default docroot, instead of /home/httpd. 
>
>If the box ever needs to move to dynamic vhosts, the admin or config-toolset 
>just has to drop in a symlink in /var/wwww to expose the site as a virtual 
>domain.

Very reasonable.  /home/httpd was the result of moving from the very old
/usr/local/httpd, which is where things were installed before I gave the
Apache ebuild a massive overhaul.  We need not stay with /home/httpd
forever, in fact it really does need to move somewhere else.  Looks
like /var/www has become the defacto standard.

Donny

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-07  1:08 Troy Dack
  0 siblings, 0 replies; 38+ messages in thread
From: Troy Dack @ 2003-08-07  1:08 UTC (permalink / raw
  To: glep; +Cc: gentoo-dev@gentoo.org


[-- Attachment #1.1: Type: text/plain, Size: 861 bytes --]

Please find attached a GLEP (#11?) detailing standards for Gentoo Web
Application Installations.

Some areas (notably vhost related) require more detail.

The initial draft of this GLEP resulted in a very productive discussion
on the gentoo-dev mailing list, with a number of developers
contributing.

Acceptance of this GLEP will enable the developers of the required tools
to complete the tools and the details of the proposal.

-- 
Troy Dack        "Yes, yes, I know that, Sydney ... Everybody knows that!
tad@gentoo.org    ... But look: Four wrongs squared, minus two wrongs to 
                  the fourth power, divided by this formula, do make a
                  right." -- Gary Larson

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C
 

[-- Attachment #1.2: glep-webapps-1.1.txt --]
[-- Type: text/plain, Size: 9809 bytes --]

GLEP: 11
Title: Web Application Installation
Version: $Revision: 1.1 $
Last-Modified: $Date: 2003/08/07 10:00 $
Author:	Troy Dack <tad@gentoo.org>
Discussions-To: gentoo-dev@gentoo.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 02 August 2003
Post-History: 03 Aug 2003

Credits
=======

Based on comments posted to gentoo-dev mailing list [#WebAppPost1]_
[#WebAppPost2]_ [#WebAppPost3]_ by:

	Stuart Herbert <stuart@gentoo.org>, Max Kalika <max@gentoo.org>,
	Robin H.Johnson <robbat2@gentoo.org> and others

Definitions
===========

	*Web Application*
		an application that requires a web server to function and interacts with
		the user via a browser

	*Web Application Instance*
		An apparent install of the Web Application that is served up via the
		webserver. There may be any number of instances per Web Application.
		This is a major use for web applications. Our Gentoo Zope setup
		already provides instances and can be used for some concepts on this
		matter.

	*Web Application Setup Program*
		A script similar in function to zope-config that sets up instances.

	*Document Root*
		a location in the file system that forms the main document tree visible from
		the web

Conventions
===========

	When describing the location of a directory in the file system it
	wil be shown *with* a trailing, eg::

		/foo/bar/

	When describing the location of a specific file (irrespective of any
	file extention) it will shown *with out* a trailing slash, eg::

		/foo/blah

Abstract
========

To define where and how web based applications should be installed by Gentoo.

Motivation
==========

Currently there is no standard defined regarding the installation of web
based applicaitons in Gentoo.  This leads to ebuild authors creating a
variety of methods to determine:

	* where the application should be installed
	* what user and permissions the application should be given
	* where any configuration files related to the application should be
	  installed.

Due to a lack of standard install method configuration files are at
risk of being overwritten during upgrade, potentially causing system
administrators down tine as they have to reconfigure web applications
after an upgrade.

Rationale
=========

A discussion on the gentoo-dev mailing list [#WebAppPost1]_ raised the
following points regarding how Gentoo handles the installation of web based
applications:

	1. Gentoo installed web applications (eg: horde, phpbb, cacti,
	   phpmysql) should not be installed in the Document Root of a web server.
	2. Web applications should not have their configuration files installed
	   under the Document Root of a web server.

		i. Web Application must be slotted by their major version numbers to
		   further avoid downtime when true configuration changes are required.

	3. Web applications should not be owned by the same user as the web server.
	4. It should be easily possible to have multiple instances of a web
	   application without any duplication of source files.
	5. It should be immediately apparent how to control instances of a web
	   application.

Implementation
==============

Max Kalika <max@gentoo.org> stated that he has a preliminary eclass that
implements a good deal of this GLEP.

Stuart Herbert <stuart@gentoo.org> has committed::

	webapp-apache.eclass

to CVS, this is a stop-gap measure whilst this GLEP is being finalised.


1. Web Server
---------------------

A common default web server will have to be selected and ebuild authors should
ensure that their applications contain configuration directives suitable for
that server.  Given the popularity of the Apache web server it is suggested
that Apache be selected as the Gentoo default web server.

Whilst it is acknowledged that other web servers do exist and are used, there
has to be an assumption made somewhere that people who choose to use something
other than the default have enough knowledge to adapt configurations
accordingly.

1.1 Default Document Root
'''''''''''''''''''''''''

To ensure the greatest flexibility when installing applications the following
*Document Root* locations are to be used:

	* For single host installations::

		/var/www/localhost/htdocs/

	* For multiple virtual host installastions::

		/var/www/<fully qualified domain name>/htdocs/
		eg:
			/var/www/www.gentoo.org/htdocs/

1.2 Apache 2
''''''''''''''''''''''''

All web application .ebuild will honour any USE flags that are intended to
add support for Apache 2 as well as supporting Apache 1 installations.


2. Virtual Host Flexibility
---------------------------

In a similar vein to Gentoo's Zope scripts, namely zope-config, we
should be able to have multiple instances of a single web application
without duplicating all of the files.

This also allows system administrators to control where web applications
will appear on their system, as well as to customize a file in a single
instance of a web application without effecting the original material.

This is easily acheived thru use of Apache configuration directivies and
symlinks. For PHP instances, see http://tavi.sourceforge.net/VirtualHosts
for some details.

The primary idea here is that to the web-application, it appears that
all of it's configuration and files are in the instance directory, but
the files are physicalled located elsewhere.

2.1 New "vhost" USE Flag
''''''''''''''''''''''''

To enable support for multiple virtual host installations a new USE flag is
to be added to Portage. The use flag will be::

	vhost

When *vhost* is _set_ the installation location and configuration for the web
application will be effected, see below for more details.

2.2 VHost Configuration Tool
''''''''''''''''''''''''''''

To assist administration of multiple virtual hosts a "VHost Configuration Tool"
needs to be developed and implemented.  Initial discussion and regarding the VHost
Config tool can be found at http://article.gmane.org/gmane.linux.gentoo.devel/10874.

The VHost Configuration Utility will need to be a seperate package, maintained by Gentoo.
Apache .ebuilds will require the VHost Config tool as a dependency (DEPEND).

<< TO BE EXPANDED UPON >>

3. Application Installation Location
------------------------------------

The current accepted standard Document Root in Gentoo is /home/httpd.  The
discussion suggest that this is not the best location to install web based
applications.

Web applications should be installed outside of the Document Root using the following
defaults:

	* for files to be served to clients::

		/usr/share/webapps/${PF}/

		/usr/share/webapps/${PF}/public_html/ for files served by the web server

		/usr/share/webapps/${PF}/cgi-bin/ for CGI-BIN files

	* install configuration files in::

		/etc/webapps/${PF}/

	* for documentation files (not served to clients)::

		/usr/share/doc/${PF}/

3.1 Single Host Installation
''''''''''''''''''''''''''''

For single host installations the .ebuild will make the required
configurations changes and symlinks using the VHost Config tool to ensure
that the web application is available to be served from::

	/var/www/localhost/htdocs/${PN}

3.2 Virtual Host Installation
'''''''''''''''''''''''''''''

For installations that support multiple virtual hosts the .ebuild will
install the web application into the default location and then leave configuration
to the user through the VHost Config tool.

<< TO BE EXPANDED UPON >>

4. Application Configuration
----------------------------

Having application configuration files in the Document Root of a web
server is a potential security risk.  Additionally given the way that many
ebuilds currently install web applications it can also lead to the
overwriting of important configuration files.

As stated above web application configuration files are to be installed into::

	/etc/webapps/${PF}/

By installing application configuration files in /etc Portage CONFIG_PROTECT
features can be used to ensure that configuration files are not overwritten.

4.1 Virtual Host Support
''''''''''''''''''''''''

<< TO BE EXPANDED UPON >>

5. Application Permissions
--------------------------

Installing web applications and giving the web server ownership of the files
is a security risk.  This can possibly lead to application configuration
files being accessed by unwanted third parties.

All web applications should be owned by *root* unless the application
absolutely requires write access to its installation directories at execution
time.

Backwards Compatibility
=======================

There may be some issues regarding compatibility with existing installs of
web applications.  This is particularly true if the default Document Root is
moved from what is accepted as the current standard (/home/httpd).

The main issues are:
	* transition of existing configuration files to the
	  /etc/webapps/${PF}/ directory.
	* modification/reconfiguration of applications so that they
	  are aware of the location of configuration files.
	* creating approriate Apache configuration snippets for inclusion
	  in the Apache configuration files.


References
==========

.. [#WebAppPost1] http://article.gmane.org/gmane.linux.gentoo.devel/10411
.. [#WebAppPost2] http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&root=%3C1059843010.5023.80.camel%40carbon.internal.lan%3E
.. [#WebAppPost3] http://news.gmane.org/onethread.php?group=gmane.linux.gentoo.devel&root=%3C86960000.1060038977%40valkyrie.lsit.ucsb.edu%3E

Copyright
=========

This document has been placed in the public domain.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2003-08-07  1:08 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation 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-03 14:49     ` [gentoo-dev] Re: [gentoo-core] " Stuart Herbert
2003-08-05  3:46       ` Robin H.Johnson
2003-08-05 10:21         ` Stuart Herbert
2003-08-05  8:12 ` Troy Dack
  -- strict thread matches above, loose matches on Subject: below --
2003-08-04 17:11 Max Kalika
2003-08-04 22:16 ` Stuart Herbert
2003-08-05  9:49   ` Michael Cummings
2003-08-04 23:16 Max Kalika
2003-08-05  0:14 ` Stuart Herbert
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-07  1:08 Troy Dack

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox