- openldap-bugs - openldap.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs