When including a directory of configuration files, the reference must not contain a symbolic link. I e.g. have the following case: /mnt/disk0/www.server1/<lots of virtual servers>.conf /mnt/disk0/www.server2/<lots of virtual servers>.conf /virtual/www.server1 --- symbolic link --> /mnt/disk0/www.server1/ /virtual/www.server2 --- symbolic link --> /mnt/disk0/www.server2/ If I put Include /mnt/disk0/www.server1/*.conf into httpd.conf, it works. If I put Include /virtual/www.server1/*.conf into httpd.conf, it works not. In the strace of the httpd process, it is visible that apache tests, whether the /virtual/www.server1 reference is a directory but gets an error and halts. Apache should test, whether an include reference is a symbolic link and if yes, test its target to be a directory.
That is by intention in order to avoid infinite loops. It just needs to be better documented.
Sorry to bother you, but IMHO this is still a bug. We e.g. have a scenario where this include link points to an NFS mounted directory which can change due to failover reasons. This is how I found the problem. Basically I have a Include "/virtual/foo/*.conf" and the foo can be dynamically change doing a failover and a httpd restart. Our current solution rewrites the config files using sed and is awkward at best (pun intended). Can we have an IncludeFollowLinksYesIveReadTheManualAndKnowAboutPossibleLoops directive? :-) (Would you accept patches?) For content we have "FollowSymLinks".Why not the same thing for the configuration?
I've finally found a way to stop include directive recursion (by using the pool context). So I no longer see a need for the symlink stopper at all, hence I'm going to patch it out. (just replacing ap_is_rdirectory with ap_is_directory in ap_process_resource_config and process_resource_config_nofnmatch). The recursion stopper is currently in 2.1 and proposed for backport into 2.0.
Thanks a lot! This will really help me with our HA environments and future releases of the httpd.
FYI: The fix will be in 2.0.51.
*** Bug 31099 has been marked as a duplicate of this bug. ***