[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote:
> --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
That's a valid point.  However, it does not explain why the TLS errors 
aren't (or "shouldn't be") logged via syslog.