Gentoo Archives: gentoo-dev

From: Eric Sammer <eric@××××××××××××.com>
To: "Robin H. Johnson" <robbat2@g.o>
Cc: Gentoo Developers <gentoo-dev@g.o>
Subject: Re: [gentoo-dev] Web app GLEP?
Date: Thu, 30 Oct 2003 08:59:44
Message-Id: 3FA0D2FF.4000703@ineoconcepts.com
In Reply to: Re: [gentoo-dev] Web app GLEP? by "Robin H. Johnson"
1 Robin H. Johnson wrote:
2 > At the moment I've been writing more of
3 > the vhost-config code to deal with adding and removing vhost entities,
4 > and exploring the best route to do it. Once the vhost stuff is done,
5 > then the webapp-config stuff builds on top of it (as the webapps need
6 > the ability to add custom snippets to the webserver configuration).
7
8 Right... That's what I was looking for. I just wasn't sure if had been
9 finished and just not publicized or was still masked. I suppose one has
10 to draw a line at some point due to the endless combinations that
11 someone could come up with (apache 1, apache 2, custom modules, custom
12 configs, support for multiple versions or installations of a web server,
13 etc.).
14
15 For what it's worth, I've never met a system that seemed to work for the
16 way we do things. Mostly, it's because we need a fairly custom mod_perl
17 development environment that mirrors the production servers, but for
18 reasons beyond that as well.
19
20 Quick example of our "normal" setup:
21
22 Apache install:
23 /opt/apache-x.xx - ...so multiple apache versions can be tested side by
24 side (and quickly removed). In most cases, there's only one or *maybe*
25 one production + one testing, but it's still a requirement. Apache is
26 usually built by hand because mod_perl as a DSO can have some "issues"
27 under heavy load and mod_ssl is also required. In some cases, we use
28 reverse proxy configs for performance with a non-mod_perl httpd running
29 in front of the mod_perl servers (running on port 8080). This kind of
30 thing is usually not easy to get out of "lowest common denominator"
31 Apache builds from distros and requires multiple static builds of 'httpd.'
32
33 Content:
34
35 /export/www/<virtual host>/ - In some cases, /export can be a network
36 mount and /home isn't so /home/httpd doesn't fly (although it could,
37 just as easily, I suppose). This is probably the easiest part of our
38 config we could change.
39
40 Logging:
41
42 ...Isn't sent to /var for fear of IO contention with boxes that host
43 mail and www services. It's usually a non-issue, but it's a "learned
44 behavior" when there are multiple controllers with multiple disks and
45 one is /var and separate from the rest of the system.
46
47 Apache conf:
48
49 ...Is kept with the version of Apache (in /opt/apache-x.xx), rather than
50 in /etc so they can travel (visually / physically) with the version of
51 apache they correspond with. Symlinking stuff all over the place usually
52 just causes more headaches than it's worth so that doesn't help.
53
54 This all usually means using built-by-hand (or custom in house tools /
55 ebuilds) rather than anything that is meant for generic distribution.
56 It's an FHS abomination, for sure, but I've never been able to make the
57 "distro way" (any distro - RH, Deb, Gentoo, SuSE, etc.) work as I need
58 it to.
59
60 The point of this long winded description / justification is that I'm
61 curious if what is being worked on will be flexible enough to
62 accommodate things like specific versioned apache installs, willy-nilly
63 content locations, and config files that don't make me cry when I look
64 at them (i.e. littered with 'include ../../foo.conf'). I don't expect to
65 just 'emerge apache mod_perl mod_ssl' and get something like this, but
66 it would be nice if it was close because managing all of this stuff like
67 this on a larger number of machines is not a cup of tea.
68
69 Either way, thanks for the reply (and sorry for the diatribe)... ;)
70
71 --
72 Eric Sammer
73 eric@××××××××××××.com
74 http://www.ineoconcepts.com
75
76 --
77 gentoo-dev@g.o mailing list