- openldap-bugs - openldap.org

(ITS#5854) Double send response in meta backend
by jorge.perez＠adaptia.net 11 Dec '08

11 Dec '08

Full_Name: Jorge Perez Burgos Version: 2.4.11 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz Submission from: (NULL) (194.237.142.20) Meta backend send two response codes when trying to reconnect to other slapd. Steps to reproduce: Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough meta backend. Do some traffic operations. Restart slapd_B and do some modify, delete or add operation, response code 52 is received although the operation is sucessful. Using a tcpdump you can see two response codes for the request. I attach a possible patch for this issue.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Dec '08

10 Dec '08

--=-svDYOuAyXlEqIDWU48Ko Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 12:22 +1100, Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > > A tentative implementation is in HEAD, please test. You need to: >=20 > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). >=20 > > - configure as --enable-deref > >=20 > > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > > work as global overlay yet, sorry). >=20 > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. >=20 > > - run searches like > > > > $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' > >=20 > > you'll see results like >=20 > When using Samba4's client, it seems to work, but it is as if it extends > the control to the full expected length, but not the data. Ie, attached > this is the control response I got back from the 'make testenv' > environment in Samba4. I've also attached the full LDAP request. >=20 > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > parsing bug). >=20 > I can make the Samba4 tree that reproduces this available as a GIT > repository if you like. =20 To reproduce: In a checkout from git://git.samba.org/abartlet/samba.git master run: OPENLDAP_ROOT=3D/usr/local/ TEST_LDAP=3Dyes make testenv Then in the xterm that pops up, run: bin/ldbsearch -H ldap://localdc1 cn=3Dadministrator --controls=3Dextended_dn:1:1 This will not return the extended DN (compare with TEST_LDAP=3Dno), because it fails to parse the returned control in libcli/ldap/ldap_controls.c (I suspect my parser also needs work) Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-svDYOuAyXlEqIDWU48Ko Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQJosz4A8Wyi0NrsRAuLgAJwIYEfeK/rj9xXw+/2KiVhDPw6bvwCeJwaj Q/I64Xu6suP53nnqNT6Bkv0= =GSzF -----END PGP SIGNATURE----- --=-svDYOuAyXlEqIDWU48Ko--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Dec '08

10 Dec '08

--=-3DGTDdLilVnhuysLkRP/ Content-Type: multipart/mixed; boundary="=-vUh+QDuuW5KKlkVC19pp" --=-vUh+QDuuW5KKlkVC19pp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > A tentative implementation is in HEAD, please test. You need to: Thankyou very much. I downloaded CVS HEAD and tested it out (finally - the Samba4 side of the implementation took far longer than I expected). > - configure as --enable-deref >=20 > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > work as global overlay yet, sorry). This is something Samba4 will need, as many of our links are cross-database. But fixing this for a single DB is a big help in any case. > - run searches like > > $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' >=20 > you'll see results like When using Samba4's client, it seems to work, but it is as if it extends the control to the full expected length, but not the data. Ie, attached this is the control response I got back from the 'make testenv' environment in Samba4. I've also attached the full LDAP request. The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 parsing bug). I can make the Samba4 tree that reproduces this available as a GIT repository if you like. =20 Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=control Content-Type: application/octet-stream; name=control Content-Transfer-Encoding: base64 MIIDnzCBqAQIbWVtYmVyT2YEOGNuPUVudGVycHJpc2UgQWRtaW5zLGNuPVVzZXJzLGRjPXNhbWJh LGRjPWV4YW1wbGUsZGM9Y29toGIwMwQJZW50cnlVVUlEMSYEJGU4MmNiMjE4LTViNmEtMTAyZC05 MDk4LTU1MGYxMWFkZWE4OTArBAlvYmplY3RTaWQxHgQcAQUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA== --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=request Content-Type: application/octet-stream; name=request Content-Transfer-Encoding: base64 MIINiwIBBmOBvQQaREM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20KAQIKAQACAQACAQABAQCgKqIT oxEECWlzRGVsZXRlZAQEVFJVRaMTBAJjbgQNYWRtaW5pc3RyYXRvcjBkBAlpc0RlbGV0ZWQEAmNu BAEqBAllbnRyeVVVSUQED2NyZWF0ZVRpbWVzdGFtcAQPbW9kaWZ5VGltZXN0YW1wBA9jcmVhdGVU aW1lc3RhbXAECGVudHJ5Q1NOBAhtZW1iZXJPZqCCDMQwggzABBkxLjMuNi4xLjQuMS40MjAzLjY2 Ni41LjE2BIIMoTCCDJ0wIQQHb3duZXJCTDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAiBAhtZW1i ZXJPZjAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAtBBNub25TZWN1cml0eU1lbWJlckJMMBYECWVu dHJ5VVVJRAQJb2JqZWN0U0lEMCsEEWROUmVmZXJlbmNlVXBkYXRlMBYECWVudHJ5VVVJRAQJb2Jq ZWN0U0lEMCQECnNpdGVPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRaXNQcml2aWxl Z2VIb2xkZXIwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRc2VydmVyUmVmZXJlbmNlQkwwFgQJ ZW50cnlVVUlEBAlvYmplY3RTSUQwJQQLZE1ETG9jYXRpb24wFgQJZW50cnlVVUlEBAlvYmplY3RT SUQwKwQRcXVlcnlQb2xpY3lPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIwQJYXNzaXN0 YW50MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDEEF21zRFMtTWVtYmVyc0ZvckF6Um9sZUJMMBYE CWVudHJ5VVVJRAQJb2JqZWN0U0lEMCkED2xhc3RLbm93blBhcmVudDAWBAllbnRyeVVVSUQECW9i amVjdFNJRDAnBA1mU01PUm9sZU93bmVyMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCgEDm1zQ09N LVVzZXJMaW5rMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCQECm1hc3RlcmVkQnkwFgQJZW50cnlV VUlEBAlvYmplY3RTSUQwMwQZbXNEUy1OQy1SZXBsaWNhLUxvY2F0aW9uczAWBAllbnRyeVVVSUQE CW9iamVjdFNJRDAuBBRpcHNlY0lTQUtNUFJlZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJ RDAhBAdzZWVBbHNvMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCYEDGhhc01hc3Rlck5DczAWBAll bnRyeVVVSUQECW9iamVjdFNJRDAuBBRmUlNNZW1iZXJSZWZlcmVuY2VCTDAWBAllbnRyeVVVSUQE CW9iamVjdFNJRDAwBBZtc0RTLVNEUmVmZXJlbmNlRG9tYWluMBYECWVudHJ5VVVJRAQJb2JqZWN0 U0lEMCoEEG5vdGlmaWNhdGlvbkxpc3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwJQQLcHJlZmVy cmVkT1UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKQQPbXNEUy1Ob25NZW1iZXJzMBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMC8EFW1zRFMtVGFza3NGb3JBelJvbGVCTDAWBAllbnRyeVVVSUQECW9i amVjdFNJRDArBBFpcHNlY05GQVJlZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAjBAlz ZWNyZXRhcnkwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwMAQWYnJpZGdlaGVhZFNlcnZlckxpc3RC TDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAqBBBySURTZXRSZWZlcmVuY2VzMBYECWVudHJ5VVVJ RAQJb2JqZWN0U0lEMDAEFmZyc0NvbXB1dGVyUmVmZXJlbmNlQkwwFgQJZW50cnlVVUlEBAlvYmpl Y3RTSUQwNAQabXNDT00tVXNlclBhcnRpdGlvblNldExpbmswFgQJZW50cnlVVUlEBAlvYmplY3RT SUQwLwQVbXNEUy1UYXNrc0ZvckF6VGFza0JMMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCMECW1h bmFnZWRCeTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAvBBVkZWZhdWx0T2JqZWN0Q2F0ZWdvcnkw FgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRbm9uU2VjdXJpdHlNZW1iZXIwFgQJZW50cnlVVUlE BAlvYmplY3RTSUQwIAQGbWVtYmVyMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCsEEXN1YlNjaGVt YVN1YkVudHJ5MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDIEGGRlZmF1bHRMb2NhbFBvbGljeU9i amVjdDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDArBBFkeW5hbWljTERBUFNlcnZlcjAWBAllbnRy eVVVSUQECW9iamVjdFNJRDArBBFtc0RTLU5vbk1lbWJlcnNCTDAWBAllbnRyeVVVSUQECW9iamVj dFNJRDAoBA5kb21haW5Dcm9zc1JlZjAWBAllbnRyeVVVSUQECW9iamVjdFNJRDA0BBptc0RTLU9w ZXJhdGlvbnNGb3JBelJvbGVCTDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAsBBJkb21haW5Qb2xp Y3lPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKAQOb2JqZWN0Q2F0ZWdvcnkwFgQJZW50 cnlVVUlEBAlvYmplY3RTSUQwLgQUaGFzUGFydGlhbFJlcGxpY2FOQ3MwFgQJZW50cnlVVUlEBAlv YmplY3RTSUQwJgQMc2l0ZU9iamVjdEJMMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCcEDXF1ZXJ5 UG9saWN5QkwwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRZGlzdGluZ3Vpc2hlZE5hbWUwFgQJ ZW50cnlVVUlEBAlvYmplY3RTSUQwMQQXYnJpZGdlaGVhZFRyYW5zcG9ydExpc3QwFgQJZW50cnlV VUlEBAlvYmplY3RTSUQwNAQabXNEUy1PcGVyYXRpb25zRm9yQXpUYXNrQkwwFgQJZW50cnlVVUlE BAlvYmplY3RTSUQwKwQRbXNEUy1oYXNNYXN0ZXJOQ3MwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQw KwQRZGVmYXVsdENsYXNzU3RvcmUwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRc2hvd0luQWRk cmVzc0Jvb2swFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwLgQUaXBzZWNPd25lcnNSZWZlcmVuY2Uw FgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKQQPc2VydmVyUmVmZXJlbmNlMBYECWVudHJ5VVVJRAQJ b2JqZWN0U0lEMCsEEW1zRFMtSGFzRG9tYWluTkNzMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMC4E FG1zRFMtT2JqZWN0UmVmZXJlbmNlMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDAEFm1zRFMtT2Jq ZWN0UmVmZXJlbmNlQkwwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwJgQMbmV0Ym9vdFNDUEJMMBYE CWVudHJ5VVVJRAQJb2JqZWN0U0lEMCkED21zRHMtbWFzdGVyZWRCeTAWBAllbnRyeVVVSUQECW9i amVjdFNJRDAwBBZtc0NPTS1QYXJ0aXRpb25TZXRMaW5rMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lE MCYEDGRlZmF1bHRHcm91cDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAuBBRpcHNlY0ZpbHRlclJl ZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAnBA1kaXJlY3RSZXBvcnRzMBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMCUEC3RydXN0UGFyZW50MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMC0E E3JJRE1hbmFnZXJSZWZlcmVuY2UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIQQHbWFuYWdlcjAW BAllbnRyeVVVSUQECW9iamVjdFNJRDAwBBZwaHlzaWNhbExvY2F0aW9uT2JqZWN0MBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMCEEB3N1YlJlZnMwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIwQJcm9v dFRydXN0MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDkEH2lwc2VjTmVnb3RpYXRpb25Qb2xpY3lS ZWZlcmVuY2UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKAQObWFuYWdlZE9iamVjdHMwFgQJZW50 cnlVVUlEBAlvYmplY3RTSUQwIAQGbkNOYW1lMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lE --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=response Content-Type: application/octet-stream; name=response Content-Transfer-Encoding: base64 MIITbwIBBmSCD54ENGNuPUFkbWluaXN0cmF0b3IsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20wgg9kMBUEAmNuMQ8EDUFkbWluaXN0cmF0b3IwRwQLZGVzY3JpcHRpb24xOAQ2QnVp bHQtaW4gYWNjb3VudCBmb3IgYWRtaW5pc3RlcmluZyB0aGUgY29tcHV0ZXIvZG9tYWluMB0EEnVz ZXJBY2NvdW50Q29udHJvbDEHBAU2NjA0ODArBAlvYmplY3RTaWQxHgQcAQUAAAAAAAUVAAAAUZnM kG8t4Wyarf059AEAADARBAphZG1pbkNvdW50MQMEATEwJwQOYWNjb3VudEV4cGlyZXMxFQQTOTIy MzM3MjAzNjg1NDc3NTgwNzAhBA5zQU1BY2NvdW50TmFtZTEPBA1BZG1pbmlzdHJhdG9yMCAEFmlz Q3JpdGljYWxTeXN0ZW1PYmplY3QxBgQEVFJVRTAcBAlzYW1iYTRSRE4xDwQNQWRtaW5pc3RyYXRv cjBDBAtvYmplY3RDbGFzczE0BAN0b3AEBnBlcnNvbgQUb3JnYW5pemF0aW9uYWxQZXJzb24EBHVz ZXIECXNhbWJhNFRvcDBTBA5vYmplY3RDYXRlZ29yeTFBBD9jbj1QZXJzb24sY249U2NoZW1hLGNu PUNvbmZpZ3VyYXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20wggPGBBRuVFNlY3VyaXR5 RGVzY3JpcHRvcjGCA6wEggOoAQAEgBQAAAAgAAAAAAAAADAAAAABAQAAAAAABRIAAAABAgAAAAAA BSAAAAAgAgAABAB4AxcAAAAAACQA/wEPAAEFAAAAAAAFFQAAAFGZzJBvLeFsmq39OQACAAAAABQA /wEPAAEBAAAAAAAFEgAAAAAAGAD/AQ8AAQIAAAAAAAUgAAAAJAIAAAAAFACUAAIAAQEAAAAAAAUK AAAABQAoAAABAAABAAAAUxpyqy8e0BGYGQCqAEBSmwEBAAAAAAAFCgAAAAUAKAAAAQAAAQAAAFQa cqsvHtARmBkAqgBAUpsBAQAAAAAABQoAAAAFACgAAAEAAAEAAABWGnKrLx7QEZgZAKoAQFKbAQEA AAAAAAUKAAAABQAoADAAAAABAAAAhri1d0qU0RGuvQAA+ANnwQEBAAAAAAAFCgAAAAUAKAAwAAAA AQAAALKVV+RVlNERrr0AAPgDZ8EBAQAAAAAABQoAAAAFACgAMAAAAAEAAACzlVfkVZTREa69AAD4 A2fBAQEAAAAAAAUKAAAABQAsABAAAAABAAAA+IhwA+EK0hG0IgCgyWj5OQECAAAAAAAFIAAAACkC AAAFACwAEAAAAAEAAAAAQhZMwCDQEadoAKoAbgUpAQIAAAAAAAUgAAAAKQIAAAUALAAQAAAAAQAA AEDCCrypedARkCAAwE/C1M8BAgAAAAAABSAAAAApAgAAAAAUAAAAAgABAQAAAAAABQsAAAAFACgA EAAAAAEAAABCL7pZonnQEZAgAMBPwtPPAQEAAAAAAAULAAAABQAoABAAAAABAAAAhri1d0qU0RGu vQAA+ANnwQEBAAAAAAAFCwAAAAUAKAAQAAAAAQAAALOVV+RVlNERrr0AAPgDZ8EBAQAAAAAABQsA AAAFACgAEAAAAAEAAABUAY3k+LzREYcCAMBPuWBQAQEAAAAAAAULAAAABQAoAAABAAABAAAAUxpy qy8e0BGYGQCqAEBSmwEBAAAAAAABAAAAAAUALAAQAAAAAQAAABAgIF+ledARkCAAwE/C1M8BAgAA AAAABSAAAAApAgAABQA4ADAAAAABAAAAf3qWv+YN0BGihQCqADBJ4gEFAAAAAAAFFQAAAFGZzJBv LeFsmq39OQUCAAAFACwAEAAAAAEAAAAdsalGrmBaQLfo/4pY1FbSAQIAAAAAAAUgAAAAMAIAAAUA LAAwAAAAAQAAAByatm0ilNERrr0AAPgDZ8EBAgAAAAAABSAAAAAxAgAAMBIEC2JhZFB3ZENvdW50 MQMEATAwDwQIY29kZVBhZ2UxAwQBMDASBAtjb3VudHJ5Q29kZTEDBAEwMBYED2JhZFBhc3N3b3Jk VGltZTEDBAEwMBEECmxhc3RMb2dvZmYxAwQBMDAQBAlsYXN0TG9nb24xAwQBMDAXBA5wcmltYXJ5 R3JvdXBJRDEFBAM1MTMwEQQKbG9nb25Db3VudDEDBAEwMB0EDnNBTUFjY291bnRUeXBlMQsECTgw NTMwNjM2ODAgBAp1bmljb2RlUHdkMRIEEFbmq7Kw6TnpZ8QxgOHGErcwHQQHZEJDU1B3ZDESBBBX Elb3c3RGQrJn3yLLlF4+MCIEDG50UHdkSGlzdG9yeTESBBBW5quysOk56WfEMYDhxhK3MCIEDGxt UHdkSGlzdG9yeTESBBBXElb3c3RGQrJn3yLLlF4+MIIGIgQXc3VwcGxlbWVudGFsQ3JlZGVudGlh bHMxggYFBIIGAQAAAAD0BQAAAAAAACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgAFAAAwAgADABAQBQAHIAaQBtAGEAcgB5ADoASwBlAHIAYgBlAHIAbwBzADAzMDAwMDAwMDIw MDAwMDAzQzAwM0MwMDRDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzMDAwMDAwMDgwMDAwMDA4ODAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMTAwMDAwMDA4MDAwMDAwOTAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwNTMwMDQxMDA0RDAwNDIwMDQxMDAyRTAwNDUwMDU4 MDA0MTAwNEQwMDUwMDA0QzAwNDUwMDJFMDA0MzAwNEYwMDREMDA0MTAwNjQwMDZEMDA2OTAwNkUw MDY5MDA3MzAwNzQwMDcyMDA2MTAwNzQwMDZGMDA3MjAwNzk0OUNCRkJGNDBCMjM0OTc5NDlDQkZC RjQwQjIzNDkQAEAAAgBQAGEAYwBrAGEAZwBlAHMANEIwMDY1MDA3MjAwNjIwMDY1MDA3MjAwNkYw MDczMDAwMDAwNTcwMDQ0MDA2OTAwNjcwMDY1MDA3MzAwNzQwMB4AwAMBAFAAcgBpAG0AYQByAHkA OgBXAEQAaQBnAGUAcwB0ADMxMDAwMTFEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwRUI2RjczQUZC QzMzOTYxNEVFNjQ3MUZDMEVEQ0FEN0VBMTk5RThCRjEwNDc5NzJCMjE1NzUwNEM0RUM4OUJCM0M1 MERFNDc4OTk5OEQwODdCQkJCQkFFREVGMjE3OUVGRUI2RjczQUZCQzMzOTYxNEVFNjQ3MUZDMEVE Q0FEN0U4MjNERDkxRUQ2NzI1NjU3RUUxQTNDRDQ0NTFGRTZGRTFFOEU0OEEyMjYxNTYwNDcwQzkz MUQwMTAxM0I3OEYzRDI4QzI1RjU1Nzk2QzhFM0FDRjIwQURFNjZGRTMwMDY4NjNGOTA4QTE2RkZG QzZFQTAzM0Q1OTFERkQzRUJGRjlGRjI3OEU1NEM2NjQ1MzM2RTcyNUM5NkNDQkJDMUZGQkM3QTA0 QUI5QTg3NzVCQkIyRkExMEQ0RkQ0QkY0MUIxNTY1QjJFMzNCRjA4ODUzMjI2MDVDQTRERTM2NEU3 Qzg2M0Y5MDhBMTZGRkZDNkVBMDMzRDU5MURGRDNFQkZGNjI5NzU5N0MxNThBNzA4QTM4MEVDOTZE MTY0MzhERjZGMjAyQ0QwNUQ4QjcxRjgzQjBBQkY0OEMzOEFERjJGNDhBMTA0MzA1OEExNDU0RTk2 NUE0NjI5REYzMjZGMjQ4QkYxQUZFNkFDQTU0OEU0OEVBN0I1NUQ4ODJGMDY2MEE4QTMyRTI5RkQ0 RDMyMzI3Mjk1Qzk5QTUyQzA4NTY3NUZENDVCNTI2M0MxMDQ2NDhBQ0Y4QUNEQjExNDVFQ0JEQzMy OTc5RkQ4RjZCMkU0RTI0MkQ4N0JFRTlGMEREODVDMzA2NTZFQTJENTUyRjhCNEExNzQ5QTA0OTFD QTA2NDMwQkM2NjlCNjIwNDlEQTdGRkY5MzI5Nzc1RDk1QjZERTg3OUExMTg5QjM2QUNFNTlFMDEx MzNCQTJFNDM5RTJENzQ5MTYzRDI4MEI1Q0VEMDQyMEE4RTUyRERFMTkzRjRFM0Q2OUY5REQ4NThB ODBFQjI5NUY0ODEwOUQ3RDlCMkVFOUUyNzY0NTQxOTNERDgxOUUzNjg1RUVDM0VDMEI4MzRBRDQ3 OTk4NEM3MjUxNzRDNzk4NTNDNUZGMDkwRUE1Q0M0RjU5QjIzREEzOTBDMEM4MkMyRTEyMkQwOEM1 M0IxMjAzRTdDRkNBN0UzQjI2Q0Y1MkREQjczRjFBM0VGQzExQjdEREQ4M0YyREJERDgzMzY2RTM5 MEYwMkNGOQAwIgQKcHdkTGFzdFNldDEUBBIxMjg3MzQzMDg1NDAwMDAwMDAwHAQVbXNEUy1LZXlW ZXJzaW9uTnVtYmVyMQMEATEwEwQMaW5zdGFuY2VUeXBlMQMEATQwMwQJZW50cnlVVUlEMSYEJGU4 MDFjMTBjLTViNmEtMTAyZC05MDk2LTU1MGYxMWFkZWE4OTAkBA9jcmVhdGVUaW1lc3RhbXAxEQQP MjAwODEyMTEwMTAwNTRaMDYECGVudHJ5Q1NOMSoEKDIwMDgxMjExMDEwMDU0LjQwNjkzOFojMDAw MDAwIzAwMCMwMDAwMDAwJAQPbW9kaWZ5VGltZXN0YW1wMREEDzIwMDgxMjExMDEwMDU0WjCCATEE CG1lbWJlck9mMYIBIwQ4Y249RW50ZXJwcmlzZSBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9 ZXhhbXBsZSxkYz1jb20ENGNuPVNjaGVtYSBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhh bXBsZSxkYz1jb20ENGNuPURvbWFpbiBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20EQmNuPUdyb3VwIFBvbGljeSBDcmVhdG9yIE93bmVycyxjbj1Vc2VycyxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbQQ3Y249QWRtaW5pc3RyYXRvcnMsY249QnVpbHRpbixkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbaCCA8YwggPCBBkxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjE2BIID ozCCA58wgagECG1lbWJlck9mBDhjbj1FbnRlcnByaXNlIEFkbWlucyxjbj1Vc2VycyxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbaBiMDMECWVudHJ5VVVJRDEmBCRlODJjYjIxOC01YjZhLTEwMmQt OTA5OC01NTBmMTFhZGVhODkwKwQJb2JqZWN0U2lkMR4EHAEFAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-vUh+QDuuW5KKlkVC19pp-- --=-3DGTDdLilVnhuysLkRP/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQGs/z4A8Wyi0NrsRApYSAKCypwyLcW8Xy7h/bZm+jVgwfXsrzACgqKLt aQNMQH/eZvlH1z5jyZ7/FYA= =OLsg -----END PGP SIGNATURE----- --=-3DGTDdLilVnhuysLkRP/--

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by ando＠sys-net.it 10 Dec '08

10 Dec '08

jsafrane(a)redhat.com wrote: > Following ldapsearch crashes when referral chasing is enabled in very unusual > environment with many AD servers referring to each other (I had to increase > refhoplimit to chase all the referrals). Thanks for the detailed report. However, IMHO, automatic referral chasing Is Broken. Clients should explicitly chase them, possibly providing some interactive means for rebinding. This is what is currently done, for example, by slapd when using slapo-chain(5), and what should be done by proxy backends as well. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 09 Dec '08

09 Dec '08

Full_Name: Jan Safranek Version: 2.4.13 OS: Linux. Fedora 9, x86_64 URL: http://people.redhat.com/jsafrane/openldap-referral-crash/ Submission from: (NULL) (89.102.11.105) Following ldapsearch crashes when referral chasing is enabled in very unusual environment with many AD servers referring to each other (I had to increase refhoplimit to chase all the referrals). $ ldapsearch -x -C -D cn=uzivatelk,ou=Services,ou=BOUDA,ou=administrace,dc=broken,dc=net -w 'mojeheslo' -b "dc=broken,dc=net" -h f9 "(sAMAccountName=uzivatel)" ldapsearch: sockbuf.c:88: ber_sockbuf_ctrl: Assertion `sb != ((void *)0)' failed. You can find the stack trace below and ldapsearch -d -1 output at http://people.redhat.com/jsafrane/openldap-referral-crash/, together with LDAP traffic in pcap format. IMO, if there are more referrals involved (A refers to B, which refers to C), wait4msg() and try_read1msg() functions are called recursively several times. When referral to C is being resolved, the stack looks like this: 1: try_read1msg 2: wait4msg 3: ldap_result ... 4: ldap_chase_v3referrals 5: try_read1msg 6: wait4msg 7: ldap_result ... 8: ldap_chase_v3referrals 9: try_read1msg 10: ldap_result 11: wait4msg 12: do_search 13: main Looking at the wait4msg(), result.c:393, it goes through all connections inside LDAP structure: for ( lc = ld->ld_conns; rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL; ) { if ( lc->lconn_status == LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { <...mutexes...> rc = try_read1msg( ld, msgid, all, &lc, result ); <...mutexes...> if ( lc == NULL ) { /* if lc gets free()'d, * there's no guarantee * lc->lconn_next is still * sane; better restart * (ITS#4405) */ lc = ld->ld_conns; /* don't get to next conn! */ break; } } /* next conn */ lc = lc->lconn_next; } And try_read1msg() can release the connection and change the list of connections, see result.c:944: ldap_free_connection( ld, lc, 0, 1 ); <...mutexes...> lc = *lcp = NULL; The calling wait4msg() expects that called try_read1msg() may free a connection and does not crash. But if more wait4msg() are called recursively, the "bottom ones", #6 and #11 in my stack example above, do not know about the change which try_read1msg() in #1 has made and can hold already freed 'lc' pointer -> crash. IMHO there should be some other check, that ensures that wait4msg() restarts the loop even if some inner try_read1msg() modifies the list. Or there could be some ldap_use_connecion() in try_read1msg() when referrals are being chased, so the connection does get freed only by the right try_read1msg() - #5 in my case and not #1. However, my knowledge of OpenLDAP internals is somewhat limited and I am not able to tell which way is the best. It's quite hard to reproduce the bug, the packets must arrive in the right order, so the connection to B is being freed when referral to C is being chased. I am not able to reproduce it in more controlled environment, the log is quite huge and it contains some other not so interesting referrals. The connection, which is freed too early, is connection to 'sec.broken.net' - look for the last 'ldap_free_connection: actually freed' in the log. I hope my explanation above is somewhat readable and I didn't confuse you too much :). Do not hesitate to ask for specific details. Here is the promised real stack trace. It asserts when the 'lc' in wait4msg() has been freed by previous call to try_read1msg. (gdb) bt full #0 0x0000003b49632215 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003b49633d83 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003b4962b039 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x000000000044d4b1 in ber_sockbuf_ctrl (sb=0x0, opt=8, arg=0x0) at sockbuf.c:88 p = (Sockbuf_IO_Desc *) 0x452f65 ret = 0 __PRETTY_FUNCTION__ = "ber_sockbuf_ctrl" #4 0x0000000000416222 in try_read1msg (ld=0x1b80fa0, msgid=18, all=1, lcp=0x7fffe4f67ae8, result=0x7fffe4f67be8) at result.c:1190 ber = (BerElement *) 0x1b8c040 newmsg = (LDAPMessage *) 0x1b91ca0 l = (LDAPMessage *) 0x0 prev = (LDAPMessage *) 0x1b8d370 id = 2 idx = 0 tag = 115 len = 78 foundit = 0 lr = (LDAPRequest *) 0x0 tmplr = (LDAPRequest *) 0x1b8d220 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} lc = (LDAPConn *) 0x1b8e3e0 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = -1}, ber_tag = 0, ber_len = 87, ber_usertag = 0, ber_buf = 0x1b8c0a0 "\002\001\005s\204", ber_ptr = 0x1b8c0f7 "", ber_end = 0x1b8c0f7 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} rc = -2 refer_cnt = 1 hadref = 1 simple_request = 0 err = 5 lderr = 1 __PRETTY_FUNCTION__ = "try_read1msg" bv_nod = {bv_len = 22, bv_val = 0x452b0b "1.3.6.1.4.1.1466.20036"} #5 0x0000000000414c67 in wait4msg (ld=0x1b80fa0, msgid=18, all=1, timeout=0x7fffe4f67bf0, result=0x7fffe4f67be8) at result.c:402 err = 0 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 100000} tv0 = {tv_sec = 0, tv_usec = 100000} start_time_tv = {tv_sec = 1228828417, tv_usec = 878311} tvp = (struct timeval *) 0x7fffe4f67b10 lc = (LDAPConn *) 0x1b8e3e0 __PRETTY_FUNCTION__ = "wait4msg" #6 0x0000000000414433 in ldap_result (ld=0x1b80fa0, msgid=18, all=1, timeout=0x7fffe4f67bf0, result=0x7fffe4f67be8) at result.c:127 lm = (LDAPMessage *) 0x0 rc = 18 __PRETTY_FUNCTION__ = "ldap_result" #7 0x0000000000428313 in ldap_new_connection (ld=0x1b80fa0, srvlist=0x7fffe4f67df0, use_ldsb=0, connect=1, bind=0x7fffe4f67dc0) at request.c:560 tv = {tv_sec = 0, tv_usec = 100000} res = (LDAPMessage *) 0x0 msgid = 18 rc = 0 passwd = {bv_len = 0, bv_val = 0x0} err = 1 savedefconn = (LDAPConn *) 0x1b8a380 lc = (LDAPConn *) 0x1b8c690 async = 0 __PRETTY_FUNCTION__ = "ldap_new_connection" ---Type <return> to continue, or q <return> to quit--- #8 0x00000000004276b5 in ldap_send_server_request (ld=0x1b80fa0, ber=0x1b8d290, msgid=17, parentreq=0x1b8a6e0, srvlist=0x7fffe4f67df0, lc=0x0, bind=0x7fffe4f67dc0) at request.c:207 lr = (LDAPRequest *) 0x1b8d290 incparent = 1 rc = 389 #9 0x0000000000429be6 in ldap_chase_v3referrals (ld=0x1b80fa0, lr=0x1b8cb40, refs=0x0, sref=1, errstrp=0x1b8cb70, hadrefp=0x7fffe4f67f2c) at request.c:1209 unfollowed = 0x0 unfollowedcnt = 0 origreq = (LDAPRequest *) 0x1b8a6e0 srv = (LDAPURLDesc *) 0x1b8c7b0 ber = (BerElement *) 0x1b8d290 refarray = (char **) 0x1b8c670 lc = (LDAPConn *) 0x0 rc = 0 count = 0 i = 0 j = 0 id = 17 rinfo = {ri_msgid = 2, ri_request = 99, ri_url = 0x1b91c30 "ldap://DomainDnsZones.sec.broken.net/DC=DomainDnsZones,DC=sec,DC=broken,DC=…"} #10 0x000000000041553d in try_read1msg (ld=0x1b80fa0, msgid=-1, all=0, lcp=0x7fffe4f680e8, result=0x7fffe4f68228) at result.c:729 refs = (char **) 0x1b8c670 ber = (BerElement *) 0x1b8ae00 newmsg = (LDAPMessage *) 0x0 l = (LDAPMessage *) 0x1e4f68080 prev = (LDAPMessage *) 0x7fffe4f68080 id = 2 idx = 0 tag = 115 len = 80 foundit = 0 lr = (LDAPRequest *) 0x1b8cb40 tmplr = (LDAPRequest *) 0x1b8a550 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} lc = (LDAPConn *) 0x1b8beb0 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = -1}, ber_tag = 0, ber_len = 89, ber_usertag = 0, ber_buf = 0x1b8c600 "\002\001\003s\204", ber_ptr = 0x1b8c659 "", ber_end = 0x1b8c659 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 err = 4 lderr = 1 __PRETTY_FUNCTION__ = "try_read1msg" bv_nod = {bv_len = 22, bv_val = 0x452b0b "1.3.6.1.4.1.1466.20036"} #11 0x0000000000414c67 in wait4msg (ld=0x1b80fa0, msgid=-1, all=0, timeout=0x0, result=0x7fffe4f68228) at result.c:402 err = 0 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} start_time_tv = {tv_sec = 0, tv_usec = 0} tvp = (struct timeval *) 0x0 lc = (LDAPConn *) 0x1b8beb0 __PRETTY_FUNCTION__ = "wait4msg" #12 0x0000000000414433 in ldap_result (ld=0x1b80fa0, msgid=-1, all=0, timeout=0x0, result=0x7fffe4f68228) at result.c:127 lm = (LDAPMessage *) 0x0 rc = 100 __PRETTY_FUNCTION__ = "ldap_result" ---Type <return> to continue, or q <return> to quit--- #13 0x0000000000408dbf in dosearch (ld=0x1b80fa0, base=0x1b7f5e0 "dc=broken,dc=net", scope=2, filtpatt=0x0, value=0x7fffe4f6b881 "(sAMAccountName=uzivatel)", attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=-1) at ldapsearch.c:1280 filter = 0x7fffe4f6b881 "(sAMAccountName=uzivatel)" rc = 0 nresponses = 7 nentries = 1 nreferences = 6 nextended = 0 npartial = 0 res = (LDAPMessage *) 0x0 msg = (LDAPMessage *) 0x0 msgid = 2 retoid = 0x0 retdata = (struct berval *) 0x0 nresponses_psearch = -1 cancel_msgid = -1 #14 0x00000000004084cc in main (argc=14, argv=0x7fffe4f6a4f8) at ldapsearch.c:1112 filtpattern = 0x7fffe4f6b881 "(sAMAccountName=uzivatel)" attrs = (char **) 0x0 line = '\0' <repeats 1344 times>, "\006\000\000\000\000\000\000\000\200\220öäÿ\177\000\000\220\220öäÿ\177\000\000\231C!J;\000\000\000\237C!J;\000\000\000\023pdI;", '\0' <repeats 47 times>, "º\005\000\000\004\000\000\000\000\000\000\000à\220öäÿ\177\000\000ð\220öäÿ\177\000\000ÔB!J;\000\000\000ØB!J;\000\000\000\023pdI;", '\0' <repeats 47 times>, "º\005\000\000X\220öäÿ\177\000\000x\220öäÿ\177\000\000 \220öäÿ\177\000\000p\220öäÿ\177\000\000Ð\213öäÿ\177", '\0' <repeats 18 times>, "\205ç Iøÿÿÿ\000\000\000\000\000\000\000\000èÔAI;\000\000\000"... fp = (FILE *) 0x0 rc = 4213523 rc1 = 0 i = 0 first = 32767 ld = (LDAP *) 0x1b80fa0 seber = (BerElement *) 0x0 vrber = (BerElement *) 0x0 syncber = (BerElement *) 0x0 syncbvalp = (struct berval *) 0x0 err = 4216832 (gdb)

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by h.b.furuseth＠usit.uio.no 09 Dec '08

09 Dec '08

hyc(a)symas.com writes: >ando(a)sys-net.it wrote: >>h.b.furuseth(a)usit.uio.no wrote: >>> If it knows enough to complain, why not restart the indexing task? >> >> There should be an option in doing that. I don't quite see why. If you add an index via cn=config, that starts an indexing task while slapd is running. A following shutdown-restart is not necessarily related to a desire to not run that task. >> In fact, I suspect running slapindex -q can be much more efficient >> than letting slapd index while serving without index. (...) If you shut down slapd because you want to use slapindex, then you know what you want - so just go ahead and use slapindex. No extra flag needed. I suppose there could be a flag to _not_ start the indexing task when you add an index via cn=config, so you always must slapindex. > I suppose we should save the last entryID that was indexed at shutdown time, > so that the indexer task can resume at the next startup. We'd also need some > coordination with slapindex, so that if you ran slapindex after shutdown, it > would erase the saved status. Rather than add any fields to the DB index > files, it would probably be OK to write the status in the cn=config tree. Or a status file in the database directory. A cn=config attribute would make it messy to swap database directories around, since one must also modify cn=config when doing so. -- Hallvard

1 0

Re: (ITS#5852) ACL behaviour does not match Admin Guide
by andrew.findlay＠skills-1st.co.uk 09 Dec '08

09 Dec '08

On Mon, Dec 08, 2008 at 09:01:44PM +0000, quanah(a)zimbra.com wrote: > > Full_Name: Andrew Findlay > > Version: HEAD 2008-12-05 > > OS: SuSE 10.2 > > URL: > > Submission from: (NULL) (88.97.25.132) > > > > > > Section 7.2.5 Access Control Examples says: > > ... > > Also note that if no access to directive matches or no by <who> clause, > > access is denied. That is, every access to directive ends with an > > implicit by * none clause and every access list ends with an implicit > > access to * by * none directive. > > > > The statement about access *lists* ending with a deny directive is wrong > > (or at least misleading). > > I think it is quite clear: > > The structure of the access control directives is > ... > Lists of access directives are evaluated in the order they appear in > slapd.conf. > > Each <who> clause list is implicitly terminated by a > > by * none stop > > > So, there are acl directives where each directive is an element of a list. > Every element of a list of acl directives is terminated by * none stop. That is not the aspect that worries me here. The statement in 7.2.5 agrees with what you say about individual directives. I am concerned about the behaviour of complete access *lists*. For example, if my global acccess list says: access to * by * read and the access list for a BDB database holding the suffix 'dc=example,dc=org' says: access to dn.exact="cn=nonesuch,dc=example,dc=org" by users read (i.e. it is very restrictive and does not give ANON anything) In this case the statement in 7.2.5 implies that ANON should not be able to read dc=example,dc=org but tests show that it can. Changing the global access list to: access to * by users read prevents ANON from reading dc=example,dc=org and thus proves that the per-database access list does not end with 'by * none stop' (but the complete list including the global section does). Sections 7.2.4 and 7.3.4 describe this behaviour rather better, but do not mention the default-deny that gets appended to a non-empty access list. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by rhafer＠suse.de 09 Dec '08

09 Dec '08

Am Montag 08 Dezember 2008 16:39:33 schrieb Hallvard B Furuseth: > Yes, this sounds familiar. I guess I mentioned it but didn't have time > to check it. The offending if() comes from tpool.c rev 1.81, which was > apparently a wrong fix to ITS#5194. rev 1.82 was the right fix. > (Except I'm not so sure it was the _complete_ fix - might need to lock > ldap_pvt_thread_pool_mutex while changing or even accessing *tpool, or > something like that...) > > Anyway, the patch looks correct to me, undoing rev 1.81. Thanks very much for the clarification. > The current code is clear enough in retrospect - a thread pool pause in > halts pool_destroy() since pool_resume() doesn't broadcast - and thus a > cn=config update (or access?) aborts slapd shutdown:-( It doesn't really abore shutdown in sense of slapd accepting requests again. slapd is completely lockup in such a condition. It doesn't accept requests anymore, neither does it shutdown completely. Anyway, I've just applied the fix to HEAD. -- regards, Ralf

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 08 Dec '08

08 Dec '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> - the index should be invalidated >>> - slapd, at the next manual startup, should complain about the need to >>> run slapindex first. >> If it knows enough to complain, why not restart the indexing task? > > There should be an option in doing that. In fact, I suspect running > slapindex -q can be much more efficient than letting slapd index while > serving without index. Of course, slapd cannot serve while > slapindex'ing, so I think human intervention is needed to determine > what's most appropriate on a case by case basis. I suppose we should save the last entryID that was indexed at shutdown time, so that the indexer task can resume at the next startup. We'd also need some coordination with slapindex, so that if you ran slapindex after shutdown, it would erase the saved status. Rather than add any fields to the DB index files, it would probably be OK to write the status in the cn=config tree. -- -- 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#5852) ACL behaviour does not match Admin Guide
by quanah＠zimbra.com 08 Dec '08

08 Dec '08

--On Monday, December 08, 2008 7:33 PM +0000 andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: HEAD 2008-12-05 > OS: SuSE 10.2 > URL: > Submission from: (NULL) (88.97.25.132) > > > Section 7.2.5 Access Control Examples says: > ... > Also note that if no access to directive matches or no by <who> clause, > access is denied. That is, every access to directive ends with an > implicit by * none clause and every access list ends with an implicit > access to * by * none directive. > > The statement about access *lists* ending with a deny directive is wrong > (or at least misleading). I think it is quite clear: The structure of the access control directives is ... Lists of access directives are evaluated in the order they appear in slapd.conf. Each <who> clause list is implicitly terminated by a by * none stop So, there are acl directives where each directive is an element of a list. Every element of a list of acl directives is terminated by * none stop. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5852) ACL behaviour does not match Admin Guide
by andrew.findlay＠skills-1st.co.uk 08 Dec '08

08 Dec '08

Full_Name: Andrew Findlay Version: HEAD 2008-12-05 OS: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) Section 7.2.5 Access Control Examples says: ... Also note that if no access to directive matches or no by <who> clause, access is denied. That is, every access to directive ends with an implicit by * none clause and every access list ends with an implicit access to * by * none directive. The statement about access *lists* ending with a deny directive is wrong (or at least misleading). The truth is that the global access list is effectively appended to each per-database list. If the resulting list is non-empty then a default deny is appended. If there are *no* access directives applicable to a backend at all then a default read is used. slapd.access(5) is clearer about this but still not clear enough about the default-deny case. Sections 7.2.4 and 7.3.4 are fairly clear about the drop-though from backend ACLs to global ACLs, but say nothing about the default-deny case. Clearly the docs do not match the code in this area. In many ways I prefer the idea that an access list should end with a default deny (and *not* get the global list appended), but there may well be people depending on the current behaviour.

1 0

(ITS#5851) ACL behaviour does not match slapd.access(5)
by andrew.findlay＠skills-1st.co.uk 08 Dec '08

08 Dec '08

Full_Name: Andrew Findlay Version: HEAD 2008-12-05 OS: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) Some ACL behaviours do not match slapd.access(5). slapd.access(5) says: > For entries not held in any backend (such as a root DSE), > the directives of the first backend (and any global directives) are used. I created a slapd.conf where the global ACL was: access to * by * none and the single BDB backend had acls: access to dn.exact="" by * read access to dn.exact="cn=nonesuch" by * read The anon user could not read the root DSE: ldapsearch -LLL -H ldap://localhost:1389/ -b '' -s base -x '(objectclass=*)' + I next moved the root access clause to the global section: access to dn.exact="" by * read access to * by * none The BDB backend now had this ACL: access to dn.exact="cn=nonesuch" by * read Anon was now able to read the root DSE. Thus it appears that the root DSE is controlled by the global ACL but not by the first backend ACL. My feeling is that the behaviour is right and the manpage needs updating. The Admin Guide has similar statements in 7.2.4 and 7.3.4. The complete slapd.conf file follows for reference: ------------------------------------------------------------------------------- # Logging - this goes to syslog as 'local4' # # 512+256 to enable stats logging # loglevel 768 # Schema definitions # include ../../etc/schema/core.schema include ../../etc/schema/cosine.schema include ../../etc/schema/inetorgperson.schema # These should have absolute pathnames on production systems pidfile ./slapd.pid argsfile ./slapd.args ######################################################################## # Default ACL ######################################################################## access to * by * none ######################################################################## ####################################################################### # The main database ####################################################################### ######################################################################## database bdb suffix "dc=example,dc=org" rootdn "cn=root,dc=example,dc=org" password-hash {SSHA} # rootpw password # The database directory MUST exist prior to running slapd AND # should only be accessable by the slapd/tools. Mode 700 recommended. # This should be an absolute pathname on production servers. # directory ./openldap-db # Entry cache size # cachesize 4000 # How often we force a checkpoint on the underlying database # kilobytes and seconds # checkpoint 128 300 ######################################################################## # Indices to maintain ######################################################################## index objectClass eq ######################################################################## # ACLs for this database ######################################################################## access to dn.exact="" by * read access to dn.exact="cn=nonesuch" by * read

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by ando＠sys-net.it 08 Dec '08

08 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> - the index should be invalidated >> - slapd, at the next manual startup, should complain about the need to >> run slapindex first. > > If it knows enough to complain, why not restart the indexing task? There should be an option in doing that. In fact, I suspect running slapindex -q can be much more efficient than letting slapd index while serving without index. Of course, slapd cannot serve while slapindex'ing, so I think human intervention is needed to determine what's most appropriate on a case by case basis. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

ando(a)sys-net.it writes: > - the index should be invalidated > - slapd, at the next manual startup, should complain about the need to > run slapindex first. If it knows enough to complain, why not restart the indexing task? -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

Yes, this sounds familiar. I guess I mentioned it but didn't have time to check it. The offending if() comes from tpool.c rev 1.81, which was apparently a wrong fix to ITS#5194. rev 1.82 was the right fix. (Except I'm not so sure it was the _complete_ fix - might need to lock ldap_pvt_thread_pool_mutex while changing or even accessing *tpool, or something like that...) Anyway, the patch looks correct to me, undoing rev 1.81. The current code is clear enough in retrospect - a thread pool pause in halts pool_destroy() since pool_resume() doesn't broadcast - and thus a cn=config update (or access?) aborts slapd shutdown:-( -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by rhafer＠suse.de 08 Dec '08

08 Dec '08

Am Freitag 05 Dezember 2008 09:07:53 schrieb Howard Chu: > I seem to recall there was a race such that the condvar had already been > destroyed before it got here. Don't remember the details at the moment, and > not in a position to look it up either, but perhaps trawling thru -devel > will reveal it. Sounds like something Hallvard brought up in the past. I failed to see how such a race could happen with the current code in HEAD. The condvar is only destroyed after ltp_open_count decreased to 0. There might have been such problems when _thread_pool_destroy just used a simple if statement (instead of a while loop) for checking ltp_open_count. But that has been changed long ago, as part of ITS#4943. Maybe Hallvard can shed some light on this. -- regards, Ralf

1 0

(ITS#5850) adding a new server to ammr pool switches mirror-mode off
by ando＠sys-net.it 06 Dec '08

06 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When adding a new value to olcSyncrepl to a member of a mmr pool, in order to configure a new pool member, olcMirrorMode is automatically reset since the URI of the new olcSyncrepl differs from the olcServerID. A workaround consists in explicitly reseting olcMirrorMode to TRUE within the same modify operation. p.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > dhawes(a)vt.edu wrote: >> Full_Name: David Hawes >> Version: 2.4.13 >> OS: Debian GNU/Linux 4.0 >> URL: >> Submission from: (NULL) (98.117.88.57) >> >> >> As outlined at: >> >> http://www.openldap.org/lists/openldap-software/200811/msg00136.html >> >> OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd >> under valgrind yields the following: >> >> ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are >> definitely lost in loss record 19 of 23 >> ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) >> ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) >> ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) >> ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) >> ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) >> ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) >> ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) >> ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) >> ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) >> ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) >> ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) >> ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) >> ==13311== by 0x8076926: connection_read_thread (connection.c:1286) >> ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==13311== by 0x415823F: start_thread (in >> /lib/tls/i686/cmov/libpthread-2.3.6.so) >> ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) >> >> Philip Guenther notes: >> >> In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: >> the call to SSL_get_peer_certificate() in tls_get_cert() increments the >> reference count on the cert and it never gets decremented by a call to >> X509_free(). Simply adding the call there might not be safe, depending on >> whether the berval that tls_get_cert_dn() sets up relies on the underlying >> X509 to stay valid for longer than this chain of calls, as the X509 may be >> invalidated by a rehandshake. > > Calling X509_free(x) before the return statement in tls_get_cert_dn() > does fix the memory leak, though I do not know if this is proper, as > Philip noted. My apologies for not checking the ITS before sending that message. The fix in HEAD works.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.13 > OS: Debian GNU/Linux 4.0 > URL: > Submission from: (NULL) (98.117.88.57) > > > As outlined at: > > http://www.openldap.org/lists/openldap-software/200811/msg00136.html > > OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd > under valgrind yields the following: > > ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are > definitely lost in loss record 19 of 23 > ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) > ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) > ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) > ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) > ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) > ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) > ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) > ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) > ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) > ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) > ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) > ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) > ==13311== by 0x8076926: connection_read_thread (connection.c:1286) > ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) > ==13311== by 0x415823F: start_thread (in > /lib/tls/i686/cmov/libpthread-2.3.6.so) > ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) > > Philip Guenther notes: > > In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: > the call to SSL_get_peer_certificate() in tls_get_cert() increments the > reference count on the cert and it never gets decremented by a call to > X509_free(). Simply adding the call there might not be safe, depending on > whether the berval that tls_get_cert_dn() sets up relies on the underlying > X509 to stay valid for longer than this chain of calls, as the X509 may be > invalidated by a rehandshake. Calling X509_free(x) before the return statement in tls_get_cert_dn() does fix the memory leak, though I do not know if this is proper, as Philip noted.

1 0

Re: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 04 Dec '08

04 Dec '08

I could have sworn I had uploaded the revised version of the patch back in August after some cleaning by Kurt, but have no way of confirming it. So I've uploaded it again as guenther-20081204.patch.

1 0

(ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 04 Dec '08

04 Dec '08

Full_Name: David Hawes Version: 2.4.13 OS: Debian GNU/Linux 4.0 URL: Submission from: (NULL) (98.117.88.57) As outlined at: http://www.openldap.org/lists/openldap-software/200811/msg00136.html OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd under valgrind yields the following: ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 23 ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) ==13311== by 0x8076926: connection_read_thread (connection.c:1286) ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) ==13311== by 0x415823F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) Philip Guenther notes: In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: the call to SSL_get_peer_certificate() in tls_get_cert() increments the reference count on the cert and it never gets decremented by a call to X509_free(). Simply adding the call there might not be safe, depending on whether the berval that tls_get_cert_dn() sets up relies on the underlying X509 to stay valid for longer than this chain of calls, as the X509 may be invalidated by a rehandshake.

1 0

ITS#5847 back-ndb indexing
by hyc＠symas.com 04 Dec '08

04 Dec '08

This is a known limitation in the current version of back-ndb. (See this message for further details http://www.openldap.org/lists/openldap-devel/200810/msg00094.html ) Note that back-ndb is marked "Experimental". You should not use it unless you're prepared to write fixes for it.

1 0

Re: (ITS#5845) Distribution List support for OpenLDAP schema
by bejnet＠yahoo.com 03 Dec '08

03 Dec '08

--0-334172624-1228364660=:46006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Andrew for the reply.=0A=0A=0AQMail schema didn't seem to work for a= distribution list. I am looking for other options as well.=0A=0AI agree th= at this is a mail system issue. I am using Exim/Dovecot for mails. I though= t it was the LDAP which gets the group mail id from the address book for th= e Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick.=0A= =0AWith Regards=0ABejoy=0A=0A=0A=0A________________________________=0AFrom:= Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>=0ATo: bejnet(a)yahoo.com=0A= Cc: openldap-its(a)openldap.org=0ASent: Wednesday, 3 December, 2008 2:02:05 P= M=0ASubject: Re: (ITS#5845) Distribution List support for OpenLDAP schema= =0A=0AOn Wed, Dec 03, 2008 at 05:02:52AM +0000, bejnet(a)yahoo.com wrote:=0A= =0A> I want to create distribution list in OpenLDAP. Meaning - If I have a = group=0A> called admins(a)ldap.com and there are two members - bejoy(a)ldap.com= and=0A> bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com =3D both thes= e members must=0A> get the email. Exchange has this feature. This mail id s= hould have a display=0A> name feature as well - that would show up on searc= h of address books.=0A> =0A> At present the work around is using qmail's sc= hema for this distribution list. I=0A> believe inetOrgPerson schema could h= ave a group version too - which would need a=0A> compulsory attribute calle= d members which must have atleast one member mentioned=0A> under it.=0A=0AI= think you have just described groupOfNames. I do not like groupOfNames=0A*= because* it makes the member attribute mandatory, which makes management=0A= complicated.=0A=0AAnyway, I cannot see this as a defect in OpenLDAP. LDAP s= chema is=0Aextensible: if you want something that is not in the standard se= t=0Ayou can add it locally. You say that you have used qmail's schema:=0Ais= there anything wrong with that?=0A=0AMost LDAP-capable mail systems can be= persuaded to use groups as=0Amailing lists, but that is a mail system issu= e not an OpenLDAP one.=0AIt could be argued that simple groups are not rich= enough to use=0Afor list expansion (no way to keep track of per-member lis= t=0Apreferences etc) but if we are going to talk about defining an=0Aimprov= ed group this is the wrong place to do it: maybe IETF's=0Aldapext list woul= d be better.=0A=0AAndrew=0A-- =0A------------------------------------------= -----------------------------=0A| From Andrew Findlay, Skil= ls 1st Ltd |=0A| Consultant in large-scale systems, network= s, and directory services |=0A| http://www.skills-1st.co.uk/ = +44 1628 782565 |=0A-----------------------------------------------= ------------------------=0A=0A=0A=0A From Chandigarh to Chennai - find= friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups= / --0-334172624-1228364660=:46006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon= t-size:12pt"><div>Thanks Andrew for the reply. </div><div style=3D"font-= family: times new roman,new york,times,serif; font-size: 12pt;"> QMail s= chema didn't seem to work for a distribution list. I am looking for other o= ptions as well. I agree that this is a mail system issue. I am using= Exim/Dovecot for mails. I thought it was the LDAP which gets the group mai= l id from the address book for the Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick. = With Regards Bejoy <div style=3D"font-family: arial,helvetica= ,sans-serif; font-size: 13px;"><hr size=3D"1">From: Andrew F= indlay <andrew.findlay(a)skills-1st.co.uk> To: bejnet(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, 3 December, 2008 2:02:05 PM<b= r>Subject: Re: (ITS#5845) = Distribution List support for OpenLDAP schema On Wed, Dec 03,= 2008 at 05:02:52AM +0000, <a ymailto=3D"mailto:bejnet@yahoo.com" href=3D"m= ailto:bejnet@yahoo.com">bejnet(a)yahoo.com</a> wrote: > I want to c= reate distribution list in OpenLDAP. Meaning - If I have a group > ca= lled <a ymailto=3D"mailto:admins@ldap.com" href=3D"mailto:admins@ldap.com">= admins(a)ldap.com</a> and there are two members - <a ymailto=3D"mailto:bejoy@= ldap.com" href=3D"mailto:bejoy@ldap.com">bejoy(a)ldap.com</a> and > <a ymailto=3D"mailto:bejnet@ldap.com" href=3D"mailto:bejnet@ldap.com">bejnet@= ldap.com</a>; and mail is sent to <a ymailto=3D"mailto:admins@ldap.com" hre= f=3D"mailto:admins@ldap.com">admins(a)ldap.com</a> =3D both these members mus= t > get the email. Exchange has this feature. This mail id should hav= e a display > name feature as well - that would show up on search of = address books. > > At present the work around is using qmail's= schema for this distribution list. I > believe inetOrgPerson schema = could have a group version too - which would need a > compulsory attr= ibute called members which must have atleast one member mentioned > u= nder it. I think you have just described groupOfNames. I do not like= groupOfNames *because* it makes the member attribute mandatory, which m= akes management complicated. Anyway, I cannot see this as a defec= t in OpenLDAP. LDAP schema is extensible: if you want something that is = not in the standard set you can add it locally. You say that you have used = qmail's schema: is there anything wrong with that? Most LDAP-capa= ble mail systems can be persuaded to use groups as mailing lists, but th= at is a mail system issue not an OpenLDAP one. It could be argued that s= imple groups are not rich enough to use for list expansion (no way to ke= ep track of per-member list preferences etc) but if we are going to talk= about defining an improved group this is the wrong place to do it: mayb= e IETF's ldapext list would be better. Andrew -- ---------= -------------------------------------------------------------- |  &= nbsp;             From Andrew Findlay, Skill= s 1st Ltd                | | Co= nsultant in large-scale systems, networks, and directory services | |&nb= sp;   <a href=3D"http://www.skills-1st.co.uk/" target=3D"_blank">http://www.skills-1st.co.uk/</a>      &nb= sp;         +44 1628 782565    | --------= --------------------------------------------------------------- </div></= div></div> =0A <hr size=3D1></hr> Add more friends to your = messenger and enjoy! <a href=3D"http://in.rd.yahoo.com/tagline_messenger_6/= *http://messenger.yahoo.com/invite/"> Invite them now.</a></body></html> --0-334172624-1228364660=:46006--

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 22:14:20 schrieb Quanah Gibson-Mount: > <http://www.oracle.com/technology/software/products/berkeley-db/db/index.ht >ml> > > Berkeley DB Release History > > > Latest Production Release > 4.7.25 > Requires log file format upgrade. change log - patches (1) > > Click on the "1", it's a link to the patch: > > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> > After applying the patches, everything seems to be working working now. Thank you very much for your assistance! tk

1 0

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

--On Wednesday, December 03, 2008 9:54 PM +0100 Thomas Koeller <thomas(a)koeller.dyndns.org> wrote: > Am Mittwoch, 3. Dezember 2008 21:22:11 schrieb Quanah Gibson-Mount: >> Did you apply the patch from Oracle? And did you apply the patch in the >> build/ directory shipped with OpenLDAP? Both are necessary. It'd be >> nice if Oracle would add the second patch to their website, since it's >> needed, and it came from them. > > No, I missed that. I found the patch shipped with OpenLDAP, but what do > you mean by '_the_ patch from Oracle'? I revisited their website but could > not spot any patches there. <http://www.oracle.com/technology/software/products/berkeley-db/db/index.html> Berkeley DB Release History Latest Production Release 4.7.25 Requires log file format upgrade. change log - patches (1) Click on the "1", it's a link to the patch: <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs