On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote: > Now you are providing conflicting answers. The man page for back-ldap makes > zero reference to ldap.conf(5). It only mentions slapd.conf(5). The > syncrepl section of slapd.conf(5)/slapd-config(5) only mention the > network-timeout value being pulled in from ldap.conf(5). So which is it? Do > they follow the man page behaviors (which would mean no ldap.conf(5) for > slapd-ldap, and only network-timeout for syncrepl), or do they violate the > man page description?
(replying to the gist of the entire thread) I'm happy with back-ldap, etc. honouring global ldap.conf. Deployments that need to avoid that can and should define LDAPNOINIT. Also AFAIK libldap initialisation happens before any configuration is even parsed so might be a bit harder to avoid it. > Generally, it seems to me we at the least have a documentation bug, in that > back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) > should note that they will rely on ldap.conf(5) in the absence of TLS (and > possibly other paremters) if they are not found in slapd.conf(5). We should document what happens somewhere, definitely. Maybe TLS section of slapd.conf manpage? I'll defer to you where that should happen and hopefully either of also you wants to write it (and the LDAPNOINIT advice) while I work on fixing this :) I'll just tweak things later so the docs fit exactly what happens when it comes to setting up slapd_tls_ld and what the relevant clients (syncrepl and back-ldap) do too. > Additionaly, what should we do about ITS#8427? It was clearly fixing a valid > bug. Do we revert it? Do we fix the behavior so it fixes the bug reported, > but does not introduce a regression? > > And we need to know the answer to that and have a fix in rather quickly. I'll see tomorrow about reproducing the regression with ldap.conf. If I'm successful, extending the test case and a fix should not take long. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP