httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Burgoyne <burgo...@keenuh.com>
Subject Re: new config organization for 2.1
Date Sat, 25 Sep 2004 12:01:14 GMT
I'll throw in my two cents.

As part of a large multi group organization (that I am sorry to say does
not get along all that well) I have, for security reasons, split up our
configuration file into about 20 seperate files. Certain people or groups
have access to certain things that I am comfortable with them changing.
Others are protected from all access (other than root).

To add further, when you encounter a large configuration such as 1500
hosts, 2000 redirects and 2000 rewrite rules, you can get significant
organization by putting some things in seperate file. Indeed, one of the
best uses of seperate config files is that the fact I have multiple
virtual hosts that require the same configuration items, say for
redirects, but not for rewrites. Using an include for a common set of
redirects ensures that when config changes are made, they only have to be
made in one place, not many (and I usually have a half dozen changes a
day). Wehn i took over management of the web server it was a single
monothlithic conf file that was hopelessly messed up. By splitting it up
it became much more manageable.

Therefore I think there are certainly valid reasons to split up the conf
file, and from a usability perspective, it may be a bit more confusing
upon an initial install, but the benefits down the road were immense for
me. Mind you, being in an organization where 12 people of varying
degree of expertise have access to the conf file and can restart the web
server in not common. Any downtime is not tolerated and has to be followed
up with a post mortem.

Jeffrey Burgoyne

Chief Technology Architect
KCSI Keenuh Consulting Services Inc
burgoyne@keenuh.com

On Fri, 24 Sep 2004, Joshua Slive wrote:

>
> On Fri, 24 Sep 2004, Brad Nicholes wrote:
>
> >   Maybe I am jumping in here out of turn, but let me ask the obvious
> > question.  Why would we want to split the standard base httpd.conf file
> > up into multiple files?  Doesn't this end up just confusing the average
> > user?  One thing that I always tell new users of Apache is that rather
> > than trying to understand the entire alpabetical list of directives in
> > the httpd docs, go read the comments in the standard httpd.conf file.
> > This gives them a good idea of what the base set of directives are and
> > how they are used in a working context.  For newbies reading a single
> > .conf file seems easier to understand than trying to trace through
> > multiple .conf files just to figure out the big picture.  For those that
> > are Apache experts, they have already rewritten and rearchitected the
> > the httpd.conf file to fit their needs so they don't care.  I can
> > understand splitting dead or rarely used directives out, but it seems
> > much easier to read as a single file.  Maybe just some additional
> > formatting and comments to distinguish MPM directives from Language from
> > Vhosts, etc. is needed.
>
> I agree entirely with the main sentiment.  The idea here is not to create
> a multi-file mess, but instead to create a much simpler httpd.conf that
> contains only the stuff that users really need.  That is the only config
> file that will be active by default, and the only one new users need to
> read at the start.
>
> But then users who need more advanced stuff---or who simply want to
> explore the capabilities of apache---need to have good examples too.
> Those examples are kept in separate config files in a separate directory.
> I provided commented-out Include directives, but users who prefer can
> simply copy the examples directly into httpd.conf.
>
> I guess my fundemental disagreement with you is that I don't believe that
> the current httpd.conf is salvagable by adding more comments or structure.
> The comments in that file are already quite verbose, and the file is just
> too darn long and complicated to be easily digested.  If you can suggest a
> better compromise solution, I am very interested.
>
> Joshua.
>

Mime
View raw message