On 8/26/2011 1:18 PM, Always Learning wrote: > Are you running two include lines in httpd.conf? One for > /data/apache/custom and one for /etc/httpd/conf.d? Or maybe doing a ln > from conf.d to custom? > /etc/httpd/conf/httpd.conf has:- > > 112: Include conf.d/*.conf > > 126: User apache > 127: Group apache > 128: > 129: #------------ Section 2: 'Main' server configuration ------------ > 130: > 131: Include /data/config/apache/server.conf > 132: > 133: #------------- Section 3: Virtual Hosts --------------------------- > 134: > 135: include /data/config/apache/domain.* > 136: > 137: #------------------------------------------------------------------ > > OK, so you have just chosen to put your vhost confs in an alternate directory. There are sound reasons for doing that, like ease of backups and dumb minded restores that any low level tech could do. Me... I just do a single vhost.conf file for all virtual servers. Works fine for me thus far and there's less trash to look through when trying to find a conf file. All good. I backup all of /etc and am not worried as we have no dumb minded techs that would ever be doing a restore so don't need an easier solution. Doing what you are doing might be a simpler solution or a vastly more complex solution... all depending on the services running... upgrade frequency and how well everything works during those updates. It all depends on what the servers are doing. To suggest others follow in your footsteps however is very short sighted. Again, I would never tell you that you shouldn't do it your way. That would be very short sighted of me. The two includes in httpd.conf allows both areas to load, but does break 'alternative' installs, such as squirrelmail as just one of many examples (assuming you got rid of the /etc/httpd/conf.d include). So, yum install squirrelmail would not work without customization on your system, along with a number of other system wide tools one might want to run under apache. Python, php, manual, welcome, webalizer, ssl, squid, proxy_ajp, perl, cacti are all examples. Again though, adding in one new conf file for a temporary patch has nothing to do with how your servers are set up but how the vast majority of CentOS servers 'are' set up and to suggest an alternative area is just off the topic and potentially confusing to those that are trying to follow a step by step procedure down to the letter. I'm done with this this part of this thread and hope it can get back to what it was intended to do and that was simply how to avoid this DoS attack... NOT how to relocate where files are stored. I do recognize the merits of what you are doing. John Hinton