From: Robin H.Johnson <robbat2@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] apache.eclass proposed
Date: Mon, 9 Jun 2003 22:43:04 -0700 [thread overview]
Message-ID: <20030610054304.GA9137@cherenkov.orbis-terrarum.net> (raw)
In-Reply-To: <20030610030204.GA31790@breccia.escarpment>
[-- Attachment #1: Type: text/plain, Size: 6734 bytes --]
On Mon, Jun 09, 2003 at 11:02:05PM -0400, Donny Davies wrote:
> Ned Ludd wrote:
> >The means by which the DocumentRoot is found is actually pretty elegant
> >and the functionality of that can easily be placed in an eclass. I'd
> >consider this a big plus in terms of usability. As you're pointing out,
> >/var/www is the FHS compliant place to put the documentroot anyway, so
> >I'm not sure why we're being like RedHat in this respect.
> I would strongly advise you to get your facts straight before
> rolling through here muttering something like that. This is not
> correct. I'm afraid you need to do some remedial reading on the
> situation.
I agree with Donny here. There is no standard place to put the
DocumentRoot. I have always used /var/www for a variety of reasons.
Amongst them, is that /home is in many larger setups, an NFS mount, and
I don't particuallar want to always have it mounted. (I am presently
looking at auto-mounting just the current users home directories install
of all of /home).
My personal setups for Apache do away with a single DocumentRoot, as I
usually have a number of VirtualHosts on each machine.
I do:
DocumentRoot /var/www/(domain)/(host)/
such that:
www.orbis-terrarum.net
comes from
/var/www/orbis-terrarum.net/www/
> You may want to visit http://www.pathname.com/fhs/ where you
> can learn that there *IS* no standard for this. And as such,
> the location in which to install Apache and other web-related
> files, is simply nothing more the opinion of the person you're
> currently talking to. The current FHS version doesnt address
> this area. I havent looked at any of the work in progress for
> FHS 2.3 by the way; perhaps there's new developments there?
There is nothing proposed for this in FHS2.3 AFAIK, or can find in the
FHS BugZilla.
> If you want even more standards, then please open your
> config.layout file, distributed with the Apache source code,
> and well, take your pick from several more "standards".
And be aware of the 'Gentoo' layout in it that we use for Apache2.
For Apache1, the ebuild specifies locations directly to override where
they are installed instead of the clean layout route that is used in
Apache2.
> As for the apache2 USE flag; I made it so that the mod_php
> ebuild didnt have to *guess* at which API to build the DSO
> for. I've talked with Robin about this, and we'd both very
> much like to see it "go away". It's nasty.
To revisit that discussion, I've actually had two users come to me
with another, better reason to have both installed at the same time:
"Being able to develop a web application that has to run in BOTH
environments, with only a single machine to work on."
"Using a single machine, running Apache2 for some custom module they
have, as well as having a really minimal Apache1 running to serve
tarballs without the overhead added by the Apache2 stuff they use."
> Robin H.Johnson wrote:
> >Having both installed simultaneously is a very messy business already,
> >as they both use /home/httpd, and contain binaries with identical names.
> They are configured to serve from the same DocumentRoot. I
> didnt want to introduce *another* docroot. They'll overwrite
> some icons from the other's install. I assume those who
> really, really want those default ASF icons from the other
> version, can figure out howto get them from the tarball.
> Same for the default introduction pages. Is this a big
> deal? What binaries are you talking about? I took
> pains to SLOT=2 Apache2, Im not aware of any binaries
> getting overwritten.
My apologies. Earlier on in the lifespan of Apache2 in Gentoo, more
things were overwritten, but it seems practically all of that is cleared
up now.
There are exactly two files outside of icons and htdocs that are
overwritten:
/home/httpd/cgi-bin/printenv
/home/httpd/cgi-bin/test-cgi
Seeing as they are identical in both Apache1 and Apache2, I don't see
any need for concern with them.
I also made a further comparision on icons and htdocs via md5sums.
Icons between the two are identical, and the old difference is that
Apache2 has a bunch of 'powered by apache2' logos as additional items.
The contents of htdocs have changed significently however, with no
common files between the two remaining the same.
> As for the eclass, it's obviously a natural progression.
> I have not attempted to create one yet because I dont
> really have a great idea for what functions it should
> provide. The very basic ones proposed were simply not
> enough to convince me to add this yet. If they were
> I would have added one months ago. What other functions
> would be desired from an web-related eclass? I'm not
> *completely* and outright opposed to the stuff proposed,
> Im just saying it's weak, and well, it certainly isnt
> a sic "way to totally and easily manage the whole
> Apache config" as somebody else mentioned. Far from
> it.
One point for a web applications eclass:
When web servers BEYOND Apache are present, the complexity involved in
finding the 'DocumentRoot' equivilent grows a LOT, and then it does make
sense to belong in an eclass, as somebody adding a web application
doesn't want to have to figure out the details behind how to get the
DocumentRoot from AOLServer for example.
We are a lot closer to this than you may realize.
We do presently have a few web servers:
Apache1/2
publicfile
resin(-ee)
mini_httpd
fnord
There really should be a virtual/webserver that many of these provide,
but you get into issues of what modules can be used to a degree.
There should NOT however, be anything to restricts you to only having a
single webserver installed.
> Further, Im not of the opinion that having a "bonifide"
> location in which to install these files on a Gentoo
> system (/home/httpd/{htdocs,cgi-bin} is a BAD idea,
> and having them just the way they are now at least
> provides this.
As I originally stated, installing to a fixed location would be fine, as
that would be fine for the great majority of users. How that location is
chosen is arbitary.
For the sake of backwards-compatibility and support more servers easily,
perhaps some form of installing the actual files for each server into
/usr/share/(server)/... and symlinking them into /home/httpd would make
more sense? Note that the files should be explictly symlinked, and NOT
the directories for 'htdocs' and 'cgi-bin'.
--
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 --]
next prev parent reply other threads:[~2003-06-10 5:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-08 10:12 [gentoo-dev] apache.eclass proposed Ned Ludd
2003-06-08 19:45 ` Robin H.Johnson
2003-06-08 19:50 ` Paul de Vrieze
2003-06-09 3:07 ` Ned Ludd
2003-06-09 6:01 ` Robin H.Johnson
2003-06-09 17:23 ` Brad Laue
2003-06-10 3:02 ` Donny Davies
2003-06-10 5:43 ` Robin H.Johnson [this message]
2003-06-12 0:13 ` Stewart
-- strict thread matches above, loose matches on Subject: below --
2003-06-08 14:32 Joshua Brindle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030610054304.GA9137@cherenkov.orbis-terrarum.net \
--to=robbat2@gentoo.org \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox