From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Marco Cuccato <mcuccato(dot)vts(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: LDAPS trusted ca support |
Date: | 2019-11-25 21:33:09 |
Message-ID: | CA+hUKGJ5zkegT-ViSB4S2=GZuvAH3hdo-nF24bRnNzJLUcn_yw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Nov 26, 2019 at 4:35 AM Marco Cuccato <mcuccato(dot)vts(at)gmail(dot)com> wrote:
> Ok sorry for the mail before I misunderstood your suggestion.
> I verified the ldap.conf file and the TLS_CACERT parameter points to a PEM file which already contains the certificate that signs the LDAP server certificate.
Here are some things I'd check: When you used the ldapsearch command,
did you use -ZZ? (Just -Z means something like try to use SSL but
don't worry if it doesn't work; -ZZ requires it to work). Does the
"postgres" user (assuming the RHEL packages use that to run
PostgreSQL) have permissions to read the files it needs to read? If
you become that user with su - postgres, can you use the "ldapsearch"
command successfully? If you do strace -f -p [postmaster], and then
try to log in with your LDAP-authenticated user, does it give you a
clue about what files it is accessing or failing to access, and then
if you compare "strace ldapsearch ...", does that give you a clue
about what is different? If you do ldd /path/to/postgres and ldd
/path/to/ldapsearch can you see that they're both using the same
libldap-XXX.so.Y (if they were using different OpenLDAP client
libraries they might have different .conf paths compiled into them)?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-25 23:18:25 | Re: BUG #16137: pg_upgrade fails with an index over nesting function |
Previous Message | PG Bug reporting form | 2019-11-25 21:00:07 | BUG #16137: pg_upgrade fails with an index over nesting function |