* [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; 33+ 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] 33+ messages in thread
* Re: [gentoo-dev] [GLEP] Web Application Installation
2003-08-02 16:50 Troy Dack
@ 2003-08-02 20:39 ` Robin H.Johnson
2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
` (2 subsequent siblings)
3 siblings, 0 replies; 33+ 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] 33+ messages in thread
* Re: [gentoo-dev] [GLEP] Web Application Installation
2003-08-02 16:50 Troy Dack
2003-08-02 20:39 ` Robin H.Johnson
2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
@ 2003-08-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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ messages in thread
* Re: [gentoo-dev] [GLEP] Web Application Installation
2003-08-04 17:11 [gentoo-dev] [GLEP] Web Application Installation Max Kalika
@ 2003-08-04 22:16 ` Stuart Herbert
2003-08-05 9:49 ` Michael Cummings
0 siblings, 1 reply; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ messages in thread
* Re: [gentoo-dev] [GLEP] Web Application Installation
2003-08-02 16:50 Troy Dack
` (2 preceding siblings ...)
2003-08-03 0:30 ` Austin Frank
@ 2003-08-05 8:12 ` Troy Dack
3 siblings, 0 replies; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ messages in thread
* [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-07 1:08 Troy Dack
0 siblings, 0 replies; 33+ 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] 33+ messages in thread
end of thread, other threads:[~2003-08-07 1:08 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-08-04 17:11 [gentoo-dev] [GLEP] Web Application Installation Max Kalika
2003-08-04 22:16 ` Stuart Herbert
2003-08-05 9:49 ` Michael Cummings
-- strict thread matches above, loose matches on Subject: below --
2003-08-07 1:08 Troy Dack
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-02 16:50 Troy Dack
2003-08-02 20:39 ` Robin H.Johnson
2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
2003-08-02 23:51 ` Stuart Herbert
2003-08-03 2:26 ` [gentoo-dev] " Max Kalika
2003-08-03 14:46 ` Stuart Herbert
2003-08-03 15:20 ` Max Kalika
2003-08-03 17:43 ` Stuart Herbert
2003-08-03 19:03 ` Max Kalika
2003-08-03 19:43 ` Stuart Herbert
2003-08-04 4:29 ` Max Kalika
2003-08-04 10:43 ` Stuart Herbert
2003-08-03 0:30 ` Austin Frank
2003-08-03 7:50 ` Tal Peer
2003-08-03 14:45 ` Don Seiler
2003-08-05 8:12 ` Troy Dack
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox