Re: (ITS#7693) ProxyCache Problems
by quanah@zimbra.com
--On Thursday, September 12, 2013 2:38 PM +0000 teichler(a)message-mobile.de
wrote:
> Full_Name: Mike Teichler
> Version: 2.4
> OS: Windows 7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.152.191.58)
>
>
>
> Hello,
>
> I have an Issue with the ProxyCache on OpenLDAP
> (2.4.23-32.el6_4.1)[CentOS 6] which should Cache the Queryanswers from an
> OpenLDAP ( 2.3.43-12.el5_7.9)[CentOS 5] Server.
Please upgrade to a supported release series (2.3 is not supported).
Please upgrade to a current release (2.4.36 is the most recent release).
2.4.23 as built by RedHat is known to have numerous problems.
If you cannot build OpenLDAP yourself, then I would suggest the packages
from the LTB project, which have OpenLDAP builds of 2.4.36 for both RHEL5
and RHEL6:
<http://ltb-project.org/wiki/download#openldap>
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 2 months
(ITS#7693) ProxyCache Problems
by teichler@message-mobile.de
Full_Name: Mike Teichler
Version: 2.4
OS: Windows 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.152.191.58)
Hello,
I have an Issue with the ProxyCache on OpenLDAP (2.4.23-32.el6_4.1)[CentOS 6]
which should Cache the Queryanswers from an OpenLDAP ( 2.3.43-12.el5_7.9)[CentOS
5] Server.
The Problem isn't the Proxy but the Cache. When I do a query, i get the right
Answer.
But if I look into the LDAP.log with locklevel=2048,
I always get the Strings:
QUERY NOT ANSWERABLE
QUERY NOT CACHABLE
and if I shutdown the Server where the Proxy get its Informations it doesn't
answers to the same query.
My Konfiguration:
In: /etc/openldap/slapd.d/olcDatabase={1}ldap/olcOverlay={0}pcache.ldif
dn: olcOverlay={0}pcache
objectClass: olcOverlayConfig
objectClass: olcPcacheConfig
olcOverlay: {0}pcache
olcPcache: bdb 100000 30 1000 3600
olcPcacheAttrset: 0 objectClass gidNumber mail cn uid displayName uidNumber ou
userPassword
olcPcacheTemplate: "(objectClass=)" 0 3600
olcPcachePosition: tail
olcPcacheMaxQueries: 10000
olcPcacheValidate: FALSE
structuralObjectClass: olcPcacheConfig
entryUUID: 3a14c15c-ab42-1032-824e-7d8dac3932bf
creatorsName: cn=config
createTimestamp: 20130906131604Z
olcPcacheOffline: FALSE
olcPcachePersist: TRUE
entryCSN: 20130910133719.273176Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130910133719Z
In: /etc/openldap/slapd.d/olcDatabase={1}ldap/olcOverlay={0}pcache/olcDatabase={0}bdb.ldif
dn: olcDatabase={0}bdb
objectClass: olcBdbConfig
objectClass: olcPcacheDatabase
olcDatabase: {0}bdb
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 10000
olcDbConfig: {0} #
olcDbConfig: {1} # Set the database in memory cache size.
olcDbConfig: {2} #
olcDbConfig: {3} set_cachesize 0 524288000 1
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: displayName pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 3a14cbde-ab42-1032-824f-7d8dac3932bf
creatorsName: cn=config
createTimestamp: 20130906131604Z
entryCSN: 20130906131604.110178Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130906131604Z
If you need more Informations please ask.
best regards,
M. Teichler
10 years, 2 months
(ITS#7692) segfault in overlay constraint - constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713
by coudot@linagora.com
Full_Name: Clement OUDOT
Version: 2.4.35
OS: CentOS 6 64bits
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.145.72.122)
I use the overlay constraint to check that a value of the attribute ssoRoles
exists in the directory. The configuration looks like this:
----------------------------------------------
overlay constraint
constraint_attribute ssoRoles uri
ldap:///ou=applications,dc=cirra,dc=net?entrydn?sub?(&(objectClass=organizationalUnit)(ou:dn:=roles))
restrict="ldap:///ou=users,dc=cirra,dc=net??one?(objectClass=inetOrgPerson)"
----------------------------------------------
An ldapmodify with this LDIF crash the slapd process:
----------------------------------------------
dn: uid=toto,ou=users,dc=cirra,dc=net
changetype: modify
add: ssoRoles
ssoRoles: ou=ROLE_PES,ou=roles,ou=simabo,ou=applications,dc=cirra,dc=net
----------------------------------------------
The crash occurs because the entry uid=toto,ou=users,dc=cirra,dc=net do not
exist. The same LDIF on an existing entry works well.
Below is the stacktrace generated with gdb:
----------------------------------------------
(gdb) run -d 0
Starting program: /usr/local/openldap/libexec/slapd -d 0
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffb3d42700 (LWP 16519)]
[New Thread 0x7fffb3541700 (LWP 16521)]
[New Thread 0x7fffb2d40700 (LWP 16522)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb2d40700 (LWP 16522)]
constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at
constraint.c:713
713 int diff = e->e_nname.bv_len - c->restrict_ndn.bv_len;
Missing separate debuginfos, use: debuginfo-install
berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64
cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64
cyrus-sasl-ldap-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-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.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64
krb5-libs-1.10.3-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64
libselinux-2.0.94-5.3.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64
nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6.x86_64
zlib-1.2.3-29.el6.x86_64
(gdb) bt full
#0 constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at
constraint.c:713
diff = <value optimized out>
__PRETTY_FUNCTION__ = "constraint_check_restrict"
#1 0x000000000054b39f in constraint_update (op=<value optimized out>,
rs=0x7fffb2d3f950) at constraint.c:989
j = <value optimized out>
ce = 0
on = 0x9e5e30
be = 0x7fffb2d3e4e0
c = 0x9e60f0
cp = <value optimized out>
target_entry = 0x0
target_entry_copy = 0x0
modlist = 0x7fffa8000920
m = 0x7fffa8000920
b = 0x7fffa81015c0
i = <value optimized out>
rsv = {bv_len = 24, bv_val = 0x60f2a4 "modify breaks constraint"}
rc = <value optimized out>
msg = 0x0
is_v = <value optimized out>
#2 0x00000000004a6d7a in overlay_op_walk (op=0x7fffa8000960, rs=0x7fffb2d3f950,
which=op_modify, oi=0x9e1020, on=0x9e5e30)
at backover.c:661
func = 0x9e5e88
rc = 32768
#3 0x00000000004a7847 in over_op_func (op=0x7fffa8000960, rs=<value optimized
out>, which=<value optimized out>)
at backover.c:723
oi = <value optimized out>
on = <value optimized out>
be = 0x9ba220
db = {bd_info = 0x9e5e30, bd_self = 0x9ba220,
be_ctrls =
"\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001",
'\000' <repeats 12 times>, "\001", be_flags = 2312, be_restrictops = 0,
be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0,
sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport
= 0, sss_update_tls = 0,
sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9dca20,
be_nsuffix = 0x9dca50, be_schemadn = {
bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val =
0x0}, be_rootdn = {bv_len = 26,
bv_val = 0x9dcb70 "cn=manager,dc=cirra,dc=net"}, be_rootndn =
{bv_len = 26,
bv_val = 0x9dcbc0 "cn=manager,dc=cirra,dc=net"}, be_rootpw = {bv_len
= 38,
bv_val = 0x9dc8b0 "{SSHA}2S9rqrduHEq4AcNIfS+wxClQwbD5aoLn"},
be_max_deref_depth = 15, be_def_limit = {
lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0,
lms_s_unchecked = -1, lms_s_pr = 0,
lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9e01a0, be_acl
= 0x9b9850, be_dfltaccess = ACL_READ,
be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0},
be_update_refs = 0x0,
---Type <return> to continue, or q <return> to quit---
be_pending_csn_list = 0xa6f7f0, be_pcl_mutex = {__data = {__lock = 0,
__count = 0, __owner = 0, __nusers = 0,
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = '\000' <repeats 39 times>,
__align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8838c0,
be_private = 0x9ba3c0, be_next = {
stqe_next = 0x9e6470}}
cb = {sc_next = 0x0, sc_response = 0x4a6af0 <over_back_response>,
sc_cleanup = 0, sc_private = 0x9e1020}
sc = <value optimized out>
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#4 0x000000000045728b in fe_op_modify (op=0x7fffa8000960, rs=0x7fffb2d3f950) at
modify.c:303
update = <value optimized out>
repl_user = <value optimized out>
op_be = <value optimized out>
bd = 0x88c200
textbuf = ">\000\000\000\000\000\000\000\240\030\020\250\377\177\000\000\000\000\000\000\000\000\000\000@\026\020\250\377\177\000\000\240\235G\000\000\000\000\000\267\244E",
'\000' <repeats 13 times>, "\003\000\000\000\060\000\000\000[\000\000\000|",
'\000' <repeats 11 times>, "\b", '\000' <repeats 31 times>,
">\000\000\000\000\000\000\000\360\025\020\250\377\177\000\000\000\000\000\000\000\000\000\000
\t\000\250\377\177\000\000\000\000\000\000\000\000\000\000@É
#5 0x0000000000457bb6 in do_modify (op=0x7fffa8000960,
rs=0x7fffb2d3f950) at modify.c:177
dn = {bv_len = 33, bv_val = 0x7fffa8101507
"uid=toto,ou=users,dc=cirra,dc=net"}
textbuf = "\027\f\000\250\377\177", '\000' <repeats 42 times>,
"PG\253\367\000\000\000\000P\333\377\367\377\177\000\000\000\000A", '\000'
<repeats 13 times>, "\030f@\000\000\000\000\000Y\345`\237\064", '\000' <repeats
11 times>"\351, \363[\000\000\000\000\000`\t\000\250\377\177\000\000\340\024\302\236\064\000\000\000\377\377\377\377\377\177\000\000\030\372Ó²\377\177\000\000\210\021\302\236\064\000\000\000@\304X\237\064",
'\000' <repeats 11 times>,
":\236\240\236\064\000\000\000\320\016\000\250\377\177\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\260\372Ó²\377\177\000\000\360.I",
'\000' <repeats 13 times>,
"\t\000\000\000\062\000\000\000`\t\000\250\377\177\000\000\320\016\000\250\377\177\000"
tmp = <value optimized out>
#6 0x000000000043f9a9 in connection_operation (ctx=0x7fffb2d3fab0,
arg_v=0x7fffa8000960) at connection.c:1155
rc = 80
cancel = <value optimized out>
op = 0x7fffa8000960
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0,
sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0,
sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags =
0, r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0},
sru_extended = {r_rspoid = 0x0,
r_rspdata = 0x0}}, sr_flags = 0}
tag = 102
opidx = SLAP_OP_MODIFY
conn = 0x7ffff632bc10
---Type <return> to continue, or q <return> to quit---
memctx = 0x7fffa8000ed0
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#7 0x0000000000440195 in connection_read_thread (ctx=0x7fffb2d3fab0,
argv=<value optimized out>) at connection.c:1291
rc = <value optimized out>
cri = {op = 0x7fffa8000960, func = 0, arg = 0x0, ctx = 0x7fffb2d3fab0,
nullop = <value optimized out>}
s = <value optimized out>
#8 0x0000000000593d00 in ldap_int_thread_pool_wrapper (xpool=0x960c00) at
tpool.c:688
pool = 0x960c00
task = 0x7fffac0008c0
work_list = <value optimized out>
ctx = {ltu_id = 140736193627904, ltu_key = {{ltk_key = 0x43e7c0,
ltk_data = 0x7fffa8000dc0,
ltk_free = 0x43e890 <conn_counter_destroy>}, {ltk_key = 0x492d40,
ltk_data = 0x7fffa8000ed0,
ltk_free = 0x492d60 <slap_sl_mem_destroy>}, {ltk_key = 0xa6f810,
ltk_data = 0x7fffa8100f80,
ltk_free = 0x4f7280 <bdb_reader_free>}, {ltk_key = 0x452ba0,
ltk_data = 0x0,
ltk_free = 0x452970 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data
= 0x0, ltk_free = 0} <repeats 25 times>, {
ltk_key = 0x0, ltk_data = 0x349f607eea, ltk_free = 0}, {ltk_key =
0x0, ltk_data = 0x0, ltk_free = 0}, {
ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}}
kctx = <value optimized out>
keyslot = 555
hash = <value optimized out>
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#9 0x000000349f607851 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x000000349f2e890d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)
----------------------------------------------
Please tell me if something else is needed in this bug report.
Regards,
Clement OUDOT.
10 years, 2 months
Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah@zimbra.com
--On Thursday, September 12, 2013 3:31 AM +0000 chewcs(a)bii.a-star.edu.sg
wrote:
> This is a multi-part message in MIME format.
> --------------010103040709080503030708
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> One more thing: the ldap master version is
>
> Openldap 2.3.40 on sunOS
Syncrepl in 2.3.40 is known to be broken. I would advise you to upgrade it
to 2.4.36.
This ITS will be closed as invalid.
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 2 months
Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs@bii.a-star.edu.sg
This is a multi-part message in MIME format.
--------------010103040709080503030708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
One more thing: the ldap master version is
Openldap 2.3.40 on sunOS
While the ldap slave is :
OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54)
On 09/12/13 10:23, CHEW Chee Siang wrote:
> One more thing. The entry with "cn=depth" name won't sync only when
> adding entries to ou=mailinglist. Somehow it is ok with ou=people.
>
>
>
> "Master" LDAP configuration:
> /Include /go/to/core.schema//
> //Include /go/to/cosine.schema//
> //Include /go/to/inetorgperson.schema//
> //Include /go/to/nis.schema//
> //Include /go/to/samba.schema//
> //Include /go/to/test.schema//
> //pidfile /go/to/slapd.pid//
> //argsfile /go/to/slapd.args/
>
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> /TLSCACertificateFile /go/to/ldap.pem//
> //TLSCertificateFile /go/to/ldap.pem//
> //TLSCertificateKeyFile /go/to/ldap.key/
>
> access to attrs=userPassword
> by self write
> by users read
> by peername.ip=127.0.0.1 read
> by peername.ip=10.X.0.0%255.255.0.0 read
> by peername.ip=172.X.129.132 read
> by peername.ip=172.X.1.109 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=X.X.68.0%255.255.255.0 read
> by anonymous auth
>
> access to attrs=cryptPassword,md5Password,shadowLastChange
> by self write
> by users read
> by peername.ip=127.0.0.1 read
> by peername.ip=10.217.0.0%255.255.0.0 read
> by peername.ip=172.X.129.132 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=X.X.68.0%255.255.255.0 read
> by anonymous none
>
> access to dn.subtree="ou=zgroups,dc=test,dc=com
> by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write
> by self read
> by users read
> by peername.ip=127.0.0.1 read
> by peername.ip=10.X.0.0%255.255.0.0 read
> by peername.ip=X.X.X.0%255.255.255.0 read
> by peername.ip=172.X.129.132 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by anonymous none
>
> access to *
> by self read
> by users read
> by peername.ip=127.0.0.1 read
> by peername.ip=10.X.0.0%255.255.0.0 read
> by peername.ip=172.X.129.132 read
> by peername.ip=172.X.1.109 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=172.X.0.0%255.255.0.0 read
> by peername.ip=X.X.68.0%255.255.255.0 read
> by anonymous none
>
> # Database backend configuration.
>
> allow bind_v2
> database bdb
> password-hash {CRYPT}
> directory /go/to/ldap-master
> suffix "dc=test,dc=com"
> rootdn "cn=root,dc=test,dc=com"
> rootpw secret
> index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq
>
> # Configure syncrepl (provider)
>
> overlay syncprov
> syncprov-checkpoint 1 1 # <ops> <minutes>
> syncprov-sessionlog 100 # <max number of session logs>
>
>
>
>
> "Slave" LDAP configuration:
> include /usr/local/openldap/etc/openldap/schema/core.schema
> include //usr/local/openldap/etc/openldap/schema/test.schema/
> include /usr/local/openldap/etc/openldap/schema/cosine.schema
> include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
> include /usr/local/openldap/etc/openldap/schema/nis.schema
> include /usr/local/openldap/etc/openldap/schema/samba.schema
>
>
> # Define global ACLs to disable default read access.
> allow bind_v2
>
> pidfile /usr/local/openldap/var/run/slapd.pid
> argsfile /usr/local/openldap/var/run/slapd.args
> loglevel 256
> moduleload back_hdb.la
> moduleload syncprov.la
> moduleload back_monitor.la
> moduleload back_ldap.la
>
> access to *
> by self write
> by users read
> by peername.ip=127.0.0.1 read
> by peername.ip=172.20.201.0%255.255.255.0 read
> by anonymous read
>
> #######################################################################
> # BDB database definitions
> #######################################################################
>
> database bdb
> suffix /"dc=test,dc=com"/
> rootdn "cn=Manager,/dc=test,dc=com"/
> rootpw secret
> directory /usr/local/openldap/var/openldap-data
>
> # Indices to maintain
> index cn,sn,uid pres,eq,approx,sub
> index objectClass eq
>
>
> index entryCSN,entryUUID eq
> syncrepl rid=1
> provider=/ldap://ldap-master.com/
> type=refreshOnly
> interval=00:00:00:30
> searchbase=/"dc=test,dc=com"/
> scope=sub
> schemachecking=off
> bindmethod=simple
> binddn=/"cn=ldaplogin,ou=people,dc=test,dc=com"/
> credentials=/secret/
>
>
> On 09/12/13 05:57, Quanah Gibson-Mount wrote:
>> --On Wednesday, September 11, 2013 8:03 AM +0000
>> chewcs(a)bii.a-star.edu.sg wrote:
>>
>>> Full_Name: Chew Chee Siang
>>> Version: slapd 2.4.36
>>> OS: CentOS 6.4
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (123.136.68.2)
>>>
>>>
>>> The setup is a master-slave configuration
>>> Whenever a new user with name starting with "depth" is created at
>>> master,
>>> the record will not be sync to slave using syncrepl.
>>> The other records are ok.
>>> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com
>>> or cn=depth,ou=people,dc=tt,dc=com
>>
>> Provide your configuration minus passwords.
>>
>> --Quanah
>>
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Lead Engineer
>> Zimbra, Inc
>> --------------------
>> Zimbra :: the leader in open source messaging and collaboration
>>
>
--------------010103040709080503030708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">One more thing: the ldap master version
is <br>
<pre wrap="">Openldap 2.3.40 on sunOS
</pre>
<pre wrap=""><font face="sans-serif">While the ldap slave is :</font>
</pre>
OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54)<br>
<br>
<br>
On 09/12/13 10:23, CHEW Chee Siang wrote:<br>
</div>
<blockquote cite="mid:523125B9.2020004@bii.a-star.edu.sg"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-cite-prefix">One more thing. The entry with
"cn=depth" name won't sync only when adding entries to
ou=mailinglist. Somehow it is ok with ou=people.<br>
<br>
<br>
<br>
"Master" LDAP configuration:<br>
<i>Include /go/to/core.schema</i><i><br>
</i><i>Include /go/to/cosine.schema</i><i><br>
</i><i>Include /go/to/inetorgperson.schema</i><i><br>
</i><i>Include /go/to/nis.schema</i><i><br>
</i><i>Include /go/to/samba.schema</i><i><br>
</i><i>Include /go/to/test.schema</i><i><br>
</i><i>pidfile /go/to/slapd.pid</i><i><br>
</i><i>argsfile /go/to/slapd.args</i><br>
<br>
TLSCipherSuite HIGH:MEDIUM:+SSLv2<br>
<i>TLSCACertificateFile /go/to/ldap.pem</i><i><br>
</i><i>TLSCertificateFile /go/to/ldap.pem</i><i><br>
</i><i>TLSCertificateKeyFile /go/to/ldap.key</i><br>
<br>
access to attrs=userPassword<br>
by self write<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.1.109 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.68.0%255.255.255.0 read<br>
by anonymous auth<br>
<br>
access to attrs=cryptPassword,md5Password,shadowLastChange<br>
by self write<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.217.0.0%255.255.0.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.68.0%255.255.255.0 read<br>
by anonymous none<br>
<br>
access to dn.subtree="ou=zgroups,dc=test,dc=com<br>
by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write<br>
by self read<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.X.0%255.255.255.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by anonymous none<br>
<br>
access to *<br>
by self read<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.1.109 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.68.0%255.255.255.0 read<br>
by anonymous none<br>
<br>
# Database backend configuration.<br>
<br>
allow bind_v2<br>
database bdb<br>
password-hash {CRYPT}<br>
directory /go/to/ldap-master<br>
suffix "dc=test,dc=com"<br>
rootdn "cn=root,dc=test,dc=com"<br>
rootpw secret<br>
index objectClass,uid,uidNumber,entryCSN,entryUUID
pres,eq<br>
<br>
# Configure syncrepl (provider)<br>
<br>
overlay syncprov<br>
syncprov-checkpoint 1 1 # <ops> <minutes><br>
syncprov-sessionlog 100 # <max number of session
logs><br>
<br>
<br>
<br>
<br>
"Slave" LDAP configuration:<br>
include
/usr/local/openldap/etc/openldap/schema/core.schema<br>
include <i>/usr/local/openldap/etc/openldap/schema/test.schema</i><br>
include
/usr/local/openldap/etc/openldap/schema/cosine.schema<br>
include
/usr/local/openldap/etc/openldap/schema/inetorgperson.schema<br>
include /usr/local/openldap/etc/openldap/schema/nis.schema<br>
include /usr/local/openldap/etc/openldap/schema/samba.schema<br>
<br>
<br>
# Define global ACLs to disable default read access.<br>
allow bind_v2<br>
<br>
pidfile /usr/local/openldap/var/run/slapd.pid<br>
argsfile /usr/local/openldap/var/run/slapd.args<br>
loglevel 256<br>
moduleload back_hdb.la<br>
moduleload syncprov.la<br>
moduleload back_monitor.la<br>
moduleload back_ldap.la<br>
<br>
access to *<br>
by self write<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=172.20.201.0%255.255.255.0 read<br>
by anonymous read<br>
<br>
#######################################################################<br>
# BDB database definitions<br>
#######################################################################<br>
<br>
database bdb<br>
suffix <i>"dc=test,dc=com"</i><br>
rootdn "cn=Manager,<i>dc=test,dc=com"</i><br>
rootpw secret<br>
directory /usr/local/openldap/var/openldap-data<br>
<br>
# Indices to maintain<br>
index cn,sn,uid pres,eq,approx,sub<br>
index objectClass eq<br>
<br>
<br>
index entryCSN,entryUUID eq<br>
syncrepl rid=1<br>
provider=<i><a moz-do-not-send="true"
class="moz-txt-link-freetext">ldap://ldap-master.com</a></i><br>
type=refreshOnly<br>
interval=00:00:00:30<br>
searchbase=<i>"dc=test,dc=com"</i><br>
scope=sub<br>
schemachecking=off<br>
bindmethod=simple<br>
binddn=<i>"cn=ldaplogin,ou=people,dc=test,dc=com"</i><br>
credentials=<i>secret</i><br>
<br>
<br>
On 09/12/13 05:57, Quanah Gibson-Mount wrote:<br>
</div>
<blockquote cite="mid:75FEF2DB661402B3EB284EDD@%5B192.168.1.22%5D"
type="cite">--On Wednesday, September 11, 2013 8:03 AM +0000 <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:chewcs@bii.a-star.edu.sg">chewcs(a)bii.a-star.edu.sg</a>
wrote: <br>
<br>
<blockquote type="cite">Full_Name: Chew Chee Siang <br>
Version: slapd 2.4.36 <br>
OS: CentOS 6.4 <br>
URL: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a>
<br>
Submission from: (NULL) (123.136.68.2) <br>
<br>
<br>
The setup is a master-slave configuration <br>
Whenever a new user with name starting with "depth" is created
at master, <br>
the record will not be sync to slave using syncrepl. <br>
The other records are ok. <br>
For e.g. cn=depth-maker,ou=people,dc=tt,dc=com <br>
or cn=depth,ou=people,dc=tt,dc=com <br>
</blockquote>
<br>
Provide your configuration minus passwords. <br>
<br>
--Quanah <br>
<br>
<br>
<br>
-- <br>
<br>
Quanah Gibson-Mount <br>
Lead Engineer <br>
Zimbra, Inc <br>
-------------------- <br>
Zimbra :: the leader in open source messaging and collaboration
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
--------------010103040709080503030708--
10 years, 2 months
Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs@bii.a-star.edu.sg
This is a multi-part message in MIME format.
--------------040706000700030201020504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
One more thing. The entry with "cn=depth" name won't sync only when
adding entries to ou=mailinglist. Somehow it is ok with ou=people.
"Master" LDAP configuration:
/Include /go/to/core.schema//
//Include /go/to/cosine.schema//
//Include /go/to/inetorgperson.schema//
//Include /go/to/nis.schema//
//Include /go/to/samba.schema//
//Include /go/to/test.schema//
//pidfile /go/to/slapd.pid//
//argsfile /go/to/slapd.args/
TLSCipherSuite HIGH:MEDIUM:+SSLv2
/TLSCACertificateFile /go/to/ldap.pem//
//TLSCertificateFile /go/to/ldap.pem//
//TLSCertificateKeyFile /go/to/ldap.key/
access to attrs=userPassword
by self write
by users read
by peername.ip=127.0.0.1 read
by peername.ip=10.X.0.0%255.255.0.0 read
by peername.ip=172.X.129.132 read
by peername.ip=172.X.1.109 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=X.X.68.0%255.255.255.0 read
by anonymous auth
access to attrs=cryptPassword,md5Password,shadowLastChange
by self write
by users read
by peername.ip=127.0.0.1 read
by peername.ip=10.217.0.0%255.255.0.0 read
by peername.ip=172.X.129.132 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=X.X.68.0%255.255.255.0 read
by anonymous none
access to dn.subtree="ou=zgroups,dc=test,dc=com
by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write
by self read
by users read
by peername.ip=127.0.0.1 read
by peername.ip=10.X.0.0%255.255.0.0 read
by peername.ip=X.X.X.0%255.255.255.0 read
by peername.ip=172.X.129.132 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by anonymous none
access to *
by self read
by users read
by peername.ip=127.0.0.1 read
by peername.ip=10.X.0.0%255.255.0.0 read
by peername.ip=172.X.129.132 read
by peername.ip=172.X.1.109 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=172.X.0.0%255.255.0.0 read
by peername.ip=X.X.68.0%255.255.255.0 read
by anonymous none
# Database backend configuration.
allow bind_v2
database bdb
password-hash {CRYPT}
directory /go/to/ldap-master
suffix "dc=test,dc=com"
rootdn "cn=root,dc=test,dc=com"
rootpw secret
index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq
# Configure syncrepl (provider)
overlay syncprov
syncprov-checkpoint 1 1 # <ops> <minutes>
syncprov-sessionlog 100 # <max number of session logs>
"Slave" LDAP configuration:
include /usr/local/openldap/etc/openldap/schema/core.schema
include //usr/local/openldap/etc/openldap/schema/test.schema/
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/samba.schema
# Define global ACLs to disable default read access.
allow bind_v2
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
loglevel 256
moduleload back_hdb.la
moduleload syncprov.la
moduleload back_monitor.la
moduleload back_ldap.la
access to *
by self write
by users read
by peername.ip=127.0.0.1 read
by peername.ip=172.20.201.0%255.255.255.0 read
by anonymous read
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix /"dc=test,dc=com"/
rootdn "cn=Manager,/dc=test,dc=com"/
rootpw secret
directory /usr/local/openldap/var/openldap-data
# Indices to maintain
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
index entryCSN,entryUUID eq
syncrepl rid=1
provider=/ldap://ldap-master.com/
type=refreshOnly
interval=00:00:00:30
searchbase=/"dc=test,dc=com"/
scope=sub
schemachecking=off
bindmethod=simple
binddn=/"cn=ldaplogin,ou=people,dc=test,dc=com"/
credentials=/secret/
On 09/12/13 05:57, Quanah Gibson-Mount wrote:
> --On Wednesday, September 11, 2013 8:03 AM +0000
> chewcs(a)bii.a-star.edu.sg wrote:
>
>> Full_Name: Chew Chee Siang
>> Version: slapd 2.4.36
>> OS: CentOS 6.4
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (123.136.68.2)
>>
>>
>> The setup is a master-slave configuration
>> Whenever a new user with name starting with "depth" is created at
>> master,
>> the record will not be sync to slave using syncrepl.
>> The other records are ok.
>> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com
>> or cn=depth,ou=people,dc=tt,dc=com
>
> Provide your configuration minus passwords.
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Lead Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
--------------040706000700030201020504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">One more thing. The entry with
"cn=depth" name won't sync only when adding entries to
ou=mailinglist. Somehow it is ok with ou=people.<br>
<br>
<br>
<br>
"Master" LDAP configuration:<br>
<i>Include /go/to/core.schema</i><i><br>
</i><i>Include /go/to/cosine.schema</i><i><br>
</i><i>Include /go/to/inetorgperson.schema</i><i><br>
</i><i>Include /go/to/nis.schema</i><i><br>
</i><i>Include /go/to/samba.schema</i><i><br>
</i><i>Include /go/to/test.schema</i><i><br>
</i><i>pidfile /go/to/slapd.pid</i><i><br>
</i><i>argsfile /go/to/slapd.args</i><br>
<br>
TLSCipherSuite HIGH:MEDIUM:+SSLv2<br>
<i>TLSCACertificateFile /go/to/ldap.pem</i><i><br>
</i><i>TLSCertificateFile /go/to/ldap.pem</i><i><br>
</i><i>TLSCertificateKeyFile /go/to/ldap.key</i><br>
<br>
access to attrs=userPassword<br>
by self write<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.1.109 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.68.0%255.255.255.0 read<br>
by anonymous auth<br>
<br>
access to attrs=cryptPassword,md5Password,shadowLastChange<br>
by self write<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.217.0.0%255.255.0.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.68.0%255.255.255.0 read<br>
by anonymous none<br>
<br>
access to dn.subtree="ou=zgroups,dc=test,dc=com<br>
by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write<br>
by self read<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.X.0%255.255.255.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by anonymous none<br>
<br>
access to *<br>
by self read<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=10.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.129.132 read<br>
by peername.ip=172.X.1.109 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=172.X.0.0%255.255.0.0 read<br>
by peername.ip=X.X.68.0%255.255.255.0 read<br>
by anonymous none<br>
<br>
# Database backend configuration.<br>
<br>
allow bind_v2<br>
database bdb<br>
password-hash {CRYPT}<br>
directory /go/to/ldap-master<br>
suffix "dc=test,dc=com"<br>
rootdn "cn=root,dc=test,dc=com"<br>
rootpw secret<br>
index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq<br>
<br>
# Configure syncrepl (provider)<br>
<br>
overlay syncprov<br>
syncprov-checkpoint 1 1 # <ops> <minutes><br>
syncprov-sessionlog 100 # <max number of session
logs><br>
<br>
<br>
<br>
<br>
"Slave" LDAP configuration:<br>
include /usr/local/openldap/etc/openldap/schema/core.schema<br>
include <i>/usr/local/openldap/etc/openldap/schema/test.schema</i><br>
include /usr/local/openldap/etc/openldap/schema/cosine.schema<br>
include
/usr/local/openldap/etc/openldap/schema/inetorgperson.schema<br>
include /usr/local/openldap/etc/openldap/schema/nis.schema<br>
include /usr/local/openldap/etc/openldap/schema/samba.schema<br>
<br>
<br>
# Define global ACLs to disable default read access.<br>
allow bind_v2<br>
<br>
pidfile /usr/local/openldap/var/run/slapd.pid<br>
argsfile /usr/local/openldap/var/run/slapd.args<br>
loglevel 256<br>
moduleload back_hdb.la<br>
moduleload syncprov.la<br>
moduleload back_monitor.la<br>
moduleload back_ldap.la<br>
<br>
access to *<br>
by self write<br>
by users read<br>
by peername.ip=127.0.0.1 read<br>
by peername.ip=172.20.201.0%255.255.255.0 read<br>
by anonymous read<br>
<br>
#######################################################################<br>
# BDB database definitions<br>
#######################################################################<br>
<br>
database bdb<br>
suffix <i>"dc=test,dc=com"</i><br>
rootdn "cn=Manager,<i>dc=test,dc=com"</i><br>
rootpw secret<br>
directory /usr/local/openldap/var/openldap-data<br>
<br>
# Indices to maintain<br>
index cn,sn,uid pres,eq,approx,sub<br>
index objectClass eq<br>
<br>
<br>
index entryCSN,entryUUID eq<br>
syncrepl rid=1<br>
provider=<i><a class="moz-txt-link-freetext" href="ldap://ldap-master.com">ldap://ldap-master.com</a></i><br>
type=refreshOnly<br>
interval=00:00:00:30<br>
searchbase=<i>"dc=test,dc=com"</i><br>
scope=sub<br>
schemachecking=off<br>
bindmethod=simple<br>
binddn=<i>"cn=ldaplogin,ou=people,dc=test,dc=com"</i><br>
credentials=<i>secret</i><br>
<br>
<br>
On 09/12/13 05:57, Quanah Gibson-Mount wrote:<br>
</div>
<blockquote cite="mid:75FEF2DB661402B3EB284EDD@%5B192.168.1.22%5D"
type="cite">--On Wednesday, September 11, 2013 8:03 AM +0000
<a class="moz-txt-link-abbreviated" href="mailto:chewcs@bii.a-star.edu.sg">chewcs(a)bii.a-star.edu.sg</a> wrote:
<br>
<br>
<blockquote type="cite">Full_Name: Chew Chee Siang
<br>
Version: slapd 2.4.36
<br>
OS: CentOS 6.4
<br>
URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a>
<br>
Submission from: (NULL) (123.136.68.2)
<br>
<br>
<br>
The setup is a master-slave configuration
<br>
Whenever a new user with name starting with "depth" is created
at master,
<br>
the record will not be sync to slave using syncrepl.
<br>
The other records are ok.
<br>
For e.g. cn=depth-maker,ou=people,dc=tt,dc=com
<br>
or cn=depth,ou=people,dc=tt,dc=com
<br>
</blockquote>
<br>
Provide your configuration minus passwords.
<br>
<br>
--Quanah
<br>
<br>
<br>
<br>
--
<br>
<br>
Quanah Gibson-Mount
<br>
Lead Engineer
<br>
Zimbra, Inc
<br>
--------------------
<br>
Zimbra :: the leader in open source messaging and collaboration
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------040706000700030201020504--
10 years, 2 months
Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah@zimbra.com
--On Wednesday, September 11, 2013 8:03 AM +0000 chewcs(a)bii.a-star.edu.sg
wrote:
> Full_Name: Chew Chee Siang
> Version: slapd 2.4.36
> OS: CentOS 6.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (123.136.68.2)
>
>
> The setup is a master-slave configuration
> Whenever a new user with name starting with "depth" is created at master,
> the record will not be sync to slave using syncrepl.
> The other records are ok.
> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com
> or cn=depth,ou=people,dc=tt,dc=com
Provide your configuration minus passwords.
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 2 months
(ITS#7691) syncrepl does not work with names start with depth
by chewcs@bii.a-star.edu.sg
Full_Name: Chew Chee Siang
Version: slapd 2.4.36
OS: CentOS 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (123.136.68.2)
The setup is a master-slave configuration
Whenever a new user with name starting with "depth" is created at master, the
record will not be sync to slave using syncrepl.
The other records are ok.
For e.g. cn=depth-maker,ou=people,dc=tt,dc=com
or cn=depth,ou=people,dc=tt,dc=com
10 years, 2 months
Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by pierangelo.masarati@polimi.it
Thanks for the report; I have a quick fix, I'm testing it and will
commit shortly.
p.
On 09/10/2013 09:14 PM, ck(a)cksoft.de wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --4178219828-1091139785-1378839346=:6609
> Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed
> Content-Transfer-Encoding: 8BIT
> Content-ID: <alpine.BSF.2.00.1309102056121.6609(a)pohjola.cksoft.de>
>
> Hi,
>
> On Tue, 10 Sep 2013, Michael Ströder wrote:
>
>> ck(a)cksoft.de wrote:
>>> we have a java application using JNDI that uses the password modify extended
>>> operation to change user passwords.
>>> [..]
>>> When running slapd with heavy logging we save the only difference to ldappasswd
>>> which works fine against our masters is that JNDI sets the ManageDsaIT by
>>> default.
>>
>> Of course slapd should never crash.
>
> yes of course not. This opens an attack vector for shooting down the slapd to at least anyone who has bind access which is concerning me.
>
> Apart from that the customers problem is solved. We just stopped sending the control. A bit like Dr. Dr. it hurts when I Do this. Then why don't you stop doing it.
>
>> But strictly speaking the semantics of using ManageDsaIT control along with
>> password modify ext.op. is not specified - at least not in RFC 3062.
>
> yes. jndi sets the control by default.
>
>>From looking at the assert
>
> slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed.
>
> the comment in chain.c seems to hint at an overly simple assumption. But in understand too little of slapd internals and code flow:
>
> 188 static int
> 189 chaining_control_remove(
> 190 Operation *op,
> 191 LDAPControl ***oldctrlsp )
> 192 {
> 193 LDAPControl **oldctrls = *oldctrlsp;
> 194
> 195 /* we assume that the first control is the chaining control
> 196 * added by the chain overlay, so it's the only one we explicitly
> 197 * free */
> 198 if ( op->o_ctrls != oldctrls ) {
> 199 assert( op->o_ctrls != NULL );
> 200 assert( op->o_ctrls[ 0 ] != NULL );
> 201
> 202 free( op->o_ctrls );
> 203
> 204 op->o_chaining = 0;
> 205 op->o_ctrls = oldctrls;
> 206 }
> 207
> 208 *oldctrlsp = NULL;
> 209
> 210 return 0;
> 211 }
>
>
> Could it be as simple as walking the linked list and just removing the chaining control.
>
> Of course another strategy might be to filter anything but the chaining control up front.
>
> Greetings
> Christian
>
>>
>> Ciao, Michael.
>>
>>
>
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
10 years, 2 months