openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

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

11 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 11 Sep '13

11 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 11 Sep '13

11 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 10 Sep '13

10 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

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by ck＠cksoft.de 10 Sep '13

10 Sep '13

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. > > -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1091139785-1378839346=:6609--

1 0

(ITS#7690) OpenLDAP 2.4.36 crashing with MDB
by marco.pizzoli＠gmail.com 10 Sep '13

10 Sep '13

Full_Name: Marco Pizzoli Version: 2.4.36 OS: RHEL 5.4 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) NOTICE: This is not a complete bug report. I'm aware I'm not providing useful information on the exact problem and how to fix it. I'm filing this ITS just to keep track of a crash happened to me with the latest release of OpenLDAP with MDB. WHAT HAS HAPPENED A colleague of mine tried to create a clone of an entry by using a graphic client. Something bad happened during that and as a result he obtained an entry nested 509 times: uid=pippo,uid=pippo,uid=pippo,etc...etc...ou=root When trying to delete the root of those entries, with phpldapadmin, I managed to crash OL without nothing executed. It was an MDB database. I zeroed that db, made it repopulate (it is part of a multi-master topology) by using the HDB database engine and re-tried to delete that (root)entry. This time the operation, even not completing (it dropped only half the of the subtree), it suffered no crash. All other slapds in the multi-master topology crashed. I restated the command on the first and this time it completed well. In the end, I re-used the MDB database after having those entries syncronized by other slapd of the multi-master topology. As said in advance, I simply can't provide any conf or core or anything else.

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by michael＠stroeder.com 10 Sep '13

10 Sep '13

This is a cryptographically signed message in MIME format. --------------ms020200010309050905060801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ck(a)cksoft.de wrote: > we have a java application using JNDI that uses the password modify ext= ended > operation to change user passwords. > [..] > When running slapd with heavy logging we save the only difference to ld= appasswd > which works fine against our masters is that JNDI sets the ManageDsaIT = by > default. Of course slapd should never crash. But strictly speaking the semantics of using ManageDsaIT control along wi= th password modify ext.op. is not specified - at least not in RFC 3062. Ciao, Michael. --------------ms020200010309050905060801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTEwMTgyMzM1WjAj BgkqhkiG9w0BCQQxFgQUEspAhGoCvSxwItIQvDO9RKj4c1kwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEASG/b4BKftKYcHYL3Q2ELEB+o3JQzuFoN kJf0ZxDQGuyOoR55w0WpGITlb+WOblLtZm34rdrB8ZeHbX3AmC4VH4yiuV8wnjByychDpbG0 8w+5Kqgm0Zrl/NYFpSbyYJJu3wvv1Jcj/pgRQ0BTprM95rMbEnC2XnNfp0JQeSZ0BmvbL6Fc R8yPkRqfxrsvHoCaGAlHlRihqSalR0m3JPjMM9H0TcfxJEtz2/rdtjN8zi3RRV94qmwd4qCk JW8FRFQEzdcd8Kjkd3HxRPfTTWNIbnROi9/K7wEb/lGgL8hBkgsz6pRGviD6xpIXZnYZ9+Vw o5+e3J5DNhfWgDgPtKCuRAAAAAAAAA== --------------ms020200010309050905060801--

1 0

Re: (ITS#7689) Configuration directive 'logfile' has no use
by quanah＠zimbra.com 10 Sep '13

10 Sep '13

--On Tuesday, September 10, 2013 4:02 PM +0000 eurban(a)harris.com wrote: > Full_Name: Eric Urban > Version: 2.4.36 > OS: RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (158.147.58.198) > > > Hi, I have been working on packaging 2.4.36 for RHEL 6.4. No issues > there. One requirement is to have logging enabled by default. OpenLDAP > supports syslog, but its use is discouraged within my business area. I > noticed the 'logfile' configuration directive. I still use the > 'slapd.conf' configuration file format, if that matters. I added the > following line to my 'slapd.conf' "logfile" is not a replacement for syslog logging, and is an entirely separate function. Please read the slapd.conf(5) man page. Closing this ITS as invalid. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7689) Configuration directive 'logfile' has no use
by eurban＠harris.com 10 Sep '13

10 Sep '13

Full_Name: Eric Urban Version: 2.4.36 OS: RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.147.58.198) Hi, I have been working on packaging 2.4.36 for RHEL 6.4. No issues there. One requirement is to have logging enabled by default. OpenLDAP supports syslog, but its use is discouraged within my business area. I noticed the 'logfile' configuration directive. I still use the 'slapd.conf' configuration file format, if that matters. I added the following line to my 'slapd.conf' logfile /var/log/openldap/openldap.log loglevel none sync stats Then I did mkdir /var/log/openldap chown ldap:ldap /var/log/openldap I restart OpenLDAP and the log file is created but never written to. If I start openldap with 'slapd -d -1' the log file is written to. I checked in include/ldap_log.h and see that the macros for LogN check against 'ldap_debug' before calling lutil_debug. The pseudo-variable 'ldap_debug' is a preprocessor #define at the bottom of the same file. It is just an integer bitmask for logging. I took a look at servers/slapd/bconfig.c and see that 'config_generic' does an fopen() and then passes the result to lutil_debug_file. So far, so good. In config_loglevel the 'loglevel' directive from my slapd.conf is parsed and assigned to 'ldap_syslog' but never 'ldap_debug'. So slapd in server mode will create this file but never write to it. If you set 'logfile' in slapd.conf and start with the -d flag it will, but this is pretty pointless is as you already have the logging messages in your terminal in that case. Is this intentional? I'm not seeing the utility of the 'logfile' configuration directive. In normal operations it's only purpose will be to create an empty file and to confuse system administrators.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs