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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ messages in thread

end of thread, other threads:[~2003-08-05 10:23 UTC | newest]

Thread overview: 19+ 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

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