- openldap-bugs - openldap.org

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

Should now be fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> I see the issue, and I've isolated it to the case where you're removing a > value. In that case, in attr_cmp(), nn == 0 and no < o; the original test > for modifying an attribute without matching rule fails. I've fixed it > according to this patch, not sure whether it's appropriate for other cases > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-syncrepl-no-…> > > Please test and review. Thanks, p. Please disregard, this patch is breaking other things (basically, producer's and consumer's entries are equivalent, but attrs are listed in a different order; this conforms to the LDAP model but breaks the original, preferable behavior). Working at a better fix. p.

1 0

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Patrick Cernko > Version: 2.4.21 > OS: Linux > URL: > http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… > Submission from: (NULL) (139.19.3.67) > > > Hi OpenLDAP-Programmers, > > although some related bug reports were posted in the past years, this > issue > still seems not to be fixed: > > OpenLDAP's syncrepl replication fails if it comes to removing one of a > multi-value attribes of an object if this attribute does not have a > equality > matching rule defined in the schema. Modification works on the master > server but > fails to replicate to the slave(s) leaving them with the dit version just > before > and not replicating any other changes any more. > > I compiled a small example how to reproduce the problem with the (maybe > "well-known") nisNetgroupTriple attribute from nis.schema as shipped with > openldap-2.4.21: > > - extract the files from > http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… > into an empty working directory > - download the tarball to that working dir and configure similar to the > just > extracted configure.sh > - build and install it to get an install subdir in the working dir > - start the master using sh master.sh in the working dir > This will create the "master" database in your working dir, slapadd the > dit.ldif and start a master slapd with a unix socket /tmp/master. > - start the slave using sh slave.sh > This will create "slave" database in your working dir and start the > slave > slapd with a unix socket /tmp/slave which will immediately start syncing > from > the running master > - if you want you can search the 2 servers with > install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL > resp. > install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL > - use "python mod.py" to remove one of the nisNetgroupTriple attributes > from the > netgroup object > - you will see a debug message from the slave server like this: > > bdb_modify_internal: delete nisNetgroupTriple > bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality > matching > rule > send_ldap_result: err=18 matched="" text="modify/delete: > nisNetgroupTriple: no > equality matching rule" > null_callback : error code 0x12 > slap_graduate_commit_csn: removing 0x29931c0 > 20100120124712.028626Z#000000#000#000000 > syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18) > syncrepl_entry: rid=001 be_modify failed (18) > > if not, use "python mod.py add" to re-add the removed nisNetgroupTriple > and > try again. Sometimes, it seems to work (race condition?). > - you can also verify the difference with: > install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL > cn=netgroup > install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL > cn=netgroup > - from now on, the slave will fail to sync any succeeding changes, as it > continuously tries to sync the modification above first. :-( > > Now, obviously having an attribute without equality matching rule is not a > good > idea in the first place. However, the (official?) nis.schema comes with > such an > attribute which we must use like this (e.g. we would have to patch the > Solaris > kernel to change it for the Solaris NFS server). > > It is possible to modify a nisNetgroup object like this: according to the > debugging output, I guess the master removes simply ALL nisNetgroupTriple > attributes and adds only the attributes that should remain. When the > corresponding syncrepl_entry is handled by the slave, it seems the it in > contrast tries to really only remove the 2-be-removed attribute which does > not > work as it cannot identify the right one due to a missing eq-match > operator. > > I suggest the best way to solve this issue is to try to get syncrepl do > exactly > the same actions (not resulting changes) as the server does. I see the issue, and I've isolated it to the case where you're removing a value. In that case, in attr_cmp(), nn == 0 and no < o; the original test for modifying an attribute without matching rule fails. I've fixed it according to this patch, not sure whether it's appropriate for other cases <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-syncrepl-no-…> Please test and review. Thanks, p.

1 0

Re: (ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Jochen Keutel > Version: 2.4.21 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.159.206.14) > > > dnssrv_back_referrals() always returns ldap URLs - even when the original > request was a ldaps query. This is a (logical) duplicate of ITS#6462; see related answers. > Additionally only protocol and hostname are put into the URL - the search > base > doesn't appear any more. > > Problematic code: > > url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] ); > url.bv_val = ch_malloc( url.bv_len + 1 ); > > strcpy( url.bv_val, "ldap://" ); > strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] ); > > I'm not sure whether you want me to deliver a complete patch or not ... This behavior conforms to RFC4511, section 4.1.10: - If the <dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request. I note that few lines above the same RFC states: - It is RECOMMENDED that the <dn> part be present to avoid ambiguity. However, slapd-dnssrv(5) computes the referral from DNS SRV records, rather than returning data it knows about. So returning the <dn> part here would be incorrect, in my opinion, as the client could legitimately rely on the fact that the returned DN is appropriate, while it may not. p.

1 0

Re: (ITS#6462) DNS SRV records: ldaps ???
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> --On Wednesday, January 27, 2010 1:28 AM +0000 jochen(a)keutel.de wrote: > >> Full_Name: Jochen Keutel >> Version: 2.4.21 >> OS: Solaris 10 >> URL: ftp://ftp.openldap.org/incoming/ > >> protocol is either "ldap" oder "ldaps". > > LDAPS is not a defined protocol. I would suggest using LDAP with > startTLS, > which is RFC Defined. One could argue that OpenLDAP supports ldaps in many places. I agree in general with your reply, but I'd treat this ITS as a feature request, although I'm not going to give it any special priority. p.

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Robert Hanson > Version: 2.4.21 > OS: RedHat 4.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.203.208.250) > > > 1) start with an empty database; use slapadd to add a large (3 MB) > database. 2) > Use ldapbrowser to delete nearly all the nodes. After this process, I get > to a > point where a subnode can't be deleted; I see the message "12:00:27 PM: > Failed > to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink > Communications > Reason: [LDAP: error code 80 - DN index delete failed] > 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, > ou=Company, > o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser > window. > > Steps to reproduce: (on redhat linux; I think any linux will do) > 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the > distro. > 2) copy built slapd to an appropriate place. link it to slapadd. > 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is > scheduled to > close 3/23/2010; let me know if you need the file uploaded again). unzip > the > file, it contains the slapcat.out; a blank database (in a subfolder), and > a > slapd.conf file. > 4) Edit the slapd.conf file as needed to point to the directory where you > put > the database. > > That was the setup, now here are the steps to reproduce the problem: > > 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. > 6) start slapd (using slapd -d 1 -f slapd.conf) > 7) use ldapbrowser to delete the "lcc=call center 1" node. > > It takes a long time, but eventually you'll see it fail while trying to > delete > the "agents" node. Can you reproduce with -dtrace? It'll generate a large log file, please only post the part related to the failure. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

A fix is in HEAD, please test slapd/syncrepl.c 1.502 -> 1.503 Thanks for reporting, p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by hyc＠symas.com 17 Apr '10

17 Apr '10

masarati(a)aero.polimi.it wrote: > >> It's not clear to me where the issue is. What is the "right" sequence the >> add of the new superior and the mordrdn should be transmitted? Should the >> provider operate differently, or should the consumer check all syncrepl >> messages and try to rebuild the final state, instead of giving up when the >> internal lookup for the newsuperior fails? Probably, a workaround could >> be to perform the modrdn by crating the new superior as a glue object, >> which eventually will be replaced by the actual add. > > I've quickly hacked things this way, and it seems to work fine. > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.…> > > Please let me know if this approach is sound enough, I might have > overlooked some implications. Patch looks good, solution makes sense. This is one of the reasons we would expect glue entries to be used. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6524) gnutls cipher spec is unclear
by matthijs＠cacholong.nl 17 Apr '10

17 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kurt Zeilenga wrote: > On Apr 17, 2010, at 3:15 AM, matthijs(a)cacholong.nl wrote: > >> On Apr 16, 2010, at 6:01 PM, Howard Chu wrote: >>> If Peter wants his patch considered for inclusion in OpenLDAP he = >> should write to the ITS himself, we cannot accept 3rd party = >> contributions. >> >> What's the reasoning behind this? > > 3rd parties (middle men) not only hinder good communication between the authors(s) of the contribution and the Project/Foundation, they introduce various risks to both the author and the Project/Foundation. > > Regard, Kurt (Executive Director, The OpenLDAP Foundation) > Hi, Thanks for the explanation, I'll keep it in mind when forwarding patches and / or bug reports from the Debian bugtracker. Regards, Matthijs Mohlmann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvKDnUACgkQ2n1ROIkXqbDFtwCgjOrjYmDPXtqYpQrQTNzq7gqL RcsAmgKRRJB28cke29WMHhKIIcB/+q7L =QTpi -----END PGP SIGNATURE-----

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> It's not clear to me where the issue is. What is the "right" sequence the > add of the new superior and the mordrdn should be transmitted? Should the > provider operate differently, or should the consumer check all syncrepl > messages and try to rebuild the final state, instead of giving up when the > internal lookup for the newsuperior fails? Probably, a workaround could > be to perform the modrdn by crating the new superior as a glue object, > which eventually will be replaced by the actual add. I've quickly hacked things this way, and it seems to work fine. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.…> Please let me know if this approach is sound enough, I might have overlooked some implications. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

>> Full_Name: Julien COMBES >> Version: 2.4.21 >> OS: Debian 5.0.4 >> URL: ftp://ftp.openldap.org/incoming/its-syncrepl-loop-moddn.tar.bz2 >> Submission from: (NULL) (212.23.175.185) >> >> >> Hello, >> >> I think I have found a loop problem with syncrepl replication with >> openldap >> 2.4.21, BDB 4.7.25 with all patches and hdb database. The problem >> appears >> sometimes when an entry is moved with "modrdbn -s" in a node which has >> just been >> created. I have reproduced the problem with the creation of a node and a >> moddn >> while the consumer was stopped and then restarted after. >> >> The problem follows these steps : >> - When it starts, the consumer does a request objectClass=* on the >> provider : >> Feb 12 09:09:19 ldapma24-ida01 slapd[30445]: conn=1007 op=1 SRCH >> base="dc=my,dc=domain" scope=2 deref=0 filter="(objectClass=*)" >> >> - The consumer finds the modrdn and tries to do this : >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: >> ==>hdb_modrdn(cn=user1,ou=A,dc=my,dc=domain,cn=user1,ou=X,dc=my,dc=domain) >> >> - The consumer fails with these errors : >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: => >> hdb_dn2id("ou=x,dc=my,dc=domain") >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: <= hdb_dn2id: get failed: >> DB_NOTFOUND: No matching key/data pair found (-30988) >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: hdb_modrdn: >> newSup(ndn=ou=x,dc=my,dc=domain) not here! >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: conn=-1 >> op=0 p=0 >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: err=32 >> matched="" >> text="new superior not found" >> >> - The consumer retries the request objectClass=* on the provider and >> loops on >> the problem. The replication doesn't work anymore. >> >> To reproduce the problem, I have used these steps : >> - start an empty provider >> - ldapadd the entries in mydomain.ldif >> ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f mydomain.ldif >> - start the consumer. >> - stop the consumer when replication is finished >> - ldapadd the new node >> ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f add.ldif >> - modrdn -s >> ldapmodrdn -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -r -s >> "ou=X,dc=my,dc=domain" >> "cn=user1,ou=A,dc=my,dc=domain" "cn=user1" >> - start the consumer >> >> I join in its-syncrepl-loop-moddn.tar.bz2 : >> - slapd.conf of provider and consummer >> - log files of provider and consummer >> - mydomain.ldif and add.ldif > > Thanks for the detailed report. The bug is confirmed, and it's not > related to back-hdb, but seems to be syncrepl-related in general. It's not clear to me where the issue is. What is the "right" sequence the add of the new superior and the mordrdn should be transmitted? Should the provider operate differently, or should the consumer check all syncrepl messages and try to rebuild the final state, instead of giving up when the internal lookup for the newsuperior fails? Probably, a workaround could be to perform the modrdn by crating the new superior as a glue object, which eventually will be replaced by the actual add. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Julien COMBES > Version: 2.4.21 > OS: Debian 5.0.4 > URL: ftp://ftp.openldap.org/incoming/its-syncrepl-loop-moddn.tar.bz2 > Submission from: (NULL) (212.23.175.185) > > > Hello, > > I think I have found a loop problem with syncrepl replication with > openldap > 2.4.21, BDB 4.7.25 with all patches and hdb database. The problem appears > sometimes when an entry is moved with "modrdbn -s" in a node which has > just been > created. I have reproduced the problem with the creation of a node and a > moddn > while the consumer was stopped and then restarted after. > > The problem follows these steps : > - When it starts, the consumer does a request objectClass=* on the > provider : > Feb 12 09:09:19 ldapma24-ida01 slapd[30445]: conn=1007 op=1 SRCH > base="dc=my,dc=domain" scope=2 deref=0 filter="(objectClass=*)" > > - The consumer finds the modrdn and tries to do this : > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: > ==>hdb_modrdn(cn=user1,ou=A,dc=my,dc=domain,cn=user1,ou=X,dc=my,dc=domain) > > - The consumer fails with these errors : > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: => > hdb_dn2id("ou=x,dc=my,dc=domain") > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: <= hdb_dn2id: get failed: > DB_NOTFOUND: No matching key/data pair found (-30988) > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: hdb_modrdn: > newSup(ndn=ou=x,dc=my,dc=domain) not here! > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: conn=-1 > op=0 p=0 > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: err=32 > matched="" > text="new superior not found" > > - The consumer retries the request objectClass=* on the provider and > loops on > the problem. The replication doesn't work anymore. > > To reproduce the problem, I have used these steps : > - start an empty provider > - ldapadd the entries in mydomain.ldif > ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f mydomain.ldif > - start the consumer. > - stop the consumer when replication is finished > - ldapadd the new node > ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f add.ldif > - modrdn -s > ldapmodrdn -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -r -s > "ou=X,dc=my,dc=domain" > "cn=user1,ou=A,dc=my,dc=domain" "cn=user1" > - start the consumer > > I join in its-syncrepl-loop-moddn.tar.bz2 : > - slapd.conf of provider and consummer > - log files of provider and consummer > - mydomain.ldif and add.ldif Thanks for the detailed report. The bug is confirmed, and it's not related to back-hdb, but seems to be syncrepl-related in general. p.

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Himmelbauer > Version: 2.4.19 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/himmelbauer-100301.patch > Submission from: (NULL) (92.248.100.200) > > > Was not able to retrieve database entries from a corrupted LDAP database > using > slapcat (openldap 2.4.19) with option -c. It aborts after the first > corrupted > entry with > > <= entry_decode: slap_str2undef_ad(object�!p): > AttributeDescription > contains inappropriate characters > # no data for entry id=xxxxxxxx > > and doesn't continue with the next valid entry as I would have expected. > > A damaged database is not good, but as slapcat is described as the tool to > recover the non-corrupted data in various forums, it would be good when it > really continues on errors. Other ldap-related tools like ldapsearch > ignore the > damaged data, so it is really annoying, when you want to recover your data > and > don't even get all the readable entries. > > The patch corrects the handling of damaged entries by slapcat when -c is > used, > so that the output is continued with the next non-damaged entry. When -c > is not > used slapcat stops after the first corrupted entry (as expected). > > The patch works for me, but I know that it is not really correct, because > when > there would be no non-damaged entry left it would either cause a endless > loop or > some crashes. > > So a modification would be needed to stop the loop when the last database > entry > was processed, but I didn't know how to access that id. I do not quite understand this report and your fix. The code seems to work as intended. "continue" here means keep processing the database if an entry can't be extracted from the database. This does by no means imply that processing can always continue. If the database is corrupted, it is likely that from the first appearance of the corruption, not even the next entry id can be retrieved at all. Otherwise, if the only error consists in not being able to extract an entry, continuation occurs as expected in the current code. What likely happened in your case was that as soon as the database corruption was encountered, be_entry_next() was unable to compute the id of the next entry. This is why you don't even get a log of the ids of the entries that couldn't be extracted. I'd close this ITS. p.

1 0

Re: (ITS#6524) gnutls cipher spec is unclear
by Kurt＠OpenLDAP.org 17 Apr '10

17 Apr '10

On Apr 17, 2010, at 3:15 AM, matthijs(a)cacholong.nl wrote: > On Apr 16, 2010, at 6:01 PM, Howard Chu wrote: >> If Peter wants his patch considered for inclusion in OpenLDAP he =3D > should write to the ITS himself, we cannot accept 3rd party =3D > contributions. >=20 > What's the reasoning behind this? 3rd parties (middle men) not only hinder good communication between the = authors(s) of the contribution and the Project/Foundation, they = introduce various risks to both the author and the Project/Foundation. Regard, Kurt (Executive Director, The OpenLDAP Foundation)

1 0

(ITS#6526) slapd does not start: slapo-rwm + rewriteContext searchfilter + rewriteRule + cn=config
by daniel＠pluta.biz 17 Apr '10

17 Apr '10

Full_Name: Daniel Pluta Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:749a:cf80:5be3:e252) Using the following rwm configuration: overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(ou=openldap)$1)" ":@I" 1.) works fine after starting slapd with: slapd -f slapd.conf 2.) converts fine (at least no error messages): slaptest -f slapd.conf -F slapd.d 3.) but slapd's startup aborts when using: slapd -F slapd.d fyi here's slapd's output when started "slapd -F slapd.d -d -1" (rwm-related output): ldif_read_file: read entry file: "/tmp/openldap/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb/olcOverlay={1}rwm.ldif" => str2entry: "dn: olcOverlay={1}rwm objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {1}rwm olcRwmRewrite: {0}rwm-rewriteEngine "on" olcRwmRewrite: {1}rwm-rewriteContext "searchFilter" olcRwmRewrite: {2}rwm-rewriteRule "(.*)" "(&(ou=openldap)$1)" ":@I" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE structuralObjectClass: olcRwmConfig entryUUID: 2dbc3768-de64-102e-990e-a3438cd19586 creatorsName: cn=config createTimestamp: 20100417115744Z entryCSN: 20100417115744.885645Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100417115744Z " >>> dnPrettyNormal: <olcOverlay={1}rwm> => ldap_bv2dn(olcOverlay={1}rwm,0) <= ldap_bv2dn(olcOverlay={1}rwm)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={1}rwm)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={1}rwm)=0 <<< dnPrettyNormal: <olcOverlay={1}rwm>, <olcOverlay={1}rwm> >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <<< dnNormalize: <cn=config> >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <<< dnNormalize: <cn=config> <= str2entry(olcOverlay={1}rwm) -> 0x9581ef4 => test_filter PRESENT => access_allowed: search access to "olcOverlay={1}rwm,olcDatabase={2}hdb,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 line 0 (rwm-rewriteEngine "on") line 0 (rwm-rewriteEngine "on") line 0 (rwm-rewriteContext "searchFilter" ==> here the shell is back :-/ BTW: after commenting out 'rwm-rewriteRule "(.*)" "(&(ou=openldap)$1)" ":@I"' slapd starts just fine. Adding this rule vi cn=config works, but searchfilter-rewriting does not work. Removeing the rule via cn=config results in assertion error rwm.c's function "rwm_cf_gen" in line 2158.

1 0

(ITS#6525) gnutls cipher spec is unclear
by peter＠adpm.de 17 Apr '10

17 Apr '10

Full_Name: Peter Marschall Version: 2.4.21 OS: Linux / BSD URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-20100417-*.patch Submission from: (NULL) (94.217.132.71) Hi, as Matthijs Mohlmann already noted in ITS#6524, the man pages about the TLSCipherSuite resp. TLS_CIPHER_SUITE are for gnutls a bit unclear, only an example for OpenSSL is provided. I wrote patches to alleviate this problem and sent them to the Debian bug tracking system (from where Matthijs they kindly [and with my permission] forwarded to ITS#6524). Please find the patches in * ftp://ftp.openldap.org/incoming/Peter-Marschall-20100417-ldap.conf_TLS_CIPH… * ftp://ftp.openldap.org/incoming/Peter-Marschall-20100417-slapd.conf-TLSCiph… Please consider them for inclusion in the next release of OpenLDAP (BTW, when will that be?) Thanks Peter Marschall

1 0

Re: (ITS#6524) gnutls cipher spec is unclear
by matthijs＠cacholong.nl 17 Apr '10

17 Apr '10

On Apr 16, 2010, at 6:01 PM, Howard Chu wrote: > matthijs(a)cacholong.nl wrote: >> Full_Name: Matthijs Mohlmann >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.163.247.203) >>=20 >>=20 >> Hi, >>=20 >> The manpage about the TLS_CIPHER_SUITE is for gnutls a bit unclear, = only an >> example for OpenSSL is provided. >>=20 >> Peter Marschall wrote a patch for this documentation issue. >=20 > If Peter wants his patch considered for inclusion in OpenLDAP he = should write to the ITS himself, we cannot accept 3rd party = contributions. >=20 >> See also: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D510346 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D563113 >>=20 >> Regards, >>=20 >> Matthijs Mohlmann >=20 >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ Hi, What's the reasoning behind this? I'll ask Peter to file this issue in ITS. Regards, Matthijs Mohlmann

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 16 Apr '10

16 Apr '10

This is a cryptographically signed message in MIME format. --------------ms040209080804080304070307 Content-Type: multipart/alternative; boundary="------------020001050102090908040002" This is a multi-part message in MIME format. --------------020001050102090908040002 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hi, it's been a while, but the changelog overlay is still necessary in our=20 environment, so I changed five lines in the code to keep up with the=20 current stable version of OpenLDAP. You can find the patch and the documentation in: ftp://ftp.openldap.org/incoming/rieger-changelog-2.4.21-pkg-100416.tgz <= ftp://ftp.openldap.org/incoming/rieger-changelog-23-pkg-080706.tgz> the patch and the overlay has been tested against OpenLDAP 2.4.21. Sebastian --------------020001050102090908040002 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO-885= 9-15"> </head> <body bgcolor=3D"#ffffff" text=3D"#000000"> Hi, it's been a while, but the changelog overlay is still necessary in our environment, so I changed five lines in the code to keep up with the current stable version of OpenLDAP. You can find the patch and the documentation in: <pre><a href=3D"ftp://ftp.openldap.org/incoming/rieger-changelog-23-pkg-080706.t= gz">ftp://ftp.openldap.org/incoming/rieger-changelog-2.4.21-pkg-100416.tg= z</a> the patch and the overlay has been tested against OpenLDAP 2.4.21. </pre> Sebastian </body> </html> --------------020001050102090908040002-- --------------ms040209080804080304070307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWAjCC BwowggXyoAMCAQICAwCdWDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MDkyNjAwMDAwMVoXDTEwMDkyNjIzNTk1OVowcTEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYVc2ViYXN0aWFuQHJpZWdlci5pbmZvMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwtbXkuAbQ11bUAkNHp59cKjUVBRE0xNY F1wt9Yeb0HqnulERLuDAgSChPh1v2HoCwNtYlSrSbBaL6Hs2zXt/ATrUgkBi0FNuUAGVKubd sQN118tW1jMEaUmSsVO0vaj509jGL+81kkq0raPcqgQqvMwYs1ZShfH/WpkzKGUwvpthZxCG U1sGQPIgR7iiE2J6b9mb71D1QiGs9A2KcBBpTPUAleHz4QPG+x7LUzMuVzpZ51rTXd9T59Fv r3x4tsgLQ7JZgNPwQ1XOaIDdpC2FItDK9nNIvTkeYfo6+Ue456/ZHSCUkFzJNYZteWXux10k T4UKS5+jfv+CTVMeDR8iUQIDAQABo4IDjTCCA4kwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTscNXjgXcy8YBjZv0h XzV2WlkSHTAgBgNVHREEGTAXgRVzZWJhc3RpYW5AcmllZ2VyLmluZm8wgagGA1UdIwSBoDCB nYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wggFH BgNVHSAEggE+MIIBOjCCATYGCysGAQQBgbU3AQIBMIIBJTAuBggrBgEFBQcCARYiaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5z dGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBvAYIKwYBBQUHAgIwga8wFBYNU3RhcnRD b20gTHRkLjADAgEBGoGWTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5j b20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEARMqy5GWeKJXpUBwrSjtO0gWn XSZyW49x2M2Nne+zG6xXAf6We+gl4dpnktuVc3a8fk9syfjYHdRF5adWC/5E/rpq7SB3jMsA G8BfnOpQXzJlTNPda3YLcE328AtxGBAM+4HZSIBGDLeaLU0V+ZdTq6J+q+Z+vtsWtAe4gyIi w7kDbkJ8Q726Q4jW5AitmC7O/3JV7nZ3i5cboYRK6jduxSH7NRKa2SLqvQel7rfZDeYMzK9o PHXYgwkddPSrwaF/0Wtrkk3sKuswOzyQB6/4S4mkuT8bFuox4puIJwyi2LMQeuXmHN9Vny/9 Roo6FB32sgdjlZbzSTGblhFCaM9n9TCCBwowggXyoAMCAQICAwCdWDANBgkqhkiG9w0BAQUF ADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTA5MDkyNjAwMDAwMVoX DTEwMDkyNjIzNTk1OVowcTEeMBwGA1UEChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYD VQQDEyBTdGFydENvbSBGcmVlIENlcnRpZmljYXRlIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYV c2ViYXN0aWFuQHJpZWdlci5pbmZvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA wtbXkuAbQ11bUAkNHp59cKjUVBRE0xNYF1wt9Yeb0HqnulERLuDAgSChPh1v2HoCwNtYlSrS bBaL6Hs2zXt/ATrUgkBi0FNuUAGVKubdsQN118tW1jMEaUmSsVO0vaj509jGL+81kkq0raPc qgQqvMwYs1ZShfH/WpkzKGUwvpthZxCGU1sGQPIgR7iiE2J6b9mb71D1QiGs9A2KcBBpTPUA leHz4QPG+x7LUzMuVzpZ51rTXd9T59Fvr3x4tsgLQ7JZgNPwQ1XOaIDdpC2FItDK9nNIvTke Yfo6+Ue456/ZHSCUkFzJNYZteWXux10kT4UKS5+jfv+CTVMeDR8iUQIDAQABo4IDjTCCA4kw CQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MB0GA1UdDgQWBBTscNXjgXcy8YBjZv0hXzV2WlkSHTAgBgNVHREEGTAXgRVzZWJhc3RpYW5A cmllZ2VyLmluZm8wgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKhgYGkfzB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHmCAQ0wggFHBgNVHSAEggE+MIIBOjCCATYGCysGAQQBgbU3AQIB MIIBJTAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCB vAYIKwYBBQUHAgIwga8wFBYNU3RhcnRDb20gTHRkLjADAgEBGoGWTGltaXRlZCBMaWFiaWxp dHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEARMqy5GWeKJXpUBwrSjtO0gWnXSZyW49x2M2Nne+zG6xXAf6We+gl4dpnktuVc3a8 fk9syfjYHdRF5adWC/5E/rpq7SB3jMsAG8BfnOpQXzJlTNPda3YLcE328AtxGBAM+4HZSIBG DLeaLU0V+ZdTq6J+q+Z+vtsWtAe4gyIiw7kDbkJ8Q726Q4jW5AitmC7O/3JV7nZ3i5cboYRK 6jduxSH7NRKa2SLqvQel7rfZDeYMzK9oPHXYgwkddPSrwaF/0Wtrkk3sKuswOzyQB6/4S4mk uT8bFuox4puIJwyi2LMQeuXmHN9Vny/9Roo6FB32sgdjlZbzSTGblhFCaM9n9TCCB+IwggXK oAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIx MDE1NFoXDTEyMTAyMjIxMDE1NFowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOM pohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl 0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOh V+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1 xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y /w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8wCwYDVR0P BAQDAgGmMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjCBqAYDVR0jBIGgMIGdgBRO C+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIE AjAAMD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5j b20vc2ZzY2EuY3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9zZnNjYS1jcmwuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5j cmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYj aHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6 Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAn FiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFi aWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwUAYJ YIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgRnJl ZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUAA4ICAQCqmuHgW4zOHRv8 HcYsMCCgt5Mm/fECts0RKL8p/8cwz/+B/wXPBRQ04KCUfp19i4tBD91O07IxvgmiIvdPvGJU oQA6ZD635v/Es4xrSbXzOhGpbiToaXKjK9zssyt2mBiT+USHmery0930Gg2bCKKF5emEhUf9 B6VOBSQ3NMLshWmZhWwq406fETWMkVk01+plkr/k62jsLo98663XUqYFBItlqsDPRv+aOCF0 Gxh8e6F07y+s68PSDmDt0DimQ4BTYR3ilIKjAFIi3IP/loXBnvmOLpirsYIbcGmLIA/2y3yH 6KdzQv7uSasAwloswCa7oZmzleCxvOfTBQm9sP2HmOecwz1RpkNzGXa4sHTiq4ZRYzo2IoZp tvFBzrzQ9ht5CtC757oni6o0DHOhrlHGQEDlr/eqVuAX24kF6QKomzDHm9D2SEmuzxRMxogX NsQLlUZDOJAff/oongNQ/zk4kScLH+q5KFYDrDfXwsOdtrczprlX4qg0uGxWL9NLF/3RRsGr B1FH9w7C4aQ0mHXo2++Eio7bqiwyDrgJtmwNWsQOvu5IxXjSJ4ElOjj0jK3vsQI6HP+nKGjB rYRQ/popq/4v/BfMA8Hcs2rO6MZHQrWlvIVYq/JiZ26eAm3JJZQzD5HkOqkDZsUg4Tnql9Y8 sdnE4v7z6vv08sVf7LZXoTGCA9AwggPMAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0ECAwCdWDAJBgUrDgMCGgUAoIICEDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0MTYxODEzMTFaMCMGCSqGSIb3DQEJBDEWBBSemYdx 261TAGqe6598nsAxx3VvpzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgMAnVgwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0ECAwCdWDANBgkqhkiG9w0BAQEFAASCAQCzjUvvX7cFLTKWOJkM0N6i LT/0W7gZwWe0lyhQqYhLZdNMf3wOmnbiyQZPtJKUEAZXjfqtF8NWfDeC1ewYmSNCT8UlgCA/ Lx0Dvnn3IxqFheyFNm2W9xiCw8AOJmTSLQFIICbVzR3vEKHeM/oRKXywueFgmr4lqFbG00az 4QMU/J9Og/UffErMKvmwtGz4YAHMDPFCZ0Mh6PTZaUNh/6iuyXIeBlC0b9BpajAQJhUUU3G9 e4l/9se5XcghrP4K1t+UvtSGATPdlVOCAvwmxw694Fp+Dk563gYaAl+swMfP8xbQelu59ZBr oi6dDEtmqsCMNvZRF7ICsLxZlqI95gn8AAAAAAAA --------------ms040209080804080304070307--

1 0

Re: (ITS#6524) gnutls cipher spec is unclear
by hyc＠symas.com 16 Apr '10

16 Apr '10

matthijs(a)cacholong.nl wrote: > Full_Name: Matthijs Mohlmann > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.163.247.203) > > > Hi, > > The manpage about the TLS_CIPHER_SUITE is for gnutls a bit unclear, only an > example for OpenSSL is provided. > > Peter Marschall wrote a patch for this documentation issue. If Peter wants his patch considered for inclusion in OpenLDAP he should write to the ITS himself, we cannot accept 3rd party contributions. > See also: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563113 > > Regards, > > Matthijs Mohlmann > > Patch: > --- openldap-2.1.21/doc/man/man5/ldap.conf.5 > +++ openldap-2.1.21/doc/man/man5/ldap.conf.5 2010-04-15 08:26:41.000000000 > +0200 > @@ -334,19 +334,37 @@ > .B TLS_CIPHER_SUITE<cipher-suite-spec> > Specifies acceptable cipher suite and preference order. > <cipher-suite-spec> should be a cipher specification for OpenSSL, > -e.g., HIGH:MEDIUM:+SSLv2. > +<cipher-suite-spec> should be a cipher specification for OpenSSL resp. GNUtls. > +Example: > +.RS > +.RS > +.TP > +.I OpenSSL: > +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2 > +.TP > +.I GNUtls: > +TLS_CIPHER_SUITE SECURE256:!AES-128-CBC > +.RE > > -To check what ciphers a given spec selects, use: > +To check what ciphers a given spec selects in OpenSSL, use: > > .nf > openssl ciphers \-v<cipher-suite-spec> > .fi > > -To obtain the list of ciphers in GNUtls use: > +With GNUtls the available specs can be found in the manual page of > +.BR gnutls\-cli (1) > +(see the description of the > +option > +.BR \-\-priority ). > + > +In older versions of GNUtls, where gnutls\-cli does not support the option > +\-\-priority, you can obtain the \(em more limited \(em list of ciphers by > calling: > > .nf > - gnutls-cli \-l > + gnutls\-cli \-l > .fi > +.RE > .TP > .B TLS_RANDFILE<filename> > Specifies the file to obtain random bits from when /dev/[u]random is > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6524) gnutls cipher spec is unclear
by matthijs＠cacholong.nl 16 Apr '10

16 Apr '10

Full_Name: Matthijs Mohlmann Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.163.247.203) Hi, The manpage about the TLS_CIPHER_SUITE is for gnutls a bit unclear, only an example for OpenSSL is provided. Peter Marschall wrote a patch for this documentation issue. See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563113 Regards, Matthijs Mohlmann Patch: --- openldap-2.1.21/doc/man/man5/ldap.conf.5 +++ openldap-2.1.21/doc/man/man5/ldap.conf.5 2010-04-15 08:26:41.000000000 +0200 @@ -334,19 +334,37 @@ .B TLS_CIPHER_SUITE <cipher-suite-spec> Specifies acceptable cipher suite and preference order. <cipher-suite-spec> should be a cipher specification for OpenSSL, -e.g., HIGH:MEDIUM:+SSLv2. +<cipher-suite-spec> should be a cipher specification for OpenSSL resp. GNUtls. +Example: +.RS +.RS +.TP +.I OpenSSL: +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2 +.TP +.I GNUtls: +TLS_CIPHER_SUITE SECURE256:!AES-128-CBC +.RE -To check what ciphers a given spec selects, use: +To check what ciphers a given spec selects in OpenSSL, use: .nf openssl ciphers \-v <cipher-suite-spec> .fi -To obtain the list of ciphers in GNUtls use: +With GNUtls the available specs can be found in the manual page of +.BR gnutls\-cli (1) +(see the description of the +option +.BR \-\-priority ). + +In older versions of GNUtls, where gnutls\-cli does not support the option +\-\-priority, you can obtain the \(em more limited \(em list of ciphers by calling: .nf - gnutls-cli \-l + gnutls\-cli \-l .fi +.RE .TP .B TLS_RANDFILE <filename> Specifies the file to obtain random bits from when /dev/[u]random is

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by Kurt＠OpenLDAP.org 15 Apr '10

15 Apr '10

On Apr 15, 2010, at 5:37 PM, hyc(a)symas.com wrote: > Dzmitry Stremkouski wrote: >> http://www.openldap.org/doc/admin24/schema.html - Contains them, as = well >=20 > I guess the web site is just out of date. I note that update to date for doc/admin24 means "as of the last 2.4 = patch release". -- Kurt=

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by hyc＠symas.com 15 Apr '10

15 Apr '10

Dzmitry Stremkouski wrote: > http://www.openldap.org/doc/admin24/schema.html - Contains them, as well I guess the web site is just out of date. The last link in question was fixed by ITS#6493 on 2010-03-18. The IANA link was fixed on 2007-07-07. I don't recall when the bsa link was removed, but it's gone in the 2.4 doc. > On Mon, Apr 12, 2010 at 10:10 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > mitroko(a)gmail.com <mailto:mitroko@gmail.com> wrote: > > Full_Name: Dmitry Stremkouski > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.84.189.132) > > > Hello guys. The part of OpenLDAP Manual (wich can be found here - > http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken > links. > Please correct. > > > The 2.3 release is no longer maintained. This doc will not be updated. > > FE: http://www.alvestrand.no/harald/objectid/ - dead > A: http://www.bsa-global.com/ - dead (doesn't look good enough for > global OID > authority) > A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, > but futher, > IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) > > Thanks. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > <pre> > (o_ - Dzmitry Stremkouski. > //\ - cel: +7 (916) 090-85-68 > V_/_- web: http://mitroko.com > </pre> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 15 Apr '10

15 Apr '10

>> Such a behavior allows replays attacks >> within the modification propagation time frame, but it ensures that bind >> are still possible when then master is down. I think it could be >> interesting to have a configuration setting for that. > > We should bring this to -devel, to see whether it makes sense and whether > it would be acceptable. A fix in this sense is in HEAD. Modifications consist in the original patch (well-known SASL mechs exploit the dontUseCopy control to actually lookup and propagate auxprops to the master ("sasl-auxprops-dontusecopy" directive). Another directive ("sasl-auxprops-dontusecopy-ignore") allows to ignore errors and lookup/store auxprops locally. By default it's FALSE for consistency. If set to TRUE, replicas will be misaligned, but service will be possible. Choose what best fits your needs. Both directives are not documented yet, as I consider the whole code highly experimental. Right now, is only built when #define LDAP_DEVEL. Please note that the relatively minor modifications to slapo-chain(5) are not conditioned on #define SLAP_AUXPROP_DONTUSECOPY, because I think they are generally useful, and I've checked they don't break anything (I could check so far). Please report any inconvenience. p.

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 15 Apr '10

15 Apr '10

Am Donnerstag 15 April 2010 00:53:04 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: > >> rhafer(a)suse.de wrote: > >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > >>>> But how did the suffix entry get created without an entryCSN in > >>>> the first place? The MOD that updates the contextCSN doesn't > >>>> happen until after the suffix entry already exists. > >>> > >>> It wasn't created without an entryCSN. It always had one. But the > >>> MOD to update the contextCSN (coming from the provider) doesn't > >>> contain one. So bdb_modify() will call slap_mods_opattrs() to add > >>> entryCSN to the MOD operation. The easiest fix is probably to > >>> never touch the opattrs if "updatedn" is doing MODs, though I am > >>> not yet sure if it might break something. Currently my fix (not > >>> committed yet) only skips the slap_mods_opattrs() step if > >>> "updatedn" it is doing a MOD on contextCSN. > >> > >> Ah, got it. Yes, sounds like your fix is fine. > > > > Do you think it's fine to always skip slap_mods_opattrs() if > > "updatedn" is writing? Or should I check for contextCSN MODs > > specifically? > > > >> Historically the updatedn user (e.g. slurpd) has always provided > >> all of the operational attributes in its updates. > > I guess the question is what have we done in the past for updatedn > writes? If we filled in missing opattrs, then we should continue to > do so. So it should be a special case for contextCSN mods. Ok, that's how the current fix work. So I think we are fine here now. -- Ralf

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> If you don't mind playing with HEAD code, you could try this patch > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-14-extra-attrs.…> Never mind, I think I already made it incompatible with HEAD code. I'm going to commit this stuff anyway, please stay tuned. p. > You need to add > > extra_attrs OpenLDAPACI > > within the database that contains the offending slapo-rwm instance. > > Please test and report. Thanks, p. > > > >

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

If you don't mind playing with HEAD code, you could try this patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-14-extra-attrs.…> You need to add extra_attrs OpenLDAPACI within the database that contains the offending slapo-rwm instance. Please test and report. Thanks, p.

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 14 Apr '10

14 Apr '10

rhafer(a)suse.de wrote: > Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: >> rhafer(a)suse.de wrote: >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: >>>> But how did the suffix entry get created without an entryCSN in the >>>> first place? The MOD that updates the contextCSN doesn't happen >>>> until after the suffix entry already exists. >>> >>> It wasn't created without an entryCSN. It always had one. But the >>> MOD to update the contextCSN (coming from the provider) doesn't >>> contain one. So bdb_modify() will call slap_mods_opattrs() to add >>> entryCSN to the MOD operation. The easiest fix is probably to never >>> touch the opattrs if "updatedn" is doing MODs, though I am not yet >>> sure if it might break something. Currently my fix (not committed >>> yet) only skips the slap_mods_opattrs() step if "updatedn" it is >>> doing a MOD on contextCSN. >> >> Ah, got it. Yes, sounds like your fix is fine. > Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" > is writing? Or should I check for contextCSN MODs specifically? > >> Historically the updatedn user (e.g. slurpd) has always provided all of >> the operational attributes in its updates. > I guess the question is what have we done in the past for updatedn writes? If we filled in missing opattrs, then we should continue to do so. So it should be a special case for contextCSN mods. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> --Boundary-00=_glFxL04kLcJl7l6 > Content-Type: Text/Plain; > charset="iso-8859-15" > Content-Transfer-Encoding: quoted-printable > > Thanks for your quick answer Pierangelo, > > On Monday, 12. April 2010, masarati(a)aero.polimi.it wrote: >> > [...] >> > My guess is that you're trying to use ACIs with a non-local storage. >> In >> > that case your analysis is correct. Can you provide your (sanitized) >> > configuration? > > I am using a local hdb backend. > > In order to generate a minimal test case I found out, that it seems to > be=20 > related to the rwm overlay. > > Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 > active. > Commenting out the rwm directives completely makes the searches work as=20 > expected. > > Please find attached a testcase with slapd.conf and ldif data. > To experience the issue simply perform a search with e.g. attribute 1.1 as > = > one=20 > of the users in the data. > Then comment the rwm-... lines in slapd.conf, restart slapd and try again. > Voil=E0 the difference. I see. probably, a relatively "quick" fix would be to allow to define a list of attributes, specific for a database, that is available to all implementations that need to muck with requested attrs (e.g. slapd-ldap, slapd-meta, slapo-rwm). They are supposed to be added to the list of requested attrs whenever appropriate. It's up to the administrato to keep it updated with everything that may be needed by special features like ACI. Something like required_attrs OpenLDAPACI In the future, we might be able to figure out a clever way to self-detect what attributes need to be treated this way. I'll work at that, time permitting. Thanks for reporting. p.

1 0

(ITS#6523) idassert marks proxyAuthz as non-critical
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando RFC 4370 requires the criticality flag to be present and set to TRUE. I also note that slapd by default tolerates this behavior, and provides the disallow proxy_authz_non_critical directive to behave in strict accordance with RFC 4370. I've introduced a corresponding proxy-authz-[non-]critical flag in idassert. p.

1 0

Re: (ITS#6518) Slapd-ldap proxy between replica and mirror
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> We have problems when we introduce a back-ldap proxy server between a > delta-syncrepl server and a mirror configuration of two servers. > > The modifications through the replica server (with chaining configuration) > over > the first mirror server are made without problems. The problem appears > when we > introduce a back-ldap proxy between replica and the two servers in mirror > mode. I've already fixed the bit of this issue related to not being able to process ordered attributes in proxies (ITS#6516). This is required to retrieve attributes authzFrom and authzTo, used by the proxy authorization process. The rest of your issue is related to the fact that the slave uses proxyAuthz to propagate the modify request to the updateref server. When this is a proxy, it needs to add proxyAuthz itself to correctly proxy the operation to the master. But two proxyAuthz controls are not allowed. You'd need to use distributed procedures, which are not implemented in OpenLDAP. A distributed operation would then consist in an extended operation that wraps the original one into a new request, with its own controls. At this point, proxyAuthz could apply incrementally at each layer. I'd treat your ITS as yet another request to implement distributed procedures. p.

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by hyc＠symas.com 14 Apr '10

14 Apr '10

rein(a)OpenLDAP.org wrote: > On 02/02/2010 04:25 PM, Hallvard B Furuseth wrote: >> Hold on. Is the current behavior self-consistent, i.e. one could call >> it an undocumented feature? If so someone may have noticed this and >> written their ACLs accordingly. It's not friendly to change the >> meaning of existing installations' ACLs in the middle of RE24. >> >> OTOH if current behavior is broken even as a "feature", fix away. >> E.g. if clients can choose which ACLs will apply in the subordinate >> by picking a base DN inside vs outside the subordinate. > > From my analyzis of the problem, the subordinate ACLs are used in all > cases except when syncprov desides which "live" modifications it should > replicate to its consumers. Searching with the credentials used by the > syncrepl consumer gives me the attributes and entries my subordinate > ACLs allows, and they are replicated during the refresh phase. But > access to entries and/or attributes being modified during the persistent > phase are rejected. > > But yes, the change should be analyzed by somebody else before being > included in a release. The fix seems to head in the right direction. One could argue that the correct behavior is to apply the subordinate's ACLs first, and then check the parent's ACLs, and then finally any global ACLs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6522) man page for pcache overlay doesn't state requirement for rootdn
by jonathan＠phillipoux.net 14 Apr '10

14 Apr '10

Full_Name: Jonathan Clarke Version: current RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-man-20100414.patch Submission from: (NULL) (82.127.99.208) In the code for the pcache overlay, there is a comment stating: /* Cached database must have the rootdn */ And trying to configure the pcache overlay on a database without rootdn, via slapd.conf, produces errors like: pcache_db_open(): underlying database of type "ldap" serving naming context "o=passwd" has no "rootdn", required by "pcache". However, the pcache man page doesn't mention this. I suggest the patch above.

1 0

(ITS#6521) docs: pcache overlay section in admin guide
by jonathan＠phillipoux.net 14 Apr '10

14 Apr '10

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jcl-admin-guide-overlays-20100414.patch Submission from: (NULL) (82.127.99.208) The section of the admin guide on the proxy cache overlay is a little out of date. The patch below: - updates deprected keywords to their new names (s/proxyAttrset/pcacheAttrset/, etc) - adds a configuration example for back-config, which is not trivial to guess

1 0

Re: (ITS#6519) syncprov sends bogus cookie on accesslog purge
by quanah＠zimbra.com 14 Apr '10

14 Apr '10

--On Tuesday, April 13, 2010 9:22 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 13, 2010 9:07 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > Here is the -d -1 output from the provider during this time period. You > can clearly see part way through where the empty cookie is sent after a > delete operation is completed. I can confirm Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays Modified Files: accesslog.c 1.105 -> 1.106 Log Message: ITS#6519 don't replicate purge deletes CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/accesslog.c Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed. fixes the issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6520) ACL bug with various .expand styles
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6376) memleak in 2.3
by jonathan＠OpenLDAP.org 14 Apr '10

14 Apr '10

On 14/11/2009 05:21, mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.3 only > OS: any > URL: > Submission from: (NULL) (76.88.99.93) > > > In 2.3, if you have a lot of fast writes such that syncprov_sendresp's > op tmp memory is exhausted and it has resorted to malloc()s AND > controls are asserted, the rs.sr_ctrls free at the end of the function > leaks. > > To duplicate: Set up a master and a replica. Do mods like crazy with > some control asserted, e.g. manageDSAIT. > > 2.4/head handle this differently so it isn't a problem there. Hi, This ITS says 2.3 only, but it is listed in the changelog for 2.4.20. Did this also affect versions on the 2.4 branch < 2.4.20, then? Just checking for bug fixes and came across this inconsistency. Any enlightenment welcome. Jonathan

1 0

(ITS#6520) ACL bug with various .expand styles
by kean.johnston＠gmail.com 13 Apr '10

13 Apr '10

Full_Name: Kean Johnston Version: 2.4.21 OS: Linux (Debian Lenny) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100413.patch Submission from: (NULL) (41.133.19.25) Assumption: the following ACL should result in $0 being expanded for the set: access to dn.one="ou=hosts,dc=example,dc=com" attrs=authorizedService by set.expand="[cn=access,$0]/member* & user" compare by * =rsdx break Reason for assumption: man slapd.access states: Forms of the <what> clause other than regex may provide submatches as well. The base(object), the sub(tree), the one(level), and the chil- dren forms provide $0 as the match of the entire string. The sub(tree), the one(level), and the children forms also provide $1 as the match of the rightmost part of the DN as defined in the <what> clause. Bug: does not work as expected. The reason is that in slap.h slap_style_t starts with ACL_STYLE_REGEX = 0, so any structure that uses slap_style_t and uses memset to null out the structure will have its default style be ACL_STYLE_REGEX. In acl.c there are 4 places where you test for ACL_STYLE_REGEX on a->acl_attrval_style without checking if an actual attribute value was supplied. The patch below fixes those cases. The better (arguably) fix would be to change slap_style_t to start with ACL_STYLE_NONE = 0, and then explicitly set the style when it is encountered in aclparse.c. However, I did not want to change slap.h in case it changes some ABI and the change to aclparse.c is larger. As things currently stand, dn.expand, set.expand and group.expand will not expand $0 and $1 as documented if you use dn.{base,one,sub,children} in the what clause. I have attached a patch, and as per instruction: I, James Kean Johnston, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. ftp://ftp.openldap.org/incoming/kean-johnston-100413.patch

1 0

Re: (ITS#6519) syncprov sends bogus cookie on accesslog purge
by quanah＠zimbra.com 13 Apr '10

13 Apr '10

--On Tuesday, April 13, 2010 9:07 PM +0000 openldap-its(a)OpenLDAP.org wrote: Here is the -d -1 output from the provider during this time period. You can clearly see part way through where the empty cookie is sent after a delete operation is completed. 01c0: 69 6c 31 24 04 22 75 73 65 72 2e 32 37 36 40 66 il1$."user.276@f 01d0: 72 65 65 6c 61 6e 63 65 72 2e 6c 61 62 2e 7a 69 reelancer.lab.zi 01e0: 6d 62 72 61 2e 63 6f 6d 30 11 04 03 75 69 64 31 mbra.com0...uid1 01f0: 0a 04 08 75 73 65 72 2e 32 37 36 30 43 04 0b 6f ...user.2760C..o 0200: 62 6a 65 63 74 43 6c 61 73 73 31 34 04 14 6f 72 bjectClass14..or 0210: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 65 72 73 ganizationalPers 0220: 6f 6e 04 0d 7a 69 6d 62 72 61 41 63 63 6f 75 6e on..zimbraAccoun 0230: 74 04 0d 61 6d 61 76 69 73 41 63 63 6f 75 6e 74 t..amavisAccount 0240: 30 2f 04 1a 7a 69 6d 62 72 61 50 61 73 73 77 6f 0/..zimbraPasswo 0250: 72 64 4d 6f 64 69 66 69 65 64 54 69 6d 65 31 11 rdModifiedTime1. 0260: 04 0f 32 30 31 30 30 34 31 33 32 30 34 35 35 34 ..20100413204554 0270: 5a 30 10 04 02 63 6e 31 0a 04 08 75 73 65 72 2e Z0...cn1...user. 0280: 32 37 36 30 2d 04 0e 7a 69 6d 62 72 61 4d 61 69 2760-..zimbraMai 0290: 6c 48 6f 73 74 31 1b 04 19 66 72 65 65 6c 61 6e lHost1...freelan 02a0: 63 65 72 2e 6c 61 62 2e 7a 69 6d 62 72 61 2e 63 cer.lab.zimbra.c 02b0: 6f 6d om <= send_search_entry: conn 2605 exit. send_ldap_result: conn=2605 op=3 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=4 tag=101 err=0 ber_flush2: 14 bytes to sd 20 0000: 30 0c 02 01 04 65 07 0a 01 00 04 00 04 00 0....e........ tls_write: want=35, written=35 0000: 17 03 01 00 1e 59 2c c6 87 d7 64 fe a5 b5 74 e9 .....Y,...d...t. 0010: ff cf e6 00 22 30 dc 8b ed 0f c2 c9 aa d7 64 43 ...."0........dC 0020: 9a d2 3a ..: ldap_write: want=14, written=14 0000: 30 0c 02 01 04 65 07 0a 01 00 04 00 04 00 0....e........ conn=2605 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(20) connection_get(20): got connid=2605 connection_read(20): checking for input on id=2605 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 12 ..... tls_read: want=18, got=18 0000: 07 3e f1 34 3c 74 48 e4 2d 64 da bf 16 b2 f0 e3 .>.4<tH.-d...... 0010: 82 1f .. TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 20 failed errno=0 (Success) connection_read(20): input error=-2 id=2605, closing. connection_closing: readying conn=2605 sd=20 for close connection_close: conn=2605 sd=20 daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: removing 20 tls_write: want=23, written=23 0000: 15 03 01 00 12 d7 55 9d 59 8c 18 96 64 bf e7 f9 ......U.Y...d... 0010: 9e 2c 0a 91 c4 9d ba .,..... TLS trace: SSL3 alert write:warning:close notify conn=2605 fd=20 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: 38r daemon: read active on 38 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(38) connection_get(38): got connid=2603 connection_read(38): checking for input on id=2603 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 12 ..... tls_read: want=18, got=18 0000: 81 9f e4 91 64 6e bc c8 ba 53 be e0 5e 5e 75 f9 ....dn...S..^^u. 0010: ac e4 .. TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 38 failed errno=0 (Success) connection_read(38): input error=-2 id=2603, closing. connection_closing: readying conn=2603 sd=38 for close connection_close: conn=2603 sd=38 daemon: removing 38 tls_write: want=23, written=23 0000: 15 03 01 00 12 50 be 29 9e e3 e6 b8 88 55 46 64 .....P.).....UFd 0010: 08 d4 83 45 e4 df b1 ...E... TLS trace: SSL3 alert write:warning:close notify conn=2603 fd=38 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 37r daemon: read active on 37 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(37) connection_get(37): got connid=2602 connection_read(37): checking for input on id=2602 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 12 ..... tls_read: want=18, got=18 0000: b8 e7 6e 24 27 de cc 33 fd 77 b9 29 8a a4 5e 79 ..n$'..3.w.)..^y 0010: 53 7c S| TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 37 failed errno=0 (Success) connection_read(37): input error=-2 id=2602, closing. connection_closing: readying conn=2602 sd=37 for close connection_close: conn=2602 sd=37 daemon: removing 37 tls_write: want=23, written=23 0000: 15 03 01 00 12 7c e4 28 fb 15 b4 f9 dc 69 44 4d .....|.(.....iDM 0010: 40 21 1b 78 7f 41 35 @!.x.A5 TLS trace: SSL3 alert write:warning:close notify conn=2602 fd=37 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero => hdb_search bdb_dn2entry("cn=accesslog") => access_allowed: search access to "cn=accesslog" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) search_candidates: base="cn=accesslog" (0x00000001) scope=1 => hdb_dn2idl("cn=accesslog") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates LE => bdb_inequality_candidates (reqStart) => key_read bdb_idl_fetch_key: <= bdb_index_read 2 candidates => key_read bdb_idl_fetch_key: <= bdb_index_read: failed (-30988) <= bdb_inequality_candidates: id=2, first=9, last=10 <= bdb_filter_candidates: id=2 first=9 last=10 <= bdb_list_candidates: id=2 first=9 last=10 <= bdb_filter_candidates: id=2 first=9 last=10 <= bdb_list_candidates: id=2 first=9 last=10 <= bdb_filter_candidates: id=2 first=9 last=10 bdb_search_candidates: id=2 first=9 last=10 entry_decode: "" <= entry_decode() => test_filter LE => access_allowed: search access to "reqStart=20100413191807.000004Z,cn=accesslog" "reqStart" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 entry_decode: "" <= entry_decode() => test_filter LE => access_allowed: search access to "reqStart=20100413191807.000009Z,cn=accesslog" "reqStart" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" => bdb_entry_get: ndn: "reqStart=20100413191807.000004Z,cn=accesslog" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("reqStart=20100413191807.000004Z,cn=accesslog") => bdb_entry_get: found entry: "reqStart=20100413191807.000004Z,cn=accesslog" bdb_entry_get: rc=0 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000004Z,cn=accesslog" "objectClass" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr objectClass => acl_mask: access to entry "reqStart=20100413191807.000004Z,cn=accesslog", attr "objectClass" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000004Z,cn=accesslog" "reqResult" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr reqResult => acl_mask: access to entry "reqStart=20100413191807.000004Z,cn=accesslog", attr "reqResult" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 <= test_filter_and 6 <= test_filter 6 syncprov_matchops: sid ffffffff fscope 1 rc 6 ==> hdb_delete: reqStart=20100413191807.000004Z,cn=accesslog bdb_dn2entry("reqStart=20100413191807.000004Z,cn=accesslog") => access_allowed: delete access to "cn=accesslog" "children" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => access_allowed: delete access to "reqStart=20100413191807.000004Z,cn=accesslog" "entry" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => hdb_dn2id_delete 0x9: "reqStart=20100413191807.000004Z,cn=accesslog" <= hdb_dn2id_delete 0x9: 0 => index_entry_del( 9, "reqStart=20100413191807.000004Z,cn=accesslog" ) => key_change(DELETE,9) bdb_idl_delete_key: 9 [66ec5701] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [98599c51] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [61e2b421] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [0096defd] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [80000000] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 <= key_change 0 <= index_entry_del( 9, "reqStart=20100413191807.000004Z,cn=accesslog" ) success ====> bdb_cache_delete( 9 ) hdb_delete: deleted id=00000009 dn="reqStart=20100413191807.000004Z,cn=accesslog" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncprov_sendresp: cookie= => send_search_entry: conn 1013 dn="reqStart=20100413191807.000004Z,cn=accesslog" => access_allowed: read access to "reqStart=20100413191807.000004Z,cn=accesslog" "entry" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr entry => acl_mask: access to entry "reqStart=20100413191807.000004Z,cn=accesslog", attr "entry" requested => acl_mask: to all values by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) conn=1013 op=2 ENTRY dn="reqStart=20100413191807.000004Z,cn=accesslog" ber_flush2: 112 bytes to sd 18 0000: 30 6e 02 01 03 64 30 04 2c 72 65 71 53 74 61 72 0n...d0.,reqStar 0010: 74 3d 32 30 31 30 30 34 31 33 31 39 31 38 30 37 t=20100413191807 0020: 2e 30 30 30 30 30 34 5a 2c 63 6e 3d 61 63 63 65 .000004Z,cn=acce 0030: 73 73 6c 6f 67 30 00 a0 37 30 35 04 18 31 2e 33 sslog0..705..1.3 0040: 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e .6.1.4.1.4203.1. 0050: 39 2e 31 2e 32 04 19 30 17 0a 01 03 04 10 43 30 9.1.2..0......C0 0060: b3 35 9f 63 47 af b6 f3 66 1b e4 76 6c 54 04 00 .5.cG...f..vlT.. tls_write: want=186, written=186 0000: 17 03 01 00 20 77 40 e5 e4 99 b3 f0 07 5a 3d c9 .... w@......Z=. 0010: 11 4b 1d c2 97 45 d2 d1 d6 52 c9 89 74 37 b7 c9 .K...E...R..t7.. 0020: fd 72 3d cf 8d 17 03 01 00 90 f3 dc 6b 91 cd f5 .r=.........k... 0030: 6a 87 21 7c 61 fa 8e 69 ea f8 21 9e ec ea 85 a2 j.!|a..i..!..... 0040: 9d f0 8a 32 82 66 62 9c bf 15 00 02 ef c0 d0 34 ...2.fb........4 0050: 16 4e 2d a6 25 e3 5f 0d 95 68 2d 7b 74 8f 41 a8 .N-.%._..h-{t.A. 0060: 4b 51 93 78 46 d6 8e 44 33 12 44 05 6c 37 09 03 KQ.xF..D3.D.l7.. 0070: b5 d3 13 58 c2 7a 82 9e 3e 0e 4d 6f f0 90 a7 3d ...X.z..>.Mo...= 0080: 4b 5f 44 5f 7d 3a cc 28 93 b6 3f 37 05 c8 c6 77 K_D_}:.(..?7...w 0090: f4 40 72 97 ea a9 0e a0 ab 98 09 5c b8 08 54 a7 .@r........\..T. 00a0: 7d 2e 72 6f 5f 14 db e4 0b bc 0b ca 1f 3e ae 83 }.ro_........>.. 00b0: 37 51 c5 82 44 b7 b4 00 9a 35 7Q..D....5 ldap_write: want=112, written=112 0000: 30 6e 02 01 03 64 30 04 2c 72 65 71 53 74 61 72 0n...d0.,reqStar 0010: 74 3d 32 30 31 30 30 34 31 33 31 39 31 38 30 37 t=20100413191807 0020: 2e 30 30 30 30 30 34 5a 2c 63 6e 3d 61 63 63 65 .000004Z,cn=acce 0030: 73 73 6c 6f 67 30 00 a0 37 30 35 04 18 31 2e 33 sslog0..705..1.3 0040: 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e .6.1.4.1.4203.1. 0050: 39 2e 31 2e 32 04 19 30 17 0a 01 03 04 10 43 30 9.1.2..0......C0 0060: b3 35 9f 63 47 af b6 f3 66 1b e4 76 6c 54 04 00 .5.cG...f..vlT.. <= send_search_entry: conn 1013 exit. => bdb_entry_get: ndn: "reqStart=20100413191807.000009Z,cn=accesslog" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("reqStart=20100413191807.000009Z,cn=accesslog") => bdb_entry_get: found entry: "reqStart=20100413191807.000009Z,cn=accesslog" bdb_entry_get: rc=0 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000009Z,cn=accesslog" "objectClass" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr objectClass => acl_mask: access to entry "reqStart=20100413191807.000009Z,cn=accesslog", attr "objectClass" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000009Z,cn=accesslog" "reqResult" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr reqResult => acl_mask: access to entry "reqStart=20100413191807.000009Z,cn=accesslog", attr "reqResult" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 <= test_filter_and 6 <= test_filter 6 syncprov_matchops: sid ffffffff fscope 1 rc 6 ==> hdb_delete: reqStart=20100413191807.000009Z,cn=accesslog bdb_dn2entry("reqStart=20100413191807.000009Z,cn=accesslog") => access_allowed: delete access to "cn=accesslog" "children" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => access_allowed: delete access to "reqStart=20100413191807.000009Z,cn=accesslog" "entry" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => hdb_dn2id_delete 0xa: "reqStart=20100413191807.000009Z,cn=accesslog" <= hdb_dn2id_delete 0xa: 0 => index_entry_del( 10, "reqStart=20100413191807.000009Z,cn=accesslog" ) => key_change(DELETE,a) bdb_idl_delete_key: a [66ec5701] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [98599c51] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [61e2b421] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [0096defd] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [80000000] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a <= key_change 0 <= index_entry_del( 10, "reqStart=20100413191807.000009Z,cn=accesslog" ) success ====> bdb_cache_delete( 10 ) daemon: activity on 1 descriptor daemon: activity on: 18r daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(18) connection_get(18): got connid=1013 connection_read(18): checking for input on id=1013 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 00 20 .... tls_read: want=32, got=32 0000: d7 e0 2b 7c 92 57 a1 11 a4 0b d8 76 81 f5 15 e7 ..+|.W.....v.... 0010: b3 58 97 b6 10 65 aa 30 9d 38 e3 2c 90 63 a5 9d .X...e.0.8.,.c.. tls_read: want=5, got=5 0000: 17 03 01 00 20 .... tls_read: want=32, got=32 0000: 2a bd 8d 49 d2 58 87 51 8f b4 32 e7 70 07 8c 13 *..I.X.Q..2.p... 0010: 1d d2 19 c8 43 a1 fb 28 89 4f cf df a8 58 6c 2a ....C..(.O...Xl* ldap_read: want=8, got=7 0000: 30 05 02 01 04 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x3f69170 ptr=0x3f69170 end=0x3f69175 len=5 0000: 02 01 04 42 00 ...B. op tag 0x42, time 1271191556 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 20 .... tls_read: want=32, got=32 0000: 04 7f 9e 27 41 7e af b2 de ec b2 b5 e9 b5 15 d7 ...'A~.......... 0010: 5f 1a 9a 5f 64 8e cf d5 8e a6 d4 e2 8b 4e 27 6e _.._d........N'n TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 18 failed errno=0 (Success) connection_read(18): input error=-2 id=1013, closing. connection_closing: readying conn=1013 sd=18 for close hdb_delete: deleted id=0000000a dn="reqStart=20100413191807.000009Z,cn=accesslog" daemon: activity on 1 descriptor daemon: activity on: send_ldap_result: conn=-1 op=0 p=0 connection_close: deferring conn=1013 sd=18 send_ldap_result: err=0 matched="" text="" daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero conn=1013 op=3 do_unbind conn=1013 op=3 UNBIND hdb_modify: cn=accesslog bdb_dn2entry("cn=accesslog") bdb_modify_internal: 0x00000001: cn=accesslog <= acl_access_allowed: granted to database root bdb_modify_internal: replace entryCSN connection_resched: attempting closing conn=1013 sd=18 connection_close: conn=1013 sd=18 => key_change(DELETE,1) bdb_idl_delete_key: 1 daemon: removing 18 <= key_change 0 tls_write: want=37, written=37 0000: 15 03 01 00 20 32 b4 ef e6 42 1b 72 80 46 e6 b5 .... 2...B.r.F.. 0010: d5 f4 ad 44 4f 37 eb c5 03 75 69 29 17 f3 be ac ...DO7...ui).... 0020: 4e 60 80 e2 4e N`..N => key_change(ADD,1) bdb_idl_insert_key: 1 TLS trace: SSL3 alert write:warning:close notify <= key_change 0 => entry_encode(0x00000001): <= entry_encode(0x00000001): conn=1013 fd=18 closed --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6519) syncprov sends bogus cookie on accesslog purge
by quanah＠zimbra.com 13 Apr '10

13 Apr '10

Full_Name: Quanah Gibson-Mount Version: 2.4.21 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When the accesslog database is purged, the syncprov overlay sends a bogus cookie response to open syncrepl clients, causing them to drop connection. This bogus cookie should never have been sent. >From the slapd log on the provider, we have the initial connection: Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 fd=18 ACCEPT from IP=10.18.97.26:60034 (IP=10.18.97.79:389) Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=0 STARTTLS Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=0 RESULT oid= err=0 text= Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 fd=18 TLS established tls_ssf=256 ssf=256 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=1 RESULT tag=97 err=0 text= Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Approximately 30 minutes later (which is my setting), the purge takes place: Apr 13 13:45:54 freelancer slapd[4276]: slap_queue_csn: queing 0x446a7200 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: slap_queue_csn: queing 0x395e788 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: slap_graduate_commit_csn: removing 0x3f94690 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: syncprov_sendresp: cookie=rid=100,csn=20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 op=2 RESULT tag=105 err=0 text= Apr 13 13:45:54 freelancer slapd[4276]: slap_graduate_commit_csn: removing 0x3f80030 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 op=3 SRCH base="" scope=2 deref=3 filter="(&(zimbraId=58a68771-fded-4aa2-baab-e1ac349e0028)(objectClass=zimbraAccount))" Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 fd=20 closed (connection lost) Apr 13 13:45:54 freelancer slapd[4276]: conn=2603 fd=38 closed (connection lost) Apr 13 13:45:54 freelancer slapd[4276]: conn=2602 fd=37 closed (connection lost) Apr 13 13:45:56 freelancer slapd[4276]: syncprov_sendresp: cookie= Apr 13 13:45:56 freelancer slapd[4276]: conn=1013 op=3 UNBIND Apr 13 13:45:56 freelancer slapd[4276]: conn=1013 fd=18 closed As you can see, an empty cookie is sent, and the consumer immediately closes connection, re-establishing it shortly thereafter: Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 fd=18 ACCEPT from IP=10.18.97.26:36796 (IP=10.18.97.79:389) Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=0 STARTTLS Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=0 RESULT oid= err=0 text= Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 fd=18 TLS established tls_ssf=256 ssf=256 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=1 RESULT tag=97 err=0 text= Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Apr 13 13:46:56 freelancer slapd[4276]: Entry reqStart=20100413204554.000009Z,cn=accesslog CSN 20100413204554.501961Z#000000#000#000000 older or equal to ctx 20100413204554.501961Z#000000#000#000000 Apr 13 13:46:56 freelancer slapd[4276]: syncprov_search_response: cookie=rid=100,csn=20100413204656.794873Z#000000#000#000000

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by hyc＠symas.com 13 Apr '10

13 Apr '10

h.b.furuseth(a)usit.uio.no wrote: >> There is no real buffer overflow here AFAICS but the real problem is, >> that the destination of the strcpy() is defined as char[1] in this >> case (it's the nrdn member of a struct diskNode). The additional >> runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the >> destination data will not fit in there and aborts. > > This is similar to the struct hack, except nrdn is not the last struct > member. IIRC it actually is invalid to use nrdn as an accessor for the > following struct members (from the compiler's point of view). > > Another case of "not quite the Struct Hack" broke last year: ITS#6303. > If _FORTIFY_SOURCE is warning us that gcc might break this code, the > memcpy patch might merely shut up the warning without fixing the > problem. In that case, the simplest change would be to do away with > struct diskNode - or keep it for reference but not actually use it. > > I'm reopening the ITS for someone else to decide if they care, I have > other things on my mind currently. > Nope, we don't care. The purpose and usage of diskNode is thoroughly documented in the comments and all of the uses are correct. Marking this Test again. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by h.b.furuseth＠usit.uio.no 13 Apr '10

13 Apr '10

> There is no real buffer overflow here AFAICS but the real problem is, > that the destination of the strcpy() is defined as char[1] in this > case (it's the nrdn member of a struct diskNode). The additional > runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the > destination data will not fit in there and aborts. This is similar to the struct hack, except nrdn is not the last struct member. IIRC it actually is invalid to use nrdn as an accessor for the following struct members (from the compiler's point of view). Another case of "not quite the Struct Hack" broke last year: ITS#6303. If _FORTIFY_SOURCE is warning us that gcc might break this code, the memcpy patch might merely shut up the warning without fixing the problem. In that case, the simplest change would be to do away with struct diskNode - or keep it for reference but not actually use it. I'm reopening the ITS for someone else to decide if they care, I have other things on my mind currently. -- Hallvard

1 0

Re: (ITS#6517) undefined references to ldif_*
by michael＠stroeder.com 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: > >>> Actually it's not that; Michael routinely builds with --enable-dynamic, >>> and libldap now (dynamically) depends on liblutil for the LDIF part. >>> >> I did not want to introduce any new dependencies nor break any existing >> code with the new LDIF library. Ideally, you would only have to link >> with -lldif for external code that wants to use the LDIF API (such as >> ldif_get_entry or ldif_parse_line). Any existing code, or code that >> just wants to use the new higher level api ldap_parse_ldif_record_x >> would only have to link with -lldap. >> >> Is --enable-dynamic the only additional build flag I need to use? > > In fact, you did not introduce any further dependence, as ldif_* functions > (those provided in liblutil/ldif.c) are present in liblutil. I fixed the > issue by reversing the link order of libraries. > > It used to be liblutil, liblber, libldap (I think that was because earlier > there used to be dependencies of liblutil on the others, please correct > me). Now it's libldap, liblber, liblutil, and it builds fine with > --enable-dynamic=yes/no. Please check whether my fix is appropriate. It seems to work for me now. Ciao, Michael.

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >> > > >>> Actually it's not that; Michael routinely builds with --enable-dynamic, >>> and libldap now (dynamically) depends on liblutil for the LDIF part. >>> >>> >> I did not want to introduce any new dependencies nor break any existing >> code with the new LDIF library. Ideally, you would only have to link >> with -lldif for external code that wants to use the LDIF API (such as >> ldif_get_entry or ldif_parse_line). Any existing code, or code that >> just wants to use the new higher level api ldap_parse_ldif_record_x >> would only have to link with -lldap. >> >> Is --enable-dynamic the only additional build flag I need to use? >> > > In fact, you did not introduce any further dependence, as ldif_* functions > (those provided in liblutil/ldif.c) are present in liblutil. I fixed the > issue by reversing the link order of libraries. > > It used to be liblutil, liblber, libldap (I think that was because earlier > there used to be dependencies of liblutil on the others, please correct > me). Now it's libldap, liblber, liblutil, and it builds fine with > --enable-dynamic=yes/no. Please check whether my fix is appropriate. > I just pulled the latest code from anonymous(a)cvs.openldap.org - started from a clean directory - ran configure with --enable-dynamic --disable-static - make depend and make install - build completed successfully - server works fine, ldapmodify works fine > p. > > > > >

1 0

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 13 Apr '10

13 Apr '10

> masarati(a)aero.polimi.it wrote: >> Actually it's not that; Michael routinely builds with --enable-dynamic, >> and libldap now (dynamically) depends on liblutil for the LDIF part. >> > I did not want to introduce any new dependencies nor break any existing > code with the new LDIF library. Ideally, you would only have to link > with -lldif for external code that wants to use the LDIF API (such as > ldif_get_entry or ldif_parse_line). Any existing code, or code that > just wants to use the new higher level api ldap_parse_ldif_record_x > would only have to link with -lldap. > > Is --enable-dynamic the only additional build flag I need to use? In fact, you did not introduce any further dependence, as ldif_* functions (those provided in liblutil/ldif.c) are present in liblutil. I fixed the issue by reversing the link order of libraries. It used to be liblutil, liblber, libldap (I think that was because earlier there used to be dependencies of liblutil on the others, please correct me). Now it's libldap, liblber, liblutil, and it builds fine with --enable-dynamic=yes/no. Please check whether my fix is appropriate. p.

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> Michael Ströder wrote: >> >>> hyc(a)symas.com wrote: >>> >>>> richm(a)stanfordalumni.org wrote: >>>> >>>>> This is most likely related to my recent LDIF changes. But I didn't >>>>> see >>>>> this problem. What platform is this? What build flags are you using? >>>>> >>>> Built fine here too, looks like an inconsistent build tree over there. >>>> >>> The build with the same build flags on the very same system worked right >>> before the recent libldif check-ins. I'm using anon CVS pserver for cvs >>> up. >>> >> The anon CVS server has some lag in receiving updates from the master >> server. >> Don't you have an account on the master? >> > > Actually it's not that; Michael routinely builds with --enable-dynamic, > and libldap now (dynamically) depends on liblutil for the LDIF part. > I did not want to introduce any new dependencies nor break any existing code with the new LDIF library. Ideally, you would only have to link with -lldif for external code that wants to use the LDIF API (such as ldif_get_entry or ldif_parse_line). Any existing code, or code that just wants to use the new higher level api ldap_parse_ldif_record_x would only have to link with -lldap. Is --enable-dynamic the only additional build flag I need to use? > p. > > > > > >

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by peter＠adpm.de 13 Apr '10

13 Apr '10

--Boundary-00=_glFxL04kLcJl7l6 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Thanks for your quick answer Pierangelo, On Monday, 12. April 2010, masarati(a)aero.polimi.it wrote: > > [...] > > My guess is that you're trying to use ACIs with a non-local storage. In > > that case your analysis is correct. Can you provide your (sanitized) > > configuration? I am using a local hdb backend. In order to generate a minimal test case I found out, that it seems to be=20 related to the rwm overlay. Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 active. Commenting out the rwm directives completely makes the searches work as=20 expected. Please find attached a testcase with slapd.conf and ldif data. To experience the issue simply perform a search with e.g. attribute 1.1 as = one=20 of the users in the data. Then comment the rwm-... lines in slapd.conf, restart slapd and try again. Voil=E0 the difference. > > [...] >=20 > Automatically detecting what attributes need to be added to requests for > proxying sounds like an overkill. Probably, a reasonable workaround could > be to add a configuration directive that lists what attributes need to be > added to requests. This directive should be honored by proxy backends and > in general by all those backends that do not pass back complete entries to > the frontend. In the case of proxy backends its use would be > straightforward, since requested attrs need to be mapped anyway in the > request. Adding some more would not be a big deal. =20 That would be absolutely sufficient for me. > Things might be a bit > more complicated in case of, say, special configurations like proxycache, > where ACIs would need to be added to all attribute templates, and so. Yet > another reason to avoid ACIs :) As much as I'd like to, but I fear I can't. I am trying to migrate from a non-OpenLDAP directory solution with a comple= x=20 permission structure in in-tree ACLs to OpenLDAP. Unfortunately the permissions are set up in a way that do not let them writ= e=20 as a short list of ACLs. Changing the permission structure is not possible as lots of applications=20 depend on it. =2D-=20 Peter Marschall peter(a)adpm.de --Boundary-00=_glFxL04kLcJl7l6 Content-Type: application/x-compressed-tar; name="testcase.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testcase.tgz" H4sIAOZWxEsAA+1YbW/jNgzuV/tXCMkBa3duXtz0CqQItq7JDTcc0sOKfjp0gyzJiTZH8iS5Sfbr R8mOm+SSJn1bN8AEAtsUxYekSJqOTnBKG0SK+ODVqAX0odOy1/bZqbsCI8yvrVYHFg/a7ZMP7dZp q3MG/HZ42jo9QK3XM+meMm2wQuhggpUmY5xukwOx+BVj9FZUR01mSDOhOG3qMhfQ8TG6Spn43L/4 giaYC6SZumMK2UU+yhQ2XAoU84T5fh1xQZKMsg2riM0MExoedYAgvmyC4abRaPjFHm8J3i03iVSs kd8/JKS52C0GMkaqUcqUlmIhDQZPx0wxRCUyY4ZUJgyfMGevRiPpp5zae89r3mHVhOU8MkV8YNXH aqSdyEYJu2pREjkacTFChzVIHqNriGsUS4XsE9eGE33kg0zC7ljiORF0cfnZ7lQMU4QJYTrfgcU8 knSOjERKStO/HgCLouvcoVzQM9KjosFmmJhereZ70dz73mnaKEBEL4/HiqTD1kZxYvgdhIaPxmAV wMroD0bMZYLBImxAIMoMQzJGOEmKRb2EY0V0b2mTA1lBv6ATLgLZM4BXgyQTeMScVAa5pnNz7CMW UswnMgPczIy3W2i3fQGkqVR0l2HLsg5EsyRGvensEWau2ZUHEXiuItYDp6FG0OBq2OgPVk9DZ5FR jPVqBcIjDKBzgUnSxISjqeKGrZkQYfInE7QpoW4TPEcTSTOb4Hmo/PwxxWbsNTOtmgmP8tIpVhKJ qWd1/D6m0TJPTSc+6H8ZAjspNjjCGsqRxVxw2zr0i6n3F9o964WrfGyg8G0coPT7P9meZWyDOzQy RZHCAopC2/yx6/ZojnydxTGfeV55RusdpHRh0UJAm2VzBUcvFcQe3jLQCqHoj/ySmzePMu5WtdWM 7XmDJHRRqb7ToAVahRhlXI8ZRQJDp7K1ny7S1zYEKsC69VxxK+nU80pR0P5JUE7yLLB93boO7ZOy mZcnKrHFGjBh1Pzyepjf3Nx86nse+6sQJCLQIhhB9YkhWBOAniSQgcycjKtPl4+oyLwuIKUIyaz3 9bfg9n1hHrImoPzeLyQ9l1zwOy5UDAQ0UObJOF7mXsKRwXvFg4TBWWKWl37NbN+uHTbeB0c/AOKh gzwK1sDf1VDtXRuY78Kysmrd2iYQzbAi4488MUxtXx/YOPWHD5myAX8f5AtoWP0hdDOONdoKttgz wQbyl+6/QbGYKYWTHOYhCViFsx1cffTfemap6OXItq5GQvlrjrb5/N/ZOv93OmeL+T/sdNp2/j9p n1Tz/79Bdei8djzvoja8LOGy6Mj3b4MudOp0lQEzNRb8bzfn+xIE7JbFBwMMJF3UqrtXR30Eb1Rz rgIS6IAGs/Ovjn1bT7Mo4aReYGY9mPrTdvBocJxkMDL4Musip+H5RoTPNiJ8nhE3dvwNXiQkTtW6 NcXEuc2e/HVuB2TClOExJ9iw0sg9dS3mA1HOBwnIyCytw5Byaf0qvfzZsr/1d1+jYcq/PZ8G95wc LUglFGxCJGWBtjtNANPQZJhNIqbqdtrfEvDnHf9/N+DhloCHbxDwLUf+pIjnup5XcVsi8jb2wHmR RYEET2wH+f8dq7yVv0J8IoqGadX7y5/D3fsvC3uyS2I/uug0HL6G/WUd+2XqddEvkq34EW70Y88Y 7+9HuJ8f4TY/wl1+7GxYD3viavEqtt9LejX42p8wWyP7nvxjMmu1Th1MPf/34ZjT+n543xzmQ03k CUEINwZhR9q8eBB24FWfPBVVVFFFFVVUUUUVVVRRRRVVVNH/l/4B1nCcvQAoAAA= --Boundary-00=_glFxL04kLcJl7l6--

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by mitroko＠gmail.com 13 Apr '10

13 Apr '10

--000e0ce0457c739d9a04841af395 Content-Type: text/plain; charset=UTF-8 http://www.openldap.org/doc/admin24/schema.html - Contains them, as well On Mon, Apr 12, 2010 at 10:10 PM, Howard Chu <hyc(a)symas.com> wrote: > mitroko(a)gmail.com wrote: > >> Full_Name: Dmitry Stremkouski >> Version: >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (95.84.189.132) >> >> >> Hello guys. The part of OpenLDAP Manual (wich can be found here - >> http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken >> links. >> Please correct. >> > > The 2.3 release is no longer maintained. This doc will not be updated. > > FE: http://www.alvestrand.no/harald/objectid/ - dead >> A: http://www.bsa-global.com/ - dead (doesn't look good enough for global >> OID >> authority) >> A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but >> futher, >> IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) >> >> Thanks. >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- <pre> (o_ - Dzmitry Stremkouski. //\ - cel: +7 (916) 090-85-68 V_/_- web: http://mitroko.com </pre> --000e0ce0457c739d9a04841af395 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <a href=3D"http://www.openldap.org/doc/admin24/schema.html">http://www.open= ldap.org/doc/admin24/schema.html</a> - Contains them, as well <div c= lass=3D"gmail_quote">On Mon, Apr 12, 2010 at 10:10 PM, Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> = wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href=3D"mailto= :mitroko@gmail.com" target=3D"_blank">mitroko(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Dmitry Stremkouski Version: OS: GNU/Linux URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (95.84.189.132) Hello guys. The part of OpenLDAP Manual (wich can be found here - <a href=3D"http://www.openldap.org/doc/admin23/schema.html" target=3D"_blan= k">http://www.openldap.org/doc/admin23/schema.html</a>) contains a lot of b= roken links. Please correct. </blockquote> The 2.3 release is no longer maintained. This doc will not be updated. <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> FE: <a href=3D"http://www.alvestrand.no/harald/objectid/" target=3D"_blank"= >http://www.alvestrand.no/harald/objectid/</a> - dead A: <a href=3D"http://www.bsa-global.com/" target=3D"_blank">http://www.bsa-= global.com/</a> - dead (doesn't look good enough for global OID authority) A: <a href=3D"http://www.iana.org/cgi-bin/enterprise.pl" target=3D"_blank">= http://www.iana.org/cgi-bin/enterprise.pl</a> - should be (redirect, but fu= ther, IMHO, will be dead, try <a href=3D"http://pen.iana.org/pen/PenApplication.p= age" target=3D"_blank">http://pen.iana.org/pen/PenApplication.page</a>) Thanks. </blockquote> -- =C2=A0-- Howard Chu =C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> -- <pre> (o_ - Dz= mitry Stremkouski. //\ - cel: +7 (916) 090-85-68 V_/_- web: <a href= =3D"http://mitroko.com">http://mitroko.com</a> </pre> --000e0ce0457c739d9a04841af395--

1 0

(ITS#6518) Slapd-ldap proxy between replica and mirror
by udorta＠iac.es 13 Apr '10

13 Apr '10

Full_Name: Ubay Dorta Version: 2.4.21 OS: Suse Linux Enterprise Server 10 SP2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.72.9.46) We have problems when we introduce a back-ldap proxy server between a delta-syncrepl server and a mirror configuration of two servers. The modifications through the replica server (with chaining configuration) over the first mirror server are made without problems. The problem appears when we introduce a back-ldap proxy between replica and the two servers in mirror mode. First Scenario: --------------------- A delta syncrepl server replicating from the first server of a mirror. IPs: delta syncrepl (192.168.1.5), mirror server 1 (192.168.1.10), mirror server 2 (192.168.1.20) replica slapd.conf ##################### # Chaining configuration # ##################### overlay chain chain-uri "ldap://mirror1:389" chain-idassert-bind bindmethod="simple" binddn="cn=replicator,dc=example,dc=com" credentials="secret" mode="self" chain-return-error TRUE ########## # Replica # ########## database bdb suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_forward_updates ppolicy_hash_cleartext overlay memberof ################## # Syncrepl directives # ################## syncrepl rid=001 provider=ldap://mirror1:389 type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=on binddn="cn=replicator,dc=example,dc=com" bindmethod=simple credentials=secret sizelimit=unlimited logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog # Refer updates to the master updateref ldap://mirror1:389 ------------------------- ------------------------- slapd.conf of mirror server #1 ------------------------------------------- # Global section serverID 1 moduleload memberof access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by dn.base="cn=replicator,dc=example,dc=com" read by * auth access to attrs=shadowLastChange by self write by * read # Give the replica DN unlimited read access. This ACL needs to be # merged with other ACL statements, and/or moved within the scope # of a database. The "by * break" portion causes evaluation of # subsequent rules. See slapd.access(5) for details. access to * by dn.base="cn=replicator,dc=example,dc=com" read by * break access to * by * read # Load the accesslog overlay moduleload accesslog.la #Load the syncprov overlay moduleload syncprov.la # Accesslog database definitions database bdb monitoring off suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ####################################################################### # BDB database definitions ####################################################################### database bdb monitoring off suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_hash_cleartext overlay memberof # Habilitar authz-policiy authz-policy to index entryCSN eq index entryUUID eq # syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #################################################### # MirrorMode - Syncrepl directive syncrepl rid=001 provider=ldap://mirror2:389 bindmethod=simple binddn="cn=Administrator,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on --------------- --------------- In the mirror servers we have set the attribute authzTo for the replicator dn: ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D 'cn=Administrator,dc=example,dc=com' -w secret authzTo # replicator, example.com dn: cn=replicator,dc=example,dc=com authzTo: ldap:///dc=example,dc=com??sub?(objectClass=person) When we launch the following modification through the replica: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=example,dc=com" In the mirror server we get: ldap-mirror1[2649]: conn=1002 op=2 PROXYAUTHZ dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD attr=userPassword ldap-mirror1[2649]: conn=1002 op=2 RESULT tag=103 err=0 text= Therefore modifying through the replica server is possible with the chaining configuration. Second sceneario -------------------------- The problem appears when we introduce the back-ldap proxy server to set the high availability feature that provides the mirror mode. IPs: ----- 192.168.1.5 -> delta syncrepl 192.168.1.10 -> Back-ldap proxy 192.168.1.20 -> Mirror mode server 1 192.168.1.30 -> Mirror mode server 2 back-ldap proxy slapd.conf: database ldap suffix "dc=example,dc=com" uri "ldap://mirror1:389 ldap://mirror2:389" rootdn "cn=Administrator,dc=example,dc=com" overlay ppolicy Launching the modification to the proxy, it works: ldapmodify -x -H ldap://proxy:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=udg77530,ou=people,dc=example,dc=com" The /var/log/messages of proxy and mirror shows the following: ldap-proxy[4051]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:42921 (IP=192.168.1.10:389) ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1015 fd=19 ACCEPT from IP=192.168.1.10:18103 (IP=192.168.1.20:1389) ldap-mirror1[3438]: conn=1015 op=0 BIND dn="" method=128 ldap-mirror1[3438]: conn=1015 op=0 RESULT tag=97 err=0 text= ldap-mirror1[3438]: conn=1015 op=1 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 fd=20 ACCEPT from IP=192.168.1.10:18104 (IP=192.168.1.20:1389) ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1016 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1015 op=2 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[4051]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-proxy[4051]: conn=1000 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1015 op=3 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[3438]: conn=1016 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1016 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=2 UNBIND ldap-mirror1[3438]: conn=1016 op=2 UNBIND ldap-mirror1[3438]: conn=1016 fd=20 closed ldap-proxy[4051]: conn=1000 fd=8 closed But when the modification is made through the replica server we get the error: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=rexample,dc=com" ldap_modify: unknown result code (123) ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: 12r ldap-proxy[3688]: ldap-proxy[3688]: daemon: read active on 12 ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap-proxy[3688]: connection_get(12) ldap-proxy[3688]: connection_get(12): got connid=1001 ldap-proxy[3688]: connection_read(12): checking for input on id=1001 ldap-proxy[3688]: op tag 0x66, time 1271064513 ldap-proxy[3688]: conn=1001 op=2 do_modify ldap-proxy[3688]: conn=1001 op=2 do_modify: dn (uid=user,ou=people,dc=example,dc=com) ldap-proxy[3688]: => get_ctrls ldap-proxy[3688]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical) ldap-proxy[3688]: parseProxyAuthz: conn 1001 authzid="dn:uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: slap_sasl_getdn: conn 1001 id=dn:uid=user,ou=people,dc=example,dc=com [len=38] ldap-proxy[3688]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: ==>slap_sasl2dn: converting SASL name uid=user,ou=people,dc=example,dc=com to a DN ldap-proxy[3688]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[3688]: parseProxyAuthz: conn=1001 "uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[3688]: <== slap_sasl_authorized: return 48 ldap-proxy[3688]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" ldap-proxy[3688]: send_ldap_result: conn=1001 op=2 p=3 ldap-proxy[3688]: send_ldap_result: err=123 matched="" text="not authorized to assume identity" ldap-proxy[3688]: send_ldap_response: msgid=3 tag=103 err=123 ldap-proxy[3688]: conn=1001 op=2 RESULT tag=103 err=123 text=not authorized to assume identity ldap-proxy[3688]: conn=1001 op=2 do_modify: get_ctrls failed ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL The file pass1_user.ldif has: dn: uid=user,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: ####CRYPT PASSWORD#### Thanks

1 0

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> richm(a)stanfordalumni.org wrote: >>>> This is most likely related to my recent LDIF changes. But I didn't >>>> see >>>> this problem. What platform is this? What build flags are you using? >>> >>> Built fine here too, looks like an inconsistent build tree over there. >> >> The build with the same build flags on the very same system worked right >> before the recent libldif check-ins. I'm using anon CVS pserver for cvs >> up. > > The anon CVS server has some lag in receiving updates from the master > server. > Don't you have an account on the master? Actually it's not that; Michael routinely builds with --enable-dynamic, and libldap now (dynamically) depends on liblutil for the LDIF part. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

masarati(a)aero.polimi.it wrote: >>>> Sorry about that. You can find it here: >>>> http://rmeggins.fedorapeople.org/ldifutil.c >>>> >>> Gotit, thanks. I have one first comment: the public API does not >>> generally expose the memory context. I'm renaming >>> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating >>> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. >>> >> tested and applied to HEAD; please test. Thanks, p. >> > > More comments: > > 1) perhaps it may be worth providing a function that converts a LDIFRecord > structure into a string, and one that sends it to a stream > For debugging purposes, or something like that? > 2) I note you put > > LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY, > LDAP_REQ_ADD */ > struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, > LDAP_REQ_RENAME */ > struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, > LDAP_REQ_RENAME */ > int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, > LDAP_REQ_RENAME */ > /* the following are for future support */ > struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */ > struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */ > struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */ > struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */ > > in the structure; the last four are not used right now. I think it would > make sense to group struct members by op in substructures, and then put > them in a union, to stress the fact that they're mutually exclusive. Much > like Howard did for the corresponding substructures in the Operation > struct in slapd. > Please check out this patch - ftp://ftp.openldap.org/incoming/openldap-2.4.21-ldifrecord-union-20100412.p… > p. > > > > >

1 0

Re: (ITS#6517) undefined references to ldif_*
by hyc＠symas.com 12 Apr '10

12 Apr '10

Michael Ströder wrote: > hyc(a)symas.com wrote: >> richm(a)stanfordalumni.org wrote: >>> This is most likely related to my recent LDIF changes. But I didn't see >>> this problem. What platform is this? What build flags are you using? >> >> Built fine here too, looks like an inconsistent build tree over there. > > The build with the same build flags on the very same system worked right > before the recent libldif check-ins. I'm using anon CVS pserver for cvs up. The anon CVS server has some lag in receiving updates from the master server. Don't you have an account on the master? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6517) undefined references to ldif_*
by michael＠stroeder.com 12 Apr '10

12 Apr '10

hyc(a)symas.com wrote: > richm(a)stanfordalumni.org wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: >>> Version: HEAD >>> OS: Linux >>> URL: >>> Submission from: (NULL) (84.163.96.140) >>> >>> >>> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o >>> .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib >>> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so >>> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so >>> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv >>> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to >>> `ldif_countlines' >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to >>> `ldif_parse_line2' >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' >>> collect2: ld returned 1 exit status >>> make[2]: *** [ldapurl] Error 1 >>> make[2]: Leaving directory >>> `/usr/src/michael/openldap/HEAD/openldap/clients/tools' >>> make[1]: *** [all-common] Error 1 >>> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' >>> make: *** [all-common] Error 1 >>> >>> >> This is most likely related to my recent LDIF changes. But I didn't see >> this problem. What platform is this? What build flags are you using? > > Built fine here too, looks like an inconsistent build tree over there. The build with the same build flags on the very same system worked right before the recent libldif check-ins. I'm using anon CVS pserver for cvs up. Ciao, Michael.

1 0

Re: (ITS#6517) undefined references to ldif_*
by hyc＠symas.com 12 Apr '10

12 Apr '10

richm(a)stanfordalumni.org wrote: > michael(a)stroeder.com wrote: >> Full_Name: >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (84.163.96.140) >> >> >> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o >> .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib >> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so >> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so >> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv >> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib >> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' >> ../../libraries/libldap/.libs/libldap.so: undefined reference to >> `ldif_countlines' >> ../../libraries/libldap/.libs/libldap.so: undefined reference to >> `ldif_parse_line2' >> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' >> collect2: ld returned 1 exit status >> make[2]: *** [ldapurl] Error 1 >> make[2]: Leaving directory >> `/usr/src/michael/openldap/HEAD/openldap/clients/tools' >> make[1]: *** [all-common] Error 1 >> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' >> make: *** [all-common] Error 1 >> >> > This is most likely related to my recent LDIF changes. But I didn't see > this problem. What platform is this? What build flags are you using? Built fine here too, looks like an inconsistent build tree over there. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (84.163.96.140) > > > cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o > .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib > ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so > /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so > ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv > -Wl,--rpath -Wl,/opt/openldap-HEAD/lib > ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' > ../../libraries/libldap/.libs/libldap.so: undefined reference to > `ldif_countlines' > ../../libraries/libldap/.libs/libldap.so: undefined reference to > `ldif_parse_line2' > ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' > collect2: ld returned 1 exit status > make[2]: *** [ldapurl] Error 1 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/clients/tools' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' > make: *** [all-common] Error 1 > > This is most likely related to my recent LDIF changes. But I didn't see this problem. What platform is this? What build flags are you using?

1 0

(ITS#6517) undefined references to ldif_*
by michael＠stroeder.com 12 Apr '10

12 Apr '10

Full_Name: Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.96.140) cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv -Wl,--rpath -Wl,/opt/openldap-HEAD/lib ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_countlines' ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_parse_line2' ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' collect2: ld returned 1 exit status make[2]: *** [ldapurl] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients/tools' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' make: *** [all-common] Error 1

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by hyc＠symas.com 12 Apr '10

12 Apr '10

mitroko(a)gmail.com wrote: > Full_Name: Dmitry Stremkouski > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.84.189.132) > > > Hello guys. The part of OpenLDAP Manual (wich can be found here - > http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken > links. > Please correct. The 2.3 release is no longer maintained. This doc will not be updated. > FE: http://www.alvestrand.no/harald/objectid/ - dead > A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID > authority) > A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, > IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) > > Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> They need to use ordered_value_*() functions instead. Fixed in HEAD. p.

1 0

(ITS#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando They need to use ordered_value_*() functions instead. A patch is coming. p.

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

>> Full_Name: Peter Marschall >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch >> Submission from: (NULL) (94.217.135.20) >> >> >> Hi, >> >> Playing around with dynacl/aci a bit I cam across the following issue: >> >> Searches that do not contain the attribute OpenLDAPaci in the list of >> attribues >> queried, omit objects. > > dynacl/aci (as the original aci code it's based on) relies on the fact > that the entry is complete. This is the case when the entry is stored > locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to > retrieve operational attributes. Please note that in the latter case, > even ACL rules based on, say, createTimestamp or so would operate > incorrectly. > > My guess is that you're trying to use ACIs with a non-local storage. In > that case your analysis is correct. Can you provide your (sanitized) > configuration? > > The "right" solution is much more general, not only related to dynacl. > Slapd needs to know in advance what (operational) attributes are required > for policy enforcing, and they need to be added to requested attrs when > entries are collected from remote storage. Your patch seems to fix your > specific need, but it is clearly inefficient. Automatically detecting what attributes need to be added to requests for proxying sounds like an overkill. Probably, a reasonable workaround could be to add a configuration directive that lists what attributes need to be added to requests. This directive should be honored by proxy backends and in general by all those backends that do not pass back complete entries to the frontend. In the case of proxy backends its use would be straightforward, since requested attrs need to be mapped anyway in the request. Adding some more would not be a big deal. Things might be a bit more complicated in case of, say, special configurations like proxycache, where ACIs would need to be added to all attribute templates, and so. Yet another reason to avoid ACIs :) p.

1 0

Re: (ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> Full_Name: Thomas Wunder > Version: 2.4.17 > OS: debian sqeueeze amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.13.106.69) I don't see a clear evidence of a bug. Software usage questions must be directed to the openldap-software list. Moreover, I just tried your verbatim configuration with the most recent code (while you're using an older release), and it seems to work as expected. This ITS will be closed. p. > I'm currently using the rwm overlay to filter the objects from my > ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and > project > the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de > Therefore I use the following section within my slapd.conf (before the > "database > hdb..." section): > > database relay > suffix > "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" > overlay rwm > #rwm-rewriteEngine on > rwm-suffixmassage > "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" > > "ou=students,dc=uni-bamberg,dc=de" > rwm-rewriteContext bindDN > rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" > rwm-rewriteContext searchFilter > rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" > > searchFilter rewriting works perfectly but I also need to rewrite the > bindDN as > every operation within ou=students,dc=uni-bamberg,dc=de needs to be > carried out > by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) > (the reason is that i don't want any user other than ldapadmin to be able > to > write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy > entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) > according to the logs and the error reply messages there seems to be no > binndn > rewriting done... > It looks like the rule never matches. > Is my rule not general enough to match each possible bindDN-String? Is > "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) > not well > formatted (does it expect something else)? Does the overlay "relay" > prevent the > replacement of the bindDN? > > As you can see I don't have any idea what might be causing my problem and > I hope > you can help me. > > >

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 12 Apr '10

12 Apr '10

Le 08/04/2010 19:26, masarati(a)aero.polimi.it a écrit : >> Ah yes, just saw this. Sorry, my email seems to be slow today (weird). >> >> Similar to my patch, but I'm unsure about the second part: >> >> } else if ( op->o_bd != gi->gi_n[0].gn_be ) { >> /* if cookie not empty, it's again this database's turn */ >> op->o_conn->c_pagedresults_state.ps_be = op->o_bd; >> } >> >> If the cookie is not empty, then it should again be this database's >> turn, even it this is this last database. >> >> This makes a search that stops in the middle of results from last >> database with a valid cookie fall back to the first database on >> continuation, and thus loop forever. >> >> Would you consider removing the else if? > > Well, it's not that simple. The fact is that paged results state is being > handled in two ways: when the database is back-bdb/hdb, the cookie is an > ID, and it's stored in ps_cookie; otherwise (e.g. back-ldap), it's a > berval, stored in ps_cookieval. I need to handle both cases. I think I > made it. > > Now, ps_cookie in c_pagedresults_state is initialized to NOID; back-bdb > will set it to 0 first, and then to whatever value it needs. Other > backends, that use ps_cookieval, will not touch it. So when ps_cookie == > NOID one needs to look at ps_cookieval (and parse it as needed), otherwise > ps_cookie suffices. You'll need to update backglue.c, controls.c and > back-bdb/search.c. > > Now it passes all cases I checked, both with local glued databases and > with back-null/back-ldap as in your example. Right - I'd missed that, regarding this difference between hdb/bdb databases and others. Thanks for the explanation! Just tested your lasted patch set, and it all works great for me, in various different scenarios. Thanks a lot. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: > >> Any update on this? >> > > Sorry I must've missed your last reply, I thought we were still waiting on you. > > Why is pem_mod_name needed as an independent variable? Since it's const I > presume it will not be changing in the future? > I guess it doesn't really matter. It may change if the PEM module decides to change its name, but that is not likely. > (Not asking for a change here, just want to understand its purpose.) > > Actually, since it and pem_library are only used once each, I would probably > just #define it instead. But again, just want to know first how constant it > really is. > See above - it doesn't matter to me either, it could be #define'd or even hard coded in the module init string. Just let me know. > I've committed the patch as-is. If any other tweaks are needed let us know. > Thanks for working on this. > Thanks!

1 0

(ITS#6515) A lot of dead links on main page of OpenLDAP man.
by mitroko＠gmail.com 12 Apr '10

12 Apr '10

Full_Name: Dmitry Stremkouski Version: OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.84.189.132) Hello guys. The part of OpenLDAP Manual (wich can be found here - http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken links. Please correct. FE: http://www.alvestrand.no/harald/objectid/ - dead A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID authority) A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) Thanks.

1 0

(ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by thomas.wunder＠swt-bamberg.de 12 Apr '10

12 Apr '10

Full_Name: Thomas Wunder Version: 2.4.17 OS: debian sqeueeze amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.13.106.69) Hi! I'm currently using the rwm overlay to filter the objects from my ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and project the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de Therefore I use the following section within my slapd.conf (before the "database hdb..." section): database relay suffix "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" overlay rwm #rwm-rewriteEngine on rwm-suffixmassage "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" "ou=students,dc=uni-bamberg,dc=de" rwm-rewriteContext bindDN rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" searchFilter rewriting works perfectly but I also need to rewrite the bindDN as every operation within ou=students,dc=uni-bamberg,dc=de needs to be carried out by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) (the reason is that i don't want any user other than ldapadmin to be able to write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) according to the logs and the error reply messages there seems to be no binndn rewriting done... It looks like the rule never matches. Is my rule not general enough to match each possible bindDN-String? Is "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) not well formatted (does it expect something else)? Does the overlay "relay" prevent the replacement of the bindDN? As you can see I don't have any idea what might be causing my problem and I hope you can help me.

1 0

Re: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by hyc＠symas.com 11 Apr '10

11 Apr '10

bcolston(a)xtec.com wrote: > Provider slapd configuration (partial): > serverID 000 > database bdb > suffix "dc=authentx" > rootdn "SUPPRESSED" > rootpw SUPPRESSED > directory /authentx/db/ldap/authentx-sync1 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 5000 This patch will probably work: diff -u -r1.309 syncprov.c --- syncprov.c 21 Jan 2010 12:33:21 -0000 1.309 +++ syncprov.c 12 Apr 2010 01:33:02 -0000 @@ -1878,7 +1878,7 @@ } /* Add any log records */ - if ( si->si_logs && op->o_tag != LDAP_REQ_ADD ) { + if ( si->si_logs ) { syncprov_add_slog( op ); } leave: ldap_pvt_thread_mutex_unlock( &si->si_resp_mutex ); But I have not tested it. The session log was originally only intended to record deletes, since they require the most work to find otherwise. Recording adds is just a shortcut since the original behavior works as designed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6498) SLAPI functions missing
by hyc＠symas.com 11 Apr '10

11 Apr '10

maci(a)satgnu.net wrote: > Full_Name: Marcel Wysocki > Version: 2.4.21 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.79.126.162) > > > I noticed that all of the SLAPI functions do manipulate LDAPMod** are missing. > from the fedora ds slapi-plugin.h: > there might be some more missing. most of it can be found in fedora ds's > modutils.c > should be worth porting to openldap Patches welcome. If you're suggesting a copy/paste from FedoraDS's code then the patch must be submitted by someone who has ownership rights on the Fedora code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6483) [PATCH] Properly use #elif
by hyc＠symas.com 11 Apr '10

11 Apr '10

delphij(a)FreeBSD.org wrote: > Full_Name: Xin LI > Version: -HEAD > OS: FreeBSD/amd64 > URL: http://people.freebsd.org/~delphij/misc/openldap-elif.diff > Submission from: (NULL) (206.40.55.65) > > > OpenLDAP uses several #elif to test if a macro is being defined, which should be > spelled as #elif defined. > > Here is a patch against CVS -HEAD. > > Index: include/ac/regex.h > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v > retrieving revision 1.20 > diff -u -p -u -p -r1.20 regex.h > --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 > +++ include/ac/regex.h 1 Mar 2010 20:12:52 -0000 > @@ -28,7 +28,7 @@ > */ > #error "No POSIX REGEX available." > > -#elif HAVE_GNUREGEX_H > +#elif defined(HAVE_GNUREGEX_H) > /* system has GNU gnuregex.h */ > # include<gnuregex.h> > #else That patch is incorrect. Autoconf HAVE_xx macros must be defined to 1 to actually be used, some scripts may also define them to 0. The current test is correct. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by hyc＠symas.com 11 Apr '10

11 Apr '10

crispy(a)cluenet.org wrote: > Hi, any word on if this can be incorporated? Committed in HEAD, thanks for the patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

>> >>> Sorry about that. You can find it here: >>> http://rmeggins.fedorapeople.org/ldifutil.c >> >> Gotit, thanks. I have one first comment: the public API does not >> generally expose the memory context. I'm renaming >> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating >> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. > > tested and applied to HEAD; please test. Thanks, p. More comments: 1) perhaps it may be worth providing a function that converts a LDIFRecord structure into a string, and one that sends it to a stream 2) I note you put LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY, LDAP_REQ_ADD */ struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ /* the following are for future support */ struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */ struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */ struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */ struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */ in the structure; the last four are not used right now. I think it would make sense to group struct members by op in substructures, and then put them in a union, to stress the fact that they're mutually exclusive. Much like Howard did for the corresponding substructures in the Operation struct in slapd. p.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 11 Apr '10

11 Apr '10

rmeggins(a)redhat.com wrote: > Any update on this? Sorry I must've missed your last reply, I thought we were still waiting on you. Why is pem_mod_name needed as an independent variable? Since it's const I presume it will not be changing in the future? (Not asking for a change here, just want to understand its purpose.) Actually, since it and pem_library are only used once each, I would probably just #define it instead. But again, just want to know first how constant it really is. I've committed the patch as-is. If any other tweaks are needed let us know. Thanks for working on this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> >> Sorry about that. You can find it here: >> http://rmeggins.fedorapeople.org/ldifutil.c > > Gotit, thanks. I have one first comment: the public API does not > generally expose the memory context. I'm renaming > ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating > the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. tested and applied to HEAD; please test. Thanks, p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> Sorry about that. You can find it here: > http://rmeggins.fedorapeople.org/ldifutil.c Gotit, thanks. I have one first comment: the public API does not generally expose the memory context. I'm renaming ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by richm＠stanfordalumni.org 11 Apr '10

11 Apr '10

On Sun, Apr 11, 2010 at 10:07 AM, <masarati(a)aero.polimi.it> wrote: >> Full_Name: Rich Megginson >> Version: CVS HEAD (2.4.21+) >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api= -20100409.patch > > Rich, > > ldifutil.c seems to be missing in that file. =A0Can you provide it? =A0Ei= ther > a separate file, or a new version of the patch is fine. Sorry about that. You can find it here: http://rmeggins.fedorapeople.org/ldifutil.c > > Thanks, p. > > >> This patch allows liblutil to provide the LDIF reading and writing >> functions as >> public APIs in a libldif, and exposes ldif.h to the public API. =A0This >> patch also creates >> a new LDAP API for parsing raw LDIF records into higher level LDAP >> structures >> such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes >> ldapmodify.c to use the new API. >> >> =A0 =A0 This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not >> assigned rights and/or interest in this work to any party. I, Richard >> Megginson am authorized by Red Hat, Inc., my employer, to release this >> work under the following terms. >> >> =A0 =A0 Red Hat, Inc. hereby place the following modifications to OpenLD= AP >> Software (and only these modifications) into the public domain. Hence, >> these modifications may be freely used and/or redistributed for any >> purpose with or without attribution and/or other notice. >> >> >> >> >> > > > > > > >

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> Full_Name: Peter Marschall > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch > Submission from: (NULL) (94.217.135.20) > > > Hi, > > Playing around with dynacl/aci a bit I cam across the following issue: > > Searches that do not contain the attribute OpenLDAPaci in the list of > attribues > queried, omit objects. dynacl/aci (as the original aci code it's based on) relies on the fact that the entry is complete. This is the case when the entry is stored locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to retrieve operational attributes. Please note that in the latter case, even ACL rules based on, say, createTimestamp or so would operate incorrectly. My guess is that you're trying to use ACIs with a non-local storage. In that case your analysis is correct. Can you provide your (sanitized) configuration? The "right" solution is much more general, not only related to dynacl. Slapd needs to know in advance what (operational) attributes are required for policy enforcing, and they need to be added to requested attrs when entries are collected from remote storage. Your patch seems to fix your specific need, but it is clearly inefficient. p.

1 0

(ITS#6513) dynacl/aci fails on searches with attributes
by peter＠adpm.de 11 Apr '10

11 Apr '10

Full_Name: Peter Marschall Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch Submission from: (NULL) (94.217.135.20) Hi, Playing around with dynacl/aci a bit I cam across the following issue: Searches that do not contain the attribute OpenLDAPaci in the list of attribues queried, omit objects. E.g. doing a base search for 1.1 on an object that has the following OpenDLAPaci value OpenLDAPaci: 0#entry#grant;r,c,s,d,x;[entry]#public# OpenLDAPaci: 0#entry#grant;r,c,s,d,x;[all]#public# (no superior object has a subtree OpenLDAPaci) does not return the DN of the object, while doing the search without arguments returns the DN. According to my experiments, it looks like the Entry *e passed as argument to dynacl_aci_mask() does not have OpenLDAPaci in its e->e_attrs. I wrote the patch ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch to verify my suspicions, and it seems to help, although at the cost of abysmally bad performance. I guess there are better ways to fix the issue (e.g. "auto-adding" OpenLDAPaci to the attributes queried from the backend and stripping it before giving it back to the client), but my knowledge of the internal workings of OpenLDAP is too limited.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> Full_Name: Rich Megginson > Version: CVS HEAD (2.4.21+) > OS: Fedora > URL: > ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20… Rich, ldifutil.c seems to be missing in that file. Can you provide it? Either a separate file, or a new version of the patch is fine. Thanks, p. > This patch allows liblutil to provide the LDIF reading and writing > functions as > public APIs in a libldif, and exposes ldif.h to the public API. This > patch also creates > a new LDAP API for parsing raw LDIF records into higher level LDAP > structures > such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes > ldapmodify.c to use the new API. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not > assigned rights and/or interest in this work to any party. I, Richard > Megginson am authorized by Red Hat, Inc., my employer, to release this > work under the following terms. > > Red Hat, Inc. hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. > > > > >

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by patrice.moreaux＠univ-savoie.fr 10 Apr '10

10 Apr '10

Dear Quanah, Thank you very much for your so fast answer. > OpenLDAP has not yet been tested with BDB 5.0. Ok, so I will use the 4.x last version of BDB. I think that in the configure script, the major version number of BDB is more or less "hard coded" as "4". This could perhaps help your team! bets regards Patrice ______________________________________________________ Patrice Moreaux, Professor email: patrice.moreaux(a)univ-savoie.fr LISTIC - Polytech Annecy-Chambéry - University of Savoie BP 80439, 74944 Annecy le Vieux Cedex, France. Phone: (+33/0) 450 096 524 - Fax: (+33/0) 450 096 559 ______________________________________________________

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by patrice.moreaux＠univ-savoie.fr 10 Apr '10

10 Apr '10

Dear Howard, Thank you very much for your answer. > quanah(a)zimbra.com wrote: >> --On Friday, April 09, 2010 11:25 PM +0000 patrice.moreaux(a)univ-savoie.fr >>> Submission from: (NULL) (193.48.130.254) >> OpenLDAP has not yet been tested with BDB 5.0. >> --Quanah > > The ITS is for legitimate bug reports, not help requests. There's no > reason OpenLDAP won't work with BDB 5.0, but this question belongs on > the -software mailing list, not the ITS. Please, excuse me for my mistake. I am in fact a new user of the OpenLDAP server. I will post on the software mailing list. Please also note that I have erroneously posted a new item in the FAQ! It will be fine is somebody of the OpenLDAP staff could discard it. Best regards, Patrice Moreaux ______________________________________________________ Patrice Moreaux, Professor email: patrice.moreaux(a)univ-savoie.fr LISTIC - Polytech Annecy-Chambéry - University of Savoie BP 80439, 74944 Annecy le Vieux Cedex, France. Phone: (+33/0) 450 096 524 - Fax: (+33/0) 450 096 559 ______________________________________________________

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by hyc＠symas.com 09 Apr '10

09 Apr '10

quanah(a)zimbra.com wrote: > --On Friday, April 09, 2010 11:25 PM +0000 patrice.moreaux(a)univ-savoie.fr > wrote: > >> Full_Name: Patrice Moreaux >> Version: 2.4.21 >> OS: Ubuntu Lucid server 32bits >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.48.130.254) > > OpenLDAP has not yet been tested with BDB 5.0. > > --Quanah The ITS is for legitimate bug reports, not help requests. There's no reason OpenLDAP won't work with BDB 5.0, but this question belongs on the -software mailing list, not the ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> We managed to install it with debug-symbols now, > but did not have a new crash (yet). > > However we did a deeper anaylysis of existing > crashes. > Here is the outcome: [snip] > (gdb) thread 1 > [Switching to thread 1 (process 17895)]#0 0x00000037a4e30045 in raise () > f= > rom /lib64/libc.so.6 > (gdb) bt > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 > #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 > #3 0x00000037a4e6f444 in _int_free () from /lib64/libc.so.6 > #4 0x00000037a4e72a6c in free () from /lib64/libc.so.6 > #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at > ../= > ../../libraries/liblber/sockbuf.c:606 I still see some inconsistencies: in sockbuf.c there's no call to free() at line 606. So, either the core is inconsistent, or slapd was linking an incorrect liblber, if at all possible. Not sure how to proceeding in debugging this issue. p.

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by quanah＠zimbra.com 09 Apr '10

09 Apr '10

--On Friday, April 09, 2010 11:25 PM +0000 patrice.moreaux(a)univ-savoie.fr wrote: > Full_Name: Patrice Moreaux > Version: 2.4.21 > OS: Ubuntu Lucid server 32bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.48.130.254) OpenLDAP has not yet been tested with BDB 5.0. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6512) configure error - BerkeleyDB 5.0 problem?
by patrice.moreaux＠univ-savoie.fr 09 Apr '10

09 Apr '10

Full_Name: Patrice Moreaux Version: 2.4.21 OS: Ubuntu Lucid server 32bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.48.130.254) Date: 2010/04/06 I installed BerkeleyDB 5.0. Running configure for OpenLDAP 2.4.21 1. BDB 5.0 header is correcty read (major=5, minor=0) 2. However I got then: -------------------------------------------------------- checking if BerkeleyDB version supported by BDB/HDB backends... yes checking for BerkeleyBD link (default)... no configure: error: BDB/HDB: BerkeleyDB not available -------------------------------------------------------- I set the paths for libs and includes. I don't know where is the problem. Could you help me, please? Thank you, regards.

1 0

Re: (ITS#6244) "now" dynacl module
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

I've uploaded a README with a simple example. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-09-README.now> p.

1 0

Re: (ITS#6456) Feature Request
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Greetings, > > Having found out this doesn't already exist as another parameter or > configuration method, I am hereby submitting a request for a particular > feature. > > When performing idassert-bind operations, such as with back_ldap, it would > be > great if an option could be added which would allow specific matched > client DNs > to be matched and asserted as usual (e.g: the anonymous user asserting to > a > backend "proxyauthenticator" account) .... while other clients (flagged > somehow) > would pass-through as themselves. > > Example (as I might do it for my purposes): > > idassert-bind > bindmethod="simple" > binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" > credentials="password_string" > starttls="yes" > tls_reqcert="never" > mode="none" > > # anonymous clients will assert as "proxyauthenticator", since the backend > may > not allow anonymous binds. > idassert-authzFrom "dn.exact:" > > # this guy will pass through as himself to the backend, as-is. > idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" > > This would be really helpful, not sure if its difficult to implement ... This is now implemented in back-ldap (idassert-passthru, olcDbIDAssertPassThru, undocumented yet). Basically, identities matching rules formally identical to those of idassert-authzFrom do not undergo identity assertion. This rule is checked before idassert-authzFrom, so in case an identity matches both, passthru wins. Please test and report. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Full_Name: Rich Megginson > Version: CVS HEAD (2.4.21+) > OS: Fedora > URL: > ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20… > > This patch allows liblutil to provide the LDIF reading and writing > functions as > public APIs in a libldif, and exposes ldif.h to the public API. This > patch also creates > a new LDAP API for parsing raw LDIF records into higher level LDAP > structures > such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes > ldapmodify.c to use the new API. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not > assigned rights and/or interest in this work to any party. I, Richard > Megginson am authorized by Red Hat, Inc., my employer, to release this > work under the following terms. > > Red Hat, Inc. hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. Kurt, if you give IPR clearance I can start (evaluating and) integrating this. p.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 09 Apr '10

09 Apr '10

Any update on this?

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 09 Apr '10

09 Apr '10

Full_Name: Rich Megginson Version: CVS HEAD (2.4.21+) OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20… This patch allows liblutil to provide the LDIF reading and writing functions as public APIs in a libldif, and exposes ldif.h to the public API. This patch also creates a new LDAP API for parsing raw LDIF records into higher level LDAP structures such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes ldapmodify.c to use the new API. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 09 Apr '10

09 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>> =20 >>>> Sounds like your servers are mis-configured, it is not legal to send = > a=3D20=3D >>> =20 >>>> referral in response to a Bind request. >>> =20 >>> I note that the technical specification doesn't actually preclude = > return =3D >>> of a referral in response to a Bind request. However, in practice, = > such =3D >>> return is quite problematic due to ambiguous semantics and security =3D= > >>> considerations. >> =20 >> Right. I can't find the discussion we had about this back in 2004, but = > certainly we've already hashed this out in great detail before. >> =20 >> The fact is that acting on a referral simply means performing a Bind = > against some other server. >> It does nothing for the authentication state of the session on the = > original server. > > Right, by returning a referral, regardless of how far the client got in = > authentication process (including completion of all challenges), the = > client is now anonymous at the original server. > > And there's a security concern, the referral information is not = > protected by the underlying authentication mechanism. It is actually = > quite possible that this be used by an attacker to cause the client to = > try authentication multiple times, possibly with chosen plaintext. > > I recommend that the library never chase bind referrals. Agreed. Patched in HEAD. > (I tend to = > think of rebind as a misfeature. Robust clients really should be using = > the async API and carefully managing security contexts and chasing.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by quanah＠zimbra.com 09 Apr '10

09 Apr '10

--On Friday, April 09, 2010 10:23 AM +0000 wilco(a)baanhofman.nl wrote: > Full_Name: Wilco Baan Hofman > Version: 2.4.11 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.82.223.18) Please don't file bug reports against ancient releases. The current stable release is OpenLDAP 2.4.21. If you can reproduce your issue using that release, then file an ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Behaviour: > Syncrepl stops working when the master server is temporarily unreachable > or > restarted. > > Expected behaviour: > Retrying to connect indefinatly, once every 10 to 30 seconds. > > Result: > This means we have to restart slapd every time there has been a slight > glitch in > the internet connection. I assume you did not read this <http://www.openldap.org/faq/data/cache/56.html> before filing the bug report. In any case, even assuming the behavior you report is caused by a bug (you are not providing any information that is vaguely useful to this extent), there has been substantial development since 2.4.11, specifically in the area of syncrepl. Unless the issue reproduces in the latest release, there is no point in even starting tracking it down. p.

1 0

(ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by wilco＠baanhofman.nl 09 Apr '10

09 Apr '10

Full_Name: Wilco Baan Hofman Version: 2.4.11 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.82.223.18) Hi, Behaviour: Syncrepl stops working when the master server is temporarily unreachable or restarted. Expected behaviour: Retrying to connect indefinatly, once every 10 to 30 seconds. Result: This means we have to restart slapd every time there has been a slight glitch in the internet connection. Regards, Wilco Baan Hofman

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 08 Apr '10

08 Apr '10

On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > Kurt(a)OpenLDAP.org wrote: >> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>=20 >>> Sounds like your servers are mis-configured, it is not legal to send = a=3D20=3D >>=20 >>> referral in response to a Bind request. >>=20 >> I note that the technical specification doesn't actually preclude = return =3D >> of a referral in response to a Bind request. However, in practice, = such =3D >> return is quite problematic due to ambiguous semantics and security =3D= >> considerations. >=20 > Right. I can't find the discussion we had about this back in 2004, but = certainly we've already hashed this out in great detail before. >=20 > The fact is that acting on a referral simply means performing a Bind = against some other server. > It does nothing for the authentication state of the session on the = original server. Right, by returning a referral, regardless of how far the client got in = authentication process (including completion of all challenges), the = client is now anonymous at the original server. And there's a security concern, the referral information is not = protected by the underlying authentication mechanism. It is actually = quite possible that this be used by an attacker to cause the client to = try authentication multiple times, possibly with chosen plaintext. I recommend that the library never chase bind referrals. (I tend to = think of rebind as a misfeature. Robust clients really should be using = the async API and carefully managing security contexts and chasing.) -- Kurt=

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 08 Apr '10

08 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > >> Sounds like your servers are mis-configured, it is not legal to send a=20= > >> referral in response to a Bind request. > > I note that the technical specification doesn't actually preclude return = > of a referral in response to a Bind request. However, in practice, such = > return is quite problematic due to ambiguous semantics and security = > considerations. Right. I can't find the discussion we had about this back in 2004, but certainly we've already hashed this out in great detail before. The fact is that acting on a referral simply means performing a Bind against some other server. It does nothing for the authentication state of the session on the original server. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 08 Apr '10

08 Apr '10

On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > Sounds like your servers are mis-configured, it is not legal to send a=20= > referral in response to a Bind request. I note that the technical specification doesn't actually preclude return = of a referral in response to a Bind request. However, in practice, such = return is quite problematic due to ambiguous semantics and security = considerations. -- Kurt

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 08 Apr '10

08 Apr '10

inlovewithGod(a)gmail.com wrote: > Full_Name: Jeremiah Martell > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.146.101.71) > > > I have three windows active directory servers setup: > childA.parent.example.com > parent.example.com > childB.parent.example.com > > I do a LDAP+GSSAPI bind to childA.parent.example.com. > The bind succeeds. > > I do a search that returns referrals, (I know I need to be referred to > parent, and then childB in order to find my result), > and I have openldap follow referrals for me. > > My rebind proc is a function that only calls: > ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, > LDAP_SASL_AUTOMATIC, sasl_driver, params ); > where sasl_driver and params is the same parameters that I used for > the initial bind call to childA. > > After the seach call, the debug looks like this: > >> ldap_chase_v3referrals, where ref[0] = parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > < ldap_sasl_interactive_bind_s > < myGSSAPIrebindProc > < ldap_chase_v3referrals > >> ldap_chase_v3referrals, where ref[0] = childB.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com > < ldap_chase_v3referrals > > ldap_chase_v3referrals, where ref[0] = > ForestDnsZones.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s ... HANG ON MUTEX > > I changed openldap to make all mutex's recursive, and this fixed my problem. I > was then able to search, chase referrals, bind to referrals with > ldap_sasl_interactive_bind_s, and eventually find my result. Sounds like your servers are mis-configured, it is not legal to send a referral in response to a Bind request. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> Ah yes, just saw this. Sorry, my email seems to be slow today (weird). > > Similar to my patch, but I'm unsure about the second part: > > } else if ( op->o_bd != gi->gi_n[0].gn_be ) { > /* if cookie not empty, it's again this database's turn */ > op->o_conn->c_pagedresults_state.ps_be = op->o_bd; > } > > If the cookie is not empty, then it should again be this database's > turn, even it this is this last database. > > This makes a search that stops in the middle of results from last > database with a valid cookie fall back to the first database on > continuation, and thus loop forever. > > Would you consider removing the else if? Well, it's not that simple. The fact is that paged results state is being handled in two ways: when the database is back-bdb/hdb, the cookie is an ID, and it's stored in ps_cookie; otherwise (e.g. back-ldap), it's a berval, stored in ps_cookieval. I need to handle both cases. I think I made it. Now, ps_cookie in c_pagedresults_state is initialized to NOID; back-bdb will set it to 0 first, and then to whatever value it needs. Other backends, that use ps_cookieval, will not touch it. So when ps_cookie == NOID one needs to look at ps_cookieval (and parse it as needed), otherwise ps_cookie suffices. You'll need to update backglue.c, controls.c and back-bdb/search.c. Now it passes all cases I checked, both with local glued databases and with back-null/back-ldap as in your example. p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

Le 08/04/2010 15:59, masarati(a)aero.polimi.it a écrit : >> Just one weird case left. Considering the same setup as described above >> (back null with 2 back ldap glued underneath): a search with pagedResults >> and a page size of 3 (the exact number of results returned by each back >> ldap), we get: >> - a first page with the 3 results from back ldap 1 >> - a second page with 3 results from back ldap 2 (so far, so good) >> - but then this last result also has a pagedResults cookie, and the search >> can go on and on, returning the same 2nd page. >> >> Presumably this is related to the patch allowing pagedResults to cross two >> databases. If the first returns an empty cookie (no more results), a new >> cookie is added. However, this should not be done if the last database >> returns no more results. > > It's related to the fact that I need to parse the cookie when it's not > parsed yet, to see whether it's empty. So I'm now parsing it also when > working with the last database, which needs to be treated specially (i.e. > it must let the empty cookie pss thru). Fixed, will commit in a moment. > > Thanks, p. Ah yes, just saw this. Sorry, my email seems to be slow today (weird). Similar to my patch, but I'm unsure about the second part: } else if ( op->o_bd != gi->gi_n[0].gn_be ) { /* if cookie not empty, it's again this database's turn */ op->o_conn->c_pagedresults_state.ps_be = op->o_bd; } If the cookie is not empty, then it should again be this database's turn, even it this is this last database. This makes a search that stops in the middle of results from last database with a valid cookie fall back to the first database on continuation, and thus loop forever. Would you consider removing the else if? Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> This is a multi-part message in MIME format. > --------------050800080103050407050909 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 8bit > > Le 08/04/2010 13:49, jonathan(a)phillipoux.net a écrit : >> On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >>>> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a Ã©crit : >>>>> When requesting paged results control on glued databases, if a >>>>> database >>>>> (either >>>>> superior or subordinate) returns one page that ends with the last >>>>> corresponding >>>>> entry in that database, the resulting cookie is empty. Thus, the >> result >>>>> returned to the client corresponds to the final result of a paged >>>>> response. >>>>> However, other databases may have returned data. A fix is being >>>>> designed. p. >>>> >>>> Your fix for this problem works well in my tests. >>>> >>>> Under the same subject, another problem arises: >>>> >>>> Consider this : >>>> - back null >>>> ---- back ldap 1 returning 3 results to a search >>>> ---- back ldap 2 returning 3 results to a search >>>> >>>> And you search "back null" with a page size of 2: >>>> - The first response contains 2 results from "back ldap 1" and a >>>> correct >>>> cookie. >>>> - The second response contains 1 result from "back ldap 1" and 1 >>>> result >>>> from "back ldap 2", and another correct cookie. >>>> - The third request, however, goes back to "back ldap 1", and returns >>>> the same results as the first response. >>>> - And so on... forever. >>>> >>>> As I mentioned, it seems that to solve this problem we would have to >>>> tie >>>> a paged results cookie to a particular backend under glue... >>> >>> Should work now. The issue was related to the fact that unless the >>> subordinate backends are local, the response to pgaed results has not >> been >>> parsed into the connection structure... >> >> Yes, much better now. >> >> Just one weird case left. Considering the same setup as described above >> (back null with 2 back ldap glued underneath): a search with >> pagedResults >> and a page size of 3 (the exact number of results returned by each back >> ldap), we get: >> - a first page with the 3 results from back ldap 1 >> - a second page with 3 results from back ldap 2 (so far, so good) >> - but then this last result also has a pagedResults cookie, and the >> search >> can go on and on, returning the same 2nd page. >> >> Presumably this is related to the patch allowing pagedResults to cross >> two >> databases. If the first returns an empty cookie (no more results), a new >> cookie is added. However, this should not be done if the last database >> returns no more results. > > It seems it just needs a simple exception for the last database. The > attached patch works for me. > > Jonathan > -- > -------------------------------------------------------------- > Jonathan Clarke - jonathan(a)phillipoux.net > -------------------------------------------------------------- > Ldap Synchronization Connector (LSC) - http://lsc-project.org > -------------------------------------------------------------- > > --------------050800080103050407050909 > Content-Type: text/x-patch; > name="jcl-backglue-20100408.patch" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="jcl-backglue-20100408.patch" > > Index: servers/slapd/backglue.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/backglue.c,v > retrieving revision 1.153 > diff -a -u -r1.153 backglue.c > --- servers/slapd/backglue.c 6 Apr 2010 20:04:58 -0000 1.153 > +++ servers/slapd/backglue.c 8 Apr 2010 15:39:34 -0000 > @@ -559,6 +559,7 @@ > > /* Check whether the cookie is empty, > * and give remaining databases a chance > + * unless this is already the last database > */ > if ( op->o_bd != gi->gi_n[0].gn_be ) { > int c; > @@ -581,7 +582,7 @@ > tag = ber_scanf( ber, "{im}", &size, &cookie ); > assert( tag != LBER_ERROR ); > > - if ( BER_BVISEMPTY( &cookie ) ) { > + if ( BER_BVISEMPTY( &cookie ) && i != 0 ) { > if ( btmp == b0 ) { > op->o_conn->c_pagedresults_state.ps_be = gi->gi_n[gi->gi_nodes > - 1].gn_be; Yes, thanks. I already fixed it almost the same way. p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

This is a multi-part message in MIME format. --------------050800080103050407050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Le 08/04/2010 13:49, jonathan(a)phillipoux.net a écrit : > On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >>> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a Ã©crit : >>>> When requesting paged results control on glued databases, if a database >>>> (either >>>> superior or subordinate) returns one page that ends with the last >>>> corresponding >>>> entry in that database, the resulting cookie is empty. Thus, the > result >>>> returned to the client corresponds to the final result of a paged >>>> response. >>>> However, other databases may have returned data. A fix is being >>>> designed. p. >>> >>> Your fix for this problem works well in my tests. >>> >>> Under the same subject, another problem arises: >>> >>> Consider this : >>> - back null >>> ---- back ldap 1 returning 3 results to a search >>> ---- back ldap 2 returning 3 results to a search >>> >>> And you search "back null" with a page size of 2: >>> - The first response contains 2 results from "back ldap 1" and a correct >>> cookie. >>> - The second response contains 1 result from "back ldap 1" and 1 result >>> from "back ldap 2", and another correct cookie. >>> - The third request, however, goes back to "back ldap 1", and returns >>> the same results as the first response. >>> - And so on... forever. >>> >>> As I mentioned, it seems that to solve this problem we would have to tie >>> a paged results cookie to a particular backend under glue... >> >> Should work now. The issue was related to the fact that unless the >> subordinate backends are local, the response to pgaed results has not > been >> parsed into the connection structure... > > Yes, much better now. > > Just one weird case left. Considering the same setup as described above > (back null with 2 back ldap glued underneath): a search with pagedResults > and a page size of 3 (the exact number of results returned by each back > ldap), we get: > - a first page with the 3 results from back ldap 1 > - a second page with 3 results from back ldap 2 (so far, so good) > - but then this last result also has a pagedResults cookie, and the search > can go on and on, returning the same 2nd page. > > Presumably this is related to the patch allowing pagedResults to cross two > databases. If the first returns an empty cookie (no more results), a new > cookie is added. However, this should not be done if the last database > returns no more results. It seems it just needs a simple exception for the last database. The attached patch works for me. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------050800080103050407050909 Content-Type: text/x-patch; name="jcl-backglue-20100408.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jcl-backglue-20100408.patch" Index: servers/slapd/backglue.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/backglue.c,v retrieving revision 1.153 diff -a -u -r1.153 backglue.c --- servers/slapd/backglue.c 6 Apr 2010 20:04:58 -0000 1.153 +++ servers/slapd/backglue.c 8 Apr 2010 15:39:34 -0000 @@ -559,6 +559,7 @@ /* Check whether the cookie is empty, * and give remaining databases a chance + * unless this is already the last database */ if ( op->o_bd != gi->gi_n[0].gn_be ) { int c; @@ -581,7 +582,7 @@ tag = ber_scanf( ber, "{im}", &size, &cookie ); assert( tag != LBER_ERROR ); - if ( BER_BVISEMPTY( &cookie ) ) { + if ( BER_BVISEMPTY( &cookie ) && i != 0 ) { if ( btmp == b0 ) { op->o_conn->c_pagedresults_state.ps_be = gi->gi_n[gi->gi_nodes - 1].gn_be; --------------050800080103050407050909--

1 0

Re: (ITS#6508) memberof segmentation fault
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

Fixed in HEAD; please check. a_numvals was added in September 2007 (slap.h 1.831 Fri Sep 21 06:43:56 2007); slapo-memberof.c was first committed in August 2007 (memberof.c 1.1 Fri Aug 24 00:46:58 2007), but developed about one year earlier. I'm surprised it survived so long without the a_numvals bit :) Thanks, p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs