On Thu, May 14, 2020 at 4:05 AM Christoph Berg <myon@debian.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";
