samba with openldap provisioning

[Howard Chu]

> Date: Tue, 03 Sep 2013 11:29:05 +1200
> From: Andrew Bartlett <abartlet at samba.org>
> To: Nadezhda Ivanova <nivanova at samba.org>
> Cc: Samba Technical <samba-technical at lists.samba.org>

> On Tue, 2013-09-03 at 10:42 +1200, Andrew Bartlett wrote:
>> > On Tue, 2013-09-03 at 08:29 +1200, Andrew Bartlett wrote:
>>> > > On Mon, 2013-09-02 at 17:09 +0300, Nadezhda Ivanova wrote:
>>>> > > > Hi Andrew,
>>>> > > >
>>>> > > > I was also able to provision, after applying your patches and removing
>>>> > > > --use-rfc2307 and adding --use-ntvfs in my provision command. Phew!
>>>> > > > One step forward! Now I get a bigger shovel and continue digging on
>>>> > > > the openldap side, I'll keep you posted on the progress.
>>> > >
>>> > > Great!  So I can reproduce exactly what you did, was this with OpenLDAP
>>> > > from CVS or from GIT?
>>> > >
>>> > > Let's keep digging, we will make this pig fly again!
>> >
>> > I've found the missing patch.  We ripped this out when we dropped the
>> > LDAP backend.  With this patch, we now connect in 'samba', and are ready
>> > to pass the baton back over to the OpenLDAP side of things.  The next
>> > error is from slapd, with one of the reasons we stopped doing this:
>> > 'invalid' (presumably extended) DNs.
>> >
>> > dn: cn=NTDS
>> > Settings,cn=RUTH,cn=Servers,cn=Default-First-Site-Name,cn=Sites,cn=Configuration,dc=ldap,dc=samba,dc=example,dc=com
>> >
>> >
>> >
>> > ldb: ldb_trace_response: DONE
>> > error: 0
>> >
>> > ldb: ldb_trace_next_request: (partition)->search
>> > ldb: ldb_trace_next_request: (schema_data)->search
>> > ldb: ldb_trace_next_request: (entryuuid)->search
>> > ldb: ldb_trace_next_request: (paged_searches)->search
>> > ldb: ldb_trace_next_request: (simple_dn)->search
>> > ldb: ldb_trace_next_request: (ldap)->search
>> > ldb: ldb_asprintf/set_errstring: LDAP error 34 LDAP_INVALID_DN_SYNTAX -
>> > <invalid DN> <>
>> >
>> > Andrew Bartlett
>
> I can confirm it fails in the same way with OpenLDAP from GIT.
>
> The next step will be to have OpenLDAP communicate over LDAP, not LDAPi.
> The key for that will be again handling more provision options that were
> removed with 696a70c9faac27bcd473b6c2f1444abd267ae6e6 so that we start
> ldapd listening in TCP, and connect to it over TCP.  That way, wireshark
> can see what is on the wire.

The next step is to read the docs or talk to us... :P

You don't need wireshark for this. Just run slapd with packet debug enabled. I 
usually use slapd -d7 as a starting point.

   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/