In article <Pine.GSO.4.02.9808130946100.544-100000@gort.spry.com> you wrote:
> Is there any possibility of naming the new mod_ssl something other than
> mod_ssl?
You cannot easily rename it because the Apache configuration stuff depends on
this name, too. But there is a better solution for your problem:
> This may seem like a strange request, but here's why I ask. I use both
> Stronghold and Apache-SSL. My configuration files contain directives for
> both, with the incompatible lines contained within "<IfModule ...>"
> blocks. In other words:
> ...
> # Stronghold
> <IfModule mod_ssl.c>
> ...
> </IfModule>
> ...
> # Apache-SSL
> <IfModule apache_ssl.c>
> ...
> </IfModule>
> If the new mod_ssl module uses the same name as Stronghold, then I won't
> be able to use this scheme. From an architecture point of view, this
> simply doesn't seem very clean... to have 2 different modules (with
> incompatible directives) with the same module name.
Just replace the above with:
# Stronghold
<IfDefine Stronghold>
<IfModule mod_ssl.c>
...
</IfModule>
</IfDefine>
...
# mod_ssl
<IfDefine mod_ssl>
<IfModule mod_ssl.c>
...
</IfModule>
</IfDefine>
Then you can fire up the beast with Stronghold by using
$ httpd -DStronghold
and the when you want to use mod_ssl you fire it up with:
$ httpd -Dmod_ssl
Is this acceptable?
> I'm sure I can make different config files and swap them when I swap the
> executable (which is what I used to do). But the <IfModule ...> directive
> just seems like a prefect solution. If there's another way to accomplish
> the same task, by all means let me know.
Yes, use <IfDefine>. That was added by me to Apache 1.3 exactly because of the
drawbacks of <IfModule>: One usually need _logical_ sections inside httpd.conf
and not _physically_ ones. You can also directly replace the <IfModule> with
the <IfDefine> if you want above. There is no real need to use both, of
course.
> PS. This is not a major catastrophe, it's mainly used only on development
> systems where development and testing needs to be done with both servers.
> But every little bit of simplification helps.
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com