From: Eric Sammer <eric@ineoconcepts.com>
To: "Robin H. Johnson" <robbat2@gentoo.org>
Cc: Gentoo Developers <gentoo-dev@gentoo.org>
Subject: Re: [gentoo-dev] Web app GLEP?
Date: Thu, 30 Oct 2003 03:59:43 -0500 [thread overview]
Message-ID: <3FA0D2FF.4000703@ineoconcepts.com> (raw)
In-Reply-To: <20031030082614.GA1319@curie-int.orbis-terrarum.net>
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 parent reply other threads:[~2003-10-30 8:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-30 8:09 [gentoo-dev] Web app GLEP? Eric Sammer
2003-10-30 8:22 ` Mike Frysinger
2003-10-30 8:30 ` Eric Sammer
2003-10-30 8:26 ` Robin H. Johnson
2003-10-30 8:59 ` Eric Sammer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FA0D2FF.4000703@ineoconcepts.com \
--to=eric@ineoconcepts.com \
--cc=gentoo-dev@gentoo.org \
--cc=robbat2@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox