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 |