Package: nslcd Version: 0.9.12-4 I have an nslcd configuration for a large site that uses tls_cacertfile to pin a specific root CA for the ldaps:// server. There was a cert update on the server (without my knowledge) that resulted in the required root CA changing. Unfortunately, this is how the situation presented in syslog:
2024-12-16T10:01:01.432192-05:00 darkstar nslcd[1898]: [2fcf4d] <passwd="xyuser"> failed to bind to LDAP server ldaps://ldap.example.com/: Can't contact LDAP server: (unknown error code): Resource temporarily unavailable 2024-12-16T10:01:01.432230-05:00 darkstar nslcd[1898]: [2fcf4d] <passwd="xyuser"> no available LDAP server found, sleeping 1 seconds 2024-12-16T10:01:02.445088-05:00 darkstar nslcd[1898]: [2fcf4d] <passwd="xyuser"> failed to bind to LDAP server ldaps://ldap.example.com/: Can't contact LDAP server: (unknown error code): Resource temporarily unavailable 2024-12-16T10:01:02.445125-05:00 darkstar nslcd[1898]: [2fcf4d] <passwd="xyuser"> no available LDAP server found, sleeping 1 seconds 2024-12-16T10:01:03.455484-05:00 darkstar nslcd[1898]: [2fcf4d] <passwd="xyuser"> failed to bind to LDAP server ldaps://ldap.example.com/: Can't contact LDAP server: (unknown error code): Resource temporarily unavailable 2024-12-16T10:01:03.455521-05:00 darkstar nslcd[1898]: [2fcf4d] <passwd="xyuser"> no available LDAP server found, sleeping 1 seconds Debug logging just gave more "Resource temporarily unavailable" errors, and strace(1) showed connect() calls failing with EINPROGRESS, read()s with EAGAIN. Meanwhile, other LDAP clients (like ldapsearch(1)) connected just fine with the same credentials. It wasn't until I tried replacing tls_cacertfile with tls_cacertdir that things started working again, and the issue became clear. TLS connection errors are a common source of administrative issues with LDAP configuration, and the program ought to give a clear indication of same to allow for quick diagnosis.
