[Date Prev][Date Next]
Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
- From: email@example.com
- Date: Thu, 18 Mar 2010 01:26:12 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
--On Wednesday, March 17, 2010 8:17 PM +0000 firstname.lastname@example.org wrote:
> tjoen wrote:
>> On Mon, 2010-03-08 at 16:19 +0000, email@example.com 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
>>> - 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: 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
> 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.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration