Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.

[quanah@zimbra.com]

--On Wednesday, March 17, 2010 8:17 PM +0000 korvus@comcast.net wrote:

> tjoen wrote:
>> On Mon, 2010-03-08 at 16:19 +0000, korvus@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



--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration