Hi,
I am currently configuring the isc-dhcp-server-ldap on Debian 9(stretch)
but the server doesn't read LDAP conf correctly!
My configuration works both in Debian 7 (wheezy) and Debian 8(jessie) but
not in Debian 9.
When I try to start the dhcp-server service on Debian 9 with the same
configurations from Debian 8 and 7 I start to see weird searches on the
ldap log about dhcpTSigKey and dhcpFailOverPeer:
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=1 SRCH
base="dc=mycompany,cn=com" scope=2 deref=0
filter="(&(objectClass=dhcpServer)(|(cn=server3)(cn=server3.mycompany.com
)))"
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=2 SRCH
base="cn=server3,cn=dhcp,cn=server3.mycompany.com,cn=servers,dc=company,cn=com"
scope=0 deref=0 filter="(&(objectClass=dhcpService)(|(|(dhcpPrimaryDN=cn=
server3.company.com,cn=servers,dc=company,cn=com)(dhcpSecondaryDN=cn=
server3.company.com,cn=servers,dc=company,cn=com))(?dhcpServerDN=cn=
server3.company.com,cn=servers,dc=company,cn=com)))"
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=3 SRCH
base="cn=server3,cn=dhcp,cn=server3.mycompany.com,cn=servers,dc=company,cn=com"
scope=1 deref=0
filter="(!(|(|(?objectClass=dhcpTSigKey)(objectClass=dhcpClass))(?objectClass=dhcpFailOverPeer)))"
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=3 SEARCH RESULT tag=101
err=0 nentries=0 text=
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=4 SRCH
base="cn=server3,cn=dhcp,cn=server3.mycompany.com,cn=servers,dc=company,cn=com"
scope=1 deref=0
filter="(|(|(?objectClass=dhcpTSigKey)(objectClass=dhcpClass))(?objectClass=dhcpFailOverPeer))"
Feb 28 15:04:43 server2 slapd[12478]: conn=1028 op=4 SEARCH RESULT tag=101
err=0 nentries=0 text=
and I don't have those attributes.
By the other hand on Debian 7 (wheezy) and Debian 8(jessie) with the same
configurations the filter used is (objectClass=*):
Feb 28 15:12:12 server2 slapd[12478]: conn=1032 op=1 SRCH
base="company=sc,cn=com" scope=2 deref=0
filter="(&(objectClass=dhcpServer)(|(cn=server3)(cn=server3.mycompany.com
)))"
Feb 28 15:12:12 server2 slapd[12478]: conn=1032 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Feb 28 15:12:12 server2 slapd[12478]: conn=1032 op=2 SRCH
base="cn=server3,cn=dhcp,cn=server3.company.com,cn=servers,dc=company,cn=com"
scope=0 deref=0 filter="(&(objectClass=dhcpService)(|(dhcpPrimaryDN=cn=
server3.mycompany.com,cn=servers,dc=mycompany,cn=com)(dhcpSecondaryDN=cn=
server3.mycompany.com,cn=servers,dc=company,cn=com)))"
Feb 28 15:12:12 server2 slapd[12478]: conn=1032 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Feb 28 15:12:12 server2 slapd[12478]: conn=1032 op=3 SRCH
base="cn=server3,cn=dhcp,cn=server3.company.com,cn=servers,dc=company,cn=com"
scope=1 deref=0 filter="(objectClass=*)"
Feb 28 15:12:12 server2 slapd[12478]: conn=1032 op=3 SEARCH RESULT tag=101
err=0 nentries=19 text=
And thus the  dhcp-server-ldap works and can read my networks perfectly.
This is very similiar to bug #655364.

Could you please analyse it and tell me if I need to use an extra parameter
for new version or if this is really a bug?

Thank you for your time and sorry for the inconvinience,
Ricardo Cardoso

Hi,

since this was actually quite important for me, I sat down with the
source code and tried to understand what happens.

I found that I could not understand why that LDAP query only looks
for those three objectClasses, in my opinion the routine should try to
read ALL possible classes under the base DN, because it is supposed to
read the complete configuration, after all.

So I changed the LDAP search query and - behold - the server works!

You can find my changes below.

Best,       Stefan


root@t30gate2018:/custom/dhcp-4.3.6-P1/server# diff -c ldap.c ldap.c~
*** ldap.c    2018-04-25 15:39:44.319411654 +0200
--- ldap.c~    2018-04-25 15:30:10.000000000 +0200
***************
*** 2043,2049 ****
       }

     if ((ret = ldap_search_ext_s (ld, dn, LDAP_SCOPE_ONELEVEL,
!                                 "(objectClass=*)",
                                   NULL, 0, NULL, NULL,
                                   NULL, 0, &resfirst)) != LDAP_SUCCESS)
       {
--- 2043,2049 ----
       }

     if ((ret = ldap_search_ext_s (ld, dn, LDAP_SCOPE_ONELEVEL,
!
"(|(|(objectClass=dhcpTSigKey)(objectClass=dhcpClass))(objectClass=dhcpFailOverPeer))",
                                   NULL, 0, NULL, NULL,
                                   NULL, 0, &resfirst)) != LDAP_SUCCESS)
       {

Dear submitter,

as the package isc-dhcp has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1143544

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)