HI!
I've tried the following without success:
Disabled Link Time Optimization (LTO), recently introduced for openSUSE Tumbleweed, in packages openldap2 and dhcp-server. Just to make sure it does not cause any harm.
Upstream update to dhcp 4.4.1 without any of openSUSE's back-port patches.
dhcpd does not even contact the LDAP server. It seems there's some call into libldap failing and this is handled by dhcpd as connection error.
FWIW: I've attached the strace output of the following command which does not say much: LDAPNOINIT=1 /usr/sbin/dhcpd -T
I have no clues where to look now and I have to give up.
Could someone review the source of dhcpd? The relevant files are ldap*.c:
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=tree;f=server
Ciao, Michael.
------------------------- dhcpd.conf ------------------------------ ldap-server "127.0.0.1"; ldap-port 389; ldap-username "cn=host.example.com,ou=DHCP,example,dc=com"; ldap-password "host-secret"; ldap-base-dn "ou=DHCP,example,dc=com"; ldap-ssl off; ldap-method dynamic;
Michael Ströder wrote:
HI!
I've tried the following without success:
Disabled Link Time Optimization (LTO), recently introduced for openSUSE Tumbleweed, in packages openldap2 and dhcp-server. Just to make sure it does not cause any harm.
Upstream update to dhcp 4.4.1 without any of openSUSE's back-port patches.
dhcpd does not even contact the LDAP server. It seems there's some call into libldap failing and this is handled by dhcpd as connection error.
FWIW: I've attached the strace output of the following command which does not say much: LDAPNOINIT=1 /usr/sbin/dhcpd -T
strace is not useful here. Pretty sure we've stated this many times before.
Use ltrace in this case.
On 7/17/19 4:41 PM, Howard Chu wrote:
strace is not useful here. Pretty sure we've stated this many times before.
Sorry. Indeed ltrace output is more helpful.
Here's the test with 2.4.48:
------------------------------------------------------------------------------------ 27337 ldap_initialize() = <void> 27337 free(0x560583024230) = <void> 27337 ldap_set_option() = <void> 27337 ldap_set_option() = <void> 27337 ldap_set_rebind_proc() = <void> 27337 strdup("xxxxxxxxxxxxxxxxxxxxxxxx") = 0x560583024230 27337 strlen() = <void> 27337 ldap_sasl_bind_s() = <void> 27337 free(0x560583024230) = <void> 27337 ldap_err2string() = <void> 27337 __vsnprintf_chk(0x5605829dbde0, 1024, 1, 1024) = 77 27337 __syslog_chk(3, 1, 0x5605828fa7f1, 0x5605829dbde0) = 0 27337 write(2, "Error: Cannot login into ldap se"..., 77) = 77 27337 write(2, "\n", 1) = 1 ------------------------------------------------------------------------------------
With 2.4.47 it looks different:
------------------------------------------------------------------------------------ 27776 ldap_initialize( <unfinished ...> 27776 inet_pton(2, 0x7ffc9ca4b370, 0x7ffc9ca4aed0, 0x557ed75725ff) = 0 27776 inet_pton(10, 0x7ffc9ca4b370, 0x7ffc9ca4aed0, 62) = 0 27776 malloc(312) = 0x557ed8afa810 27776 malloc(35232) = 0x557ed8afa950 27776 memset(0x557ed8afa950, '\0', 35232) = 0x557ed8afa950 27776 malloc(8800) = 0x557ed8b03300 27776 memset(0x557ed8b03300, '\0', 8800) = 0x557ed8b03300 27776 malloc(8192) = 0x557ed8b05570 ------------------------------------------------------------------------------------
Ciao, Michael.
Michael Ströder wrote:
On 7/17/19 4:41 PM, Howard Chu wrote:
strace is not useful here. Pretty sure we've stated this many times before.
Sorry. Indeed ltrace output is more helpful.
Here's the test with 2.4.48:
27337 ldap_initialize() = <void> 27337 free(0x560583024230) = <void> 27337 ldap_set_option() = <void> 27337 ldap_set_option() = <void> 27337 ldap_set_rebind_proc() = <void> 27337 strdup("xxxxxxxxxxxxxxxxxxxxxxxx") = 0x560583024230 27337 strlen() = <void> 27337 ldap_sasl_bind_s() = <void>
Find out why ldap_sasl_bind_s is failing.
27337 free(0x560583024230) = <void> 27337 ldap_err2string() = <void> 27337 __vsnprintf_chk(0x5605829dbde0, 1024, 1, 1024) = 77 27337 __syslog_chk(3, 1, 0x5605828fa7f1, 0x5605829dbde0) = 0 27337 write(2, "Error: Cannot login into ldap se"..., 77) = 77 27337 write(2, "\n", 1) = 1
With 2.4.47 it looks different:
27776 ldap_initialize( <unfinished ...> 27776 inet_pton(2, 0x7ffc9ca4b370, 0x7ffc9ca4aed0, 0x557ed75725ff) = 0 27776 inet_pton(10, 0x7ffc9ca4b370, 0x7ffc9ca4aed0, 62) = 0 27776 malloc(312) = 0x557ed8afa810 27776 malloc(35232) = 0x557ed8afa950 27776 memset(0x557ed8afa950, '\0', 35232) = 0x557ed8afa950 27776 malloc(8800) = 0x557ed8b03300 27776 memset(0x557ed8b03300, '\0', 8800) = 0x557ed8b03300 27776 malloc(8192) = 0x557ed8b05570
Ciao, Michael.
--On Wednesday, July 17, 2019 8:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
On 7/17/19 4:41 PM, Howard Chu wrote:
strace is not useful here. Pretty sure we've stated this many times before.
Sorry. Indeed ltrace output is more helpful.
Hm, does reverting any of these four ITSes allow it to work?
Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) (33945aeb96124f5956c0657b41bb68ca29fab66c)
Fixed libldap to correctly disable IPv6 when configured to do so (ITS#8754) (c4f55cea87880ca8c14b559bd77bcea19ad615cd)
Fixed libldap race condition in ldap_int_initialize (ITS#7996, ITS#8450) (cde56fad154fcd25e351c3cd84d8173d263b0a01, 877faea723ecc5721291b0b2f53e34f7921e0f7c)
Fixed libldap return code in ldap_create_assertion_control_value (ITS#8674) (8e6d1b8b81e94f89027a120ea862bd5938e953c6)
Those items are the ones that stand out to me in the change log that have the highest possibilty of affecting things.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount