From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ldap tls test fails in some environments |
Date: | 2020-05-14 04:47:03 |
Message-ID: | CA+hUKG+_n-zt1EAZaZfojjXh9StROu+880pRrXVvtQTWEC_UMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 14, 2020 at 4:05 AM Christoph Berg <myon(at)debian(dot)org> wrote:
> Some other problem emerged here in the ldap test:
Hi Christoph,
> 17:28:59 Data directory: /<<PKGBUILDDIR>>/build/src/test/ldap/tmp_check/t_001_auth_node_data/pgdata
I know nothing about Debian package building so I could be missing
something about how this works, but I wonder if our script variable
handling is hygienic enough for paths like that. Let's see... I get
an error due to that when I run "make -C src/test/ldap check" from a
source tree under "/<<PKGBUILDDIR>>/build":
sh: 1: cannot create /build/src/test/ldap/tmp_check/slapd.pid:
Directory nonexistent
That's fixable with:
- kill 'INT', `cat $slapd_pidfile` if -f $slapd_pidfile;
+ kill 'INT', `cat "$slapd_pidfile"` if -f "$slapd_pidfile";
That's a side issue, though.
> 17:28:59 # TLS
> 17:28:59 not ok 19 - StartTLS
> 17:28:59 not ok 20 - LDAPS
> 17:28:59 not ok 21 - LDAPS with URL
> It consistently fails on the build server, but works on my notebook.
> Maybe that simply means slapd is crashing, but there's no slapd
> output. Would it be possible to start slapd with "-d 255", even if
> that means it doesn't background itself?
That'd require more scripting to put it in the background...
> 17:28:59 2020-05-13 15:28:58.479 UTC [31584] [unknown] LOG: could not start LDAP TLS session: Connect error
> 17:28:59 2020-05-13 15:28:58.728 UTC [31595] [unknown] LOG: could not perform initial LDAP bind for ldapbinddn "" on server "localhost": Can't contact LDAP server
Hmm, I get exactly the same errors as this if I comment out the
following part of the test script:
# don't bother to check the server's cert (though perhaps we should)
append_to_file(
$ldap_conf,
qq{TLS_REQCERT never
});
That's a file that we point to with the environment variable LDAPCONF.
The man page for ldap.conf says:
Thus the following files and variables are read, in order:
variable $LDAPNOINIT, and if that is not set:
system file /etc/ldap/ldap.conf,
user files $HOME/ldaprc, $HOME/.ldaprc, ./ldaprc,
system file $LDAPCONF,
user files $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
variables $LDAP<uppercase option name>.
Settings late in the list override earlier ones.
This leads me to suspect that something in your build server's
environment that comes later in that list is overridding the
TLS_REQCERT setting. If that's the explanation, perhaps we should do
this, which seems to work OK on my system, since it comes last in the
list:
-$ENV{'LDAPCONF'} = $ldap_conf;
+$ENV{'LDAPTLS_REQCERT'} = "never";
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2020-05-14 05:09:46 | Re: making update/delete of inheritance trees scale better |
Previous Message | Tom Lane | 2020-05-14 02:52:29 | Re: Another modest proposal for docs formatting: catalog descriptions |