1 |
On Mon, Jun 09, 2003 at 11:02:05PM -0400, Donny Davies wrote: |
2 |
> Ned Ludd wrote: |
3 |
> >The means by which the DocumentRoot is found is actually pretty elegant |
4 |
> >and the functionality of that can easily be placed in an eclass. I'd |
5 |
> >consider this a big plus in terms of usability. As you're pointing out, |
6 |
> >/var/www is the FHS compliant place to put the documentroot anyway, so |
7 |
> >I'm not sure why we're being like RedHat in this respect. |
8 |
> I would strongly advise you to get your facts straight before |
9 |
> rolling through here muttering something like that. This is not |
10 |
> correct. I'm afraid you need to do some remedial reading on the |
11 |
> situation. |
12 |
I agree with Donny here. There is no standard place to put the |
13 |
DocumentRoot. I have always used /var/www for a variety of reasons. |
14 |
Amongst them, is that /home is in many larger setups, an NFS mount, and |
15 |
I don't particuallar want to always have it mounted. (I am presently |
16 |
looking at auto-mounting just the current users home directories install |
17 |
of all of /home). |
18 |
|
19 |
My personal setups for Apache do away with a single DocumentRoot, as I |
20 |
usually have a number of VirtualHosts on each machine. |
21 |
|
22 |
I do: |
23 |
DocumentRoot /var/www/(domain)/(host)/ |
24 |
such that: |
25 |
www.orbis-terrarum.net |
26 |
comes from |
27 |
/var/www/orbis-terrarum.net/www/ |
28 |
|
29 |
> You may want to visit http://www.pathname.com/fhs/ where you |
30 |
> can learn that there *IS* no standard for this. And as such, |
31 |
> the location in which to install Apache and other web-related |
32 |
> files, is simply nothing more the opinion of the person you're |
33 |
> currently talking to. The current FHS version doesnt address |
34 |
> this area. I havent looked at any of the work in progress for |
35 |
> FHS 2.3 by the way; perhaps there's new developments there? |
36 |
There is nothing proposed for this in FHS2.3 AFAIK, or can find in the |
37 |
FHS BugZilla. |
38 |
|
39 |
> If you want even more standards, then please open your |
40 |
> config.layout file, distributed with the Apache source code, |
41 |
> and well, take your pick from several more "standards". |
42 |
And be aware of the 'Gentoo' layout in it that we use for Apache2. |
43 |
For Apache1, the ebuild specifies locations directly to override where |
44 |
they are installed instead of the clean layout route that is used in |
45 |
Apache2. |
46 |
|
47 |
> As for the apache2 USE flag; I made it so that the mod_php |
48 |
> ebuild didnt have to *guess* at which API to build the DSO |
49 |
> for. I've talked with Robin about this, and we'd both very |
50 |
> much like to see it "go away". It's nasty. |
51 |
To revisit that discussion, I've actually had two users come to me |
52 |
with another, better reason to have both installed at the same time: |
53 |
"Being able to develop a web application that has to run in BOTH |
54 |
environments, with only a single machine to work on." |
55 |
"Using a single machine, running Apache2 for some custom module they |
56 |
have, as well as having a really minimal Apache1 running to serve |
57 |
tarballs without the overhead added by the Apache2 stuff they use." |
58 |
|
59 |
> Robin H.Johnson wrote: |
60 |
> >Having both installed simultaneously is a very messy business already, |
61 |
> >as they both use /home/httpd, and contain binaries with identical names. |
62 |
> They are configured to serve from the same DocumentRoot. I |
63 |
> didnt want to introduce *another* docroot. They'll overwrite |
64 |
> some icons from the other's install. I assume those who |
65 |
> really, really want those default ASF icons from the other |
66 |
> version, can figure out howto get them from the tarball. |
67 |
> Same for the default introduction pages. Is this a big |
68 |
> deal? What binaries are you talking about? I took |
69 |
> pains to SLOT=2 Apache2, Im not aware of any binaries |
70 |
> getting overwritten. |
71 |
My apologies. Earlier on in the lifespan of Apache2 in Gentoo, more |
72 |
things were overwritten, but it seems practically all of that is cleared |
73 |
up now. |
74 |
There are exactly two files outside of icons and htdocs that are |
75 |
overwritten: |
76 |
/home/httpd/cgi-bin/printenv |
77 |
/home/httpd/cgi-bin/test-cgi |
78 |
Seeing as they are identical in both Apache1 and Apache2, I don't see |
79 |
any need for concern with them. |
80 |
|
81 |
I also made a further comparision on icons and htdocs via md5sums. |
82 |
Icons between the two are identical, and the old difference is that |
83 |
Apache2 has a bunch of 'powered by apache2' logos as additional items. |
84 |
The contents of htdocs have changed significently however, with no |
85 |
common files between the two remaining the same. |
86 |
|
87 |
> As for the eclass, it's obviously a natural progression. |
88 |
> I have not attempted to create one yet because I dont |
89 |
> really have a great idea for what functions it should |
90 |
> provide. The very basic ones proposed were simply not |
91 |
> enough to convince me to add this yet. If they were |
92 |
> I would have added one months ago. What other functions |
93 |
> would be desired from an web-related eclass? I'm not |
94 |
> *completely* and outright opposed to the stuff proposed, |
95 |
> Im just saying it's weak, and well, it certainly isnt |
96 |
> a sic "way to totally and easily manage the whole |
97 |
> Apache config" as somebody else mentioned. Far from |
98 |
> it. |
99 |
One point for a web applications eclass: |
100 |
When web servers BEYOND Apache are present, the complexity involved in |
101 |
finding the 'DocumentRoot' equivilent grows a LOT, and then it does make |
102 |
sense to belong in an eclass, as somebody adding a web application |
103 |
doesn't want to have to figure out the details behind how to get the |
104 |
DocumentRoot from AOLServer for example. |
105 |
|
106 |
We are a lot closer to this than you may realize. |
107 |
We do presently have a few web servers: |
108 |
Apache1/2 |
109 |
publicfile |
110 |
resin(-ee) |
111 |
mini_httpd |
112 |
fnord |
113 |
|
114 |
There really should be a virtual/webserver that many of these provide, |
115 |
but you get into issues of what modules can be used to a degree. |
116 |
There should NOT however, be anything to restricts you to only having a |
117 |
single webserver installed. |
118 |
|
119 |
> Further, Im not of the opinion that having a "bonifide" |
120 |
> location in which to install these files on a Gentoo |
121 |
> system (/home/httpd/{htdocs,cgi-bin} is a BAD idea, |
122 |
> and having them just the way they are now at least |
123 |
> provides this. |
124 |
As I originally stated, installing to a fixed location would be fine, as |
125 |
that would be fine for the great majority of users. How that location is |
126 |
chosen is arbitary. |
127 |
|
128 |
For the sake of backwards-compatibility and support more servers easily, |
129 |
perhaps some form of installing the actual files for each server into |
130 |
/usr/share/(server)/... and symlinking them into /home/httpd would make |
131 |
more sense? Note that the files should be explictly symlinked, and NOT |
132 |
the directories for 'htdocs' and 'cgi-bin'. |
133 |
|
134 |
-- |
135 |
Robin Hugh Johnson |
136 |
E-Mail : robbat2@××××××××××××××.net |
137 |
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 |
138 |
ICQ# : 30269588 or 41961639 |
139 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |