Re: (ITS#7527) Problems Adding entries to back-mdb database
by hyc＠symas.com
whm(a)stanford.edu wrote:
> Full_Name: Bill MacAllister
> Version: RE24 pulled 11-Feb-2013
> OS: debian wheezy (testing)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (67.180.239.194)
>
>
> When attempting to add a new entry to a back-mdb database I am seeing
> the following failure:
>
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu"
> ldap_add: Other (e.g., implementation specific) error (80)
> additional info: index generation failed
Since you pulled RE24 on Feb 11, your code should be producing additional
error info in syslog. Please send the slapd logs associated with this error.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 3 months
(ITS#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu
Full_Name: Bill MacAllister
Version: RE24 pulled 11-Feb-2013
OS: debian wheezy (testing)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (67.180.239.194)
When attempting to add a new entry to a back-mdb database I am seeing
the following failure:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: index generation failed
The attribute that is causing the failure is suPrivilegeGroup. The
schema definition for this attribute is:
olcAttributeTypes: ( StanfordLDAPattributeType:19 NAME ( 'suPrivilegeGroup' )
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The index defined for this attribute is:
olcDbIndex: suPrivilegeGroup eq,sub
I have been able to successfully load the entry by either:
* Modifying the index definition by removing the substring index, i.e.
'olcDbIndex: suPrivilegeGroup eq,sub'.
or
* Modifying the data. The value 'suPrivilegeGroup: n:all' succeeds
and the value 'suPrivilegeGroup: ne:all' fails.
Here is a complete failing entry:
dn: suRegID=uniqueid1,cn=people,dc=stanford,dc=edu
objectClass: suPerson
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: person
displayName: Bill MacAllister
suCN: bill macallister
suDisplayNameLF: MacAllister, Bill
suGeneralID: billmacallister
suRegID: uniqueid1
suRegisteredName: William Henry MacAllister
suRegisteredNameLF: MacAllister, William Henry
suSN: macallister
suUniqueIdentifier: unique1
sn: macallister
o: University
ou: netdocs-access:all
uid: whm
cn: bill macallister
cn: william macallister
givenName: william
givenName: bill
suPrivilegeGroup: ne:all
I first started investigating this problem because some entries where
not present in the directory after a complete refresh from an ldif
dumped from a 2.4.26 server. I used slapadd to load the ldif and
there were no error messages during the load, just some entries were
missing. I expect that the lack of an error message from slapadd is
a separate, but related issue.
10 years, 3 months
Re: (ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com
--=_alternative 0036332BC1257B11_=
Content-Type: text/plain; charset="US-ASCII"
Installed the master revision (openldap-648d28f.tar.gz)
Test ok .
Many thanks,
Francesco Policastro
From:
Pierangelo Masarati <masarati(a)aero.polimi.it>
To:
<francesco.policastro(a)selex-es.com>
Cc:
<openldap-its(a)openldap.org>
Date:
12/02/2013 17:23
Subject:
Re: (ITS#7525) Bad conversion to cn=config format
Fixed in git master, please test. p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
--=_alternative 0036332BC1257B11_=
Content-Type: text/html; charset="US-ASCII"
<font size=2 face="sans-serif">Installed the master revision (openldap-648d28f.tar.gz)</font>
<br><font size=2 face="sans-serif">Test ok .</font>
<br>
<br><font size=2 face="sans-serif">Many thanks,</font>
<br><font size=2 face="sans-serif"><b>Francesco Policastro</b></font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Pierangelo Masarati <masarati(a)aero.polimi.it></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif"><francesco.policastro(a)selex-es.com></font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif"><openldap-its(a)openldap.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">12/02/2013 17:23</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: (ITS#7525) Bad conversion to cn=config
format</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Fixed in git master, please test. p.<br>
<br>
-- <br>
Pierangelo Masarati<br>
Associate Professor<br>
Dipartimento di Scienze e Tecnologie Aerospaziali<br>
Politecnico di Milano<br>
</font></tt>
<br>
--=_alternative 0036332BC1257B11_=--
10 years, 3 months
Re: (ITS#7526) Segfault in slapd-meta during olcDbUri modify
by masarati＠aero.polimi.it
> Full_Name: John Madden
> Version: 2.4.32
> OS: Linux / RHEL6/64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (168.91.17.188)
>
>
> slapd-meta frontend to another slapd, perform an ldapmodify on the
> olcDbUri
> (incidentally while troubleshooting incorrect proxy behavior) results in a
> segfault.
Your backtrace looks useless; however, I could reproduce the problem. A(n
almost blind) fix is coming.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
10 years, 3 months
(ITS#7526) Segfault in slapd-meta during olcDbUri modify
by jmadden＠ivytech.edu
Full_Name: John Madden
Version: 2.4.32
OS: Linux / RHEL6/64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (168.91.17.188)
slapd-meta frontend to another slapd, perform an ldapmodify on the olcDbUri
(incidentally while troubleshooting incorrect proxy behavior) results in a
segfault.
(gdb) attach 5979
Attaching to process 5979
Reading symbols from /usr/local/libexec/slapd...(no debugging symbols
found)...done.
Reading symbols from /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so...(no debugging
symbols found)...done.
Loaded symbols for /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x7f9dc6485700 (LWP 6928)]
[New Thread 0x7f9dc6c86700 (LWP 6927)]
[New Thread 0x7f9dc7487700 (LWP 5980)]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libsasl2.so.2
Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libssl.so.10
Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libcrypto.so.10
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libk5crypto.so.3
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libfreebl3.so...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libfreebl3.so
Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libselinux.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libnss_files.so.2
Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libnss_dns.so.2
Reading symbols from /usr/lib64/sasl2/libcrammd5.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/libcrammd5.so
Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/libanonymous.so
Reading symbols from /usr/lib64/sasl2/libplain.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/libplain.so
Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/libsasldb.so
Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdb-4.7.so
Reading symbols from /usr/lib64/sasl2/liblogin.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/liblogin.so
Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so
Reading symbols from /usr/lib64/sasl2/libgssapiv2.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/sasl2/libgssapiv2.so
0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install
cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64
glibc-2.12-1.80.el6_3.6.x86_64 keyutils-libs-1.4-4.el6.x86_64
krb5-libs-1.9-33.el6_3.3.x86_64 libcom_err-1.41.12-12.el6.x86_64
libselinux-2.0.94-5.3.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64
openssl-1.0.0-25.el6_3.1.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9dc6c86700 (LWP 6927)]
0x0000000000516517 in ?? ()
(gdb) backtrace full
#0 0x0000000000516517 in ?? ()
No symbol table info available.
#1 0x0000000000412b2c in ?? ()
No symbol table info available.
#2 0x0000000000438a8b in ?? ()
No symbol table info available.
#3 0x00000000004393b6 in ?? ()
No symbol table info available.
#4 0x00000000004212d9 in ?? ()
No symbol table info available.
#5 0x0000000000421ab5 in ?? ()
No symbol table info available.
#6 0x0000000000570da0 in ?? ()
No symbol table info available.
#7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8 0x0000003310ce811d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) info registers
rax 0x19 25
rbx 0x7f9dc6c83340 140315621602112
rcx 0x0 0
rdx 0x19 25
rsi 0x7f9dc6c83340 140315621602112
rdi 0x7f9dc6c83340 140315621602112
rbp 0x1dbaf00 0x1dbaf00
rsp 0x7f9dc6c80bf0 0x7f9dc6c80bf0
r8 0x0 0
r9 0x7f9dc6c830c0 140315621601472
r10 0x84db78 8706936
r11 0x0 0
r12 0x1d55390 30757776
r13 0x7f9dc6c83340 140315621602112
r14 0x7f9db8112be0 140315374726112
r15 0x7f9db8112670 140315374724720
rip 0x516517 0x516517
eflags 0x10283 [ CF SF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/16i $pc
=> 0x516517: mov 0x0,%rdi
0x51651f: test %rdi,%rdi
0x516522: je 0x515858
0x516528: callq 0x43b4e0
0x51652d: xor %ebp,%ebp
0x51652f: movq $0x0,0x0
0x51653b: jmpq 0x515745
0x516540: andl $0xfffffe7f,0x8
0x51654b: xor %ebp,%ebp
0x51654d: jmpq 0x515745
0x516552: andl $0xfffdffff,0x8
0x51655d: xor %ebp,%ebp
0x51655f: jmpq 0x515745
0x516564: movq $0x0,0x138(%rbp)
0x51656f: xor %ebp,%ebp
0x516571: jmpq 0x515745
(gdb) thread apply all backtrace
Thread 4 (Thread 0x7f9dc7487700 (LWP 5980)):
#0 0x0000003310ce8713 in epoll_wait () from /lib64/libc.so.6
#1 0x000000000041e5fa in ?? ()
#2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0
#3 0x0000003310ce811d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f9dc6c86700 (LWP 6927)):
#0 0x0000000000516517 in ?? ()
#1 0x0000000000412b2c in ?? ()
#2 0x0000000000438a8b in ?? ()
#3 0x00000000004393b6 in ?? ()
#4 0x00000000004212d9 in ?? ()
#5 0x0000000000421ab5 in ?? ()
#6 0x0000000000570da0 in ?? ()
#7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0
#8 0x0000003310ce811d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f9dc6485700 (LWP 6928)):
#0 0x000000331140b43c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x0000000000570df5 in ?? ()
#2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0
#3 0x0000003310ce811d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f9dcb64e7c0 (LWP 5979)):
#0 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0
#1 0x000000000041b951 in ?? ()
#2 0x00000000004081c5 in ?? ()
#3 0x0000003310c1ecdd in __libc_start_main () from /lib64/libc.so.6
#4 0x0000000000406a69 in ?? ()
#5 0x00007fffe3969bc8 in ?? ()
#6 0x000000000000001c in ?? ()
#7 0x0000000000000005 in ?? ()
#8 0x00007fffe396bd7a in ?? ()
#9 0x00007fffe396bd93 in ?? ()
#10 0x00007fffe396bd96 in ?? ()
#11 0x00007fffe396bdbe in ?? ()
#12 0x00007fffe396bdc1 in ?? ()
#13 0x0000000000000000 in ?? ()
10 years, 3 months
(ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com
Full_Name: Francesco Policastro
Version: 2.4.33
OS: RHEL 6.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (94.127.80.134)
A slapd.conf using meta backend can include the following uri definition that is
accepted as legal
uri "ldap://server2.domain2.net/ou=org Unit,dc=second,dc=newco,dc=com"
idassert-bind bindmethod=simple binddn="cn=ldap-2,cn=Users,dc=domain2,dc=net"
credentials=secret3
chase-referrals no
rebind-as-user true
map objectclass groupOfNames *
map objectclass person *
suffixmassage "dc=second,dc=newco,dc=com" "dc=domain2,dc=net"
subtree-include "ou=Users,ou=1stlocation,ou=org Unit,dc=second,dc=newco,dc=com"
...
"slaptest -f slapd.conf" returns "config file testing succeeded"
"slaptest -f slapd.conf -F slapd.d" converts to cn=config format
"slaptest -F slapd.d" issues an error:
511a57ef olcDbURI: value #0: unable to parse URI #0 in "olcDbURI
<protocol>://<server>[:port]/<naming context>".
511a57ef config error processing
olcMetaSub={1}uri,olcDatabase={1}meta,cn=config: unable to parse URI #0 in
"olcDbURI <protocol>://<server>[:port]/<naming context>"
slaptest: bad configuration directory!
I know that the offending words are in the "ou=org Unit" directive; in fact
"ou=orgUnit" (with no space) works.
The uri sintax permits to enclose the string in quotes and one assumes that
spaces are legal. They are only in slapd.conf because the cn=config conversion
does not accept them.
10 years, 3 months
(ITS#7524) Seg fault of slapd with back-meta traffic
by jorge.perez.burgos＠ericsson.com
Full_Name: Jorge Perez Burgos
Version: 2.4.32
OS: SLES 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.235.15.243)
PROBLEM
Sending high load traffic to several slapd servers that are proxying the traffic
to only one slapd. It can seen that in this situation originating servers crash
sporadically.
POSSIBLE SOLUTION
In back-meta/conn.c in the method meta_back_retry it seems that the binding flag
is not set properly in the following situation:
/* restore the "binding" flag, in case */
if ( binding ) {
LDAP_BACK_CONN_BINDING_SET( msc );
}
if ( rc == LDAP_SUCCESS ) {
quarantine = 0;
rc = meta_back_single_dobind( op, rs, mcp, candidate,
sendok, mt->mt_nretries, 0 );
Setting the binding flag before calling meta_back_single_dobind seems to solve
the issue (LDAP_BACK_CONN_BINDING_SET( msc );)
CORE DUMP TRACE
This is the backtrace of the core dumped.
Program terminated with signal 6, Aborted.
#0 0x00002ad023473f45 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00002ad023473f45 in raise () from /lib64/libc.so.6
#1 0x00002ad023475340 in abort () from /lib64/libc.so.6
#2 0x00002ad02346d486 in __assert_fail () from /lib64/libc.so.6
#3 0x000000000051cfe1 in meta_back_bind_op_result (op=0x69d2580,
rs=0x2aab95e57c70, mc=0x2aab62a44740, candidate=2, msgid=1, sendok=<value
optimized out>, dolock=0) at bind.c:392
#4 0x000000000051d130 in meta_back_proxy_authz_bind (mc=0x2aab62a44740,
candidate=2, op=0x69d2580, rs=0x2aab95e57c70, sendok=LDAP_BACK_DONTSEND,
dolock=0) at bind.c:1590
#5 0x000000000051d37b in meta_back_single_dobind (op=0x69d2580,
rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND,
nretries=<value optimized out>, dolock=0) at bind.c:605
#6 0x000000000052714d in meta_back_retry (op=0x69d2580, rs=0x2aab95e57c70,
mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND) at conn.c:769
#7 0x00000000004db025 in meta_back_search (op=0x69d2580, rs=0x2aab95e57c70) at
search.c:1154
#8 0x00000000004636d9 in fe_op_search (op=0x69d2580, rs=0x2aab95e57c70) at
search.c:402
#9 0x00000000004c4e02 in overlay_op_walk (op=0x69d2580, rs=0x2aab95e57c70,
which=op_search, oi=0x8088000, on=0x0) at backover.c:671
#10 0x00000000004c5307 in over_op_func (op=0x69d2580, rs=0x2aab95e57c70,
which=op_search) at backover.c:723
#11 0x0000000000463ee5 in do_search (op=0x69d2580, rs=0x2aab95e57c70) at
search.c:247
#12 0x0000000000460f45 in connection_operation (ctx=0x2aab95e57e50, arg_v=<value
optimized out>) at connection.c:1308
#13 0x0000000000461e05 in connection_read_thread (ctx=0x2aab95e57e50,
argv=<value optimized out>) at connection.c:1444
#14 0x000000000055cb7c in ldap_int_thread_pool_wrapper (xpool=0x8028000) at
tpool.c:688
#15 0x00002ad022ec92a3 in start_thread () from /lib64/libpthread.so.0
#16 0x00002ad02350549d in clone () from /lib64/libc.so.6
10 years, 3 months
(ITS#7522) Admin Guide: bugs in example
by openldap＠laimbock.com
Full_Name: Patrick Laimbock
Version: RE24
OS: CentOS 6.3 x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (94.210.175.192)
In the OpenLDAP Admin Guide on page 38 it says:
34. olcSuffix: "dc=example,dc=com"
35. olcDbDirectory: /usr/local/var/openldap-data
36. olcRootDN: "cn=Manager,dc=example,dc=com"
37. olcRootPW: secret
38. olcDbIndex: uid pres,eq
39. olcDbIndex: cn,sn,uid pres,eq,approx,sub
When I try to slapadd that example config I get the following errors:
5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax
1.3.6.1.4.1.1466.115.121.1.12)
5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax
1.3.6.1.4.1.1466.115.121.1.12)
/etc/openldap34/slapd.d: line 1: duplicate index definition for attr "uid"
When I remove the quotes from the olcSuffix (line 34) and olcRootDN (line 36)
entries and remove the double uid from either line 38 or line 39 then the
slapadd action is successful.
10 years, 3 months
