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 [EMAIL PROTECTED] 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. >
