On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote:
--On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net
wrote:
> tjoen wrote:
>> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote:
>>> After some chatter on the mailing list, the problem is now
>>> understood:
>>> - TLS error messages are indeed reported by OpenLDAP:
>>> TLS: could not use key file
>>> `/usr/local/etc/openldap/certs/ldap.key.pem'.
>> ...
>>> - The only way to see these error messages is to start the daemon
>>> with
>>> '-d stats'
>> ...
>>> My suggestions: print the TLS error messages out to syslog, or if
>>> that's not possible, print them to stdout regardless of whether the
>>> daemon is running in the foreground or not.
>>
>> Isn't it in local4.* ?
>>
>
> No, they do not get sent to local4.* - the only TLS message which makes
> it there in this scenario is: slapd[72041]: main: TLS init def ctx
> failed: -1
>
> Like I said, the ONLY way to get the actual TLS error messages is to run
> the daemon by hand in the foreground with loglevel stats by way of
> 'slapd
> -d stats'. Per the manpage this also prevents slapd from forking:
> -d debug-level
> Turn on debugging as defined by debug-level. If this
> option is specified, even with a zero argument, slapd
> will not fork or disassociate from the invoking
> terminal.
>
>
> Let me know if I'm still not being clear.
If you are trying to debug an issue, you most certainly should be
running slapd -d <level>... that's why it exists.
--Quanah
That's a valid point. However, it does not explain why the TLS errors
aren't (or "shouldn't be") logged via syslog.