openldap-bugs September 2013

openldap-bugs@openldap.org

30 participants
114 discussions

Re: (ITS#7693) ProxyCache Problems
by quanah＠zimbra.com 13 Sep '13

13 Sep '13

--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

1 0

(ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com 13 Sep '13

13 Sep '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 19 URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch Submission from: (NULL) (46.5.2.70) Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is broken for IPv6 for current versions of openldap. Tested with version 2.4.35 It's not clear if this ever worked properly. Connections immediately fail with: ldap_search_ext: Can't contact LDAP server (-1) The reason for this is that the LDAP_CONNECTIONLESS buffers include a prefix containing an address in a "struct sockaddr". However, struct sockaddr, is not a concrete type. In particular struct sockaddr_in6 is longer than struct sockaddr. Noted here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… So this leads to failures when using IPv6 as the code assumes that the address length is equal to sizeof (struct sockaddr). Seen here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… Example command: $ ldapsearch -d -1 -LL -H 'cldap://[2620:52:0:2223::1:1]' -b '' -s base '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon Output will contain this: ldap_write: want=96 error=Invalid argument Which is the EINVAL resulting from bad value passed to sendto().

1 0

(ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 13 Sep '13

13 Sep '13

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

1 0

(ITS#7692) segfault in overlay constraint - constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713
by coudot＠linagora.com 12 Sep '13

12 Sep '13

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.

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah＠zimbra.com 12 Sep '13

12 Sep '13

--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

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 12 Sep '13

12 Sep '13

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 <pre wrap="">Openldap 2.3.40 on sunOS </pre> <pre wrap="">While the ldap slave is : </pre> OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) On 09/12/13 10:23, CHEW Chee Siang wrote: </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. "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=<a moz-do-not-send="true" class="moz-txt-link-freetext">ldap://ldap-master.com</a>                         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: </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: <blockquote type="cite">Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> 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 </blockquote> Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote> </blockquote> </body> </html> --------------010103040709080503030708--

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 12 Sep '13

12 Sep '13

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. "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=<a class="moz-txt-link-freetext" href="ldap://ldap-master.com">ldap://ldap-master.com</a>                         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: </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: <blockquote type="cite">Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> 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 </blockquote> Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote> </body> </html> --------------040706000700030201020504--

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah＠zimbra.com 12 Sep '13

12 Sep '13

--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

1 0

(ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

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

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by pierangelo.masarati＠polimi.it 11 Sep '13

11 Sep '13

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

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2013