- openldap-bugs - openldap.org

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.3.33 > OS: Linux EL 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.215.24.208) > > > I have two synrepl slaves and entries in both of them seem to degrade, over > time, into "objectClass: glue" entities. > > These entries are not updated, so this degradation appears to be autonomous in > the slaves. The slaves have identical problems, the master retains the > structure of the entries. > > I see IS#4626 which has this same sort of problem, and perhaps I should have > followed on to that, but I can say that this problem must be much worse in > 2.3.33 than previously, since this has only happened to me since upgrading to > this release. > > My ou people is reduced to glue as is the ou access. The simplesecurity object > is gone entirely from the slaves' database. This is only the beginning of the > display of differences in the data. > > These entries were not modified since the database creation, and the > disintegration only occurs in the slaves. > > Let me know if more info is needed. Since you mention that this occurs more often in 2.3.33 than in "previous releases" - what previous version are you comparing to? Please provide the relevant section of your slave slapd.conf - the database clause and its syncrepl statement at least. Are there any ACLs on the provider that would prevent the slave from seeing parts of the affected entries? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by quanah＠stanford.edu 24 Jan '07

24 Jan '07

--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

Full_Name: Bob Wells Version: 2.3.33 OS: Linux RH 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.81.96.200) REQUEST FEATURE: Need capability to move an entire entry beneath another branch in the tree. Example: uid=jdoe,ou=customers,dc=acme,dc=com (Customer exists) uid=jdoe,ou=archive,ou=customers,dc=acme,dc=com (Customer account deleted from within application and moved to archive tree branch) Currently, we do not believe openLDAP supports this capability. We have used rebind and rename. We are unable to find a way to do what we need it to do. Therefore, we request this type of feature in the product. Thanks in advance, Bob Wells-070124

1 0

Crypt invalide credential
by Arrouan 24 Jan '07

24 Jan '07

Hi, I'm using OpenLDAP under Linux/Gentoo (with crypt enabled). I can bind user with SSHA password, but i can't bind user with CRYPT password. OpenLDAP is link with Postfix/Courier and need CRYPT password. I check the ACL and it seem the issue isn't there. Anyone know how to fix this issue ? I have other postfix+openldap server and they all work without any problem. Thanks

2 1

Re:(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 23 Jan '07

23 Jan '07

Hi, this is my test setup ##provider### slapd.conf pidfile /tmp/run/slapd1.pid argsfile /tmp/run/slapd1.args loglevel sync modulepath /usr/local/libexec/openldap moduleload syncprov.la access to dn.base="" by * read access to dn.base="cn=Subschema" by * read suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/slapd1/ index objectClass eq overlay syncprov -------------------- initial.ldif dn: dc=my-domain,dc=com objectclass: domain dc: my-domain dn: ou=organisation 1,dc=my-domain,dc=com objectclass: organizationalUnit ou: organisation 1 dn: ou=organisation 2,dc=my-domain,dc=com objectclass: organizationalUnit ou: organisation 2 dn: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com objectclass: inetorgperson cn: Foo Bar sn: Bar mail: foobar(a)my-domain.com telephoneNumber: +49.40.2997714 dn: cn=Bar Foo,ou=organisation 2,dc=my-domain,dc=com objectclass: alias objectclass: extensibleObject aliasedObjectName: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com cn: Bar Foo sn: Foo --------------- ## Consumer #### slapd.conf include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /tmp/run/slapd2.pid argsfile /tmp/run/slapd2.args loglevel sync access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/slapd2/ index objectClass eq syncrepl rid=02 provider=ldap://localhost:9001 binddn=cn=Manager,dc=my-domain,dc=com bindmethod=simple credentials=secret searchbase="dc=my-domain,dc=com" scope=sub type=refreshAndPersist retry="5 5 300 5" -------------------- After starting the comsumer, the initial dataset gets replicated. If adding the following entries (using web2ldap) to the provider dn: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com sn: Miller cn: Mike Miller mail: mmiller(a)my-domain.com telephoneNumber: +49.40.4450003 objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person dn: cn=Miller Mike,ou=organisation 2,dc=my-domain,dc=com aliasedObjectName: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com cn: Miller Mike objectClass: alias objectClass: extensibleObject dn: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com sn: Smith cn: Joe Smith mail: jsmith(a)my-domain.com telephoneNumber: +49.40.4450004 objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person dn: cn=Smith Joe,ou=organisation 2,dc=my-domain,dc=com aliasedObjectName: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com cn: Smith Joe objectClass: alias objectClass: extensibleObject the alias objects are not replicated, only after a consumer restart. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 23 Jan '07

23 Jan '07

Am Montag, 22. Januar 2007 22:28 schrieb Pierangelo Masarati: > dieter(a)dkluenter.de wrote: > > Full_Name: Dieter Kluenter > > Version: 2.4.2alpha > > OS: linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (84.142.177.66) > > > > > > When adding a alias abject to the provider, syncprov fowllows the > > referral and is not updating the alias object to the consumer, > > Dieter, > > are you talking about aliases or referrals? Hi Ando, In this particular case I am talking about aliases. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4813) glue/syncrepl
by aej＠wpi.edu 23 Jan '07

23 Jan '07

Full_Name: Allan E. Johannesen Version: 2.3.33 OS: Linux EL 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.215.24.208) I have two synrepl slaves and entries in both of them seem to degrade, over time, into "objectClass: glue" entities. These entries are not updated, so this degradation appears to be autonomous in the slaves. The slaves have identical problems, the master retains the structure of the entries. I see IS#4626 which has this same sort of problem, and perhaps I should have followed on to that, but I can say that this problem must be much worse in 2.3.33 than previously, since this has only happened to me since upgrading to this release. My ou people is reduced to glue as is the ou access. The simplesecurity object is gone entirely from the slaves' database. This is only the beginning of the display of differences in the data. These entries were not modified since the database creation, and the disintegration only occurs in the slaves. Let me know if more info is needed. Thanks. *** users.ldapv2.2007.01.23.ldif.pure Tue Jan 23 09:10:50 2007 --- users.ldapv2back.2007.01.23.ldif.pure Tue Jan 23 09:10:53 2007 *************** *** 10,18 **** dn: ou=People,dc=WPI,dc=EDU objectClass: top ! objectClass: organizationalUnit ! ou: People ! structuralObjectClass: organizationalUnit dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU objectClass: top --- 10,17 ---- dn: ou=People,dc=WPI,dc=EDU objectClass: top ! objectClass: glue ! structuralObjectClass: glue dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU objectClass: top *************** *** 1498,1514 **** dn: ou=Access,dc=WPI,dc=EDU objectClass: top ! objectClass: organizationalUnit ! ou: Access ! structuralObjectClass: organizationalUnit ! ! dn: cn=retiresql,ou=Access,dc=WPI,dc=EDU ! objectClass: top ! objectClass: simpleSecurityObject ! objectClass: applicationProcess ! cn: retiresql ! userPassword:: e1NTSEF9Qno0NllDM2pwRWZSZGh6OFdRY2RWNWpjdklaWHM0ekU= ! structuralObjectClass: applicationProcess dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU objectClass: top --- 1497,1504 ---- dn: ou=Access,dc=WPI,dc=EDU objectClass: top ! objectClass: glue ! structuralObjectClass: glue dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU objectClass: top

1 0

(ITS#4812) ldapmodify doesn't report error when the server closed the connection
by rhafer＠suse.de 23 Jan '07

23 Jan '07

Full_Name: Ralf Haferkamp Version: 2.3, HEAD OS: Any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.166.107) ldapmodify doesn't report errors from a failed ldap_result() call. This can be reproduce by using ldapmodify via stdin and connecting to a server with a very short idletimeout. If the MODIFY operation is sent after the connection is closed no error message is shown to the user. The only indication of a failure is the EXIT code of ldapmodify. This is fixed in HEAD now.

1 0

Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by hyc＠symas.com 23 Jan '07

23 Jan '07

Thomas.Fritz(a)bam.de wrote: > Full_Name: Thomas Fritz > Version: 2.3.33 > OS: Debian Gnu/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.63.61.111) > > > We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb > backend. > > When performing the modrdn operation against the master, no update directives > for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are > written to the replog file. Hence, the databases of master and slave differ by > the values of these attributes after replication. > > This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions > back to (at least) 2.3.24 are affected. This is not a bug, it is a consequence of the design of slurpd. slurpd uses LDIF (RFC2849) for its replog format, and simply propagates LDAP operations as recorded there. In LDIF a modrdn record can only specify newrdn, deleteoldrdn, and newsuperior parameters. Likewise, these are the only parameters that can be specified in an LDAP modrdn operation. This design limitation is one of many reasons why slurpd has been deprecated. If you want to perform replication and preserve these attributes, you can use syncrepl instead. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by ando＠sys-net.it 22 Jan '07

22 Jan '07

This bug report is missing the most important part: a backtrace of the core dumped when the problem occurs. Please provide one. p.

1 0

(ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by niels＠signaturgruppen.dk 22 Jan '07

22 Jan '07

Full_Name: Niels Frimodt Sørensen Version: 2.3.32 OS: Solaris URL: Submission from: (NULL) (80.160.139.81) Hi, refreshAndPersist mode of syncrepl seems to have problems with Monitor. The slave is dumping core when I do ldapsearch against cn=Connections, cn=Monitor. The system is running on Solaris 9 and based on OpenLDAP 2.3.32. Replication works just fine. If I change syncrepl type to refreshOnly then the ldapsearch is completed without core dump. Further information on configuration and debug below. The Master has the following conf: # slapd.conf # Schema include /opt/ldap/content2/schema/core.schema # Control files pidfile /opt/ldap/backend2/var/slapd.pid argsfile /opt/ldap/backend2/var/slapd.args database bdb suffix "c=NO" rootdn "cn=Manager,c=NO" rootpw Test1234 directory /opt/ldap/content2/data checkpoint 128 10 # Indices to maintain index objectclass,entryCSN,entryUUID eq index serialNumber pres,eq index mail pres,eq index cn pres,eq cachesize 100000 threads 64 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 database monitor The slave has the following conf: # slapd.conf # Schema include /opt/ldap/content-buslave/schema/core.schema # Control files pidfile /opt/ldap/backend-buslave/var/slapd.pid argsfile /opt/ldap/backend-buslave/var/slapd.args # database defs database bdb suffix "c=NO" rootdn "cn=Manager,c=NO" rootpw Test1234 directory /opt/ldap/content-buslave/data checkpoint 128 10 # Indices to maintain index objectclass,entryCSN,entryUUID eq index serialNumber pres,eq index mail pres,eq index cn pres,eq cachesize 100000 threads 32 syncrepl rid=123 provider=ldap://127.0.0.1:3892 type=refreshAndPersist searchbase="c=NO" filter="(objectClass=*)" scobe=sub attrs="" schemachecking=off bindmethod=simple updatedn="cn=Manager,c=NO" binddn="cn=Manager,c=NO" credentials="Test1234" database monitor The ldapsearch output that indicate the problem: ldapsearch -h localhost -p 3891 -b "cn=Monitor" "cn=Connections" + # extended LDIF # # LDAPv3 # base <cn=Monitor> with scope subtree # filter: cn=Connections # requesting: + # # Connections, Monitor dn: cn=Connections,cn=Monitor structuralObjectClass: monitorContainer creatorsName: modifiersName: createTimestamp: 20070122103402Z modifyTimestamp: 20070122103402Z entryDN: cn=Connections,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE ldap_result: Can't contact LDAP server (-1) The slave debugs the following during the search: ... => test_filter EQUALITY => access_allowed: search access to "cn=Connections,cn=Monitor" "cn" requested => access_allowed: backend default search access granted to "(anonymous)" <= test_filter 6 => send_search_entry: conn 0 dn="cn=Connections,cn=Monitor" => access_allowed: read access to "cn=Connections,cn=Monitor" "entry" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "structuralObjectClass" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "creatorsName" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "modifiersName" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "createTimestamp" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "modifyTimestamp" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "entryDN" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "subschemaSubentry" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "hasSubordinates" requested => access_allowed: backend default read access granted to "(anonymous)" ber_flush: 308 bytes to sd 13 0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn= 0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M 0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st 0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl 0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo 0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat 0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m 0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1... 0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest 0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221 00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify 00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200 00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&.. 00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co 00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon 00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem 0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn= 0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has 0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1... 0130: 54 52 55 45 TRUE ldap_write: want=308, written=308 0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn= 0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M 0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st 0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl 0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo 0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat 0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m 0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1... 0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest 0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221 00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify 00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200 00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&.. 00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co 00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon 00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem 0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn= 0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has 0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1... 0130: 54 52 55 45 TRUE conn=0 op=1 ENTRY dn="cn=connections,cn=monitor" <= send_search_entry: conn 0 exit. Segmentation Fault - core dumped -- Venlig hilsen/Kind regards Niels Frimodt Sørensen Signaturgruppen A/S www.signaturgruppen.dk

1 0

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 22 Jan '07

22 Jan '07

ando(a)sys-net.it wrote: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: 2.4.2alpha >> When adding a alias abject to the provider, syncprov fowllows the referral and >> is not updating the alias object to the consumer, > > Dieter, > > are you talking about aliases or referrals? > > I also note that, AFAIK, 2.4.2alpha is way out of sync with HEAD. While > a new 2.4 release might be desirable, I suggest you test HEAD instead. I note that this code has been present in syncprov, unchanged, for quite a long time (throughout 2.3 to current): if ( op->ors_deref & LDAP_DEREF_SEARCHING ) { send_ldap_error( op, rs, LDAP_PROTOCOL_ERROR, "illegal value for derefAliases" ); return rs->sr_err; } which would prevent syncprov from chasing aliases during a search. As such, I think you need provide a test case that illustrates the problem. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4810) syncprov follows referrals
by ando＠sys-net.it 22 Jan '07

22 Jan '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.2alpha > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.177.66) > > > When adding a alias abject to the provider, syncprov fowllows the referral and > is not updating the alias object to the consumer, Dieter, are you talking about aliases or referrals? I also note that, AFAIK, 2.4.2alpha is way out of sync with HEAD. While a new 2.4 release might be desirable, I suggest you test HEAD instead. p.

1 0

(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 21 Jan '07

21 Jan '07

Full_Name: Dieter Kluenter Version: 2.4.2alpha OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.177.66) When adding a alias abject to the provider, syncprov fowllows the referral and is not updating the alias object to the consumer, -Dieter

1 0

Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by ando＠sys-net.it 20 Jan '07

20 Jan '07

Apparently, according to slurpd's replog, no operational attrs are modified on modrdn. In fact, modrdn is replicated as a plain modrdn, which does not alter the write-related operational attrs (nor it is allowed to, according to LDIF, as per RFC 2849). Rep-logging an additional modify that only changes the write-related operational attrs could fix the problem, at the cost of not making it atomical. A "cleaner" solution would be to wrap a modify with a control that gets added to the modrdn operation by slurpd, which modifies modifiersName, modifyTimestamp and entryCSN using the "relax" control. Or, the (yet unpublished) "relax" control could be redefined to allow an optional control value that contains a modification required to maintain consistency of the final entry, or something like that. This definitely needs investigation, but it could be considered yet another reason for dropping slurpd. p.

1 0

(ITS#4809) Replication of operational attributes when performing modrdn operation
by Thomas.Fritz＠bam.de 19 Jan '07

19 Jan '07

Full_Name: Thomas Fritz Version: 2.3.33 OS: Debian Gnu/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.63.61.111) We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb backend. When performing the modrdn operation against the master, no update directives for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are written to the replog file. Hence, the databases of master and slave differ by the values of these attributes after replication. This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions back to (at least) 2.3.24 are affected.

1 0

(ITS#4808) erroneous error code testing in back-ldap
by ando＠sys-net.it 17 Jan '07

17 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando in a couple of places, LDAP_SERVER_DOWN is tested after client library error codes have already been mapped to response codes (LDAP_SERVER_DOWN => LDAP_UNAVAILABLE). As a consequence, delete and modrdn are not retried as appropriate. p.

1 0

(ITS#4807) CLOCK-Pro cache replacement
by hyc＠OpenLDAP.org 16 Jan '07

16 Jan '07

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/hyc-20070116.txt Submission from: (NULL) (76.168.84.21) Submitted by: hyc This is a rough implementation of the CLOCK-Pro cache replacement algorithm for back-bdb. It's based on the paper published here http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/abs05-3.html Currently the performance is not very good; the algorithm can invoke multiple scans of the Clock list and our lock overhead for those scans is too high. I'm not planning to do any more with this at the moment, just wanted to post it so it doesn't get lost, in case someone else is interested. I didn't want to commit it behind #ifdef's because that would get too messy. This implementation deviates from the paper in two major respects: 1) it's possible for an EntryInfo node to get its Reference bit set even when the entry is not Resident. This happens very frequently, in cache_find_ndn. As such, EntryInfo nodes without an Entry, but that have been Referenced, do not get flushed by HANDtest. 2) Nodes can get their Reference bit cleared at many points during the Clock-Pro processing, so the bit is not a good indication of whether a node is currently in use and may be safely freed. So, elaborate lock checks are used at each point where the original algorithm would simply free a node (HANDcold, HANDtest). It would be nice if our locking setup could be simplified. If someone else wants to jump in and clean it up, it may be worth committing down the road.

1 0

(ITS#4806) allow internal operations to require more specific access privileges
by ando＠sys-net.it 16 Jan '07

16 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Occasionally, internal operations, and significantly searches, are performed for some given purpose which would require different access privileges than, for example in case of searches, "search" on the filter and "read" on the data. In those cases, it may be useful to allow issuers of internal operations to change the access privilege that's requested. This feature (is implemented to address an issue with slapo-dynlist(5) which uses an internal search to collect data for compare, and thus checks "search" access on the filter of the memberURL and "read" on the datum to be compared. See <http://www.openldap.org/lists/openldap-devel/200701/msg00056.html> for discussion.

1 0

(ITS#4805) memory leak in syncrepl code
by ando＠sys-net.it 15 Jan '07

15 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando There seems to be few memory leaks in syncrepl code (detected by valgrind when running test048); one is when parsing an entry and sync "present" or "done". It's now fixed in HEAD/re23. Others are being investigated p.

1 0

Re: (ITS#4591) back-meta does not propagate response controls
by ando＠sys-net.it 15 Jan '07

15 Jan '07

ando(a)sys-net.it wrote: > In most cases, all response payload (matched, referrals) is ignored when calling > ldap_parse_result(); only in searches matched and referrals are handled. For most operations this should now be fixed, since response passes thru meta_back_op_result(), which takes care of controls. However, in case of searches, handling this issue may be problematic, as different targets may return different, possibly overlapping or incompatible controls in response, so ignoring them might be safe. A minimal, forgiving approach could be to record response controls, and, in case only one target returned any, use them; otherwise, either ignore them or complain somehow. p.

1 0

Re: Antwort: Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 12 Jan '07

12 Jan '07

Michael.Heep(a)o2.com wrote: > Today I deployed a patched 2.3.32 version on one of our replicas and > changed the config to include the aforementioned dynlist/valsort > construct. > It's been running nicely for a few hours now. Seems like the patch fixed > this issue. Thank you very much! Thanks for the feedback. The fix will appear in 2.3.33. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Antwort: Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by Michael.Heep＠o2.com 12 Jan '07

12 Jan '07

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 005BCC39C1257261_= Content-Type: text/plain; charset="US-ASCII" Today I deployed a patched 2.3.32 version on one of our replicas and changed the config to include the aforementioned dynlist/valsort construct. It's been running nicely for a few hours now. Seems like the patch fixed this issue. Thank you very much! With kind regards Michael Heep Pierangelo Masarati <ando(a)sys-net.it> 11.01.2007 23:37 An michael.heep(a)o2.com Kopie openldap-its(a)openldap.org Thema Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > A bug (ITS#4801) was recently fixed in slapo-dynlist(5) which appeared in conjunction with slapo-valsort(5). The fix is available both in HEAD and in re23 CVS (tag OPENLDAP_REL_ENG_2_3). The relevant change is in servers/slapd/overlays/dynlist.c 1.28 -> 1.29 (HEAD) or 1.5.2.9 -> 1.5.2.10 (re23). Could you please check if it does any good to the issue you reported? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------ --=_alternative 005BCC39C1257261_= Content-Type: text/html; charset="US-ASCII" Today I deployed a patched 2.3.32 version on one of our replicas and changed the config to include the aforementioned dynlist/valsort construct. It's been running nicely for a few hours now. Seems like the patch fixed this issue. Thank you very much! With kind regards Michael Heep <table width=100%> <tr valign=top> <td width=40%>Pierangelo Masarati <ando(a)sys-net.it> 11.01.2007 23:37 <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>An</div> <td>michael.heep(a)o2.com <tr valign=top> <td> <div align=right>Kopie</div> <td>openldap-its(a)openldap.org <tr valign=top> <td> <div align=right>Thema</div> <td>Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive </table> <table> <tr valign=top> <td> <td></table> </table> <tt>michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset                extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. >   A bug (ITS#4801) was recently fixed in slapo-dynlist(5) which appeared in conjunction with slapo-valsort(5).  The fix is available both in HEAD and in re23 CVS (tag OPENLDAP_REL_ENG_2_3).  The relevant change is in servers/slapd/overlays/dynlist.c 1.28 -> 1.29 (HEAD) or 1.5.2.9 -> 1.5.2.10 (re23).  Could you please check if it does any good to the issue you reported? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office:   +39.02.23998309 Mobile:   +39.333.4963172 Email:    pierangelo.masarati(a)sys-net.it ------------------------------------------ </tt> --=_alternative 005BCC39C1257261_=--

1 0

Deny bind for subtree not working?
by Daniel Hasler 12 Jan '07

12 Jan '07

Hi I try to deni BIND for all entries in a subtree. I compiled openldap with the LDAP backend, because this is only a proxy that forwards request to another directory. Following is my configuration: >include /local/home/hasleda4/openldap/etc/openldap/schema/core.schema >include /local/home/hasleda4/openldap/etc/openldap/schema/cosine.schema >include /local/home/hasleda4/openldap/etc/openldap/schema/inetorgperson.schema > >pidfile /local/home/hasleda4/openldap/var/run/gaad-slapd.pid >argsfile /local/home/hasleda4/openldap/var/run/gaad-slapd.args > >database ldap >suffix "dc=company,dc=com" >uri "ldaps://other-dir.net:26930" > >access to dn.subtree="ou=people,ou=intranet,dc=company,dc=com" by dn.subtree="ou=applications,ou=intranet,dc=company,dc=com" read > by * none >access to dn.subtree="ou=applications,ou=intranet,dc=company,dc=com" by users read > by anonymous auth > by * none >access to * by * read As by the first ACL, anonymous users are not allowed to bind against "ou=people,ou=intranet,dc=novartis,dc=com". If I now try to bind, the ACL seems not to be evaluated (I run slapd with -d 128 to see ACL processing, and there is no output during the BIND) and the BIND operation succeeds if I give the correct password. Is this a bug? Or just how openldap behaves for bind operations? Is there another way to deny bind operations for a subtree? Thanks for any response. Cheers Dani

1 0

Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 11 Jan '07

11 Jan '07

michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > A bug (ITS#4801) was recently fixed in slapo-dynlist(5) which appeared in conjunction with slapo-valsort(5). The fix is available both in HEAD and in re23 CVS (tag OPENLDAP_REL_ENG_2_3). The relevant change is in servers/slapd/overlays/dynlist.c 1.28 -> 1.29 (HEAD) or 1.5.2.9 -> 1.5.2.10 (re23). Could you please check if it does any good to the issue you reported? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs