httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: patch? (Patch to fix the fatal missing VHost dir)
Date Sat, 01 Jun 1996 21:28:48 GMT
> > I am also including in this patch a genericized version of my
> > VHostConfigdir patch of old. This change allows you to specify
> > 'ConfigDir' directives which are parsed for '*.conf' files.
> > I've elected to be specific about file extension so that it
> > would still be possible to have non-config files in these 
> > directories, as well as being about to turn off certain files
> > by renaming them.
> 
> This is fine, but refresh my memory - are srm.conf, httpd.conf, and 
> access.conf all complete opaque as to where directives can go?

Yes. To the best of my knowledge. I've been running with 1 config file
for quite some time, with exception of the separate VirtualHost files
that are stuffed in a sub-directory.

> I.e., is 
> there a qualitative difference between the resource config file and the 
> server config file and/or the access config files, or could I put 
> absolutely everything in httpd.conf?  I think this is the case, but if 
> not, then doesn't ConfigDir need some knowlege of what type of config 
> files it'll find there?

ConfigDir should allow you to make your config setup more modular.
My intent is to be able to output and maintain separate VHost config
files from a config editor. Separating into separate files makes life
more simple.

> It might also be nice to make sure a situation like the following doesn't 
> happen - I have a main httpd.conf and a bunch of sub-conf files which 
> each do configuration for one virtualhost, and then I set ownerships and 
> permissions for each of those so that separate people are editing them.  
> I obviously don't want one of the vhost-conf maintainers to be able to 
> set the User directive.  Although, I suppose all this (even the ConfigDir 
> functionality) could be solved using Perl scripts that run once rather 
> than putting the functionality deep inside the server...

After past comments from Alexei, I made this more generic which probably
makes what you describe even more of an issue. I agree with Alexei's 
suggestion. I think, as you point out, that building a .conf file from
your users subdirs is probably safest from your point of view.






Mime
View raw message