1 |
Chugga chugga chugga! :-) |
2 |
|
3 |
Quoting Stuart Herbert <stuart@g.o>: |
4 |
|
5 |
> On Sunday 03 August 2003 4:20 pm, Max Kalika wrote: |
6 |
>> Correct. I also create an apache config block as |
7 |
>> |
8 |
>> /etc/webapps/<application>.conf |
9 |
> |
10 |
> If it's apache-specific, can't we at least call it |
11 |
> <application>-apache.conf? |
12 |
|
13 |
You're absolutely right, and in fact this is what the eclass does right now |
14 |
(as shown by the example I posted earlier). |
15 |
|
16 |
> Thanks for the example - it helps a great deal. Now, how would you deal |
17 |
> with a site needing to run two copies of horde under the one web server? |
18 |
|
19 |
Hmm. This depends on the app. Some apps have virtual hosting built-in |
20 |
others do not. Those that do not, may need some sysadmin intervention, |
21 |
doing some parallel installs, symlinking, what-have-you. I think we need |
22 |
to have a limit to how much we can do at install time and how much we can |
23 |
configure for the user out-of-the-box. For example, we don't have any way |
24 |
of having two postfix instances installed and running on the same box with |
25 |
the ebuild, but the sysadmin can go ahead and configure the installed |
26 |
product to achieve the needed functionality. |
27 |
|
28 |
> Yeah - but how do you handle sites (like ISPs) that need to run multiple |
29 |
> installations of the same app on the same box? You can't have a single |
30 |
> globla configuration file for that. Makes sense for the home user, but |
31 |
> not for ISPs. |
32 |
|
33 |
Continuing from above, it seems best left to the systems admin in designing |
34 |
how to implement virtual hosting. For example, horde has built-in virtual |
35 |
hosting where you specify multiple servers and the specific one gets chosen |
36 |
based on the server hostname. Of course this isn't foolproof as things |
37 |
like SSL will break it, but in any case, this decision has to be left to |
38 |
the person installing it. It seems like the gentoo philosophy is to install |
39 |
the necessary minimum to have a running product and leave the major |
40 |
tinkering to the admin. Going back to the postfix example, although the |
41 |
package has support for delivering mail to LMTP through a content filter |
42 |
that will scan for spam and viruses, it doesn't do it out of the box and |
43 |
takes a bit of tinkering to get right. I'm of the opinion that if someone |
44 |
wants to set up an ISP, they better know what they're doing and will be |
45 |
able to figure out how to virtualize the necessary packages they want to |
46 |
offer to their clients. |
47 |
|
48 |
> Well, PHP apps'll need to check for which PHP extensions are active from |
49 |
> time to time. |
50 |
|
51 |
Ok. If there's a lot of language-specific work that needs to be done, then |
52 |
breaking it up into separate eclasses makes sense, otherwise, I'm worried |
53 |
about clutter. :) |
54 |
|
55 |
>> Certainly. Perhaps if we don't find anything that is language specific |
56 |
>> (which I have yet to see), we can take a different approach and do |
57 |
>> webapp-<webservertype> |
58 |
> |
59 |
> See previous emails. I *really* don't support making any of this stuff |
60 |
> webserver-specific in the ebuilds or eclasses ;-) A two-stage install - |
61 |
> ebuilds to get apps onto the machine, user-space tools to install an app |
62 |
> for a specific web server - are the way to go, imho. |
63 |
|
64 |
Fair enough. So something like "webapp-config <application> <webserver>" ? |
65 |
|
66 |
> How do you make an app install on (say) Zeus or (say) iPlanet or (say) |
67 |
> n.e.other web server if the ebuild itself is server-specific? We're |
68 |
> boxing ourselves in, for no good reason. |
69 |
|
70 |
No idea. :-) |
71 |
|
72 |
> Gentoo's supposed to be about configurability. It even says so right at |
73 |
> the top of www.gentoo.org. Let's not throw that out of the window just |
74 |
> yet ;-) |
75 |
|
76 |
I wouldn't consider it! :-) |
77 |
|
78 |
--mk |
79 |
|
80 |
-- |
81 |
gentoo-dev@g.o mailing list |