From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16454 invoked by uid 1002); 30 Oct 2003 08:59:44 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 27309 invoked from network); 30 Oct 2003 08:59:44 -0000 Message-ID: <3FA0D2FF.4000703@ineoconcepts.com> Date: Thu, 30 Oct 2003 03:59:43 -0500 From: Eric Sammer Organization: Ineo Concepts User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031025 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robin H. Johnson" Cc: Gentoo Developers References: <3FA0C734.9070807@ineoconcepts.com> <20031030082614.GA1319@curie-int.orbis-terrarum.net> In-Reply-To: <20031030082614.GA1319@curie-int.orbis-terrarum.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on samus X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 Subject: Re: [gentoo-dev] Web app GLEP? X-Archives-Salt: e6c125e5-48e8-476c-b1cb-5874c19571f2 X-Archives-Hash: a45a950c95a0db398fb3dc2eee7cc61f 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// - 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