From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Log LDAP "diagnostic messages"? |
Date: | 2017-07-26 01:21:26 |
Message-ID: | CAEepm=2_dA-SYpFdmNVwvKsEBXOUj=K4ooKovHmvj6jnMdt8dw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
Some LDAP error codes are a bit vague. For example:
LDAP_CONNECT_ERROR Indicates a connection problem.
LDAP_PROTOCOL_ERROR A protocol violation was detected.
To learn more, you have to call
ldap_get_option(LDAP_OPT_DIAGNOSTIC_MESSAGE). Should we do that? For
example, instead of:
LOG: could not start LDAP TLS session: Protocol error
... you could see:
LOG: could not start LDAP TLS session: Protocol error
DETAIL: LDAP diagnostic message: unsupported extended operation
Well, that may not be the most illuminating example, but that's a
message sent back by the LDAP server that we're currently throwing
away, and can be used to distinguish between unsupported TLS versions,
missing StartTLS extension and various other cases. Perhaps that
particular message would also be available via your LDAP server's
logs, if you can access them, but in some cases we're throwing away
client-side messages that are not available anywhere else like "TLS:
unable to get CN from peer certificate", "TLS: hostname does not match
CN in peer certificate" and more.
Something like the attached.
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
ldap-diagnostic-message.patch | application/octet-stream | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-07-26 01:26:41 | Re: segfault in HEAD when too many nested functions call |
Previous Message | Craig Ringer | 2017-07-26 00:54:37 | Re: Syncing sql extension versions with shared library versions |