[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Web app GLEP?
From:       Eric Sammer <eric () ineoconcepts ! com>
Date:       2003-10-30 8:59:43
[Download RAW message or body]

Robin H. Johnson wrote:
> At the moment I've been writing more of
> the vhost-config code to deal with adding and removing vhost entities,
> and exploring the best route to do it. Once the vhost stuff is done,
> then the webapp-config stuff builds on top of it (as the webapps need
> the ability to add custom snippets to the webserver configuration).

Right... That's what I was looking for. I just wasn't sure if had been 
finished and just not publicized or was still masked. I suppose one has 
to draw a line at some point due to the endless combinations that 
someone could come up with (apache 1, apache 2, custom modules, custom 
configs, support for multiple versions or installations of a web server, 
etc.).

For what it's worth, I've never met a system that seemed to work for the 
way we do things. Mostly, it's because we need a fairly custom mod_perl 
development environment that mirrors the production servers, but for 
reasons beyond that as well.

Quick example of our "normal" setup:

Apache install:
/opt/apache-x.xx - ...so multiple apache versions can be tested side by 
side (and quickly removed). In most cases, there's only one or *maybe* 
one production + one testing, but it's still a requirement. Apache is 
usually built by hand because mod_perl as a DSO can have some "issues" 
under heavy load and mod_ssl is also required. In some cases, we use 
reverse proxy configs for performance with a non-mod_perl httpd running 
in front of the mod_perl servers (running on port 8080). This kind of 
thing is usually not easy to get out of "lowest common denominator" 
Apache builds from distros and requires multiple static builds of 'httpd.'

Content:

/export/www/<virtual host>/ - In some cases, /export can be a network 
mount and /home isn't so /home/httpd doesn't fly (although it could, 
just as easily, I suppose). This is probably the easiest part of our 
config we could change.

Logging:

...Isn't sent to /var for fear of IO contention with boxes that host 
mail and www services. It's usually a non-issue, but it's a "learned 
behavior" when there are multiple controllers with multiple disks and 
one is /var and separate from the rest of the system.

Apache conf:

...Is kept with the version of Apache (in /opt/apache-x.xx), rather than 
in /etc so they can travel (visually / physically) with the version of 
apache they correspond with. Symlinking stuff all over the place usually 
just causes more headaches than it's worth so that doesn't help.

This all usually means using built-by-hand (or custom in house tools / 
ebuilds) rather than anything that is meant for generic distribution. 
It's an FHS abomination, for sure, but I've never been able to make the 
"distro way" (any distro - RH, Deb, Gentoo, SuSE, etc.) work as I need 
it to.

The point of this long winded description / justification is that I'm 
curious if what is being worked on will be flexible enough to 
accommodate things like specific versioned apache installs, willy-nilly 
content locations, and config files that don't make me cry when I look 
at them (i.e. littered with 'include ../../foo.conf'). I don't expect to 
just 'emerge apache mod_perl mod_ssl' and get something like this, but 
it would be nice if it was close because managing all of this stuff like 
this on a larger number of machines is not a cup of tea.

Either way, thanks for the reply (and sorry for the diatribe)... ;)

-- 
Eric Sammer
eric@ineoconcepts.com
http://www.ineoconcepts.com

--
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]