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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
