Gentoo Archives: gentoo-dev

From: Max Kalika <max@g.o>
To: stuart@g.o, Max Kalika <max@g.o>, Troy Dack <tad@g.o>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Sun, 03 Aug 2003 19:03:06
Message-Id: 2147483647.1059912184@[]
In Reply to: Re: [gentoo-dev] [GLEP] Web Application Installation by Stuart Herbert
1 Chugga chugga chugga! :-)
3 Quoting Stuart Herbert <stuart@g.o>:
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?
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).
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?
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.
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.
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.
48 > Well, PHP apps'll need to check for which PHP extensions are active from
49 > time to time.
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. :)
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.
64 Fair enough. So something like "webapp-config <application> <webserver>" ?
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.
70 No idea. :-)
72 > Gentoo's supposed to be about configurability. It even says so right at
73 > the top of Let's not throw that out of the window just
74 > yet ;-)
76 I wouldn't consider it! :-)
78 --mk
80 --
81 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] [GLEP] Web Application Installation Stuart Herbert <stuart@g.o>