On Thu, Nov 05, 1998, Jan Wedekind wrote:
>[...]
> - If the SSLLog path/directory does not exist, there's no error message
> within the error_log, and the parent dies with exit(1).
>
> I just greped through the source but didn't see the
> error within ssl_log_open(). Maybe the error is detected at some
> other point with the source.
<grin> This was nice bug caused by a chicken and egg problem: The "cannot open
SSL logfile"-error is done with the SSL logfile mechanism itself. And this
operated only when the logfile is still open ;-) Because in mod_ssl a generic
logfile mechanism is used which duplicates errors to the error_log. So the
error was inside let ssl_log(). It is allowed to deny operation when the SSL
logfile is not open, but only when it's not an error message (which has to be
dup'ed to the error_log). This is now fixed for 2.1b9 and now works as
expected for me, i.e. I correctly get the error inside Apache's error_log.
Thanks for discovering this.
> - obsolete options are also reported, if marked as or even written
> within a comment, e.g.:
> [Thu Nov 5 09:44:13 1998] [warn] mod_ssl: Obsolete/unsupported
> directive: # Test mark and for option noSSLFakeBasicAuth
> [Thu Nov 5 09:42:16 1998] [warn] mod_ssl: Obsolete/unsupported
> directive: #noSSLFakeBasicAuth
Ops, that was a general bug in my mapping functions. They were a little bit
too general in applying the directive mapping. I've now enhanced it so comment
and blank lines are recognized correctly, too. Thanks for the hint, Jan.
> - CHANGES mailed to the list within 2.0.14 and 2.1b* are not included
> within CHANGES file in the distribution.
> (would be helpfull for changing old configuration files to newer ones)
You mean the CHANGES between 2.0.x and 2.0.14 and CHANGES.20, right? If not
what exactly do you mean? The CHANGES file contains all changes between 2.0.x
and 2.1bx. WHat especially do you mean is helpful for the config file
upgrades?
BTW, although 2.1.0 should out-of-the-box work with old (Apache-SSL 1.x and
mod_ssl 2.0.x) configuration files because of the compat mechanism, I'll write
a UPDATE document for the 2.1.0 distribution which explains all user visible
changes and how one should upgrade the clean way (using compat stuff is not
clean, IMHO).
> - one the machine mentioned above the Server now starts up fine,
> and also mod_perl runs without problems but only on insecure
> connections.
> At secure connections I receive an SIGSEGV on the child also
> at URL's, where handlers of mod_perl aren't configured at all.
> Without mod_perl the server runs fine, so I assume that's an other
> problem with DSO support within mod_perl and not mod_ssl.
> I'll try to compile/link with -g and report later on this.
Yeah, try to find out where it segfaults. It has not be to only mod_perl's
fault. Perhaps it's some conflict caused by mod_ssl, who knows. Although I've
now never got any more segfaults with 2.1b8. But this doesn't mean nothing...
;_) Send us and Doug at least the backtrace ("bt"), Jan.
Thanks for participating in the 2.1 testing phase.
Greetings,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
