Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 85828 invoked by uid 500); 15 Aug 2001 17:55:38 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 85802 invoked from network); 15 Aug 2001 17:55:38 -0000 Date: Wed, 15 Aug 2001 10:55:40 -0700 From: Aaron Bannert To: new-httpd@apache.org Subject: Re: Apache config files and alternate config sources Message-ID: <20010815105540.I7727@clove.org> References: <3B7A9679.4274F4DC@sharp.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7A9679.4274F4DC@sharp.fm>; from minfrin@sharp.fm on Wed, Aug 15, 2001 at 05:34:17PM +0200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 607 On Wed, Aug 15, 2001 at 05:34:17PM +0200, Graham Leggett wrote: > Hi all, > > Part two in the grand LDAP plan is to support the storing of > configuration data in an LDAP directory, somewhat along the lines of > what has been achieved with qmail+ldap+control. This allows multiple > machines (probably in a redundant configuration) to derive their config > from a common datasource rather than relying on files on each machine's > filesystem. It also allows the LDAP schema checking mechanism to do a > kind of syntax checking on the LDAP config, which ensures that a bogus > Apache config cannot be applied in the first place - a Good Thing(TM) :) > > In order to achieve this technically, I have a number of questions. > > It's been a while since I looked at the way the config files are read in > v2.0 - so my understanding could be way off - however as I understand it > a config file is opened by Apache, and it is read line by line, feeding > non-comment lines to be processed by the config subsystem. The Include > directive is handled roughly as a kind of recursion, where a new file is > opened and the loop continued. > > To support LDAP (and potentially other methods, such as the Windows > Registry), I propose a new hook. This would call one or more functions > whose job it is to recognise the filename/urlname of the configuration, > read that object in, and then render each line of config appropriately > as it is done now. For example the "file" module would recognise the URL > "conf/httpd.conf", while the "ldap" module would recognise URL > "ldap:///blah" and the "registry" module would recognise the URL > "registry:///some/key". > > A default config file on an Apache system might include the line: > "Include ldap:///blah" which includes an LDAP object at that point, or > Apache could be started with "httpd -f ldap:///blah". > > Does this sound like the right approach? One of the biggest dangers in this kind of a thing (and it is rather similiar to depending on a remote DTD in XML) is that you are now implicitly trusting DNS for authenticity. A poisoned DNS entry could be catastrophic. To me it sounds like the main thing we are trying to accomplish here is to allow for centralized configuration, which is useful in things like server farms or for rapid deployment of cloned or slightly mutated configurations. What other things are we trying to solve with this? -aaron