On 8/26/2011 7:27 AM, Always Learning wrote: > On Thu, 2011-08-25 at 22:56 -0700, John R Pierce wrote: > >> by putting all your site specific configurations in various >> .conf files in the conf.d directory, your stuff is portable, and can >> be rpm deployed on any el system without complications. > That is exactly the flexibility I have when I put my site specific > Apache stuff in /data/config/apache > > > Paul. I think the point is making use of what is by default built in to apache on our CentOS boxes. And this is and has been for some time making use of the include directed to look in /etc/httpd/conf.d directory and read in any *.conf files in that directory. So, why try to teach somebody to use another structure and customization? And why is this a good idea? Well, it does add complication in having multiple files to deal with. But the upside to that is it does reduce the number of edits to the main conf file. What is useful about this? Well, I do remember one time editing httpd.conf in Vi and after I finished Apache wouldn't restart. Panic of course immediately sets in when a webserver is not running and I looked and looked and looked and looked and couldn't find any problem with what I had done. Finally, after what seemed like an eternity, I found that I must have accidentally hit the 'x' key just after opening the file and had deleted the first '#' from the first line. I was working on a new virtual server during that edit and just knew I hadn't edited anywhere else... so had been totally concentrating on the end of the conf file instead of really looking at the top. If this had been in vhost.conf, I could have easily moved vhost.conf to vhost.conf.bak and immediately known that it was not the problem... and actually, wouldn't have had the main conf open to start with so would never have made that mistake. So, argue all you want, but many programs 'by default' add their apache conf files into /etc/httpd/conf.d so why not follow conventions? If you die, the next admin should know to look there first. And, removing or doing a temp something.conf.bak file quickly takes potential errors out of the equation. To me, the use of this includes directory is simply good practice for multiple reasons. On this list, teaching best 'standard' practices is a good idea. Who is going to think to tell someone to go look in /data/config/apache for a configuration two years from now when something breaks due to following non-standard practices? John Hinton