I've been using OpenLDAP to talk to Fedora DS, and my bindings
weren't working! This was quite vexing, so I did some investigation.
I finally pinpointed the error to ldap_get_values_len() returning
a NULL pointer for nsslapd-referral, with no error code.
Sounds sort of like a bug in OpenLDAP, no? Yes it does, but it's a bug
that's only tickled in very strange circumstances. If you use ldapvi,
well, that links to OpenLDAP, but it ignores NULLs so that's why you
never see a nsslapd-referral in your cn=config entry.
I made a dump of the buffer that OpenLDAP was parsing values out
of (I think this was what was transmitted over the network.)
Exhibit A (byte sequence containing nsslapd-referral):
Exhibit B (byte sequence containing nsslapd-localhost):
As you can see, the byte sequence for nsslapd-referral appears to have
no textual data associated with it. What's up with that?
I've got a failure, and I'm able to gdb it. However, I don't
know what to look for. What kind of tracing would you like to
see? I was going to wireshark but decrypting the Kerberos would
[16/Oct/2010:14:17:16 -0400] NSMMReplicationPlugin - agmt="cn=GSSAPI Replication to busy-beaver.mit.edu" (busy-beaver:389): Unable to parse the response to the startReplication extended operation. Replication is aborting.
Can we expect replication between 1.2.2 and 22.214.171.124 to work? I'm trying to set up MMR between two servers running the two different versions and the 126.96.36.199 master is failing with the following message in it's errors log:
[14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin stefan" (stefan:636): Unable to parse the response to the startReplication extended operation. Replication is aborting.
[14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin stefan" (stefan:636): Incremental update failed and requires administrator action
The corresponding messages in the 1.2.2 master's access file show:
[14/Oct/2010:16:26:19 -0400] conn=139 fd=65 slot=65 SSL connection from 188.8.131.52 to 184.108.40.206
[14/Oct/2010:16:26:19 -0400] conn=139 op=0 BIND dn="cn=Replication Manager,cn=config" method=128 version=3
[14/Oct/2010:16:26:19 -0400] conn=139 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config"
[14/Oct/2010:16:26:19 -0400] conn=139 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[14/Oct/2010:16:26:19 -0400] conn=139 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[14/Oct/2010:16:26:19 -0400] conn=139 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[14/Oct/2010:16:26:19 -0400] conn=139 op=2 RESULT err=0 tag=101 nentries=1 etime=0
[14/Oct/2010:16:26:19 -0400] conn=139 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[14/Oct/2010:16:26:19 -0400] conn=139 op=3 RESULT err=0 tag=101 nentries=1 etime=0
[14/Oct/2010:16:26:19 -0400] conn=139 op=4 EXT oid="2.16.840.1.1137220.127.116.11"
[14/Oct/2010:16:26:19 -0400] conn=139 op=4 RESULT err=2 tag=120 nentries=0 etime=0
[14/Oct/2010:16:27:19 -0400] conn=139 op=5 UNBIND
[14/Oct/2010:16:27:19 -0400] conn=139 op=5 fd=65 closed - U1
I looked up oid 2.16.840.1.113718.104.22.168 and it's apparently new for hooking plugins into the replication process. I just skimmed the 22.214.171.124 source code and it appears that there's logic to detect if the remote server supports it. Is that the intent and it's bugged or is replication between the two version just not supposed to work?
I am the person behind the current FDS Packaging efforts for Debian.
Roberto mentioned to me some threads  related to Debian packaging,
so I thought I share the status of my work. Hopefully interested people
can chime in and lend a hand or report bugs.
The svn repo where I commit the debian/ dir can be found on alioth 
I've setup a repository which is usable for debian Sid (i386 and amd64).
Just add the following line to your sources.list:
deb http://acksyn.org/debian sid main
To install the 389 DS:
apt-get install dirsrv
The Directory Server 126.96.36.199 package is in a fairly decent shape (modulo ipv6:
you have to disable the bindv6only proc entry)
The rest of the stack is mostly packaged but needs a lot more fixing and
polishing than the server.
Right now I am working on the Admin Server and the Console. My goal is
provide a foundation for FreeIPA in Debian. 
The Wiki page for this packagin effort can be found here 
If you have any questions, bug reports or suggestions feel free to drop
me a line per mail.
Michele Baldessari <michele(a)acksyn.org>
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
----- Missatge original -----
> I a bit confused... have you successfully created the entry using the
> console and am looking for a ldif example? Or did the creation failed
> in the console. I can give you examples of how we create our tree and
> sub suffixes if that will help, they are all in ldif format.
i've found some additional info here:
i was a little bit lost but i've finally managed to create an entry trhough console. all examples i found were using ldif and command line for entry creation, but is really easy with console. just be carefull with using the exact same name as in the suffix database creation.
thanks for your time, anyway.
We recently started using the 389 Directory Server and are seeing an odd
problem where searches start returning the wrong DN for a small number of
entries in our directory. For example, our users are in
ou=People,dc=acs,dc=albany,dc=edu but for a few user entries the server
starts returning the DN as "uid=(username),dc=acs,dc=albany,dc=edu,"
"uid=(username),ou=Group,dc=acs,dc=albany,dc=edu," or sometimes even
something like "uid=(username),=albany,,dc=acs,dc=albany,dc=edu." The
problem seems to be in memory, as restarting the directory server fixes
the problem temporarily but then it will start happening again with a
different set of entries. A db2ldif extract made while the server is in
this state does not contain any of the bad DNs.
I tried upgrading to 188.8.131.52-2. Since the upgrade, this has not happened
for any user entries, but has happened for group entries.
Has anyone else run into this problem? We are running 389 Directory
Server on Oracle Linux 5.5 and using the x86_64 389 DS packages from EPEL.
We have about 125,000 entries in our directory, most of which are in
ou=People. We recently migrated from the Sun Directory Server 5.2.
ITS Systems Management & Operations
After upgrading 389 Directory Server, I am getting a "ldap_add: Already
exists (68)" error message when importing a used to be working LDIF via the
Can someone help me to confirm that they are seeing the same thing? Adding
the entry itself is fine but the problem occurs when I try to add members to
my entry. Particularly it doesn't like the white space in between the
Here's my LDIF.
member: 333 222 111
member: 111 333 444
The admin guide says that one should use ns-newpwpolicy.pl script to set subtree password policies on the command line. Can we also set this using ldifs or is there some magic that this script perform that can't be achieved by using ldifs?
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.