- openldap-bugs - openldap.org

Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it 21 Feb '07

21 Feb '07

kiwi(a)oav.net wrote: > Full_Name: Xavier Beaudouin > Version: 2.3.33 > OS: FreeBSD 6.2 > URL: http://www.oav.net/tmp/openldap/ > Submission from: (NULL) (82.225.248.92) > Sending -> dn : uid=kiwi(a)oav.net,ou=mailboxes,dc=kazar,dc=net > objectClass : top > objectClass : kazarPerson > uid : kiwi(a)oav.net > cn : Nom Prenom > description : Sample description > uidNumber : 10 > gidNumber : 10 > userPassword : Password > homeDirectory : /home/test > mailQuota : 50 > CouriermailQuota : 50S > > str2entry: entry -1 has no dn > str2entry(dn) failed > send_ldap_result: err=0 matched="" text="" > connection_get(8) If the above is the way your LDIF is formatted, then back-perl (actually, str2entry, a helper function in the core of slapd) is working as intended. There's supposed to be no space between attribute names or "dn" and the colon ":". Please fix you PERL and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ando＠sys-net.it 21 Feb '07

21 Feb '07

ghenry(a)suretecsystems.com wrote: > Just a quick to note that there are some overlays missing from slapd.overlays.5 > in 2.4.4alpha and actual man pages. Please enumerate them; some are intentionally not present because they are not intended for real use. > Also, relay and rwm are still marked as experimental in some places. > grep experimental doc/man/man5/* > > doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay are > experimental. > > doc/man/man5/slapo-rwm.5:This overlay is experimental. > > I'll help where I can, Sure. I believe they are no longer experimental, but they still do not support back-config, so better wait until they're complete. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

old devel bugs
by Howard Chu 21 Feb '07

21 Feb '07

Are ITS#4332 and #4473 still relevant, or can we close them? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

RE: (ITS#4846) attribute 'objectClass' provided more than once
by Wolfgang.Christ＠secunet.com 21 Feb '07

21 Feb '07

Hello Howard, i'm surely using slurpd. The replication part in slapd.conf of the master is: replogfile /home/ldap/de/secartis.replog replica uri=ldap://10.36.125.15:389 bindmethod=simple binddn="cn=admin,o=secartis,c=de" credentials=secartis attrs!=structuralObjectClass attrs!=entryUUID attrs!=creatorsName attrs!=createTimestamp attrs!=entryCSN attrs!=modifiersName attrs!=modifyTimestamp i.e. i'm using the root account for replication. And that's the mistake. I changed the binddn to a user account and now it works. Thanks a lot Kind Regards Wolfgang -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Wed 2007-02-21 14:20 To: Christ, Wolfgang Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4846) attribute 'objectClass' provided more than once wolfgang.christ(a)secunet.com wrote: > Full_Name: Wolfgang Christ > Version: 2.3.32 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.68.205.167) > > > I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd > with an LDIF file like this: > > dn: cn=wolfgang,ou=organization unit,o=organization,c=de > objectClass: inetOrgPerson > objectClass: person > cn: wolfgang > sn: hilfe > userCertificate;binary:< file:///cert.crt > > OpenLDAP returns an error "attribute 'objectClass' provided more than once". If > I > remove the second objectclass with certificate and and add these in a seperate > modify step, everything is fine. > > If i modify "servers/slapd/add.c" in line 318: > > /* check for unmodifiable attributes */ > /*rs->sr_err = slap_mods_no_repl_user_mod_check( op, > modlist, &rs->sr_text, textbuf, textlen ); > if ( rs->sr_err != LDAP_SUCCESS ) { > send_ldap_result( op, rs ); > goto done; > }*/ > > and prevent calling of slap_mods_no_repl_user_mod_check(), replication works. > > Could you explain, what is the sense of slap_mods_no_repl_user_mod_check() > and why it causes slurpd not to work. Your post makes no sense. That function is only called when a normal user is trying to add an entry. It is skipped when the replication user is doing the add. So this should have nothing to do with slurpd. What are you using to perform the Add operation? Certainly OpenLDAP's ldapadd tool won't generate an error like this; it can only arise because of a malformed Add request packet. -- -- Howard Chu Chief Architect, 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#4846) attribute 'objectClass' provided more than once
by hyc＠symas.com 21 Feb '07

21 Feb '07

wolfgang.christ(a)secunet.com wrote: > Full_Name: Wolfgang Christ > Version: 2.3.32 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.68.205.167) > > > I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd > with an LDIF file like this: > > dn: cn=wolfgang,ou=organization unit,o=organization,c=de > objectClass: inetOrgPerson > objectClass: person > cn: wolfgang > sn: hilfe > userCertificate;binary:< file:///cert.crt > > OpenLDAP returns an error "attribute 'objectClass' provided more than once". If > I > remove the second objectclass with certificate and and add these in a seperate > modify step, everything is fine. > > If i modify "servers/slapd/add.c" in line 318: > > /* check for unmodifiable attributes */ > /*rs->sr_err = slap_mods_no_repl_user_mod_check( op, > modlist, &rs->sr_text, textbuf, textlen ); > if ( rs->sr_err != LDAP_SUCCESS ) { > send_ldap_result( op, rs ); > goto done; > }*/ > > and prevent calling of slap_mods_no_repl_user_mod_check(), replication works. > > Could you explain, what is the sense of slap_mods_no_repl_user_mod_check() > and why it causes slurpd not to work. Your post makes no sense. That function is only called when a normal user is trying to add an entry. It is skipped when the replication user is doing the add. So this should have nothing to do with slurpd. What are you using to perform the Add operation? Certainly OpenLDAP's ldapadd tool won't generate an error like this; it can only arise because of a malformed Add request packet. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4846) attribute 'objectClass' provided more than once
by wolfgang.christ＠secunet.com 20 Feb '07

20 Feb '07

Full_Name: Wolfgang Christ Version: 2.3.32 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.68.205.167) I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd with an LDIF file like this: dn: cn=wolfgang,ou=organization unit,o=organization,c=de objectClass: inetOrgPerson objectClass: person cn: wolfgang sn: hilfe userCertificate;binary:< file:///cert.crt OpenLDAP returns an error "attribute 'objectClass' provided more than once". If I remove the second objectclass with certificate and and add these in a seperate modify step, everything is fine. If i modify "servers/slapd/add.c" in line 318: /* check for unmodifiable attributes */ /*rs->sr_err = slap_mods_no_repl_user_mod_check( op, modlist, &rs->sr_text, textbuf, textlen ); if ( rs->sr_err != LDAP_SUCCESS ) { send_ldap_result( op, rs ); goto done; }*/ and prevent calling of slap_mods_no_repl_user_mod_check(), replication works. Could you explain, what is the sense of slap_mods_no_repl_user_mod_check() and why it causes slurpd not to work. kind regards Wolfgang Christ

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian.rieger＠gwdg.de 20 Feb '07

20 Feb '07

This is a multi-part message in MIME format. ------=_NextPart_000_026A_01C7550D.760C6C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I updated the changelog overlay to work with OpenLDAP up to 2.3.34, and removed some bugs from the changelog purging routine. Several stress = tests were done using 2.3.34 so it should work without problems. To ease installation of the overlay I assembled a patch, that adds the overlay = to configure, configure.in and portable.hin: Patch can be found in: ftp://ftp.openldap.org/incoming/changelog-rieger-070220.c Updated Source for the overlay: ftp://ftp.openldap.org/incoming/changelog-rieger-070220-patch.gz I'm currently working on fixing the overlay to work with OpenLDAP CVS = HEAD where the registration of the schema seems to have changed. -- MfG Sebastian Rieger Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen=20 Am Fassberg - 37077 G=F6ttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Gesch=E4ftsf=FChrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: G=F6ttingen Registergericht: G=F6ttingen Handelsregister-Nr. B 598 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des = DFN =FCberpr=FCft werden: = https://ca.gwdg.de/certs/root-classic/root-ca-cert.der ------=_NextPart_000_026A_01C7550D.760C6C90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXujCCBHUw ggNdoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNVBAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMg LSBHMDEwHhcNMDUwMjI4MDAyOTM3WhcNMTMwNDI4MDAyOTM3WjBbMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQ Q0EgQ2xhc3NpYyAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvNTUXjQCVx w87yo/67c+J0bhhl6sfVNVO87Jk2WMY/lPC/E1cmq6iOAe2fV10FhexSG2zIp8XqbrlPNN7s3sy/ 0jUQfHegDqWWuCDQfWLkdWHTiDhIfhcCTdLaXDRshAxE18zDJzKPu3EMeU/N5dju7/azQVi2wkzM fM9I5aARVcrYVH+OanfQo1+yCoQupE9XaGpZRCr2w1X6pf1v0JcqakuC/LBX9uk0IPtMz9Y6frOP AvCldCn8pWNdQrT6VPmJpI7zDCm6/PCAZy82cImzkfbxGpMVxNBxC3Zwgc4zT9Cn22e0Hms8Q3cm cr8hbFb3icuGnMGKp50e9L2eOokCAwEAAaOCAUIwggE+MB0GA1UdDgQWBBSDrjvMk+EkUnrpIE+D cKIq3XsvATAfBgNVHSMEGDAWgBSDrjvMk+EkUnrpIE+DcKIq3XsvATAPBgNVHRMBAf8EBTADAQH/ MIHHBgNVHR8Egb8wgbwwXKBaoFiGVmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0 aWZpY2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMFygWqBY hlZodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2NsYXNz aWMvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQDaFaWOgZRQO/CaU+xUQPj3mgnJ5MJug0ad1d+L k+K1iTUp8r9fLxnamypzVeVrHFbtC5zk9lxx8qDMiDc6sd9HYRJNikJUme/EfHPkzlbn6hTXuL6+ ZKdCeK3qQHnltEjg/NLUIaU/bukFmhOk6NrnU5XNTKcEeOJ47t0K2EWWZ6rN3Ji0FU444hGO73tl C5t1ACWaMYFakmylmagwdZPIVnA3qKFmVRTPcz3Cel56UyA2U6n9qQR8zZzkltIwx2/6SHt2EqQN u3g6iDyOWzIfsb0bRVHmvHQx3KCUZb5JNy3iue8yIB6WMbKZ+eJuwZl1Q0PJ87BjsHYglO3JX+Oy MIIFhjCCBG6gAwIBAgIEBnsYQDANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJERTETMBEGA1UE ChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQQ0Eg Q2xhc3NpYyAtIEcwMTAeFw0wNTA0MTIwOTUzNTRaFw0wOTA0MTIwOTUzNTRaMIGcMQswCQYDVQQG EwJERTFCMEAGA1UEChM5R2VzZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52 ZXJhcmJlaXR1bmcgbWJIMQswCQYDVQQLEwJDQTEcMBoGA1UEAxMTR1dERy1DQSBFYmVuZSAxIEcw MjEeMBwGCSqGSIb3DQEJARYPZ3dkZy1jYUBnd2RnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3y/2S6yGKZhpv+DwWTSH4/szbEB2yPEJUgZz5kaVId/17wKdRNKd9el03skx/ind 1IJ27YaoOybmRp5pwuNSAL7SEC2neEKcLCqkV+jDcLusV2mQ/ykgMs7No5csyhS6FxuUwBK18BlF E7tfraK3J6iyOJxzjFKB+3/ZWhasXnwEtzOUc5hRry9bTNYpyLueUa5DLR5nqIRwk1OWbx3IARbC RKrxdAupzwEAjWwz8ar2aDHgsBH41D7sfDY9wRxH04sW6K9D0BANEx+o8KhbsPQv6l0HQE7p0n6Y XQhUo5QhZ8GMfEiIh39sE1turDLut7I4bCZwrIjPT9gJqhFMWwIDAQABo4ICDjCCAgowHQYDVR0O BBYEFPP+0UOeITsrZQ3Y8arSBsKbVgajMB8GA1UdIwQYMBaAFIOuO8yT4SRSeukgT4Nwoirdey8B MA8GA1UdEwEB/wQFMAMBAf8wgccGA1UdHwSBvzCBvDBcoFqgWIZWaHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY3Jscy9yb290 LWNhLWNybC5jcmwwXKBaoFiGVmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZp Y2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHcBggrBgEF BQcBAQSBzzCBzDBkBggrBgEFBQcwAoZYaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBk BggrBgEFBQcwAoZYaHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24v eDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDAOBgNVHQ8BAf8EBAMC AQYwDQYJKoZIhvcNAQEFBQADggEBADFx3Ji676DYFd/XIY9KcsNopLqtgF5Ixr2irPOPpZ/X/zta Gss3l18EdKCCBFqhwCrd2lFOfowbxnWZ1L+WRS/+0x4a8MZoAUWyfk+pLLgv3OucY4ZhAGP5F0XJ wLRlskcnLVvt3HFQ9JsEjHo45u/QiKbZJGFPVZb5elpphRtAVTiRisw5UTiV57m07vcJhUtrt6wh 7389cz2aYYdlViMZtuaE0Z+LlSElAe4/U6tOowoR+06qDjjFNLjQ1P3fnmBPRo2zWidaLiZcfD3f qjxBgJolgeS+gS3YePj2M6NAUTu+1XKAbrFJUyrCI+qPkEcVq3yK6FkZbbhla+BKQrcwggZUMIIF PKADAgECAgou6MIgAAAAAASaMA0GCSqGSIb3DQEBBQUAMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEVi ZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFm dCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMC REUxCjAIBgNVBAUTATIwHhcNMDYxMTA5MTMzNDU3WhcNMDcwOTIwMTA1ODAwWjCBvjELMAkGA1UE BhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEzARBgNVBAcTCkdvZXR0aW5nZW4xPjA8BgNV BAoTNUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5n MRkwFwYDVQQDExBTZWJhc3RpYW4gUmllZ2VyMScwJQYJKoZIhvcNAQkBFhhzZWJhc3RpYW4ucmll Z2VyQGd3ZGcuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN+JMyvFWWLIl0gDV5t9edUF qJCNFHH/aDm40I6MZLkYZ6eyLpRVmvIQ1+KBLP8Qjagiz1HwEqwMBDNPABq50yYCHpLmKFy+BCEH r4Cjoz2AhSm4BqUhjy/XnFOqeAReo9MJfrJeslCPbfaqVV7APQl4VqALnxnDJl/1PJ4++CiLAgMB AAGjggL9MIIC+TALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHQYDVR0OBBYEFMxqWUeIRKOu1OVQe7WDZwKzQJlGMB8GA1UdIwQYMBaAFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGvBgNVHR8EgacwgaQwgaGggZ6ggZuGTmh0dHA6Ly91c2VyLWNhLmd3 ZGcuZGUvQ2VydEVucm9sbC9HV0RHLUNBJTIwRWJlbmUlMjAyJTIwR2VuZXJpYy1DQSUyMEcwMi4x LmNybIZJaHR0cDovL3BjYS5nd2RnLmRlL2NybC9nd2RnLWNhL2ViZW5lMi9nMDIuMS9nd2RnLWNh LWViZW5lMi1nZW5lcmljLWNhLmNybDCB0wYIKwYBBQUHAQEEgcYwgcMwagYIKwYBBQUHMAGGXmh0 dHA6Ly91c2VyLWNhLmd3ZGcuZGUvQ2VydEVucm9sbC91c2VyLWNhLmd3ZGcuZGVfR1dERy1DQSUy MEViZW5lJTIwMiUyMEdlbmVyaWMtQ0ElMjBHMDIuMS5jcnQwVQYIKwYBBQUHMAGGSWh0dHA6Ly9w Y2EuZ3dkZy5kZS9jcmwvZ3dkZy1jYS9lYmVuZTIvZzAyLjEvZ3dkZy1jYS1lYmVuZTItZ2VuZXJp Yy1jYS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhZ2OO4GrnU+tkQWF84sDhK7MIS2H kIMrg8myPwIBZAIBAzBKBgNVHSAEQzBBMD8GCysGAQQBgZ1IMgEBMDAwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG0wNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMA0GCSqGSIb3DQEBBQUAA4IBAQCASq3lwDZ/ o7RuoZxqmuGCZPKlVuoBsQGaNJnoGUMBoq/7UBHRym4EpMuB8wf+NxPxhcSOxUR3UwDKE3p0VnVE O//hD6CFwbed83Wn6nv4O4jHJDxTAs0JJGomtrNxFxa5NwSUHq8ujf0DSr2Zn+yq8KzmNVjuANNe sbxvtvO3rr8pLh66m4QsgvOtGZpDeeJRpJM8eN9hf9HcIrtnCNP/KN8HGESiozUB0h0ZasH9yTQZ f/K0VCTTttPnXg3cF+g+bWMc0gGQzR40oVzTt4ggC0G68gRh2yTlQxRjMxZBS7vkWBGhEYoJoLHE TQv5oNafPL4UZGIW4SjLjWiR5mUZMIIHWzCCBkOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnDEL MAkGA1UEBhMCREUxQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hl IERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UECxMCQ0ExHDAaBgNVBAMTE0dXREctQ0EgRWJl bmUgMSBHMDIxHjAcBgkqhkiG9w0BCQEWD2d3ZGctY2FAZ3dkZy5kZTAeFw0wNTA5MjAxMDU4MDBa Fw0wNzA5MjAxMDU4MDBaMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBH MDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFm dGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC62IidFd5KC11HewNoQh8DG8jcJI1fdNIf/ETt d4vOMZRRQG5+WhETBhH0d6pXjZ+V8dhlMiekFq2RpFYPictQFnEt5M49iGfX6V3PIKkaFtFTIZj0 QbGN7BWTpcCfTw6L9VwPA3olG1QYABl16Ea9mHT6nGfvwYyiadnzHCAI1XTFeF1UzOKM8EemZvGa oQncG8QUt1uqskfcLJ18ASM6GY/C108p0E9hUx2V24BQDdLdCUB6BzcW/SQdBqjRaW51mPPMxn/p bqXWrgUwkiYJOqkDY6qVUtvKGCZIumQdKxnoSB5X7tna2widH50xNX5VdMe/qnYZPLuEnbzrkOo5 AgMBAAGjggOrMIIDpzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjBuBglghkgBhvhCAQ0E YRZfU3Vib3JkaW5hdGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHZXNlbGxzY2hhZnQgZnVl ciB3aXNzZW5zY2hhZnRsaWNoZSBEYXRlbnZlcmFyYmVpdHVuZyBtYkgwHQYDVR0OBBYEFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGGBgNVHSMEfzB9gBTz/tFDniE7K2UN2PGq0gbCm1YGo6FfpF0wWzEL MAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNV BAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMgLSBHMDGCBAZ7GEAwGgYDVR0RBBMwEYEPZ3dkZy1j YUBnd2RnLmRlMAkGA1UdEgQCMAAwQgYJYIZIAYb4QgEEBDUWM2h0dHA6Ly9jYS5nd2RnLmRlL2Ny bC9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNybDBCBglghkgBhvhCAQMENRYzaHR0cDovL2Nh Lmd3ZGcuZGUvY3JsL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3JsMIGABgNVHR8EeTB3MDmg N6A1hjNodHRwOi8vY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5jcmww OqA4oDaGNGh0dHA6Ly9wY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5j cmwwgZcGCCsGAQUFBwEBBIGKMIGHMEEGCCsGAQUFBzAChjVodHRwOi8vY2EuZ3dkZy5kZS9jZXJ0 cy9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNydDBCBggrBgEFBQcwAoY2aHR0cDovL3BjYS5n d2RnLmRlL2NlcnRzL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3J0MCAGCWCGSAGG+EIBAgQT FhFodHRwOi8vY2EuZ3dkZy5kZTAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NhLmd3ZGcuZGUvcG9s aWN5L2luZGV4Lmh0bWwwTQYDVR0gBEYwRDBCBg0rBgEEAYGdSDIBAwEBMDEwLwYIKwYBBQUHAgEW I2h0dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQBj KNeFKWGSWFjcy1fR1UHC5+MdmiTUfzHVeRbLuoGOTkbjYEbjE3+FNhGgRJJwKoDU1jQXLGGBzLQT dZcZj3QO0926SpshKNmW0zVIwf9gbAzFZ17Zgfns/BenJ7hTRl4m5aHTodkmJSKNvqwWOCFTTX9H RYRiSuDC10QYRH6S7MqyZ5Gkhtdq9iLVik8Q2RIS7OIoJgYUkLOG+tZ1rtQmWb3U6p/WwF4t5CAp ErqoJ1f427lLOj0EPOsXJUcwf+km6kkcIrKopv63HTWw7HmQHLGXajf5KbZXumwcG0Z2RCZN4OE2 yfQgRi8wmhj3pSKE4ylcz7Y9ExWdWh5YJAfMMYIDhzCCA4MCAQEwgaQwgZUxKTAnBgNVBAMTIEdX REctQ0EgRWJlbmUgMiBHZW5lcmljLUNBIEcwMi4xMQswCQYDVQQLEwJjYTFCMEAGA1UEChM5R2Vz ZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52ZXJhcmJlaXR1bmcgbWJIMQsw CQYDVQQGEwJERTEKMAgGA1UEBRMBMgIKLujCIAAAAAAEmjAJBgUrDgMCGgUAoIICODAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAyMjAxNTM3NTBaMCMGCSqGSIb3 DQEJBDEWBBRi5TY/Vy3cXYPEWqMYz4n03SV5ZjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTCBtQYJKwYBBAGCNxAEMYGnMIGkMIGVMSkwJwYDVQQDEyBHV0RH LUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2Vs bHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkG A1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowgbcGCyqGSIb3DQEJEAILMYGnoIGkMIGV MSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2Ex QjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJi ZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowDQYJKoZIhvcN AQEBBQAEgYCCe7aAZSWTEemBNF86CVX2laItjfSMajZTc0C6QRMyBVaWTRevwRApEVuGXi8tuAHD ebpepRzCWjmePfpv3RjqJbuIK5lWjA8cj1/rc7oBXFfxebCt4e3QfNbDdXKsWM/DisSGRYuVRZVj J/UWHEGT0X9jvWRpzTXWVX+pJkMGUQAAAAAAAA== ------=_NextPart_000_026A_01C7550D.760C6C90--

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by timo＠physik.uni-potsdam.de 20 Feb '07

20 Feb '07

--pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, OpenLDAP issue ITS#4750 is still unresolved (it affects current versions of nss_ldap and pam_ldap), and I consider it to be pretty serious: - Even security-conscious applications like pam_ldap still parse files from unsafe locations, including the current directory. - Attempting to read from a file in the current directory can cause problems on its own, e.g. when the directory is an autofs mountpoint (In fact, I became aware of this issue by investigating deadlocks occurring in such a situation) - If an application uses LDAP in more than one context, like a program using LDAP while also linking to nss_ldap and pam_ldap, the settings can interfere (unless very much care is taken, see below). This is bad, as the very purpose of nss and pam is to make the underlying mechanisms completely transparent to the application. - The existing LDAPNOINIT mechanism is only effective for the first call which initializes the global option structure. Thus, almost no one can reliably use it: the options may already have been initialized e.g. by nss_ldap which nearly every program might link to. The suggested workaround so far is to force nss_ldap, pam_ldap, and possibly others, to override all relevant options with safe values. To me, this seems to be quite error-prone and not a satisfactory solution: - it requires duplication of much of the configuration parsing code, which needs to be kept in sync with OpenLDAP's syntax and semantics (or worse, allow the syntax to diverge), and - it requires users to think of and nail down each and every potentially relevant option separately (note that current versions of libldap and pam_ldap silently ignore syntax errors in the config file, so one may very easily be in a false sense of security). - It does not stop libldap from opening files it shouldn't open in the first place. As Kurt Zeilenga already noted, a proper solution will require some redesign, so... I include 3 patches: one for libldap (against HEAD as of 20070216), and corresponding patches for nss_ldap-254 and pam_ldap-183. The first lines of the openldap patch (the changes to ldap.h) and the nss_ldap patch should tell you how it is supposed to work: libraries can obtain a private copy of the "globaloptions", in an opaque "LDAPContext" object, to be initialized in a safe way and independently from other copies of that structure. The existing struct globaloptions is used by default to stay compatible with existing programs. I'm willing to write more documentation too but I would like to get some some feedback on it first, Regards, Timo Felbinger --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="openldap.patch" This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. These modifications are not subject to any license of University of Potsdam. I, Timo Felbinger, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. diff -Nru openldap-src/include/ldap.h openldap-src-context/include/ldap.h --- openldap-src/include/ldap.h 2007-02-12 10:53:59.000000000 +0000 +++ openldap-src-context/include/ldap.h 2007-02-17 13:22:45.000000000 +0000 @@ -696,6 +696,8 @@ */ typedef struct ldap LDAP; +typedef struct ldapoptions LDAPContext; + #define LDAP_DEREF_NEVER 0x00 #define LDAP_DEREF_SEARCHING 0x01 #define LDAP_DEREF_FINDING 0x02 @@ -890,6 +892,12 @@ int option, LDAP_CONST void *invalue)); +LDAP_F( int ) +ldap_set_option_in_context LDAP_P(( + LDAPContext *context, + int option, + LDAP_CONST void *invalue)); + /* V3 REBIND Function Callback Prototype */ typedef int (LDAP_REBIND_PROC) LDAP_P(( LDAP *ld, LDAP_CONST char *url, @@ -1382,10 +1390,30 @@ LDAP **ldp )); LDAP_F( int ) +ldap_create_in_context LDAP_P(( + LDAP **ldp, + LDAPContext *context )); + +LDAP_F( int ) ldap_initialize LDAP_P(( LDAP **ldp, LDAP_CONST char *url )); +LDAP_F( int ) +ldap_initialize_in_context LDAP_P(( + LDAP **ldp, + LDAP_CONST char *url, + LDAPContext *context )); + +LDAP_F( int ) +ldap_create_context LDAP_P(( + LDAPContext **context, + char **directives )); + +LDAP_F( int ) +ldap_destroy_context LDAP_P(( + LDAPContext *context )); + /* * in tls.c */ diff -Nru openldap-src/include/ldap_pvt.h openldap-src-context/include/ldap_pvt.h --- openldap-src/include/ldap_pvt.h 2007-02-12 03:20:24.000000000 +0000 +++ openldap-src-context/include/ldap_pvt.h 2007-02-17 13:22:45.000000000 +0000 @@ -278,6 +278,8 @@ int option, void *arg )); LDAP_F (int) ldap_pvt_tls_set_option LDAP_P(( struct ldap *ld, int option, void *arg )); +LDAP_F (int) ldap_pvt_tls_set_option_2 LDAP_P(( struct ldapoptions *lo, struct ldap *ld, + int option, void *arg )); LDAP_F (void) ldap_pvt_tls_destroy LDAP_P(( void )); LDAP_F (int) ldap_pvt_tls_init LDAP_P(( void )); diff -Nru openldap-src/libraries/libldap/init.c openldap-src-context/libraries/libldap/init.c --- openldap-src/libraries/libldap/init.c 2007-02-05 19:32:44.000000000 +0000 +++ openldap-src-context/libraries/libldap/init.c 2007-02-17 13:22:45.000000000 +0000 @@ -124,6 +124,7 @@ #define MAX_LDAP_ENV_PREFIX_LEN 8 static void openldap_ldap_init_w_conf( + struct ldapoptions *gopts, const char *file, int userconf ) { char linebuf[ AC_LINE_MAX ]; @@ -131,10 +132,11 @@ int i; char *cmd, *opt; char *start, *end; - struct ldapoptions *gopts; - if ((gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { - return; /* Could not allocate mem for global options */ + if( ! gopts ) { + if ((gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { + return; /* Could not allocate mem for global options */ + } } if (file == NULL) { @@ -244,7 +246,7 @@ * (char**) p = LDAP_STRDUP(opt); break; case ATTR_OPTION: - ldap_set_option( NULL, attrs[i].offset, opt ); + ldap_set_option_in_context( gopts, attrs[i].offset, opt ); break; case ATTR_SASL: #ifdef HAVE_CYRUS_SASL @@ -253,7 +255,7 @@ break; case ATTR_TLS: #ifdef HAVE_TLS - ldap_int_tls_config( NULL, attrs[i].offset, opt ); + ldap_int_tls_config_in_context( gopts, attrs[i].offset, opt ); #endif break; case ATTR_OPT_TV: { @@ -285,7 +287,7 @@ static void openldap_ldap_init_w_sysconf(const char *file) { - openldap_ldap_init_w_conf( file, 0 ); + openldap_ldap_init_w_conf( NULL, file, 0 ); } static void openldap_ldap_init_w_userconf(const char *file) @@ -314,11 +316,11 @@ /* try ~/file */ sprintf(path, "%s" LDAP_DIRSEP "%s", home, file); - openldap_ldap_init_w_conf(path, 1); + openldap_ldap_init_w_conf(NULL, path, 1); /* try ~/.file */ sprintf(path, "%s" LDAP_DIRSEP ".%s", home, file); - openldap_ldap_init_w_conf(path, 1); + openldap_ldap_init_w_conf(NULL, path, 1); } if(path != NULL) { @@ -326,7 +328,7 @@ } /* try file */ - openldap_ldap_init_w_conf(file, 1); + openldap_ldap_init_w_conf(NULL, file, 1); } static void openldap_ldap_init_w_env( @@ -466,9 +468,10 @@ void ldap_int_initialize_global_options( struct ldapoptions *gopts, int *dbglvl ) { if (dbglvl) - gopts->ldo_debug = *dbglvl; + /* FIXME: currently ldo_debug is an always global option only, so we set both places: */ + gopts->ldo_debug = LDAP_INT_GLOBAL_OPT()->ldo_debug = *dbglvl; else - gopts->ldo_debug = 0; + gopts->ldo_debug = LDAP_INT_GLOBAL_OPT()->ldo_debug = 0; gopts->ldo_version = LDAP_VERSION2; gopts->ldo_deref = LDAP_DEREF_NEVER; @@ -531,7 +534,10 @@ char * ldap_int_hostname = NULL; #endif -void ldap_int_initialize( struct ldapoptions *gopts, int *dbglvl ) +void ldap_int_initialize( + struct ldapoptions *gopts, + int *dbglvl, + char **directives ) { if ( gopts->ldo_valid == LDAP_INITIALIZED ) { return; @@ -593,6 +599,19 @@ ldap_int_initialize_global_options(gopts, NULL); + if( directives ) { + for( ; *directives; ++directives ) { + if( ! strncmp( *directives, "file=", 5 ) ) { + openldap_ldap_init_w_conf( gopts, *directives + 5, 1 ); + continue; + } + /* add more directives here... */ + gopts->ldo_valid = LDAP_TRASHED_SESSION; + return; + } + return; + } + if( getenv("LDAPNOINIT") != NULL ) { return; } diff -Nru openldap-src/libraries/libldap/ldap-int.h openldap-src-context/libraries/libldap/ldap-int.h --- openldap-src/libraries/libldap/ldap-int.h 2007-02-15 00:42:23.000000000 +0000 +++ openldap-src-context/libraries/libldap/ldap-int.h 2007-02-17 13:22:45.000000000 +0000 @@ -417,7 +417,7 @@ LDAP_V ( struct ldapoptions ) ldap_int_global_options; -LDAP_F ( void ) ldap_int_initialize LDAP_P((struct ldapoptions *, int *)); +LDAP_F ( void ) ldap_int_initialize LDAP_P((struct ldapoptions *, int *, char **directives )); LDAP_F ( void ) ldap_int_initialize_global_options LDAP_P(( struct ldapoptions *, int *)); @@ -652,6 +652,9 @@ LDAP_F (int) ldap_int_tls_config LDAP_P(( LDAP *ld, int option, const char *arg )); +LDAP_F (int) ldap_int_tls_config_in_context LDAP_P(( struct ldapoptions *lo, + int option, const char *arg )); + LDAP_F (int) ldap_int_tls_start LDAP_P(( LDAP *ld, LDAPConn *conn, LDAPURLDesc *srv )); diff -Nru openldap-src/libraries/libldap/open.c openldap-src-context/libraries/libldap/open.c --- openldap-src/libraries/libldap/open.c 2007-02-12 03:20:24.000000000 +0000 +++ openldap-src-context/libraries/libldap/open.c 2007-02-17 13:45:19.000000000 +0000 @@ -87,27 +87,88 @@ return ld; } +int +ldap_free_context_internals( LDAPContext *context ) +{ + ldap_free_urllist( context->ldo_defludp ); +#ifdef HAVE_CYRUS_SASL + LDAP_FREE( context->ldo_def_sasl_authzid ); + LDAP_FREE( context->ldo_def_sasl_authcid ); + LDAP_FREE( context->ldo_def_sasl_realm ); + LDAP_FREE( context->ldo_def_sasl_mech ); +#endif + return LDAP_SUCCESS; +} + +/* public destructor of LDAPContext */ +int +ldap_destroy_context( LDAPContext *context ) +{ + if( context ) { + ldap_free_context_internals( context ); + free( context ); + } + return LDAP_SUCCESS; +} + +/* public constructor of LDAPContext */ +int +ldap_create_context( + LDAPContext **context, + /* directives: NULL-terminated list of initialization directives: + * - NULL: default initialization procedure (see ldap.conf(5)) + * - { NULL }: equivalent to LDAPNOINIT + * - { ..., "file=path", ... }: parse path like user-config file + */ + char **directives ) +{ + LDAPContext *lo; + + *context = NULL; + lo = ( LDAPContext * ) LDAP_CALLOC( 1, sizeof( LDAPContext ) ); + if( ! lo ) + return LDAP_NO_MEMORY; + + Debug( LDAP_DEBUG_TRACE, "ldap_create_context %p\n", lo, 0, 0 ); + + lo->ldo_valid = LDAP_UNINITIALIZED; + ldap_int_initialize( lo, NULL, directives ); + if( lo->ldo_valid != LDAP_INITIALIZED ) + return LDAP_LOCAL_ERROR; + *context = lo; + + return LDAP_SUCCESS; +} int ldap_create( LDAP **ldp ) { + return ldap_create_in_context( ldp, NULL ); +} + +int +ldap_create_in_context( LDAP **ldp, LDAPContext *gopts ) +{ LDAP *ld; - struct ldapoptions *gopts; *ldp = NULL; - /* Get pointer to global option structure */ - if ( (gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { - return LDAP_NO_MEMORY; - } - /* Initialize the global options, if not already done. */ - if( gopts->ldo_valid != LDAP_INITIALIZED ) { - ldap_int_initialize(gopts, NULL); - if ( gopts->ldo_valid != LDAP_INITIALIZED ) - return LDAP_LOCAL_ERROR; + if( ! gopts ) { + /* default is the global context */ + if ( (gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { + return LDAP_NO_MEMORY; + } + + /* Initialize the global options, if not already done. */ + if( gopts->ldo_valid != LDAP_INITIALIZED ) { + ldap_int_initialize(gopts, NULL, NULL); + } } + if( gopts->ldo_valid != LDAP_INITIALIZED ) + return LDAP_LOCAL_ERROR; + Debug( LDAP_DEBUG_TRACE, "ldap_create\n", 0, 0, 0 ); if ( (ld = (LDAP *) LDAP_CALLOC( 1, sizeof(LDAP) )) == NULL ) { @@ -167,13 +228,7 @@ nomem: ldap_free_select_info( ld->ld_selectinfo ); - ldap_free_urllist( ld->ld_options.ldo_defludp ); -#ifdef HAVE_CYRUS_SASL - LDAP_FREE( ld->ld_options.ldo_def_sasl_authzid ); - LDAP_FREE( ld->ld_options.ldo_def_sasl_authcid ); - LDAP_FREE( ld->ld_options.ldo_def_sasl_realm ); - LDAP_FREE( ld->ld_options.ldo_def_sasl_mech ); -#endif + ldap_free_context_internals( &ld->ld_options ); LDAP_FREE( (char *)ld ); return LDAP_NO_MEMORY; } @@ -215,11 +270,17 @@ int ldap_initialize( LDAP **ldp, LDAP_CONST char *url ) { + return ldap_initialize_in_context( ldp, url, NULL ); +} + +int +ldap_initialize_in_context( LDAP **ldp, LDAP_CONST char *url, LDAPContext *context ) +{ int rc; LDAP *ld; *ldp = NULL; - rc = ldap_create(&ld); + rc = ldap_create_in_context(&ld, context); if ( rc != LDAP_SUCCESS ) return rc; diff -Nru openldap-src/libraries/libldap/options.c openldap-src-context/libraries/libldap/options.c --- openldap-src/libraries/libldap/options.c 2007-02-06 22:02:47.000000000 +0000 +++ openldap-src-context/libraries/libldap/options.c 2007-02-17 13:22:45.000000000 +0000 @@ -97,16 +97,6 @@ { struct ldapoptions *lo; - /* Get pointer to global option structure */ - lo = LDAP_INT_GLOBAL_OPT(); - if (NULL == lo) { - return LDAP_NO_MEMORY; - } - - if( lo->ldo_valid != LDAP_INITIALIZED ) { - ldap_int_initialize(lo, NULL); - } - if(ld != NULL) { assert( LDAP_VALID( ld ) ); @@ -117,6 +107,18 @@ lo = &ld->ld_options; } + if( lo == NULL ) { + /* Get pointer to global option structure */ + lo = LDAP_INT_GLOBAL_OPT(); + if (NULL == lo) { + return LDAP_NO_MEMORY; + } + + if( lo->ldo_valid != LDAP_INITIALIZED ) { + ldap_int_initialize(lo, NULL, NULL); + } + } + if(outvalue == NULL) { /* no place to get to */ return LDAP_OPT_ERROR; @@ -347,19 +349,35 @@ } int +ldap_set_option_in_context( + LDAPContext *context, + int option, + LDAP_CONST void *invalue) +{ + return ldap_set_option_2( context, NULL, option, invalue ); +} + +int ldap_set_option( LDAP *ld, int option, LDAP_CONST void *invalue) { - struct ldapoptions *lo; - int *dbglvl = NULL; + return ldap_set_option_2( NULL, ld, option, invalue ); +} - /* Get pointer to global option structure */ - lo = LDAP_INT_GLOBAL_OPT(); - if (lo == NULL) { - return LDAP_NO_MEMORY; - } +/* + * ldap_set_option_2: can set options per LDAP handle or per context. + * if handle is given, the context is ignored. + */ +int +ldap_set_option_2( + struct ldapoptions *lo, + LDAP *ld, + int option, + LDAP_CONST void *invalue) +{ + int *dbglvl = NULL; /* * The architecture to turn on debugging has a chicken and egg @@ -370,10 +388,6 @@ dbglvl = (int *) invalue; } - if( lo->ldo_valid != LDAP_INITIALIZED ) { - ldap_int_initialize(lo, dbglvl); - } - if(ld != NULL) { assert( LDAP_VALID( ld ) ); @@ -384,6 +398,17 @@ lo = &ld->ld_options; } + if( lo == NULL ) { + /* Get pointer to global option structure */ + lo = LDAP_INT_GLOBAL_OPT(); + if (lo == NULL) { + return LDAP_NO_MEMORY; + } + if( lo->ldo_valid != LDAP_INITIALIZED ) { + ldap_int_initialize(lo, dbglvl, NULL); + } + } + switch(option) { case LDAP_OPT_REFERRALS: if(invalue == LDAP_OPT_OFF) { @@ -668,7 +693,7 @@ default: #ifdef HAVE_TLS - if ( ldap_pvt_tls_set_option( ld, option, (void *)invalue ) == 0 ) + if ( ldap_pvt_tls_set_option_2( lo, ld, option, (void *)invalue ) == 0 ) return LDAP_OPT_SUCCESS; #endif #ifdef HAVE_CYRUS_SASL diff -Nru openldap-src/libraries/libldap/tls.c openldap-src-context/libraries/libldap/tls.c --- openldap-src/libraries/libldap/tls.c 2007-01-24 22:38:26.000000000 +0000 +++ openldap-src-context/libraries/libldap/tls.c 2007-02-17 13:22:45.000000000 +0000 @@ -1178,8 +1178,20 @@ } int +ldap_int_tls_config_in_context( struct ldapoptions *lo, int option, const char *arg ) +{ + return ldap_int_tls_config_2( lo, NULL, option, arg ); +} + +int ldap_int_tls_config( LDAP *ld, int option, const char *arg ) { + return ldap_int_tls_config_2( NULL, ld, option, arg ); +} + +int +ldap_int_tls_config_2( struct ldapconfig *lo, LDAP *ld, int option, const char *arg ) +{ int i; switch( option ) { @@ -1190,7 +1202,7 @@ case LDAP_OPT_X_TLS_RANDOM_FILE: case LDAP_OPT_X_TLS_CIPHER_SUITE: case LDAP_OPT_X_TLS_DHFILE: - return ldap_pvt_tls_set_option( ld, option, (void *) arg ); + return ldap_pvt_tls_set_option_2( lo, ld, option, (void *) arg ); case LDAP_OPT_X_TLS_REQUIRE_CERT: case LDAP_OPT_X_TLS: @@ -1216,7 +1228,7 @@ } if (i >= 0) { - return ldap_pvt_tls_set_option( ld, option, &i ); + return ldap_pvt_tls_set_option_2( lo, ld, option, &i ); } return -1; #ifdef HAVE_OPENSSL_CRL @@ -1230,7 +1242,7 @@ i = LDAP_OPT_X_TLS_CRL_ALL ; } if (i >= 0) { - return ldap_pvt_tls_set_option( ld, option, &i ); + return ldap_pvt_tls_set_option_2( lo, ld, option, &i ); } return -1; #endif @@ -1334,7 +1346,12 @@ int ldap_pvt_tls_set_option( LDAP *ld, int option, void *arg ) { - struct ldapoptions *lo; + return ldap_pvt_tls_set_option_2( NULL, ld, option, arg ); +} + +int +ldap_pvt_tls_set_option_2( struct ldapoptions *lo, LDAP *ld, int option, void *arg ) +{ if( ld != NULL ) { assert( LDAP_VALID( ld ) ); @@ -1345,7 +1362,8 @@ lo = &ld->ld_options; - } else { + } + if( lo == NULL ) { /* Get pointer to global option structure */ lo = LDAP_INT_GLOBAL_OPT(); if ( lo == NULL ) { --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nss_ldap.patch" This patch file is derived from PADL Software (nss_ldap). All of the modifications to PADL Software represented in the following patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. These modifications are not subject to any license of University of Potsdam. I, Timo Felbinger, hereby place the following modifications to PADL Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. diff -Nru nss_ldap-254/config.h.in nss_ldap-254-context/config.h.in --- nss_ldap-254/config.h.in 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/config.h.in 2007-02-17 14:46:02.000000000 +0000 @@ -132,6 +132,9 @@ /* Define to 1 if you have the `ldap_initialize' function. */ #undef HAVE_LDAP_INITIALIZE +/* Define to 1 if you have the `ldap_create_context' function. */ +#undef HAVE_LDAP_CREATE_CONTEXT + /* Define to 1 if you have the `ldap_ld_free' function. */ #undef HAVE_LDAP_LD_FREE diff -Nru nss_ldap-254/configure nss_ldap-254-context/configure --- nss_ldap-254/configure 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/configure 2007-02-17 14:46:37.000000000 +0000 @@ -1,4 +1,6 @@ #! /bin/sh +echo please run autoconf first! +exit 1 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 diff -Nru nss_ldap-254/configure.in nss_ldap-254-context/configure.in --- nss_ldap-254/configure.in 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/configure.in 2007-02-17 14:46:02.000000000 +0000 @@ -297,7 +297,7 @@ AC_CHECK_FUNCS(sasl_auxprop_request) AC_CHECK_FUNCS(ldap_init ldap_get_lderrno ldap_parse_result ldap_memfree ldap_controls_free) AC_CHECK_FUNCS(ldap_ld_free ldap_explode_rdn ldap_set_option ldap_get_option) -AC_CHECK_FUNCS(ldap_sasl_interactive_bind_s ldap_initialize ldap_search_ext) +AC_CHECK_FUNCS(ldap_sasl_interactive_bind_s ldap_initialize ldap_search_ext ldap_create_context) AC_CHECK_FUNCS(ldap_create_control ldap_create_page_control ldap_parse_page_control) if test "$enable_ssl" \!= "no"; then AC_CHECK_FUNCS(ldapssl_client_init ldap_start_tls_s ldap_pvt_tls_set_option ldap_start_tls) diff -Nru nss_ldap-254/ldap-nss.c nss_ldap-254-context/ldap-nss.c --- nss_ldap-254/ldap-nss.c 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/ldap-nss.c 2007-02-17 14:46:02.000000000 +0000 @@ -137,7 +137,7 @@ /* * Global LDAP session. */ -static ldap_session_t __session = { NULL, NULL, 0, LS_UNINITIALIZED }; +static ldap_session_t __session = { NULL, NULL, NULL, 0, LS_UNINITIALIZED }; #if defined(HAVE_PTHREAD_ATFORK) || defined(HAVE_LIBC_LOCK_H) || defined(HAVE_BITS_LIBC_LOCK_H) static pthread_once_t __once = PTHREAD_ONCE_INIT; @@ -1003,7 +1003,7 @@ } static NSS_STATUS -do_init_session (LDAP ** ld, const char *uri, int defport) +do_init_session ( LDAPContext **ldap_context, LDAP ** ld, const char *uri, int defport) { int rc; int ldaps; @@ -1011,6 +1011,17 @@ char *p; NSS_STATUS stat; +#ifdef HAVE_LDAP_CREATE_CONTEXT + if( ! *ldap_context ) + { + /* make sure ldap config is read in a safe way */ + static const char *directives[2] = { "file=" NSS_LDAP_PATH_CONF, NULL }; + int rc = ldap_create_context( ldap_context, directives ); + if (rc != LDAP_SUCCESS) + return NSS_UNAVAIL; + } +#endif + ldaps = (strncasecmp (uri, "ldaps://", sizeof ("ldaps://") - 1) == 0); p = strchr (uri, ':'); /* we should be looking for the second instance to find the port number */ @@ -1028,7 +1039,11 @@ uri = uribuf; } +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_initialize_in_context (ld, uri, *ldap_context); +# else rc = ldap_initialize (ld, uri); +# endif #else if (strncasecmp (uri, "ldap://", sizeof ("ldap://") - 1) != 0) { @@ -1311,7 +1326,7 @@ assert (__session.ls_current_uri <= NSS_LDAP_CONFIG_URI_MAX); assert (cfg->ldc_uris[__session.ls_current_uri] != NULL); - stat = do_init_session (&__session.ls_conn, + stat = do_init_session ( &__session.ldap_context, &__session.ls_conn, cfg->ldc_uris[__session.ls_current_uri], cfg->ldc_port); if (stat != NSS_SUCCESS) diff -Nru nss_ldap-254/ldap-nss.h nss_ldap-254-context/ldap-nss.h --- nss_ldap-254/ldap-nss.h 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/ldap-nss.h 2007-02-17 14:46:02.000000000 +0000 @@ -416,12 +416,19 @@ typedef enum ldap_session_state ldap_session_state_t; +/* for readability, make sure LDAPContext is at least a dummy type: */ +#ifndef HAVE_LDAP_CREATE_CONTEXT +# define LDAPContext void +#endif + /* * convenient wrapper around pointer into global config list, and a * connection to an LDAP server. */ struct ldap_session { + /* the context, if supported */ + LDAPContext *ldap_context; /* the connection */ LDAP *ls_conn; /* pointer into config table */ --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pam_ldap.patch" This patch file is derived from PADL Software (pam_ldap). All of the modifications to PADL Software represented in the following patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. These modifications are not subject to any license of University of Potsdam. I, Timo Felbinger, hereby place the following modifications to PADL Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. diff -Nru pam_ldap-183/config.h.in pam_ldap-183-context/config.h.in --- pam_ldap-183/config.h.in 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/config.h.in 2007-02-17 14:55:38.000000000 +0000 @@ -33,6 +33,9 @@ /* Define if you have the ldap_initialize function. */ #undef HAVE_LDAP_INITIALIZE +/* Define if you have the ldap_create_context function. */ +#undef HAVE_LDAP_CREATE_CONTEXT + /* Define if you have the ldap_memfree function. */ #undef HAVE_LDAP_MEMFREE diff -Nru pam_ldap-183/configure pam_ldap-183-context/configure --- pam_ldap-183/configure 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/configure 2007-02-17 14:55:38.000000000 +0000 @@ -1,4 +1,6 @@ #! /bin/sh +echo Please run autoconf first! +exit 1 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 diff -Nru pam_ldap-183/configure.in pam_ldap-183-context/configure.in --- pam_ldap-183/configure.in 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/configure.in 2007-02-17 14:55:38.000000000 +0000 @@ -131,6 +131,7 @@ AC_CHECK_FUNCS(ldapssl_init ldap_start_tls_s ldap_pvt_tls_set_option) fi AC_CHECK_FUNCS(ldap_initialize) +AC_CHECK_FUNCS(ldap_create_context) AC_CHECK_FUNCS(ldap_sasl_bind ldap_sasl_interactive_bind_s) AC_CHECK_FUNCS(gethostbyname_r) diff -Nru pam_ldap-183/pam_ldap.c pam_ldap-183-context/pam_ldap.c --- pam_ldap-183/pam_ldap.c 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/pam_ldap.c 2007-02-17 15:08:39.000000000 +0000 @@ -155,6 +155,11 @@ #endif static int pam_debug_level __UNUSED__ = 0; +#ifndef HAVE_LDAP_CREATE_CONTEXT +# typedef LDAPContext void; +#endif +static LDAPContext *ldap_context = 0; + #ifdef HAVE_LDAPSSL_INIT static int ssl_initialized = 0; #endif @@ -1190,6 +1195,36 @@ struct timeval tv; #endif +#ifdef HAVE_LDAP_CREATE_CONTEXT + /* make sure ldap config is read in a safe and transparent way */ + if( ! ldap_context ) + { + char *directives[2]; + int rc; + + if( session->conf->configFile == NULL ) + { + directives[0] = NULL; + } + else + { + directives[0] = malloc (strlen (session->conf->configFile) + 6); + if( directives[0] == NULL ) + return PAM_BUF_ERR; + strcpy( directives[0], "file=" ); + strcpy( directives[0]+5, session->conf->configFile ); + } + directives[1] = NULL; + rc = ldap_create_context( &ldap_context, directives ); + _pam_drop( directives[0] ); + if (rc != LDAP_SUCCESS || ! ldap_context ) + { + syslog (LOG_ERR, "pam_ldap: ldap_create_context: %s", ldap_err2string (rc)); + return PAM_SERVICE_ERR; + } + } +#endif + #ifdef HAVE_LDAP_SET_OPTION if (session->conf->debug) { @@ -1253,7 +1288,11 @@ #ifdef HAVE_LDAP_INITIALIZE if (session->conf->uri != NULL) { +# ifdef HAVE_LDAP_CREATE_CONTEXT + int rc = ldap_initialize_in_context (&session->ld, session->conf->uri, ldap_context); +# else int rc = ldap_initialize (&session->ld, session->conf->uri); +# endif if (rc != LDAP_SUCCESS) { syslog (LOG_ERR, "pam_ldap: ldap_initialize %s", @@ -1400,8 +1439,12 @@ /* rand file */ if (session->conf->tls_randfile != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_RANDOM_FILE, - session->conf->tls_randfile); +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_RANDOM_FILE, session->conf->tls_randfile); if (rc != LDAP_SUCCESS) { syslog (LOG_ERR, @@ -1415,7 +1458,12 @@ /* ca cert file */ if (session->conf->tls_cacertfile != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CACERTFILE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CACERTFILE, session->conf->tls_cacertfile); if (rc != LDAP_SUCCESS) { @@ -1429,7 +1477,12 @@ if (session->conf->tls_cacertdir != NULL) { /* ca cert directory */ - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CACERTDIR, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CACERTDIR, session->conf->tls_cacertdir); if (rc != LDAP_SUCCESS) { @@ -1443,7 +1496,12 @@ if (session->conf->tls_checkpeer > -1) { /* require cert? */ - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_REQUIRE_CERT, &session->conf->tls_checkpeer); if (rc != LDAP_SUCCESS) { @@ -1457,7 +1515,12 @@ if (session->conf->tls_ciphers != NULL) { /* set cipher suite, certificate and private key: */ - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CIPHER_SUITE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CIPHER_SUITE, session->conf->tls_ciphers); if (rc != LDAP_SUCCESS) { @@ -1470,7 +1533,12 @@ if (session->conf->tls_cert != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CERTFILE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CERTFILE, session->conf->tls_cert); if (rc != LDAP_SUCCESS) { @@ -1483,7 +1551,12 @@ if (session->conf->tls_key != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_KEYFILE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_KEYFILE, session->conf->tls_key); if (rc != LDAP_SUCCESS) { --pf9I7BMVVzbSWLtt--

1 0

(ITS#4845) Back-perl is non working
by kiwi＠oav.net 19 Feb '07

19 Feb '07

Full_Name: Xavier Beaudouin Version: 2.3.33 OS: FreeBSD 6.2 URL: http://www.oav.net/tmp/openldap/ Submission from: (NULL) (82.225.248.92) Seems since 2.3 branch back-perl doesn't work files in http://www.oav.net/tmp/openldap/ works correctly on 2.2.xx branch but seems to returns nothing. Debug output : # /usr/local/libexec/slapd -d 4 -f /usr/local/etc/openldap/slapd.conf @(#) $OpenLDAP: slapd 2.3.33 (Feb 19 2007 23:24:47) $ root@diskless.home.oav.net:/usr/ports/net/openldap23-server/work/openldap-2.3.33/servers/slapd daemon_init: <null> => ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net,0) <= ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 Starting mailboxes => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 WARNING: No dynamic config support for database perl. slapd starting connection_get(8) send_ldap_result: err=0 matched="" text="" connection_get(8) => ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net,0) <= ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 SRCH "ou=mailboxes,dc=kazar,dc=net" 2 0 0 0 0 filter: (uid=kiwi(a)oav.net) attrs: We get a request for UID Looking for : (uid=kiwi(a)oav.net) We get some results... Sending -> dn : uid=kiwi(a)oav.net,ou=mailboxes,dc=kazar,dc=net objectClass : top objectClass : kazarPerson uid : kiwi(a)oav.net cn : Nom Prenom description : Sample description uidNumber : 10 gidNumber : 10 userPassword : Password homeDirectory : /home/test mailQuota : 50 CouriermailQuota : 50S str2entry: entry -1 has no dn str2entry(dn) failed send_ldap_result: err=0 matched="" text="" connection_get(8) To the query : # ldapsearch -h 127.0.0.1 -b ou=mailboxes,dc=kazar,dc=net uid=kiwi(a)oav.net # extended LDIF # # LDAPv3 # base <ou=mailboxes,dc=kazar,dc=net> with scope subtree # filter: uid=kiwi(a)oav.net # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Seems that str2entry from search.c doesn't get any value. Is that because internals of OpenLDAP has changed ? Thanks /Xavier

1 0

Re: (ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 18 Feb '07

18 Feb '07

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> In another step towards 100% remote admin/config, could we store >> StartTLS >> certs in the directory for slapd usage, replacing the need for: >> >> TLS* config path hardcoding.? > > One step at a time... Sure, I just wanted to have this wish recorded somewhere ;-) > Ordinarily I would store certs in an entry with the > same DN as the cert. This would mean creating a directory entry for your > server name, as well as directory entries for any client certs you wanted > to > use. That's probably not the ideal way to go here. > > We could store the certs directly, in attributes under cn=config. We could > also just store DNs in the config attributes, pointing to certs in some > other > database entries. Understood. > > -- > -- Howard Chu > Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by hyc＠symas.com 18 Feb '07

18 Feb '07

ghenry(a)suretecsystems.com wrote: > In another step towards 100% remote admin/config, could we store StartTLS > certs in the directory for slapd usage, replacing the need for: > > TLS* config path hardcoding.? One step at a time... Ordinarily I would store certs in an entry with the same DN as the cert. This would mean creating a directory entry for your server name, as well as directory entries for any client certs you wanted to use. That's probably not the ideal way to go here. We could store the certs directly, in attributes under cn=config. We could also just store DNs in the config attributes, pointing to certs in some other database entries. -- -- Howard Chu Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 18 Feb '07

18 Feb '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="Howard Chu"> >> ghenry(a)suretecsystems.com wrote: >> >>> Dear All, >>> >>> If we are to suppose that slapd-config is to provide 100% remote >>> configuration, >>> then directories should be created as set in: >>> >>> olcDbDirectory >>> set_lg_dir >>> >>> >>> Questions/Needs: >>> >>> 1. How to handle existing directories on mkdir? >>> 2. Some global cn=config setting to say what cn=config is allowed to do >>> 3. Plus many more I'm sure. >> >> Some of this touches on issues raised in ITS#4535. We probably need to >> answer >> those points first. > > Understood. > In another step towards 100% remote admin/config, could we store StartTLS certs in the directory for slapd usage, replacing the need for: TLS* config path hardcoding.? Gavin.

1 0

(ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 17 Feb '07

17 Feb '07

Full_Name: Gavin Henry Version: 2.3.34/2.4.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Just a quick to note that there are some overlays missing from slapd.overlays.5 in 2.4.4alpha and actual man pages. Also, relay and rwm are still marked as experimental in some places. grep experimental doc/man/man5/* doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay are experimental. doc/man/man5/slapo-rwm.5:This overlay is experimental. I'll help where I can, Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 17 Feb '07

17 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: > >> Dear All, >> >> If we are to suppose that slapd-config is to provide 100% remote >> configuration, >> then directories should be created as set in: >> >> olcDbDirectory >> set_lg_dir >> >> >> Questions/Needs: >> >> 1. How to handle existing directories on mkdir? >> 2. Some global cn=config setting to say what cn=config is allowed to do >> 3. Plus many more I'm sure. > > Some of this touches on issues raised in ITS#4535. We probably need to > answer > those points first. Understood. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > Chief Architect, OpenLDAP http://www.openldap.org/project/ >

1 0

ITS#4535 back-config can allow break-ins
by hyc＠symas.com 17 Feb '07

17 Feb '07

The first issue here was in regards to protection for the config backend when running the tests in the test suite. That was addressed mainly by using a randomly generated rootpw for cn=config in all of the tests. Also the default ACL for the config backend is explicitly set to "access to * by * none". In terms of the potential attacks on a server through back-config - it's obvious to me that you have to treat access to back-config the same as you would treat SSH credentials for a root user on the machine. That was one of the main reasons I decided to make cn=config only usable by its rootdn in 2.3. But since you really should be able to delegate authority, we added regular ACL support for 2.4. So it still comes down to having sane ACLs configured. Most of the attacks listed here require a user to have shell access to the machine, and write access to relevant filesystems. Frankly I think these attack scenarios are contrived - if you have untrusted users logging in to your system, you have other problems already. re: a meta-config file - No. The design goal here is to remove all limitations that prevent totally remote administration of the server, not add new ones. Artificial restrictions, just like artificially restricting 2.3 to rootdn only, will only impair usability and eventually get removed. re: lstat/fstat to prevent use of symlinks - No. There are too many valid uses for symlinks. What might make sense would be to fstat targets and check that they are owned by the current user and are not world-writable. We might also include root-owned directories that are world-writable with the sticky bit set. re: Documentation - sure. re: slaptools with -r/-u/-g - That's been discussed in ITS#4719. The consensus there seems (to me) to be that people with root access better know wth they're doing. re: adding dangerous database configurations - this raises a question about the config DIT. It implies a need for individual containers for backends, databases, and modules, so that you can configure write access to their children attribute. Otherwise, at the moment, we have no way to give fine grained access as to who can create what entries. The other alternative is to make back-config's add handler check for wadd access to the objectclass attribute of new entries, which would be oddly inconsistent with regular backend behavior. I specifically omitted such containers in the original DIT because I assumed only a rootDN, and with the object types essentially coded into their RDNs, the containers were superfluous. I still consider such containers redundant, and would lean toward the objectclass ACL check, which we can also make value-dependent to control exactly what types of databases an administrator can add. Assuming we have fine-grain control over what databases can be added, there should be no further consideration of whether to allow back-passwd, back-perl, or whatever. If an authorized admin wants to add them, let them. Fine-grained restriction of modules is pretty much irrelevant - all we have to go on is a name, which need not bear any relation to the module's actual content. The best we can do here is check ownership, as with other path-related items. re: Can one add "some-attribute:< file:///foobar" over the protocol to a back-ldif database to read file /foobar? I don't think so, but...? No. The URL is processed by the LDIF reader, which in this case is the client. At this point we should probably split this ITS into a few different ones. The main point, vulnerability in the test suite, has already been addressed. The doc-related issues obviously should go to a Doc bug. That leaves path ownership/permission checking for one bug, and fine-grained control of Adds as a separate bug. -- -- Howard Chu Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by hyc＠symas.com 17 Feb '07

17 Feb '07

ghenry(a)suretecsystems.com wrote: > Dear All, > > If we are to suppose that slapd-config is to provide 100% remote configuration, > then directories should be created as set in: > > olcDbDirectory > set_lg_dir > > > Questions/Needs: > > 1. How to handle existing directories on mkdir? > 2. Some global cn=config setting to say what cn=config is allowed to do > 3. Plus many more I'm sure. Some of this touches on issues raised in ITS#4535. We probably need to answer those points first. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Leaks from test050 in re24
by Pierangelo Masarati 15 Feb '07

15 Feb '07

I see some small leaks in test050; I'm posting valgrind's output below, unfortunately I have no time to investigate them right now. p. ==23984== 71,251 (5,744 direct, 65,507 indirect) bytes in 153 blocks are definitely lost in loss record 7 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821A879: ber_memrealloc_x (memory.c:307) ==23984== by 0x821B178: ber_bvreplace_x (memory.c:706) ==23984== by 0x80F5734: slap_queue_csn (ctxcsn.c:168) ==23984== by 0x80F582D: slap_get_csn (ctxcsn.c:191) ==23984== by 0x8088AE3: slap_add_opattrs (add.c:601) ==23984== by 0x8123546: ldif_back_add (ldif.c:799) ==23984== by 0x806C426: config_setup_ldif (bconfig.c:3495) ==23984== by 0x806C7CD: read_config (bconfig.c:3573) ==23984== by 0x80622ED: main (main.c:747) ==23984== 65,507 bytes in 497 blocks are indirectly lost in loss record 8 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821ABD7: ber_dupbv_x (memory.c:504) ==23984== by 0x80C5A80: objectClassPretty (schema_prep.c:100) ==23984== by 0x80A09D6: ordered_value_pretty (value.c:496) ==23984== by 0x809BACA: slap_mods_check (modify.c:577) ==23984== by 0x8087AD0: do_add (add.c:160) ==23984== by 0x807F866: connection_operation (connection.c:1129) ==23984== by 0x807FD33: connection_read_thread (connection.c:1257) ==23984== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==23984== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==23984== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24033== 183 (60 direct, 123 indirect) bytes in 6 blocks are definitely lost in loss record 5 of 7 ==24033== at 0x4004405: malloc (vg_replace_malloc.c:149) ==24033== by 0x821A75F: ber_memalloc_x (memory.c:226) ==24033== by 0x821A7B2: ber_memalloc (memory.c:242) ==24033== by 0x809FB6C: value_add_one (value.c:96) ==24033== by 0x80F5EFC: slap_parse_sync_cookie (ldapsync.c:238) ==24033== by 0x81CD1EA: syncprov_parseCtrl (syncprov.c:2768) ==24033== by 0x80B7266: slap_parse_ctrl (controls.c:580) ==24033== by 0x80B7A0D: get_ctrls (controls.c:749) ==24033== by 0x80822C2: do_search (search.c:165) ==24033== by 0x807F866: connection_operation (connection.c:1129) ==24033== by 0x807FD33: connection_read_thread (connection.c:1257) ==24033== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24033== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24033== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24000== 70,778 (5,176 direct, 65,602 indirect) bytes in 142 blocks are definitely lost in loss record 8 of 9 ==24000== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==24000== by 0x821A7F0: ber_memcalloc_x (memory.c:280) ==24000== by 0x809F775: ch_calloc (ch_malloc.c:104) ==24000== by 0x8088695: slap_mods2entry (add.c:472) ==24000== by 0x80E8A14: syncrepl_message_to_entry (syncrepl.c:1723) ==24000== by 0x80E5840: do_syncrep2 (syncrepl.c:790) ==24000== by 0x80E6C23: do_syncrepl (syncrepl.c:1164) ==24000== by 0x807FD51: connection_read_thread (connection.c:1259) ==24000== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24000== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24000== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so)

1 0

Re: (ITS#4420) Hanging CLOSE_WAIT connections in ldap-backend
by aar＠cpan.org 15 Feb '07

15 Feb '07

I'm experiencing the CLOSE_WAIT problem with slapd 2.3.32 on MacOS X (PPC). Cached connections aren't being leaked but they aren't closed on idle-timeout and they remain in CLOSE_WAIT state after the remote host has gone. Compile options: ./configure --enable-rewrite --enable-ldap --enable-meta --enable-proxycache --enable-spasswd slapd.conf: =========== database ldap suffix "dc=AddressBooks,dc=example,dc=com" uri ldap://localhost:8080 idle-timeout 2 idassert-bind bindmethod=none binddn="cn=Administrative Identity,dc=sssss" credentials="admin_password" authzID="dn:cn=Sandbox,dc=local,dc=example,dc=com" mode=self authz=proxyAuthz (The problem appears also without idle-timeout.) Steps to reproduce: 1. start slapd 2. connect to slapd and do some queries 3. disconnect the proxied server (for example by killing it) 4. netstat -a still shows the connection as CLOSE_WAIT Debug: when running slapd with "-d 5", nothing is printed when the connection is closed by the remote host (i.e. when I kill it), so slapd isn't probably catching the event at all. - alessandro ranellucci.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by hyc＠symas.com 14 Feb '07

14 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >> symbol lookup error: >> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >> ldap_back_proxy_authz_ctrl > > Howard debugged this on IRC and it turns out that our (mine and > _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd > without the unixodbc lib fixes it. Yes, so there are two potential issues - the unixodbc shared library seems to be statically linked with an older version of libltdl. I didn't run into this problem on my build because I don't have that odbc library. Anyway, due to the link order of the libraries, the lt_dlopen in this library gets used before the linker resolves to the system's libltdl.so, and it seems that this version of lt_dlopen doesn't automatically export the symbols of modules that it loads. I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is because there is a new dependency in 2.3.33 between back-meta and back-ldap. The other part of this is that the slapd binary should not be getting linked against -lodbc when back_sql is built as a module. Although, if back-sql is built statically, and other backends are dynamic, this problem may still crop up. It seems that fixing -lodbc would be required then. -- -- Howard Chu Chief Architect, 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#4830) test030-relay fails with back-meta
by ahasenack＠terra.com.br 14 Feb '07

14 Feb '07

On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: > ==> rewrite_context_apply [depth=1] string='(objectClass=*)' > ==> rewrite_context_apply [depth=1] res={0,'NULL'} > [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" > /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: > symbol lookup error: > +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: > ldap_back_proxy_authz_ctrl Howard debugged this on IRC and it turns out that our (mine and _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd without the unixodbc lib fixes it.

1 0

(ITS#4843) test023-refint fails
by michael＠stroeder.com 14 Feb '07

14 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.2.127) >>>>> Starting test023-refint ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing slapd referential integrity operations... Searching unmodified database... Testing modrdn... Using ldapsearch to check dependents new rdn... Comparing ldapsearch results against original... comparison failed - modify operations did not complete correctly >>>>> ./scripts/test023-refint failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

Re: Can slapd run with only one thread to operate (ITS#4842)
by hyc＠symas.com 13 Feb '07

13 Feb '07

seuler.shi(a)gmail.com wrote: > ------=_Part_100396_21317226.1171418508303 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > What I want to do is to do operations in OpenLDAP server serially, not > concurrency > in the server. If the back database is configured to load all data in > memory, then overhead > of executing a operation is approximately equal the overhead of lock > relevant overhead in > database. So if requests are serially handled in openldap server, the lock > subsystem can > be remove from backend database. The lock subsystem can only be removed if you only permit read operations. I've done a number of tests with the locks commented out of the backend; certainly it is faster, by about 20% for single threaded operation. But that's not much of a gain considering the reduction in utility. Meanwhile, turning off threads means you cannot take advantage of multiple-processor systems, which is definitely a loss. All in all there is no benefit to pursuing this. You can spend your time exploring as you wish, but none of us will spend any of our time retreading ground that we've already studied extensively. > I just want to compare difference on performance under these two strategy. > > Although I use ./configure --without-threads, there are still two work > threads,(info thread in > gdb: there are two pthread_cond_wait records.) > > Would you give me some suggestion to reach the goal, serially handle the > received requests > in openldap server? > > Thanks a lot! > > 2007/2/14, Pierangelo Masarati <openldap-its(a)openldap.org>: >> Slapd by design needs at least 2 threads to work. That code is there >> exactly to >> avoid silly configurations with less than 2 threads. You're free to >> modify it, >> but then you shouldn't complain. Otherwise, if you don't want slapd to >> use >> threads you can compile it --without-threads (not --without--threads like >> you >> typed). >> >> If you could tell us what your real problem is with threads, maybe we >> wouldn't >> both waste time in this rather pointless issue. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Can slapd run with only one thread to operate (ITS#4842)
by seuler.shi＠gmail.com 13 Feb '07

13 Feb '07

------=_Part_100396_21317226.1171418508303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What I want to do is to do operations in OpenLDAP server serially, not concurrency in the server. If the back database is configured to load all data in memory, then overhead of executing a operation is approximately equal the overhead of lock relevant overhead in database. So if requests are serially handled in openldap server, the lock subsystem can be remove from backend database. I just want to compare difference on performance under these two strategy. Although I use ./configure --without-threads, there are still two work threads,(info thread in gdb: there are two pthread_cond_wait records.) Would you give me some suggestion to reach the goal, serially handle the received requests in openldap server? Thanks a lot! 2007/2/14, Pierangelo Masarati <openldap-its(a)openldap.org>: > > Slapd by design needs at least 2 threads to work. That code is there > exactly to > avoid silly configurations with less than 2 threads. You're free to > modify it, > but then you shouldn't complain. Otherwise, if you don't want slapd to > use > threads you can compile it --without-threads (not --without--threads like > you > typed). > > If you could tell us what your real problem is with threads, maybe we > wouldn't > both waste time in this rather pointless issue. > > p. > ------=_Part_100396_21317226.1171418508303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div>What I want to do is to do operations in OpenLDAP server serially, not concurrency</div> <div>in the server. If the back database is configured to load all data in memory, then overhead</div> <div>of executing a operation is approximately equal the overhead of lock relevant overhead in </div> <div>database. So if requests are serially handled in openldap server, the lock subsystem can</div> <div>be remove from backend database. </div> <div> </div> <div>I just want to compare difference on performance under these two strategy.</div> <div> </div> <div>Although I use ./configure --without-threads, there are still two work threads,(info thread in</div> <div>gdb: there are two pthread_cond_wait records.)</div> <div> </div> <div>Would you give me some suggestion to reach the goal, serially handle the received requests</div> <div>in openldap server?</div> <div> </div> <div>Thanks a lot!</div> <div> </div> <div><span class="gmail_quote">2007/2/14, Pierangelo Masarati <<a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>>:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Slapd by design needs at least 2 threads to work.  That code is there exactly to<br>avoid silly configurations with less than 2 threads.  You're free to modify it, <br>but then you shouldn't complain.  Otherwise, if you don't want slapd to use<br>threads you can compile it --without-threads (not --without--threads like you<br>typed).<br><br>If you could tell us what your real problem is with threads, maybe we wouldn't <br>both waste time in this rather pointless issue.<br><br>p.<br></blockquote></div><br> ------=_Part_100396_21317226.1171418508303--

1 0

Re: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by ando＠sys-net.it 13 Feb '07

13 Feb '07

hyc(a)symas.com wrote: > Hi, > I have not been paying attention to these changes since Ando was working > on them. You'll have to ask him for their update status. Sorry for overlooking yur previous message. Yes, I'm keeping that patch sort of updated, but keeping it in sync with HEAD was a pain due to the many changes that occurred in that code. I'm not sure it's ready for commit right now, and I'm not sure it works as intended, given the lack of specs (every implementor seem to have their own idea of haw that's supposed to work, and willing to interoperate, despite claims, seems to be their last concern). Preserving compatibility with re23 might not be an option, and I don't think we want that stuff to go in re23 right now. > Since you've already posted a query to the ITS, I think that would be the > appropriate place to continue the conversation. > > Looking over the ITS just now, I would say the tweak to register the > changelog overlay type is unnecessary. Nor can you fairly deprecate the > LogStyle parameter, since that appears to be the only way to invoke the > SunOne workaround. > > All in all I understand your motivations for pursuing this feature. Despite > my dislike for broken specs and broken code, I will not prevent this patch > from going in. But you should realize that wrong is wrong, and just because > Novell, Sun, and Oracle software is broken doesn't mean we should be broken > too. There are other IdM packages out there. I'll be committing something workable soon. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by hyc＠symas.com 13 Feb '07

13 Feb '07

hyc(a)symas.com wrote: > All in all I understand your motivations for pursuing this feature. Despite > my dislike for broken specs and broken code, I will not prevent this patch > from going in. But you should realize that wrong is wrong, and just because > Novell, Sun, and Oracle software is broken doesn't mean we should be broken > too. There are other IdM packages out there. While this is hardly the place for commercial endorsements, I should note that while Neil Dunbar wrote that changelog overlay for HP's purposes, we (Symas) convinced HP to adopt the accesslog format instead and HP does not rely on the changelog any more. If you're looking for software that actually conforms to open specs with some degree of technical merit, you might consider looking there, if you can't convince your current vendors to fix their products. > > Rieger, Sebastian wrote: >> Hi, >> >> I submitted a patch to update the old overlay of Neil Dunbar to OpenLDAP >> 2.3. It works for our identity management (using Novell IDM 3.01) - see >> ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I would like >> to ask, wether the patch to your accesslog that offers changelog >> functionality (ITS#4656) is likely to be committed to CVS HEAD in the near >> future. In this case I won't maintain a separate overlay. Thanks in advance >> for a quick reply, we really need changelog functionality as Novell, Sun and >> Oracle seem to depend on it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

AW: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by sebastian.rieger＠gwdg.de 13 Feb '07

13 Feb '07

This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C74F6A.DE443C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the quick reply, I'd continue the conversation with Ando and = via IST, thanks for putting them on CC:. Can you name the IdM packages you = refer to, that implement a replication mechanism that is compatible with = OpenLDAP? We tested: - Microsoft Identity Integration Server: only flat-file LDAP support = (using LDIF) (until Gemini version ~2008) - no replication, just full synchronization - Siemens DirX: using a full search over all objects (Novell Identity Manager can do so either, but you're unable to detect moved objects = then, as it looks like a delete and add of the object, and performance is low, as = for every sync cycle a full search over the tree is necessary) Oracle and Sun using changelog were already mentioned... Maybe IBM? or do you refer to the meta backend module for OpenLDAP? Thanks in advance for the advice... -- MfG Sebastian Rieger Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen=20 Am Fassberg - 37077 G=F6ttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des = DFN =FCberpr=FCft werden: = https://ca.gwdg.de/certs/root-classic/root-ca-cert.der -----Urspr=FCngliche Nachricht----- Von: Howard Chu [mailto:hyc@symas.com]=20 Gesendet: Dienstag, 13. Februar 2007 12:20 An: Rieger, Sebastian Cc: Heuer, Konrad; ando(a)OpenLDAP.org; openldap-its(a)OpenLDAP.org Betreff: Re: ITS#4656 OpenLDAP accesslog overlay using "changelog = dialect" Hi, I have not been paying attention to these changes since Ando was = working on them. You'll have to ask him for their update status. Since you've already posted a query to the ITS, I think that would be = the appropriate place to continue the conversation. Looking over the ITS just now, I would say the tweak to register the changelog overlay type is unnecessary. Nor can you fairly deprecate the LogStyle parameter, since that appears to be the only way to invoke the SunOne workaround. All in all I understand your motivations for pursuing this feature. = Despite my dislike for broken specs and broken code, I will not prevent this = patch from going in. But you should realize that wrong is wrong, and just = because Novell, Sun, and Oracle software is broken doesn't mean we should be = broken too. There are other IdM packages out there. Rieger, Sebastian wrote: > Hi, >=20 > I submitted a patch to update the old overlay of Neil Dunbar to=20 > OpenLDAP 2.3. It works for our identity management (using Novell IDM=20 > 3.01) - see ITS#4685. As my patch needs cleanup to get into OpenLDAP=20 > HEAD I would like to ask, wether the patch to your accesslog that=20 > offers changelog functionality (ITS#4656) is likely to be committed to = > CVS HEAD in the near future. In this case I won't maintain a separate=20 > overlay. Thanks in advance for a quick reply, we really need changelog = > functionality as Novell, Sun and Oracle seem to depend on it. >=20 > -- > MfG >=20 > Sebastian Rieger >=20 > Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen = Am=20 > Fassberg - 37077 G=F6ttingen > Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 >=20 > Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des=20 > DFN =FCberpr=FCft werden:=20 > https://ca.gwdg.de/certs/root-classic/root-ca-cert.der >=20 --=20 -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/ ------=_NextPart_000_00AD_01C74F6A.DE443C50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXujCCBHUw ggNdoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNVBAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMg LSBHMDEwHhcNMDUwMjI4MDAyOTM3WhcNMTMwNDI4MDAyOTM3WjBbMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQ Q0EgQ2xhc3NpYyAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvNTUXjQCVx w87yo/67c+J0bhhl6sfVNVO87Jk2WMY/lPC/E1cmq6iOAe2fV10FhexSG2zIp8XqbrlPNN7s3sy/ 0jUQfHegDqWWuCDQfWLkdWHTiDhIfhcCTdLaXDRshAxE18zDJzKPu3EMeU/N5dju7/azQVi2wkzM fM9I5aARVcrYVH+OanfQo1+yCoQupE9XaGpZRCr2w1X6pf1v0JcqakuC/LBX9uk0IPtMz9Y6frOP AvCldCn8pWNdQrT6VPmJpI7zDCm6/PCAZy82cImzkfbxGpMVxNBxC3Zwgc4zT9Cn22e0Hms8Q3cm cr8hbFb3icuGnMGKp50e9L2eOokCAwEAAaOCAUIwggE+MB0GA1UdDgQWBBSDrjvMk+EkUnrpIE+D cKIq3XsvATAfBgNVHSMEGDAWgBSDrjvMk+EkUnrpIE+DcKIq3XsvATAPBgNVHRMBAf8EBTADAQH/ MIHHBgNVHR8Egb8wgbwwXKBaoFiGVmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0 aWZpY2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMFygWqBY hlZodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2NsYXNz aWMvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQDaFaWOgZRQO/CaU+xUQPj3mgnJ5MJug0ad1d+L k+K1iTUp8r9fLxnamypzVeVrHFbtC5zk9lxx8qDMiDc6sd9HYRJNikJUme/EfHPkzlbn6hTXuL6+ ZKdCeK3qQHnltEjg/NLUIaU/bukFmhOk6NrnU5XNTKcEeOJ47t0K2EWWZ6rN3Ji0FU444hGO73tl C5t1ACWaMYFakmylmagwdZPIVnA3qKFmVRTPcz3Cel56UyA2U6n9qQR8zZzkltIwx2/6SHt2EqQN u3g6iDyOWzIfsb0bRVHmvHQx3KCUZb5JNy3iue8yIB6WMbKZ+eJuwZl1Q0PJ87BjsHYglO3JX+Oy MIIFhjCCBG6gAwIBAgIEBnsYQDANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJERTETMBEGA1UE ChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQQ0Eg Q2xhc3NpYyAtIEcwMTAeFw0wNTA0MTIwOTUzNTRaFw0wOTA0MTIwOTUzNTRaMIGcMQswCQYDVQQG EwJERTFCMEAGA1UEChM5R2VzZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52 ZXJhcmJlaXR1bmcgbWJIMQswCQYDVQQLEwJDQTEcMBoGA1UEAxMTR1dERy1DQSBFYmVuZSAxIEcw MjEeMBwGCSqGSIb3DQEJARYPZ3dkZy1jYUBnd2RnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3y/2S6yGKZhpv+DwWTSH4/szbEB2yPEJUgZz5kaVId/17wKdRNKd9el03skx/ind 1IJ27YaoOybmRp5pwuNSAL7SEC2neEKcLCqkV+jDcLusV2mQ/ykgMs7No5csyhS6FxuUwBK18BlF E7tfraK3J6iyOJxzjFKB+3/ZWhasXnwEtzOUc5hRry9bTNYpyLueUa5DLR5nqIRwk1OWbx3IARbC RKrxdAupzwEAjWwz8ar2aDHgsBH41D7sfDY9wRxH04sW6K9D0BANEx+o8KhbsPQv6l0HQE7p0n6Y XQhUo5QhZ8GMfEiIh39sE1turDLut7I4bCZwrIjPT9gJqhFMWwIDAQABo4ICDjCCAgowHQYDVR0O BBYEFPP+0UOeITsrZQ3Y8arSBsKbVgajMB8GA1UdIwQYMBaAFIOuO8yT4SRSeukgT4Nwoirdey8B MA8GA1UdEwEB/wQFMAMBAf8wgccGA1UdHwSBvzCBvDBcoFqgWIZWaHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY3Jscy9yb290 LWNhLWNybC5jcmwwXKBaoFiGVmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZp Y2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHcBggrBgEF BQcBAQSBzzCBzDBkBggrBgEFBQcwAoZYaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBk BggrBgEFBQcwAoZYaHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24v eDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDAOBgNVHQ8BAf8EBAMC AQYwDQYJKoZIhvcNAQEFBQADggEBADFx3Ji676DYFd/XIY9KcsNopLqtgF5Ixr2irPOPpZ/X/zta Gss3l18EdKCCBFqhwCrd2lFOfowbxnWZ1L+WRS/+0x4a8MZoAUWyfk+pLLgv3OucY4ZhAGP5F0XJ wLRlskcnLVvt3HFQ9JsEjHo45u/QiKbZJGFPVZb5elpphRtAVTiRisw5UTiV57m07vcJhUtrt6wh 7389cz2aYYdlViMZtuaE0Z+LlSElAe4/U6tOowoR+06qDjjFNLjQ1P3fnmBPRo2zWidaLiZcfD3f qjxBgJolgeS+gS3YePj2M6NAUTu+1XKAbrFJUyrCI+qPkEcVq3yK6FkZbbhla+BKQrcwggZUMIIF PKADAgECAgou6MIgAAAAAASaMA0GCSqGSIb3DQEBBQUAMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEVi ZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFm dCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMC REUxCjAIBgNVBAUTATIwHhcNMDYxMTA5MTMzNDU3WhcNMDcwOTIwMTA1ODAwWjCBvjELMAkGA1UE BhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEzARBgNVBAcTCkdvZXR0aW5nZW4xPjA8BgNV BAoTNUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5n MRkwFwYDVQQDExBTZWJhc3RpYW4gUmllZ2VyMScwJQYJKoZIhvcNAQkBFhhzZWJhc3RpYW4ucmll Z2VyQGd3ZGcuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN+JMyvFWWLIl0gDV5t9edUF qJCNFHH/aDm40I6MZLkYZ6eyLpRVmvIQ1+KBLP8Qjagiz1HwEqwMBDNPABq50yYCHpLmKFy+BCEH r4Cjoz2AhSm4BqUhjy/XnFOqeAReo9MJfrJeslCPbfaqVV7APQl4VqALnxnDJl/1PJ4++CiLAgMB AAGjggL9MIIC+TALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHQYDVR0OBBYEFMxqWUeIRKOu1OVQe7WDZwKzQJlGMB8GA1UdIwQYMBaAFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGvBgNVHR8EgacwgaQwgaGggZ6ggZuGTmh0dHA6Ly91c2VyLWNhLmd3 ZGcuZGUvQ2VydEVucm9sbC9HV0RHLUNBJTIwRWJlbmUlMjAyJTIwR2VuZXJpYy1DQSUyMEcwMi4x LmNybIZJaHR0cDovL3BjYS5nd2RnLmRlL2NybC9nd2RnLWNhL2ViZW5lMi9nMDIuMS9nd2RnLWNh LWViZW5lMi1nZW5lcmljLWNhLmNybDCB0wYIKwYBBQUHAQEEgcYwgcMwagYIKwYBBQUHMAGGXmh0 dHA6Ly91c2VyLWNhLmd3ZGcuZGUvQ2VydEVucm9sbC91c2VyLWNhLmd3ZGcuZGVfR1dERy1DQSUy MEViZW5lJTIwMiUyMEdlbmVyaWMtQ0ElMjBHMDIuMS5jcnQwVQYIKwYBBQUHMAGGSWh0dHA6Ly9w Y2EuZ3dkZy5kZS9jcmwvZ3dkZy1jYS9lYmVuZTIvZzAyLjEvZ3dkZy1jYS1lYmVuZTItZ2VuZXJp Yy1jYS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhZ2OO4GrnU+tkQWF84sDhK7MIS2H kIMrg8myPwIBZAIBAzBKBgNVHSAEQzBBMD8GCysGAQQBgZ1IMgEBMDAwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG0wNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMA0GCSqGSIb3DQEBBQUAA4IBAQCASq3lwDZ/ o7RuoZxqmuGCZPKlVuoBsQGaNJnoGUMBoq/7UBHRym4EpMuB8wf+NxPxhcSOxUR3UwDKE3p0VnVE O//hD6CFwbed83Wn6nv4O4jHJDxTAs0JJGomtrNxFxa5NwSUHq8ujf0DSr2Zn+yq8KzmNVjuANNe sbxvtvO3rr8pLh66m4QsgvOtGZpDeeJRpJM8eN9hf9HcIrtnCNP/KN8HGESiozUB0h0ZasH9yTQZ f/K0VCTTttPnXg3cF+g+bWMc0gGQzR40oVzTt4ggC0G68gRh2yTlQxRjMxZBS7vkWBGhEYoJoLHE TQv5oNafPL4UZGIW4SjLjWiR5mUZMIIHWzCCBkOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnDEL MAkGA1UEBhMCREUxQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hl IERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UECxMCQ0ExHDAaBgNVBAMTE0dXREctQ0EgRWJl bmUgMSBHMDIxHjAcBgkqhkiG9w0BCQEWD2d3ZGctY2FAZ3dkZy5kZTAeFw0wNTA5MjAxMDU4MDBa Fw0wNzA5MjAxMDU4MDBaMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBH MDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFm dGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC62IidFd5KC11HewNoQh8DG8jcJI1fdNIf/ETt d4vOMZRRQG5+WhETBhH0d6pXjZ+V8dhlMiekFq2RpFYPictQFnEt5M49iGfX6V3PIKkaFtFTIZj0 QbGN7BWTpcCfTw6L9VwPA3olG1QYABl16Ea9mHT6nGfvwYyiadnzHCAI1XTFeF1UzOKM8EemZvGa oQncG8QUt1uqskfcLJ18ASM6GY/C108p0E9hUx2V24BQDdLdCUB6BzcW/SQdBqjRaW51mPPMxn/p bqXWrgUwkiYJOqkDY6qVUtvKGCZIumQdKxnoSB5X7tna2widH50xNX5VdMe/qnYZPLuEnbzrkOo5 AgMBAAGjggOrMIIDpzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjBuBglghkgBhvhCAQ0E YRZfU3Vib3JkaW5hdGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHZXNlbGxzY2hhZnQgZnVl ciB3aXNzZW5zY2hhZnRsaWNoZSBEYXRlbnZlcmFyYmVpdHVuZyBtYkgwHQYDVR0OBBYEFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGGBgNVHSMEfzB9gBTz/tFDniE7K2UN2PGq0gbCm1YGo6FfpF0wWzEL MAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNV BAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMgLSBHMDGCBAZ7GEAwGgYDVR0RBBMwEYEPZ3dkZy1j YUBnd2RnLmRlMAkGA1UdEgQCMAAwQgYJYIZIAYb4QgEEBDUWM2h0dHA6Ly9jYS5nd2RnLmRlL2Ny bC9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNybDBCBglghkgBhvhCAQMENRYzaHR0cDovL2Nh Lmd3ZGcuZGUvY3JsL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3JsMIGABgNVHR8EeTB3MDmg N6A1hjNodHRwOi8vY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5jcmww OqA4oDaGNGh0dHA6Ly9wY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5j cmwwgZcGCCsGAQUFBwEBBIGKMIGHMEEGCCsGAQUFBzAChjVodHRwOi8vY2EuZ3dkZy5kZS9jZXJ0 cy9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNydDBCBggrBgEFBQcwAoY2aHR0cDovL3BjYS5n d2RnLmRlL2NlcnRzL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3J0MCAGCWCGSAGG+EIBAgQT FhFodHRwOi8vY2EuZ3dkZy5kZTAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NhLmd3ZGcuZGUvcG9s aWN5L2luZGV4Lmh0bWwwTQYDVR0gBEYwRDBCBg0rBgEEAYGdSDIBAwEBMDEwLwYIKwYBBQUHAgEW I2h0dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQBj KNeFKWGSWFjcy1fR1UHC5+MdmiTUfzHVeRbLuoGOTkbjYEbjE3+FNhGgRJJwKoDU1jQXLGGBzLQT dZcZj3QO0926SpshKNmW0zVIwf9gbAzFZ17Zgfns/BenJ7hTRl4m5aHTodkmJSKNvqwWOCFTTX9H RYRiSuDC10QYRH6S7MqyZ5Gkhtdq9iLVik8Q2RIS7OIoJgYUkLOG+tZ1rtQmWb3U6p/WwF4t5CAp ErqoJ1f427lLOj0EPOsXJUcwf+km6kkcIrKopv63HTWw7HmQHLGXajf5KbZXumwcG0Z2RCZN4OE2 yfQgRi8wmhj3pSKE4ylcz7Y9ExWdWh5YJAfMMYIDhzCCA4MCAQEwgaQwgZUxKTAnBgNVBAMTIEdX REctQ0EgRWJlbmUgMiBHZW5lcmljLUNBIEcwMi4xMQswCQYDVQQLEwJjYTFCMEAGA1UEChM5R2Vz ZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52ZXJhcmJlaXR1bmcgbWJIMQsw CQYDVQQGEwJERTEKMAgGA1UEBRMBMgIKLujCIAAAAAAEmjAJBgUrDgMCGgUAoIICODAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAyMTMxMTMxMjFaMCMGCSqGSIb3 DQEJBDEWBBSwSnJ1bnf4txKRhhP5cPI5qmC8oDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTCBtQYJKwYBBAGCNxAEMYGnMIGkMIGVMSkwJwYDVQQDEyBHV0RH LUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2Vs bHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkG A1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowgbcGCyqGSIb3DQEJEAILMYGnoIGkMIGV MSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2Ex QjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJi ZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowDQYJKoZIhvcN AQEBBQAEgYBrUMIWY8INUcy7LXqf14+Xlac8VcW5yqtR62zQzlQckIioP+K7t1EGe30zRc+ouMPC Z/03XAqTzk2CV9oI9fSIjwkN6Q9dTCiO5jbDiIGDqcF2k5Zkcwk5ebXkiWu51XjtBvj9zFvDUJmd DZXSmr5/oz2pK+GXv5kQVKlCeF9hqwAAAAAAAA== ------=_NextPart_000_00AD_01C74F6A.DE443C50--

1 0

Re: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect"
by hyc＠symas.com 13 Feb '07

13 Feb '07

Hi, I have not been paying attention to these changes since Ando was working on them. You'll have to ask him for their update status. Since you've already posted a query to the ITS, I think that would be the appropriate place to continue the conversation. Looking over the ITS just now, I would say the tweak to register the changelog overlay type is unnecessary. Nor can you fairly deprecate the LogStyle parameter, since that appears to be the only way to invoke the SunOne workaround. All in all I understand your motivations for pursuing this feature. Despite my dislike for broken specs and broken code, I will not prevent this patch from going in. But you should realize that wrong is wrong, and just because Novell, Sun, and Oracle software is broken doesn't mean we should be broken too. There are other IdM packages out there. Rieger, Sebastian wrote: > Hi, > > I submitted a patch to update the old overlay of Neil Dunbar to OpenLDAP > 2.3. It works for our identity management (using Novell IDM 3.01) - see > ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I would like > to ask, wether the patch to your accesslog that offers changelog > functionality (ITS#4656) is likely to be committed to CVS HEAD in the near > future. In this case I won't maintain a separate overlay. Thanks in advance > for a quick reply, we really need changelog functionality as Novell, Sun and > Oracle seem to depend on it. > > -- > MfG > > Sebastian Rieger > > Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen > Am Fassberg - 37077 Göttingen > Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 > > Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des DFN > überprüft werden: https://ca.gwdg.de/certs/root-classic/root-ca-cert.der > -- -- Howard Chu Chief Architect, 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#2240
by hyc＠symas.com 13 Feb '07

13 Feb '07

Gavin Henry wrote: > <quote who="Howard Chu"> >> Gavin Henry wrote: >>> hyc(a)symas.com said the following on 12/02/07 11:04: >>>> I've written up all of the remaining missing pages noted in this ITS. >>>> Someone >>>> else should review the docs to double-check and see if anything was >>>> omitted. >>>> I'll leave it up to someone else to add to RE23 if desired, otherwise >>>> we'll >>>> just leave these for RE24. >>> >>> I can't see any of these in man3 at: >>> >>> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… >>> >>> Am I looking in the wrong place? >> They all show up for me... >> >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-sockbuf.3 >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-types.3 >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_bind.3 >> (ITS#3349) >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_controls.3 >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_memory.3 >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_open.3 >> (ITS#4662) >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_tls.3 >> > > Must have been "early morning blind eyes" ;-) Thanks for checking. Please also double-check the corresponding .links files to make sure all the named functions are accounted for... -- -- Howard Chu Chief Architect, 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#2240
by ghenry＠suretecsystems.com 13 Feb '07

13 Feb '07

<quote who="Howard Chu"> > Gavin Henry wrote: >> hyc(a)symas.com said the following on 12/02/07 11:04: >>> I've written up all of the remaining missing pages noted in this ITS. >>> Someone >>> else should review the docs to double-check and see if anything was >>> omitted. >>> I'll leave it up to someone else to add to RE23 if desired, otherwise >>> we'll >>> just leave these for RE24. >> >> >> I can't see any of these in man3 at: >> >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… >> >> Am I looking in the wrong place? > > They all show up for me... > > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-sockbuf.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-types.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_bind.3 > (ITS#3349) > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_controls.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_memory.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_open.3 > (ITS#4662) > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_tls.3 > Must have been "early morning blind eyes" ;-) Thanks.

1 0

(ITS#4842) Can slapd run with only one thread to operate
by seuler.shi＠gmail.com 13 Feb '07

13 Feb '07

Full_Name: Seuler.Shi Version: 2.3.30 OS: SUSE server 9.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) The threads parameter in slapd.conf can not be configured below 2. I pretend to eleminate this limit by removing the folloing code in servers\slapd\bconfig.c file ================================================================= if ( c->value_int < 2 ) { snprintf( c->msg, sizeof( c->msg ), "threads=%d smaller than minimum value 2", c->value_int ); Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); return 1; } else if ( c->value_int > 2 * SLAP_MAX_WORKER_THREADS ) { snprintf( c->msg, sizeof( c->msg ), "warning, threads=%d larger than twice the default (2*%d=%d); YMMV", c->value_int, SLAP_MAX_WORKER_THREADS, 2 * SLAP_MAX_WORKER_THREADS ); Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); } ==================================================================== After rebuilding the modified code, the slapd can not operate request and return. I have tried another method: build the code with configuring --without--threads, the newly bebuilt code can start but can not accpet request and return and segment fault error, then the slapd crashes. How to modify the code to eleminate limit of the minimum number of threads? Thanks a lot!

1 0

Re: ITS#2240
by hyc＠symas.com 13 Feb '07

13 Feb '07

Gavin Henry wrote: > hyc(a)symas.com said the following on 12/02/07 11:04: >> I've written up all of the remaining missing pages noted in this ITS. Someone >> else should review the docs to double-check and see if anything was omitted. >> I'll leave it up to someone else to add to RE23 if desired, otherwise we'll >> just leave these for RE24. > > > I can't see any of these in man3 at: > > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… > > Am I looking in the wrong place? They all show up for me... http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-sockbuf.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-types.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_bind.3 (ITS#3349) http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_controls.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_memory.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_open.3 (ITS#4662) http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_tls.3 -- -- Howard Chu Chief Architect, 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#2240
by ghenry＠suretecsystems.com 13 Feb '07

13 Feb '07

hyc(a)symas.com said the following on 12/02/07 11:04: > I've written up all of the remaining missing pages noted in this ITS. Someone > else should review the docs to double-check and see if anything was omitted. > I'll leave it up to someone else to add to RE23 if desired, otherwise we'll > just leave these for RE24. I can't see any of these in man3 at: http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… Am I looking in the wrong place? Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions.(tm) http://www.suretecsystems.com/

1 0

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 12 Feb '07

12 Feb '07

Sure. New core dumps and binary file is at http://mariska.inter.net.il/~imriz/slapd-core.tar.gz Please notice that the previous dump was from FreeBSD ports (OpenLDAP version 2.3.33). This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the following configure options: ./configure --with-threads=posix --with-tls=openssl --enable-dynamic --without-cyrus-sasl --enable-modules --localstatedir=/var/ db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite --enable-null=mod --enabl e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- prefix=/usr/local --enable-debug -----Original Message----- From: Howard Chu [mailto:openldap-its@OpenLDAP.org] Sent: Tuesday, February 13, 2007 1:14 AM To: Imri Zvik Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) It looks like this core is from a binary without debug symbols present, can you recompile with debugging enabled and get a new stack trace and core file?

1 0

(ITS#4841) slapd+pcache keeps crashing on FreeBSD 6.2
by imriz＠co.zahav.net.il 12 Feb '07

12 Feb '07

Full_Name: Imri Zvik Version: 2.3.33 OS: FreeBSD 6.2 URL: http://mariska.inter.net.il/~imriz/75624-slapd.core Submission from: (NULL) (213.8.76.159) slapd keeps crashing every couple of hours, backtrace is as follows: (gdb) bt #0 0xa83ae58a in strcasecmp () from /lib/libc.so.6 #1 0x080a934c in an_find () #2 0x080d59bd in overlay_init () #3 0x080d61dc in overlay_init () #4 0x080c837d in overlay_op_walk () #5 0x080c8599 in overlay_op_walk () #6 0x080c8616 in overlay_op_walk () #7 0x0806ebc3 in fe_op_search () #8 0x0806e6e2 in do_search () #9 0x0806c147 in connection_done () #10 0xa816b936 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.3.so.2 #11 0xa83025cf in pthread_create () from /usr/lib/libthr.so.2 #12 0x00000000 in ?? () complete core dump is provided.

1 0

ITS#2240
by hyc＠symas.com 12 Feb '07

12 Feb '07

I've written up all of the remaining missing pages noted in this ITS. Someone else should review the docs to double-check and see if anything was omitted. I'll leave it up to someone else to add to RE23 if desired, otherwise we'll just leave these for RE24. -- -- Howard Chu Chief Architect, 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#4840) Typo in comment within ldap.h
by hyc＠symas.com 12 Feb '07

12 Feb '07

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: not relevant here > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.29.37) > > >>From ldap.h: > > -------------------------------------------------------------------------- > LDAP_F( void ) > ldap_value_free LDAP_P(( /* deprecated, use ldap_values_free_len */ > char **vals )); > #endif > -------------------------------------------------------------------------- > > I guess the comment should mention "ldap_value_free_len". > ^^ > > Ciao, Michael. Fixed in HEAD... Same typo is in RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4840) Typo in comment within ldap.h
by michael＠stroeder.com 12 Feb '07

12 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: not relevant here URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.29.37) >From ldap.h: -------------------------------------------------------------------------- LDAP_F( void ) ldap_value_free LDAP_P(( /* deprecated, use ldap_values_free_len */ char **vals )); #endif -------------------------------------------------------------------------- I guess the comment should mention "ldap_value_free_len". ^^ Ciao, Michael.

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by hyc＠symas.com 11 Feb '07

11 Feb '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > I'm seeing occasional failures of syncrepl-related tests in HEAD. In case of > test043, results differend once, but after repeating the test everything went > smoth. > > In some cases test045 resulted in a core dump: > In this case, numcsns is 8 because syncprov incorrectly tested for > BER_BVISEMPTY() instead of BER_BVISNULL when creating the csn array: Good catch. > Fixing that still results in a test failure, but without core dump: > apparently, none of the modifications made it into the consumer. > After another try, things just go smooth again... keep testing. We need to change these fixed delays for replication into explicit checks like you did for test049. Otherwise it will take too long to loop the tests enough times to trigger an error... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4839) syncrepl-related tests fail randomly
by ando＠sys-net.it 10 Feb '07

10 Feb '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I'm seeing occasional failures of syncrepl-related tests in HEAD. In case of test043, results differend once, but after repeating the test everything went smoth. In some cases test045 resulted in a core dump: (gdb) bt #0 0x00418060 in memchr () from /lib/tls/libc.so.6 #1 0x080f5eef in slap_parse_csn_sid (csn=0x87b6798) at ldapsync.c:128 #2 0x080f5fa1 in slap_parse_csn_sids (csns=0x87b6778, numcsns=8) at ldapsync.c:148 #3 0x081ce0c6 in syncprov_db_open (be=0x8770bd0) at syncprov.c:2544 #4 0x080f31de in over_db_func (be=0x8770bd0, which=db_open) at backover.c:61 #5 0x080f35dd in over_db_open (be=0x8770bd0) at backover.c:173 #6 0x0808e1d1 in backend_startup_one (be=0x8770bd0) at backend.c:212 #7 0x0808e65e in backend_startup (be=0x8770bd0) at backend.c:303 #8 0x080b578a in slap_startup (be=0x0) at init.c:248 #9 0x08062ee1 in main (argc=8, argv=0xbffa3554) at main.c:919 In this case, numcsns is 8 because syncprov incorrectly tested for BER_BVISEMPTY() instead of BER_BVISNULL when creating the csn array: (gdb) p a->a_vals[0]@8 $2 = {{ bv_len = 40, bv_val = 0x87deb60 "20070210093621.965471Z#000000#000#000000" }, { bv_len = 7566177, bv_val = 0x0 }, { bv_len = 24, bv_val = 0x11 "" }, { bv_len = 1820143995, bv_val = 0x706164 "�s����F���\211L$\004\213E\b\211\004$�\037���\205�\211E�\017\204\r����\033���=�\206��tb\213M�\213\001�@\030\002\215v" }, { bv_len = 541392999, bv_val = 0x21 "" }, { bv_len = 142432232, bv_val = 0x65 "" }, { bv_len = 142470176, bv_val = 0x0 }, { bv_len = 142305208, bv_val = 0x0 }} Fixing that still results in a test failure, but without core dump: bash-3.00$ SLAPD_DEBUG=stats ./run test045 Cleaning up test run directory leftover from previous run. Running ./scripts/test045-syncreplication-proxied... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 15 seconds for syncrepl to receive changes... 2 < Comparing retrieved entries from master and slave... test failed - master and slave databases differ apparently, none of the modifications made it into the consumer. After another try, things just go smooth again... keep testing. p.

1 0

Re: (ITS#4838) test027-emptydn fails with current had
by hyc＠symas.com 09 Feb '07

09 Feb '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.156.155) > > > It seems to fail since that last commit to back-bdb. The slapd instance starts > fine, but the ldapsearch with an empty base fails with NO_SUCH_OJBECT. > > Running ./scripts/test027-emptydn... > running defines.sh > Running slapadd to build "dc=example,dc=com" slapd database... > Running slapadd to build empty DN slapd database... > Starting slapd on TCP/IP port 9011... > Testing slapd empty DN handling... > Searching database... > ldapsearch failed (32)! Thanks, fixed. All tests pass. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4838) test027-emptydn fails with current had
by rhafer＠suse.de 09 Feb '07

09 Feb '07

Full_Name: Ralf Haferkamp Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.156.155) It seems to fail since that last commit to back-bdb. The slapd instance starts fine, but the ldapsearch with an empty base fails with NO_SUCH_OJBECT. Running ./scripts/test027-emptydn... running defines.sh Running slapadd to build "dc=example,dc=com" slapd database... Running slapadd to build empty DN slapd database... Starting slapd on TCP/IP port 9011... Testing slapd empty DN handling... Searching database... ldapsearch failed (32)!

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by kurt＠OpenLDAP.org 08 Feb '07

08 Feb '07

On Feb 8, 2007, at 5:12 PM, rklein(a)deep-field.com wrote: > "The passwords from SunONE are stored in SSHA format. This means that > for each password a salt has been generated. The password + salt is > encoded > using > SHA1 algorithm. That encoded string + salt is stored in the > password field. > > Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE > uses an 8 byte salt and OpenLDAP uses a 4 byte salt. For hash generation, yes. But the hash checking code will compute the salt size on a per check basis. > So, when OpenLDAP looks at the password strings, it gets the wrong > salt, > and will fail to decode the password." Conclusion doesn't follow. Have you actually tested this? I believe it just works. -- Kurt

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by ghenry＠suretecsystems.com 08 Feb '07

08 Feb '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="rklein(a)deep-field.com"> >> We want to migrate from using SunLDAP to using OpenLDAP. This involves >> migrating >> the existing user data from SunLDAP to OpenLDAP. We were able to do this >> successfully, however, we found an incompatibility in password >> encryption. >> Specifically: >> >> "The passwords from SunONE are stored in SSHA format. This means that >> for each password a salt has been generated. The password + salt is >> encoded >> using >> SHA1 algorithm. That encoded string + salt is stored in the password >> field. >> >> Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE >> uses an 8 byte salt and OpenLDAP uses a 4 byte salt. >> >> So, when OpenLDAP looks at the password strings, it gets the wrong salt, >> and will fail to decode the password." >> >> We're therefore requesting that OpenLDAP provide an option for an 8 byte >> salt >> for the SSHA encryption that is compatible with the SunONE encryption. >> This will >> allow us to convert to OpenLDAP without requiring all of our users to >> reset >> their passwords. Thanks. >> > > Hi, > > Sorry, I don't mean to point out the obvious, but OpenLDAP is an Open > Source project which means the source code is available for you to patch. > However, you can edit passwd.c: libraries/liblutil/passwd.c and change the salt to 8 yourself: #define SALT_SIZE 4 See how you get on. Gavin.

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by quanah＠stanford.edu 08 Feb '07

08 Feb '07

--On Thursday, February 08, 2007 5:12 PM +0000 rklein(a)deep-field.com wrote: > Full_Name: Ruth Klein > Version: 2.3.24 > OS: Solaris 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.247.247.122) > > > We want to migrate from using SunLDAP to using OpenLDAP. This involves > migrating the existing user data from SunLDAP to OpenLDAP. We were able > to do this successfully, however, we found an incompatibility in password > encryption. Specifically: > > "The passwords from SunONE are stored in SSHA format. This means that > for each password a salt has been generated. The password + salt is > encoded using > SHA1 algorithm. That encoded string + salt is stored in the password > field. > Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE > uses an 8 byte salt and OpenLDAP uses a 4 byte salt. > > So, when OpenLDAP looks at the password strings, it gets the wrong salt, > and will fail to decode the password." > > We're therefore requesting that OpenLDAP provide an option for an 8 byte > salt for the SSHA encryption that is compatible with the SunONE > encryption. This will allow us to convert to OpenLDAP without requiring > all of our users to reset their passwords. Thanks. It should be as simple as changing: passwd.c:#define SALT_SIZE 4 to passwd.c:#define SALT_SIZE 8 One of the nice things about open source... In any case, perhaps this should be considered an enhancement request for an option in slapd.conf to set the salt size there. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by ghenry＠suretecsystems.com 08 Feb '07

08 Feb '07

<quote who="rklein(a)deep-field.com"> > We want to migrate from using SunLDAP to using OpenLDAP. This involves > migrating > the existing user data from SunLDAP to OpenLDAP. We were able to do this > successfully, however, we found an incompatibility in password encryption. > Specifically: > > "The passwords from SunONE are stored in SSHA format. This means that > for each password a salt has been generated. The password + salt is > encoded > using > SHA1 algorithm. That encoded string + salt is stored in the password > field. > > Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE > uses an 8 byte salt and OpenLDAP uses a 4 byte salt. > > So, when OpenLDAP looks at the password strings, it gets the wrong salt, > and will fail to decode the password." > > We're therefore requesting that OpenLDAP provide an option for an 8 byte > salt > for the SSHA encryption that is compatible with the SunONE encryption. > This will > allow us to convert to OpenLDAP without requiring all of our users to > reset > their passwords. Thanks. > Hi, Sorry, I don't mean to point out the obvious, but OpenLDAP is an Open Source project which means the source code is available for you to patch. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#4837) SunLDAP to OpenLDAP migration problem
by rklein＠deep-field.com 08 Feb '07

08 Feb '07

Full_Name: Ruth Klein Version: 2.3.24 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.247.247.122) We want to migrate from using SunLDAP to using OpenLDAP. This involves migrating the existing user data from SunLDAP to OpenLDAP. We were able to do this successfully, however, we found an incompatibility in password encryption. Specifically: "The passwords from SunONE are stored in SSHA format. This means that for each password a salt has been generated. The password + salt is encoded using SHA1 algorithm. That encoded string + salt is stored in the password field. Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE uses an 8 byte salt and OpenLDAP uses a 4 byte salt. So, when OpenLDAP looks at the password strings, it gets the wrong salt, and will fail to decode the password." We're therefore requesting that OpenLDAP provide an option for an 8 byte salt for the SSHA encryption that is compatible with the SunONE encryption. This will allow us to convert to OpenLDAP without requiring all of our users to reset their passwords. Thanks.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 08 Feb '07

08 Feb '07

Howard Chu writes: > That's a good idea but would require more work to define indexer > functions for each matching rule before we could do anything further. I was thinking to only support it for existing indexer functions. Would 'index cn :caseExactMatch' require a new indexer function? > My reason for posting this ITS is that we already have the index > available for the DN relativeMatch rules, so we should be taking > advantage of them. Fair enough. -- Regards, Hallvard

1 0

Re: (ITS#4836) dynamic configuration support for ppolicy
by hyc＠symas.com 08 Feb '07

08 Feb '07

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.25.211.20) > > > Dynamic configuration would remove the need for restarting slapd in many > situations (add a schema, add an index), however sites requiring ppolicy on any > database in running in the same slapd cannot use dynamic configuration since > ppolicy in REL_ENG_2_3 does not have dynamic configuration support. > > ppolicy in HEAD does have such support, but the version from head does not > compile on REL_ENG_2_3, and various bugfixes since it was originally added > depend on features in HEAD. > It would be useful to have dynamic configuration support for ppolicy in > REL_ENG_2_3. "Would be useful" doesn't sound like a bug report to me, and RE23 really shouldn't be receiving enhancements at this stage of its cycle. I've added the necessary patches to RE23, but understand that requests of this sort are much less likely to be honored going forward. New code will be in RE24. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4836) dynamic configuration support for ppolicy
by bgmilne＠staff.telkomsa.net 08 Feb '07

08 Feb '07

Full_Name: Buchan Milne Version: OPENLDAP_REL_ENG_2_3 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.211.20) Dynamic configuration would remove the need for restarting slapd in many situations (add a schema, add an index), however sites requiring ppolicy on any database in running in the same slapd cannot use dynamic configuration since ppolicy in REL_ENG_2_3 does not have dynamic configuration support. ppolicy in HEAD does have such support, but the version from head does not compile on REL_ENG_2_3, and various bugfixes since it was originally added depend on features in HEAD. It would be useful to have dynamic configuration support for ppolicy in REL_ENG_2_3.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

kurt(a)OpenLDAP.org wrote: > On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > >> h.b.furuseth(a)usit.uio.no wrote: >>> Suggestion: Generalize a bit and support the slapd.conf statement >>> >>> index attr :matchingRule >>> >>> Can be used with the extended filter (attr:matchingRule:=foo), >>> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >>> >> That's a good idea but would require more work to define indexer >> functions >> for each matching rule before we could do anything further. My >> reason for >> posting this ITS is that we already have the index available for >> the DN >> relativeMatch rules, so we should be taking advantage of them. > > I note that dn2id is only useful for entryDN matching. For > matching of arbitrary DN attributes, additional indexing would > be needed. True. For the examples I've seen, this is good enough, and it's trivial to support it. > It may be possible/reasonable to integrate indexing > for this with component matching indexing... which, of course, > needs work. Yes, and time... -- -- Howard Chu Chief Architect, 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#4834) DN matching rules should be indexed
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Suggestion: Generalize a bit and support the slapd.conf statement >> >> index attr :matchingRule >> >> Can be used with the extended filter (attr:matchingRule:=foo), >> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >> > That's a good idea but would require more work to define indexer > functions > for each matching rule before we could do anything further. My > reason for > posting this ITS is that we already have the index available for > the DN > relativeMatch rules, so we should be taking advantage of them. I note that dn2id is only useful for entryDN matching. For matching of arbitrary DN attributes, additional indexing would be needed. It may be possible/reasonable to integrate indexing for this with component matching indexing... which, of course, needs work. -- Kurt > > -- > -- Howard Chu > Chief Architect, 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#4556 ditStructureRules
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 7, 2007, at 11:22 PM, hyc(a)symas.com wrote: > I've often thought about adding support here, but it looks like an > all-or-nothing proposition. I.e., when you have a server that uses > ditStructureRules, you must actually define a full set of rules > otherwise you > cannot add any user entries to the directory at all. This would be > a pretty > drastic change for people accustomed to the current behavior, where > you can > put any entry you like anywhere you like. Beginners have a hard > enough time > just getting their first two entries into the directory; requiring > the use of > ditStructureRules would seem to just make a bad situation worse. It may be possible to do something similar to what was done for ditContentRules, which are also all or none in X.500 (no rules defined means no use of aux objectcleasses in X.500). In OpenLDAP, no rules means any use of auxiliary classes is okay. But if you add a rule, any rule, then these defined rules must be followed. -- Kurt > > Possibly we could make it a configurable option - enable them with a > per-database setting, defaulting to off to preserve the current > behavior. > Fully aligning with X.500 practices would have to wait for a new > generation > of server. E.g., we currently support the use of subdatabases using > subordinate/glue. These provide some of the notion of X.500 > Administrative > Areas, except their definitions reside in the cn=config tree, not as > subentries of the main DIT. Providing full subentry-based > administration > would be a major change in how the server is operated and how the > DIT is > administered. Something for OpenLDAP 3.0. > -- > -- Howard Chu > Chief Architect, 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#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

h.b.furuseth(a)usit.uio.no wrote: > Suggestion: Generalize a bit and support the slapd.conf statement > > index attr :matchingRule > > Can be used with the extended filter (attr:matchingRule:=foo), > or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. > That's a good idea but would require more work to define indexer functions for each matching rule before we could do anything further. My reason for posting this ITS is that we already have the index available for the DN relativeMatch rules, so we should be taking advantage of them. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4835) dyngroup.schema needs clarification
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Our current schema definition defines groupOfURLs as a structural objectclass. This matches the definition used by Netscape, where this schema originates. However, the published documentation describes it as an auxiliary objectclass, and indeed the Netscape/iPlanet/Sun/FDS/RHDS servers use it as if it were an auxiliary. http://www.redhat.com/docs/manuals/dir-server/schema/6.1/oc_dir.htm#1316814 This ambiguity arises because Netscape/iPlanet/Sun/FDS/RHDS don't actually implement the LDAP/X.500 data model correctly. There are many areas where they fail to implement the model, but in this specific case they simply don't enforce schema definitions. http://forum.java.sun.com/thread.jspa?threadID=5016864&messageID=9034636 And it appears that their developers didn't consider this a problem worthy of attention. But it's creating confusion for other users. http://www.openldap.org/lists/openldap-software/200609/msg00121.html I think the right thing to do here is change our definition to AUXILIARY since that matches its actual usage. It won't match the published definitions, but those definitions are demonstrably wrong.

1 0

ITS#4556 ditStructureRules
by hyc＠symas.com 07 Feb '07

07 Feb '07

I've often thought about adding support here, but it looks like an all-or-nothing proposition. I.e., when you have a server that uses ditStructureRules, you must actually define a full set of rules otherwise you cannot add any user entries to the directory at all. This would be a pretty drastic change for people accustomed to the current behavior, where you can put any entry you like anywhere you like. Beginners have a hard enough time just getting their first two entries into the directory; requiring the use of ditStructureRules would seem to just make a bad situation worse. Possibly we could make it a configurable option - enable them with a per-database setting, defaulting to off to preserve the current behavior. Fully aligning with X.500 practices would have to wait for a new generation of server. E.g., we currently support the use of subdatabases using subordinate/glue. These provide some of the notion of X.500 Administrative Areas, except their definitions reside in the cn=config tree, not as subentries of the main DIT. Providing full subentry-based administration would be a major change in how the server is operated and how the DIT is administered. Something for OpenLDAP 3.0. -- -- Howard Chu Chief Architect, 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#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Tested, seems to work correctly now. Thanks. On Wednesday 07 February 2007 16:18, Howard Chu wrote: > Thanks, fixed. -- Ralf

1 0

Re: (ITS#4833) Back-config chokes when adding database
by hyc＠symas.com 07 Feb '07

07 Feb '07

Thanks, fixed. rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.144.248) > > > When adding a database without an explicit index set olcDatabase-Attribute slapd > crashes (find stack backtrace below). > > This is the LDIF I tried to add: > > dn: olcDatabase=ldap,cn=config > objectclass: olcDatabaseConfig > objectclass: olcldapconfig > olcDatabase: ldap > olcsuffix: cn=test > olcrootdn: cn=admin,cn=test > olcrootpw: secret > olcdburi: ldap://my.ldap.server > > When using the correct index, '{1}' in my case it works as expected. I suspect > something's wrong the special handling of the {-1} index of frontendDB, but > wasn't able to track it down completely. > > Here's the backtrace: -- -- Howard Chu Chief Architect, 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#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 07 Feb '07

07 Feb '07

Suggestion: Generalize a bit and support the slapd.conf statement index attr :matchingRule Can be used with the extended filter (attr:matchingRule:=foo), or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. -- Regards, Hallvard

1 0

(ITS#4834) DN matching rules should be indexed
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The dnSubtreeMatch, dnOneLevelMatch, dnSubordinateMatch, and dnSuperiorMatch matching rules added in OpenLDAP 2.3 can be used in extended filter clauses to get finer control over the scope of a search. Currently back-bdb/back-hdb don't do any indexing for extended filters, which can make these filters pretty expensive to evaluate. But these specific rules can take advantage of the dn2id index, which already maintains all the necessary index information. If these extensions are going to be used frequently, we should add index support here.

1 0

(ITS#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Full_Name: Ralf Haferkamp Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.144.248) When adding a database without an explicit index set olcDatabase-Attribute slapd crashes (find stack backtrace below). This is the LDIF I tried to add: dn: olcDatabase=ldap,cn=config objectclass: olcDatabaseConfig objectclass: olcldapconfig olcDatabase: ldap olcsuffix: cn=test olcrootdn: cn=admin,cn=test olcrootpw: secret olcdburi: ldap://my.ldap.server When using the correct index, '{1}' in my case it works as expected. I suspect something's wrong the special handling of the {-1} index of frontendDB, but wasn't able to track it down completely. Here's the backtrace: #0 0x0000000000415083 in config_add_internal (cfb=0x7f11c0, e=0x88af68, ca=0x40fff6c0, rs=0x41000cb0, renum=0x41000884, op=0x8ad530) at bconfig.c:4385 #1 0x00000000004156a7 in config_back_add (op=0x8ad530, rs=0x41000cb0) at bconfig.c:4523 #2 0x000000000043057b in fe_op_add (op=0x8ad530, rs=0x41000cb0) at add.c:330 #3 0x000000000042feaf in do_add (op=0x8ad530, rs=0x41000cb0) at add.c:182 #4 0x00000000004276db in connection_operation (ctx=0x41000de0, arg_v=0x8ad530) at connection.c:1129 #5 0x0000000000427bb9 in connection_read_thread (ctx=0x41000de0, argv=0xc) at connection.c:1257 #6 0x000000000053d552 in ldap_int_thread_pool_wrapper (xpool=0x85e630) at tpool.c:704 #7 0x00002b374570309e in start_thread () from /lib64/libpthread.so.0 #8 0x00002b37459d94cd in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

syncrepl.c rev 1.310 Provided a successful test: Cleaning up test run directory leftover from previous run. Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received config changes... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved configs from producer and consumer... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... >>>>> Test succeeded Many thanks, Gavin.

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

(gdb) attach 15790 Attaching to process 15790 Reading symbols from /anything/src/openldap-devel/servers/slapd/.libs/lt-slapd...done. Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from /anything/src/openldap-devel/libraries/libldap_r/.libs/libldap_r-2-devel.so.0...done. Loaded symbols for /anything/src/openldap-devel/libraries/libldap_r/.libs/libldap_r-2-devel.so.0 Reading symbols from /anything/src/openldap-devel/libraries/liblber/.libs/liblber-2-devel.so.0...done. Loaded symbols for /anything/src/openldap-devel/libraries/liblber/.libs/liblber-2-devel.so.0 Reading symbols from /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libssl.so.6...done. Loaded symbols for /lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libwrap.so.0...done. Loaded symbols for /usr/lib/libwrap.so.0 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread -1208633664 (LWP 15790)] [New Thread -1210299504 (LWP 15804)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libcrypt.so.1...done. Loaded symbols for /usr/lib/libcrypt.so.1 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 0x007de402 in __kernel_vsyscall () (gdb) n Single stepping until exit from function __kernel_vsyscall, which has no line number information. [Switching to Thread -1208633664 (LWP 15790)] 0x008554b7 in pthread_join () from /lib/libpthread.so.0 (gdb) n Single stepping until exit from function pthread_join, which has no line number information. [New Thread -1220789360 (LWP 15865)] [New Thread -1231279216 (LWP 15873)] Error while mapping shared library sections: ../../../servers/slapd/overlays/.libs/syncprov-2-devel.so.0: No such file or directory. Error while reading shared library symbols: ../../../servers/slapd/overlays/.libs/syncprov-2-devel.so.0: No such file or directory. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1220789360 (LWP 15865)] 0x080c12ed in syncrepl_del_nonpresent (op=0xb73c2ec8, si=0x81ecdb0, uuids=0x0, cookiecsn=0x81eca98) at syncrepl.c:2225 2225 csn = si->si_syncCookie.ctxcsn[0]; (gdb) bt #0 0x080c12ed in syncrepl_del_nonpresent (op=0xb73c2ec8, si=0x81ecdb0, uuids=0x0, cookiecsn=0x81eca98) at syncrepl.c:2225 #1 0x080c7028 in do_syncrep2 (op=0xb73c2ec8, si=0x81ecdb0) at syncrepl.c:818 #2 0x080c961c in do_syncrepl (ctx=0xb73c3238, arg=0x81ecf90) at syncrepl.c:1107 #3 0x00d3cf00 in ldap_int_thread_pool_wrapper (xpool=0x81cc150) at tpool.c:704 #4 0x008543db in start_thread () from /lib/libpthread.so.0 #5 0x005bf26e in clone () from /lib/libc.so.6 (gdb) p si->si_syncCookie $1 = {ctxcsn = 0x0, octet_str = {bv_len = 7, bv_val = 0x81f8d90 "rid=001"}, rid = 1, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} (gdb) frame 1 #1 0x080c7028 in do_syncrep2 (op=0xb73c2ec8, si=0x81ecdb0) at syncrepl.c:818 818 syncrepl_del_nonpresent( op, si, NULL, (gdb) p syncCookie $4 = {ctxcsn = 0x81eca90, octet_str = {bv_len = 52, bv_val = 0x81fa810 "rid=001,csn=20070206232910.544649Z#000000#000#000000"}, rid = 1, sid = -1, numcsns = 1, sids = 0x81eca50, sc_next = {stqe_next = 0x0}} (gdb) p syncCookie{ A syntax error in expression, near `{'. (gdb) print syncCookie_req $5 = {ctxcsn = 0x0, octet_str = {bv_len = 7, bv_val = 0x81f8da0 "rid=001"}, rid = 1, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} (gdb) p m $6 = 1 Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by hyc＠symas.com 06 Feb '07

06 Feb '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > >>>>>> Starting test049-sync-config ... > running defines.sh > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > ./scripts/test049-sync-config: line 164: 28156 Segmentation fault $SLAPD -F > ./slapd.d -h $URI2 -d $LVL $TIMING >../$LOG2 2>&1 (wd: > /src/openldap-devel/tests/testrun/con) > Waiting 10 seconds for syncrepl to receive changes.. > > Logs at: > > http://www.perl.me.uk/test49/slapd.1.log > http://www.perl.me.uk/test49/slapd.2.log > http://www.perl.me.uk/test49/test.out We also need a stack trace from the crash. Set your coresize to unlimited so that crashes will generate a core file. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

Full_Name: Gavin Henry Version: HEAD OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) >>>>> Starting test049-sync-config ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... ./scripts/test049-sync-config: line 164: 28156 Segmentation fault $SLAPD -F ./slapd.d -h $URI2 -d $LVL $TIMING >../$LOG2 2>&1 (wd: /src/openldap-devel/tests/testrun/con) Waiting 10 seconds for syncrepl to receive changes.. Logs at: http://www.perl.me.uk/test49/slapd.1.log http://www.perl.me.uk/test49/slapd.2.log http://www.perl.me.uk/test49/test.out Was trying to test test050, but died on 049. Is it possible to just run this test? I can't seem to figure out how, without doing a "make test" again. Gavin.

1 0

Re: (ITS#4626) "glue" objectclass in syncrepl consumer
by hyc＠symas.com 05 Feb '07

05 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Sep 22, 2006 at 07:48:33PM +0000, hyc(a)symas.com wrote: >> Yes, this makes sense. >> >> Since all of the CSNs under ou=global are greater than any CSN under >> dc=example,dc=com, none of those entries are sent. In server B your >> consumer should be configured on dc=example,dc=com, with a searchbase of >> ou=global,dc=example,dc=com. That will allow the server B provider to >> stay in sync with its consumer. > > With this change, the replication is better, but the B server cannot be > written to anymore: moving the syncrepl directive to the > dc=example,dc=com database makes it read-only because it is then > considered a consumer. This portion of your report is the same as ITS#4623. The fix for ITS#4623 is in HEAD and probably will only be in 2.4. The other part of the problem, where objects get turned into glue objects, is fixed by ITS#4813. This fix is in RE23 and will be in 2.3.34. I'm closing this ITS, you can followup to #4623 or #4813 if you need to make any further comments. -- -- Howard Chu Chief Architect, 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#4623) syncprov and glued databases: findbase failed
by hyc＠symas.com 05 Feb '07

05 Feb '07

ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: REL_ENG_2_3 (2.3.24+) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > I have a provider with two databases glued together: > dc=example,dc=com > ou=global,dc=example,dc=com > > One consumer has the syncrepl base search pointing to ou=global on the > provider. > The slapd.conf(5) manpage says that in this scenario, one should load the > overlays at the provider in this order: > > overlay glue > overlay syncprov > > If my provider config is as follows, however, I get a "findbase failed! 32" > error at the provider: The docs were wrong in this case; the required hooks for the overlay support here were not implemented. These hooks have been added to CVS HEAD and this configuration works correctly there. The changes will be part of 2.4. I don't think they'll be backported for 2.3. > I was under the impression (caused by the slapd.conf(5) manpage) that one should > only need to load the syncprov overlay once, right after glue, and it would > attend to both databases. But if I do that, then I get the error I mentioned > above when attempting to replicate the subordinate database. Right, that was the intent, but because of the missing hooks, it couldn't work. -- -- Howard Chu Chief Architect, 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#4656) Enhancement: again on Netscape style changelog
by sebastian.rieger＠gwdg.de 05 Feb '07

05 Feb '07

This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C7492A.5D6431D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great work! I submitted a patch to update the old overlay of Neil Dunbar = to OpenLDAP 2.3. It works for our identity management (using Novell IDM = 3.01) - see ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I = would like to ask, wether this patch (ITS#4656) is likely to be accepted in = the near future. In this case I won't maintain a separate overlay. But it doesn't seem to be in HEAD, for now? -- MfG Sebastian Rieger Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen=20 Am Fassberg - 37077 G=F6ttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des = DFN =FCberpr=FCft werden: = https://ca.gwdg.de/certs/root-classic/root-ca-cert.der ------=_NextPart_000_0018_01C7492A.5D6431D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXujCCBHUw ggNdoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNVBAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMg LSBHMDEwHhcNMDUwMjI4MDAyOTM3WhcNMTMwNDI4MDAyOTM3WjBbMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQ Q0EgQ2xhc3NpYyAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvNTUXjQCVx w87yo/67c+J0bhhl6sfVNVO87Jk2WMY/lPC/E1cmq6iOAe2fV10FhexSG2zIp8XqbrlPNN7s3sy/ 0jUQfHegDqWWuCDQfWLkdWHTiDhIfhcCTdLaXDRshAxE18zDJzKPu3EMeU/N5dju7/azQVi2wkzM fM9I5aARVcrYVH+OanfQo1+yCoQupE9XaGpZRCr2w1X6pf1v0JcqakuC/LBX9uk0IPtMz9Y6frOP AvCldCn8pWNdQrT6VPmJpI7zDCm6/PCAZy82cImzkfbxGpMVxNBxC3Zwgc4zT9Cn22e0Hms8Q3cm cr8hbFb3icuGnMGKp50e9L2eOokCAwEAAaOCAUIwggE+MB0GA1UdDgQWBBSDrjvMk+EkUnrpIE+D cKIq3XsvATAfBgNVHSMEGDAWgBSDrjvMk+EkUnrpIE+DcKIq3XsvATAPBgNVHRMBAf8EBTADAQH/ MIHHBgNVHR8Egb8wgbwwXKBaoFiGVmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0 aWZpY2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMFygWqBY hlZodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2NsYXNz aWMvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQDaFaWOgZRQO/CaU+xUQPj3mgnJ5MJug0ad1d+L k+K1iTUp8r9fLxnamypzVeVrHFbtC5zk9lxx8qDMiDc6sd9HYRJNikJUme/EfHPkzlbn6hTXuL6+ ZKdCeK3qQHnltEjg/NLUIaU/bukFmhOk6NrnU5XNTKcEeOJ47t0K2EWWZ6rN3Ji0FU444hGO73tl C5t1ACWaMYFakmylmagwdZPIVnA3qKFmVRTPcz3Cel56UyA2U6n9qQR8zZzkltIwx2/6SHt2EqQN u3g6iDyOWzIfsb0bRVHmvHQx3KCUZb5JNy3iue8yIB6WMbKZ+eJuwZl1Q0PJ87BjsHYglO3JX+Oy MIIFhjCCBG6gAwIBAgIEBnsYQDANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJERTETMBEGA1UE ChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQQ0Eg Q2xhc3NpYyAtIEcwMTAeFw0wNTA0MTIwOTUzNTRaFw0wOTA0MTIwOTUzNTRaMIGcMQswCQYDVQQG EwJERTFCMEAGA1UEChM5R2VzZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52 ZXJhcmJlaXR1bmcgbWJIMQswCQYDVQQLEwJDQTEcMBoGA1UEAxMTR1dERy1DQSBFYmVuZSAxIEcw MjEeMBwGCSqGSIb3DQEJARYPZ3dkZy1jYUBnd2RnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3y/2S6yGKZhpv+DwWTSH4/szbEB2yPEJUgZz5kaVId/17wKdRNKd9el03skx/ind 1IJ27YaoOybmRp5pwuNSAL7SEC2neEKcLCqkV+jDcLusV2mQ/ykgMs7No5csyhS6FxuUwBK18BlF E7tfraK3J6iyOJxzjFKB+3/ZWhasXnwEtzOUc5hRry9bTNYpyLueUa5DLR5nqIRwk1OWbx3IARbC RKrxdAupzwEAjWwz8ar2aDHgsBH41D7sfDY9wRxH04sW6K9D0BANEx+o8KhbsPQv6l0HQE7p0n6Y XQhUo5QhZ8GMfEiIh39sE1turDLut7I4bCZwrIjPT9gJqhFMWwIDAQABo4ICDjCCAgowHQYDVR0O BBYEFPP+0UOeITsrZQ3Y8arSBsKbVgajMB8GA1UdIwQYMBaAFIOuO8yT4SRSeukgT4Nwoirdey8B MA8GA1UdEwEB/wQFMAMBAf8wgccGA1UdHwSBvzCBvDBcoFqgWIZWaHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY3Jscy9yb290 LWNhLWNybC5jcmwwXKBaoFiGVmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZp Y2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHcBggrBgEF BQcBAQSBzzCBzDBkBggrBgEFBQcwAoZYaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBk BggrBgEFBQcwAoZYaHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24v eDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDAOBgNVHQ8BAf8EBAMC AQYwDQYJKoZIhvcNAQEFBQADggEBADFx3Ji676DYFd/XIY9KcsNopLqtgF5Ixr2irPOPpZ/X/zta Gss3l18EdKCCBFqhwCrd2lFOfowbxnWZ1L+WRS/+0x4a8MZoAUWyfk+pLLgv3OucY4ZhAGP5F0XJ wLRlskcnLVvt3HFQ9JsEjHo45u/QiKbZJGFPVZb5elpphRtAVTiRisw5UTiV57m07vcJhUtrt6wh 7389cz2aYYdlViMZtuaE0Z+LlSElAe4/U6tOowoR+06qDjjFNLjQ1P3fnmBPRo2zWidaLiZcfD3f qjxBgJolgeS+gS3YePj2M6NAUTu+1XKAbrFJUyrCI+qPkEcVq3yK6FkZbbhla+BKQrcwggZUMIIF PKADAgECAgou6MIgAAAAAASaMA0GCSqGSIb3DQEBBQUAMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEVi ZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFm dCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMC REUxCjAIBgNVBAUTATIwHhcNMDYxMTA5MTMzNDU3WhcNMDcwOTIwMTA1ODAwWjCBvjELMAkGA1UE BhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEzARBgNVBAcTCkdvZXR0aW5nZW4xPjA8BgNV BAoTNUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5n MRkwFwYDVQQDExBTZWJhc3RpYW4gUmllZ2VyMScwJQYJKoZIhvcNAQkBFhhzZWJhc3RpYW4ucmll Z2VyQGd3ZGcuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN+JMyvFWWLIl0gDV5t9edUF qJCNFHH/aDm40I6MZLkYZ6eyLpRVmvIQ1+KBLP8Qjagiz1HwEqwMBDNPABq50yYCHpLmKFy+BCEH r4Cjoz2AhSm4BqUhjy/XnFOqeAReo9MJfrJeslCPbfaqVV7APQl4VqALnxnDJl/1PJ4++CiLAgMB AAGjggL9MIIC+TALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHQYDVR0OBBYEFMxqWUeIRKOu1OVQe7WDZwKzQJlGMB8GA1UdIwQYMBaAFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGvBgNVHR8EgacwgaQwgaGggZ6ggZuGTmh0dHA6Ly91c2VyLWNhLmd3 ZGcuZGUvQ2VydEVucm9sbC9HV0RHLUNBJTIwRWJlbmUlMjAyJTIwR2VuZXJpYy1DQSUyMEcwMi4x LmNybIZJaHR0cDovL3BjYS5nd2RnLmRlL2NybC9nd2RnLWNhL2ViZW5lMi9nMDIuMS9nd2RnLWNh LWViZW5lMi1nZW5lcmljLWNhLmNybDCB0wYIKwYBBQUHAQEEgcYwgcMwagYIKwYBBQUHMAGGXmh0 dHA6Ly91c2VyLWNhLmd3ZGcuZGUvQ2VydEVucm9sbC91c2VyLWNhLmd3ZGcuZGVfR1dERy1DQSUy MEViZW5lJTIwMiUyMEdlbmVyaWMtQ0ElMjBHMDIuMS5jcnQwVQYIKwYBBQUHMAGGSWh0dHA6Ly9w Y2EuZ3dkZy5kZS9jcmwvZ3dkZy1jYS9lYmVuZTIvZzAyLjEvZ3dkZy1jYS1lYmVuZTItZ2VuZXJp Yy1jYS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhZ2OO4GrnU+tkQWF84sDhK7MIS2H kIMrg8myPwIBZAIBAzBKBgNVHSAEQzBBMD8GCysGAQQBgZ1IMgEBMDAwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG0wNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMA0GCSqGSIb3DQEBBQUAA4IBAQCASq3lwDZ/ o7RuoZxqmuGCZPKlVuoBsQGaNJnoGUMBoq/7UBHRym4EpMuB8wf+NxPxhcSOxUR3UwDKE3p0VnVE O//hD6CFwbed83Wn6nv4O4jHJDxTAs0JJGomtrNxFxa5NwSUHq8ujf0DSr2Zn+yq8KzmNVjuANNe sbxvtvO3rr8pLh66m4QsgvOtGZpDeeJRpJM8eN9hf9HcIrtnCNP/KN8HGESiozUB0h0ZasH9yTQZ f/K0VCTTttPnXg3cF+g+bWMc0gGQzR40oVzTt4ggC0G68gRh2yTlQxRjMxZBS7vkWBGhEYoJoLHE TQv5oNafPL4UZGIW4SjLjWiR5mUZMIIHWzCCBkOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnDEL MAkGA1UEBhMCREUxQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hl IERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UECxMCQ0ExHDAaBgNVBAMTE0dXREctQ0EgRWJl bmUgMSBHMDIxHjAcBgkqhkiG9w0BCQEWD2d3ZGctY2FAZ3dkZy5kZTAeFw0wNTA5MjAxMDU4MDBa Fw0wNzA5MjAxMDU4MDBaMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBH MDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFm dGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC62IidFd5KC11HewNoQh8DG8jcJI1fdNIf/ETt d4vOMZRRQG5+WhETBhH0d6pXjZ+V8dhlMiekFq2RpFYPictQFnEt5M49iGfX6V3PIKkaFtFTIZj0 QbGN7BWTpcCfTw6L9VwPA3olG1QYABl16Ea9mHT6nGfvwYyiadnzHCAI1XTFeF1UzOKM8EemZvGa oQncG8QUt1uqskfcLJ18ASM6GY/C108p0E9hUx2V24BQDdLdCUB6BzcW/SQdBqjRaW51mPPMxn/p bqXWrgUwkiYJOqkDY6qVUtvKGCZIumQdKxnoSB5X7tna2widH50xNX5VdMe/qnYZPLuEnbzrkOo5 AgMBAAGjggOrMIIDpzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjBuBglghkgBhvhCAQ0E YRZfU3Vib3JkaW5hdGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHZXNlbGxzY2hhZnQgZnVl ciB3aXNzZW5zY2hhZnRsaWNoZSBEYXRlbnZlcmFyYmVpdHVuZyBtYkgwHQYDVR0OBBYEFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGGBgNVHSMEfzB9gBTz/tFDniE7K2UN2PGq0gbCm1YGo6FfpF0wWzEL MAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNV BAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMgLSBHMDGCBAZ7GEAwGgYDVR0RBBMwEYEPZ3dkZy1j YUBnd2RnLmRlMAkGA1UdEgQCMAAwQgYJYIZIAYb4QgEEBDUWM2h0dHA6Ly9jYS5nd2RnLmRlL2Ny bC9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNybDBCBglghkgBhvhCAQMENRYzaHR0cDovL2Nh Lmd3ZGcuZGUvY3JsL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3JsMIGABgNVHR8EeTB3MDmg N6A1hjNodHRwOi8vY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5jcmww OqA4oDaGNGh0dHA6Ly9wY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5j cmwwgZcGCCsGAQUFBwEBBIGKMIGHMEEGCCsGAQUFBzAChjVodHRwOi8vY2EuZ3dkZy5kZS9jZXJ0 cy9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNydDBCBggrBgEFBQcwAoY2aHR0cDovL3BjYS5n d2RnLmRlL2NlcnRzL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3J0MCAGCWCGSAGG+EIBAgQT FhFodHRwOi8vY2EuZ3dkZy5kZTAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NhLmd3ZGcuZGUvcG9s aWN5L2luZGV4Lmh0bWwwTQYDVR0gBEYwRDBCBg0rBgEEAYGdSDIBAwEBMDEwLwYIKwYBBQUHAgEW I2h0dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQBj KNeFKWGSWFjcy1fR1UHC5+MdmiTUfzHVeRbLuoGOTkbjYEbjE3+FNhGgRJJwKoDU1jQXLGGBzLQT dZcZj3QO0926SpshKNmW0zVIwf9gbAzFZ17Zgfns/BenJ7hTRl4m5aHTodkmJSKNvqwWOCFTTX9H RYRiSuDC10QYRH6S7MqyZ5Gkhtdq9iLVik8Q2RIS7OIoJgYUkLOG+tZ1rtQmWb3U6p/WwF4t5CAp ErqoJ1f427lLOj0EPOsXJUcwf+km6kkcIrKopv63HTWw7HmQHLGXajf5KbZXumwcG0Z2RCZN4OE2 yfQgRi8wmhj3pSKE4ylcz7Y9ExWdWh5YJAfMMYIDhzCCA4MCAQEwgaQwgZUxKTAnBgNVBAMTIEdX REctQ0EgRWJlbmUgMiBHZW5lcmljLUNBIEcwMi4xMQswCQYDVQQLEwJjYTFCMEAGA1UEChM5R2Vz ZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52ZXJhcmJlaXR1bmcgbWJIMQsw CQYDVQQGEwJERTEKMAgGA1UEBRMBMgIKLujCIAAAAAAEmjAJBgUrDgMCGgUAoIICODAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAyMDUxMjM0MzBaMCMGCSqGSIb3 DQEJBDEWBBRzZWbcdY18vGBBk12AP1Flv0chJTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTCBtQYJKwYBBAGCNxAEMYGnMIGkMIGVMSkwJwYDVQQDEyBHV0RH LUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2Vs bHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkG A1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowgbcGCyqGSIb3DQEJEAILMYGnoIGkMIGV MSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2Ex QjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJi ZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowDQYJKoZIhvcN AQEBBQAEgYBDAP54LC4wafAmgrYjD6sC+pMKai6fgCmLMrECkBQXB9rlGKryTaDSPUzh3SGrY+/h V08OQW2Il+H1y8GqqQz4U4VvMauOiLR5i7HrDFcRPYQsJ5tS2dpgYwvtHKrjwOl3mM5kOP2UnAMG G7AbGU4201tBu44H9EbaWLA/jfgIdgAAAAAAAA== ------=_NextPart_000_0018_01C7492A.5D6431D0--

1 0

Re: (ITS#4831) dynlist returns bad data
by ando＠sys-net.it 03 Feb '07

03 Feb '07

quanah(a)stanford.edu wrote: > > --On Friday, February 02, 2007 8:26 PM +0000 quanah(a)stanford.edu wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.33 >> OS: Linux 2.6 (64-bit) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.81) >> >> >> In doing a base query of a dynamic group I had created, I found that the >> information returned when using the dynlist overlay is bogus. > > And what I expected to see was something more along the lines of: > > dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu > objectClass: groupOfURLs > cn: registry-consult > memberURL: > ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=value:value2) One of the distinguishing features of the dynlist overlay is that it can actually __create__ a dynamic view of the listed data by collecting all values of all attributes (honoring few constraints, like all additional values of single-valued attributes get discarded; I believe in HEAD code it also avoids merging other structural objectClasses unless they fit into the hierarchy of the current structuralObjectClass). To limit this, you can use the <attrs> field of the URL, so that only the listed attrs are actually merged. Or, if you want it to behave exactly like a group, you should configure it with the <member-ad> field: dynlist-attrset <group-oc> <URL-ad> [<member-ad>] The value <group-oc> is the name of the objectClass that trig- gers the dynamic expansion of the data. The value <URL-ad> is the name of the attributeDescription that cointains the URI that is expanded by the overlay; if none is present, no expansion occurs. If the intersection of the attributes requested by the search operation (or the asserted attribute for compares) and the attributes listed in the URI is empty, no expansion occurs for that specific URI. It must be a subtype of labeledURI. The value <member-ad> is optional; if present, the overlay behaves as a dynamic group: this attribute will list the DN of the entries resulting from the internal search. In this case, the <attrs> portion of the URI must be absent, and the DNs of all the entries resulting from the expansion of the URI are listed as values of this attribute. Compares that assert the value of the <member-ad> attribute of entries with <group-oc> objectClass apply as if the DN of the entries resulting from the expansion of the URI were present in the <group-oc> entry as values of the <member-ad> attribute. To see what you expect, you need to add the manageDSAit control (I believe this is undocumented; I'll fix it in a moment). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4831) dynlist returns bad data
by quanah＠stanford.edu 02 Feb '07

02 Feb '07

--On Friday, February 02, 2007 8:26 PM +0000 quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.33 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > In doing a base query of a dynamic group I had created, I found that the > information returned when using the dynlist overlay is bogus. And what I expected to see was something more along the lines of: dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs cn: registry-consult memberURL: ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=value:value2) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4831) dynlist returns bad data
by quanah＠stanford.edu 02 Feb '07

02 Feb '07

Full_Name: Quanah Gibson-Mount Version: 2.3.33 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In doing a base query of a dynamic group I had created, I found that the information returned when using the dynlist overlay is bogus. ldapsearch -LLL -Q -h ldap-dev1 -s base -b "cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu" | more was the query run. It returns: dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: suPerson cn: registry-consult cn: member A's cn cn: member B's cn ..... description: member A's description description: member B's description ...... displayName: member A's displayName givenName: member A's givenName givenName: member B's givenName .... etc, for every populated attribute in the *objects of the members*. This seems horribly broken to me. Note that this is an unmodified version of dynlist (pure 2.3.33) --Quanah

1 0

(ITS#4830) test030-relay fails with back-meta
by ahasenack＠terra.com.br 02 Feb '07

02 Feb '07

Full_Name: Andreas Hasenack Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) Hello, while running make test on a 2.3.33 build, I get an error in test030-relay when using the meta backend: (...) Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/relay: line 78: kill: (31577) - Processo inexistente >>>>> ./scripts/test030-relay failed (exit 255) make: ** [bdb-yes] Erro 255 The log shows: $ tail testrun/slapd.1.log conn=3 op=1 >>> meta_search_dobind_init[0] conn=3 op=1 <<< meta_search_dobind_init[0]=1 ==> rewrite_context_apply [depth=1] string='o=Example,c=US' ==> rewrite_rule_apply rule='((.+),)?o=Example,[ ]?c=US$' string='o=Example,c=US' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=example,dc=com'} [rw] searchBase: "o=Example,c=US" -> "dc=example,dc=com" ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: symbol lookup error: +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl

1 0

(ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 02 Feb '07

02 Feb '07

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, If we are to suppose that slapd-config is to provide 100% remote configuration, then directories should be created as set in: olcDbDirectory set_lg_dir Questions/Needs: 1. How to handle existing directories on mkdir? 2. Some global cn=config setting to say what cn=config is allowed to do 3. Plus many more I'm sure. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

syncrepl only works as rootdn
by Christopher Cowart 02 Feb '07

02 Feb '07

Hello, I have 3 installations of openldap-server-2.3.33 running on FreeBSD 6.1-REL: ldap-master, ldap1, ldap2. I am using syncrepl to replicate ldap-master to ldap1 and ldap2. The replicated directory is missing entire ou branches in my tree. I have created the following objects in my directory: cn=syncrepl-ldap1,dc=example,dc=com cn=syncrepl-ldap2,dc=example,dc=com I've made the following configurations on the provider: | access to * | by dn.regex="cn=syncrepl-(ldap1|ldap2),dc=example,dc=com" read | by * break | | # More ACLs Follow | | # For Sync Replication | overlay syncprov | syncprov-checkpoint 100 10 | syncprov-sessionlog 100 And on the consumer (ldap1): | # Sync Replication | syncrepl rid=001 | provider=ldaps://ldap-master.example.com/ | type=refreshAndPersist | interval=00:01:00:00 | searchbase="dc=example,dc=com" | scope=sub | schemachecking=off | bindmethod=simple | binddn="cn=syncrepl-ldap1,dc=example,dc=com" | credentials=supersecret Now, when I query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap1.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services You'll notice that the "System Accounts" and "System Groups" ou's are not visible in the replicated directory. Odd. Next, I run the query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But the syncrepl process is binding as "cn=syncrepl-ldap1": $ ldapsearch -D 'cn=syncrepl-ldap1,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services So, if I configure the consumer to bind as my rootdn (cn=admin), the entire directory gets replicated (as the final ldapsearch's would imply). My question is how do I properly configure the ACLs here? Shouldn't the 'read *' at the beginning of my ACL declarations match? I'm attaching the full list of my ACLs to the message. Thanks for any help or pointers you can offer. -- Chris Cowart Network and Infrastructure Systems Administrator RSSP-IT, UC Berkeley "May all your pushes be popped"

2 1

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Howard Chu wrote: >>> michael.stroeder(a)t-systems.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD >>>> OS: opensuse Linux 10.2 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.124.17.145) >>> Hmm, all tests are passing for me right now. >>> >> Never mind. I just refreshed back-ldap and back-meta and test032 is failing >> for me now too. > > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Looks fine now, thanks. -- -- Howard Chu Chief Architect, 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Fixed in HEAD, please test. BTW, the bug showed up essentially because the output was sort of incorrectly diverted to the file that gets checked. Generally speaking, it might impact re23 as well, although that test is currently succeeding. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> michael.stroeder(a)t-systems.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: opensuse Linux 10.2 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.124.17.145) >> Hmm, all tests are passing for me right now. >> > Never mind. I just refreshed back-ldap and back-meta and test032 is failing > for me now too. I've recently added some diagnostics messages to proxy failures, to indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts to contact the remote target. Apparently, slapo-chain(5) leaves 'round some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

Howard Chu wrote: > michael.stroeder(a)t-systems.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: opensuse Linux 10.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.124.17.145) > > Hmm, all tests are passing for me right now. > Never mind. I just refreshed back-ldap and back-meta and test032 is failing for me now too. -- -- Howard Chu Chief Architect, 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

michael.stroeder(a)t-systems.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: opensuse Linux 10.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.17.145) Hmm, all tests are passing for me right now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by michael.stroeder＠t-systems.com 01 Feb '07

01 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: opensuse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.17.145) >>>>> Starting test032-chain ... running defines.sh Running slapadd to build slapd database... Starting first slapd on TCP/IP port 9011... Starting second slapd on TCP/IP port 9012... Using ldapsearch to check that first slapd is running... Using ldapsearch to check that second slapd is running... Testing ldapsearch as anonymous for "dc=example,dc=com" on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Reading the referral entry ou=Other,dc=example,dc=com as anonymous on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... comparison failed - chained search didn't succeed >>>>> ./scripts/test032-chain failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by kurt＠OpenLDAP.org 31 Jan '07

31 Jan '07

On Feb 1, 2007, at 4:26 AM, hyc(a)symas.com wrote: > Fixed now. Confirmed. Thanks, Kurt

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by hyc＠symas.com 31 Jan '07

31 Jan '07

Fixed now. The fix also triggered another problem along the lines of ITS#4820; test017's comparison failed because the modifiersName attribute wasn't in the same position on the producer and the consumer. I've hacked that problem by always applying the modifiersName update. kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: MacOSX 10.4.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.80.218.136) > > > Recent builds fail test 18: > Comparing retrieved entries from master and R1 slave... > Comparing retrieved entries from master and R2 slave... > test failed - master and R2 slave databases differ >>>>>> ./scripts/test019-syncreplication-cascade failed (exit 1) > > % diff -u testrun/server[13].flt > --- testrun/server1.flt 2007-01-31 12:31:55.000000000 -0800 > +++ testrun/server3.flt 2007-01-31 12:32:00.000000000 -0800 > @@ -66,6 +66,7 @@ > seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com > userPassword:: Ympvcm4= > homePostalAddress: 19923 Seven Mile Rd. $ South Lyon, MI 49999 > +drink: Iced Tea > description: Hiker, biker > title: Director, Embedded Systems > postalAddress: Info Tech Division $ 535 W. William St. $ Anytown, MI 48103 > @@ -74,8 +75,6 @@ > pager: +1 313 555 4474 > facsimileTelephoneNumber: +1 313 555 2177 > telephoneNumber: +1 313 555 0355 > -drink: Iced Tea > -drink: Mad Dog 20/20 > > dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com > objectClass: OpenLDAPperson > > > . > -- -- Howard Chu Chief Architect, 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#4826) assertion in connection.c
by ando＠sys-net.it 31 Jan '07

31 Jan '07

hyc(a)symas.com wrote: > Aaron Richton wrote: >> Wow, thanks. I never worried about setting that because I was under the >> impression that Solaris should autoconf to use poll() -- doesn't >> FD_SETSIZE only matter under select()? > > In current releases slapd only uses select() or epoll() (which is > Linux-specific). So you're getting select() right now. In HEAD/2.4 there's > support for Solaris /dev/poll. ... which doesn't work right now (as far as I remember; need to look at that before Solaris 8 becomes obsolete...) p.

1 0

Re: (ITS#4826) assertion in connection.c
by hyc＠symas.com 31 Jan '07

31 Jan '07

Aaron Richton wrote: > Wow, thanks. I never worried about setting that because I was under the > impression that Solaris should autoconf to use poll() -- doesn't > FD_SETSIZE only matter under select()? In current releases slapd only uses select() or epoll() (which is Linux-specific). So you're getting select() right now. In HEAD/2.4 there's support for Solaris /dev/poll. The libldap library will use poll() on Solaris, but that's a different matter... > On Wed, 31 Jan 2007, Howard Chu wrote: > >> richton(a)nbcs.rutgers.edu wrote: >>> Full_Name: Aaron Richton >>> Version: 2.3.30 >>> OS: Solaris 9 >>> URL: Submission from: (NULL) (128.6.31.135) -- -- Howard Chu Chief Architect, 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#4826) assertion in connection.c
by richton＠nbcs.rutgers.edu 31 Jan '07

31 Jan '07

Wow, thanks. I never worried about setting that because I was under the impression that Solaris should autoconf to use poll() -- doesn't FD_SETSIZE only matter under select()? On Wed, 31 Jan 2007, Howard Chu wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: 2.3.30 >> OS: Solaris 9 >> URL: Submission from: (NULL) (128.6.31.135) >> >> >> Please note this is 2.3.30, so recent RE23 connection changes might make >> this >> irrelevant: > > No, no recent changes to connection.c would affect this. If your process is > actually able to use more than 4096 connections, then you need to recompile > with a larger OPENLDAP_FD_SET_SIZE. > > Note that with dtblsize = 4096, the maximum legal descriptor number is 4095, > since descriptors are zero-based. > > I'd call this a user configuration error, nothing to investigate here. > > -- > -- Howard Chu > Chief Architect, 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#4826) assertion in connection.c
by hyc＠symas.com 31 Jan '07

31 Jan '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.30 > OS: Solaris 9 > URL: > Submission from: (NULL) (128.6.31.135) > > > Please note this is 2.3.30, so recent RE23 connection changes might make this > irrelevant: No, no recent changes to connection.c would affect this. If your process is actually able to use more than 4096 connections, then you need to recompile with a larger OPENLDAP_FD_SET_SIZE. Note that with dtblsize = 4096, the maximum legal descriptor number is 4095, since descriptors are zero-based. I'd call this a user configuration error, nothing to investigate here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4827) test019-syncreplication-cascade
by kurt＠OpenLDAP.org 31 Jan '07

31 Jan '07

Full_Name: Kurt Zeilenga Version: HEAD OS: MacOSX 10.4.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.80.218.136) Recent builds fail test 18: Comparing retrieved entries from master and R1 slave... Comparing retrieved entries from master and R2 slave... test failed - master and R2 slave databases differ >>>>> ./scripts/test019-syncreplication-cascade failed (exit 1) % diff -u testrun/server[13].flt --- testrun/server1.flt 2007-01-31 12:31:55.000000000 -0800 +++ testrun/server3.flt 2007-01-31 12:32:00.000000000 -0800 @@ -66,6 +66,7 @@ seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com userPassword:: Ympvcm4= homePostalAddress: 19923 Seven Mile Rd. $ South Lyon, MI 49999 +drink: Iced Tea description: Hiker, biker title: Director, Embedded Systems postalAddress: Info Tech Division $ 535 W. William St. $ Anytown, MI 48103 @@ -74,8 +75,6 @@ pager: +1 313 555 4474 facsimileTelephoneNumber: +1 313 555 2177 telephoneNumber: +1 313 555 0355 -drink: Iced Tea -drink: Mad Dog 20/20 dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson

1 0

(ITS#4826) assertion in connection.c
by richton＠nbcs.rutgers.edu 31 Jan '07

31 Jan '07

Full_Name: Aaron Richton Version: 2.3.30 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Please note this is 2.3.30, so recent RE23 connection changes might make this irrelevant: Threw assertion 385 assert( s < dtblsize ); from connection.c. Backtrace: current thread: t@16 [1] __lwp_kill(0x0, 0x6, 0x0, 0xfec3c000, 0x0, 0x0), at 0xfec1fc54 [2] raise(0x6, 0x0, 0xd1fff638, 0x0, 0x0, 0x0), at 0xfebd0c48 [3] abort(0x3c, 0xd1fff6c8, 0x3c, 0x7efefeff, 0x81010100, 0xff0000), at 0xfebb6d50 [4] __assert(0x2314c8, 0x2314d8, 0x181, 0xd1fff86c, 0xd1fff8f0, 0xd1fff92d), at 0xfebb6ff0 =>[5] connection_init(s = 4096, listener = 0x1f4eb8, dnsname = 0x231ff0 "", peername = 0x231ff4 "", flags = 3, ssf = 0, authid = (nil)), line 385 in "connection.c" [6] connection_client_setup(s = 4096, func = 0xed908 = &`slapd`syncrepl.c`do_syncrepl(void *ctx, void *arg), arg = 0x31b4a8), line 1184 in "connection.c" [7] do_syncrepl(ctx = 0xd1fffe14, arg = 0x31b4a8), line 1099 in "syncrepl.c" [8] ldap_int_thread_pool_wrapper(xpool = 0x2c5f68), line 478 in "tpool.c" (dbx) print s s = 4096 (dbx) print dtblsize dtblsize = 4096

1 0

(ITS#4825) Native Win32 build with WGCC/Interix
by markus.duft＠salomon.at 31 Jan '07

31 Jan '07

Full_Name: Markus Duft Version: 2.3.32 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/markus.duft-31.01.2007.patch Submission from: (NULL) (193.186.16.254) Hey there. i have a patch for v2.3.32 that allowes building openldap using wgcc (interix-wgcc.sourceforge.net). The result is a native win32 binary (without dependencies to any cygwin.dll or anything like it) benefits: * fast compiler (cl.exe) * native win32, no overheads for big wrappers (there is a small wrapper though ;o) but thats statically linked (pxwc)) * debugable with Visual Studio (very cool) thats it, i'll write a FAQ for this ;o) P.S.: i know the patch is not perfect, but as a first thing it will do. there will be a second version for sure that may be nicer, so it can be incorporated with the official sources (if wanted...) Cheers, Markus

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by dieter＠dkluenter.de 31 Jan '07

31 Jan '07

Howard Chu <hyc(a)symas.com> writes: > Dieter Kluenter wrote: >> Howard Chu <hyc(a)symas.com> writes: >> >>> dieter(a)dkluenter.de wrote: .......... > > I've now checked in a new configure script, regenerated from the > current 1.645 configure.in. So that would be configure 1.684. Try that > one. (The only difference between 1.683 and 1.684 is the comment > indicating the version of configure.in.) I have just co'ed a fresh CVS HEAD and configure is OK now. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by hyc＠symas.com 31 Jan '07

31 Jan '07

Dieter Kluenter wrote: > Howard Chu <hyc(a)symas.com> writes: > >> dieter(a)dkluenter.de wrote: >>> Full_Name: Dieter Kluenter >>> Version: HEAD >>> OS: Linux URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.187.149.11) >>> Hello, >>> calling ./configure results in following error >>> --enable-dynamic=yes: command not found >>> neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking. >> Works for me. What revision is your configure script? Current is 1.683. > > pkg/ldap/configure.in,v 1.644 2007/01/10 23:54:45 hyc Exp . > > -Dieter > Even reverting to revision 1.682 of the configure script, with the typo from configure.in 1.644, I can't reproduce that error. Perhaps you should try deleting your source tree and fetching it again. You could list your full configure command here, with all relevant environment variable settings. But it seems you have a corrupted configure script. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by hyc＠symas.com 31 Jan '07

31 Jan '07

Dieter Kluenter wrote: > Howard Chu <hyc(a)symas.com> writes: > >> dieter(a)dkluenter.de wrote: >>> Full_Name: Dieter Kluenter >>> Version: HEAD >>> OS: Linux URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.187.149.11) >>> Hello, >>> calling ./configure results in following error >>> --enable-dynamic=yes: command not found >>> neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking. >> Works for me. What revision is your configure script? Current is 1.683. > > pkg/ldap/configure.in,v 1.644 2007/01/10 23:54:45 hyc Exp . That version stamp reflects the configure.in file that was used to generate the configure script, but it isn't the actual version of the configure script. You would need to use "cvs status configure" to actually check that. I've now checked in a new configure script, regenerated from the current 1.645 configure.in. So that would be configure 1.684. Try that one. (The only difference between 1.683 and 1.684 is the comment indicating the version of configure.in.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4822) After test049 is over, restarting the producer dumps core
by ando＠sys-net.it 30 Jan '07

30 Jan '07

hyc(a)symas.com wrote: > I haven't been able to reproduce this crash. I found some other problems (the > consumer wasn't able to retrieve the contextCSN at startup time because there > was no entry_fetch handler, fixed now) but none that caused a crash. I haven't identified yet what commit fixed this issue. Anyway, I've been unable to reproduce it as well, so the ITS can be closed. Thanks, p.

1 0

Re: (ITS#4822) After test049 is over, restarting the producer dumps core
by hyc＠symas.com 30 Jan '07

30 Jan '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: Linux 2.6 (CentOS 4.4) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.72.89.40) >> Submitted by: ando >> >> >> After test049 is over, restarting the producer dumps core. This happens in the >> consumer's code (!) which, as far as I can understand, is there in cn=config >> only for the purpose of replicating to the consumer and set it to be, well, a >> consumer. > The other half of this ITS remains to be investigated... I haven't been able to reproduce this crash. I found some other problems (the consumer wasn't able to retrieve the contextCSN at startup time because there was no entry_fetch handler, fixed now) but none that caused a crash. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by dieter＠dkluenter.de 30 Jan '07

30 Jan '07

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.187.149.11) >> Hello, >> calling ./configure results in following error >> --enable-dynamic=yes: command not found >> neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking. > > Works for me. What revision is your configure script? Current is 1.683. pkg/ldap/configure.in,v 1.644 2007/01/10 23:54:45 hyc Exp . -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4824) configure does not recognise --enable-dynamic
by hyc＠symas.com 29 Jan '07

29 Jan '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.187.149.11) > > > Hello, > calling ./configure results in following error > --enable-dynamic=yes: command not found > neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking. Works for me. What revision is your configure script? Current is 1.683. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4823) Cannot use zero-length IA5 String
by kurt＠OpenLDAP.org 29 Jan '07

29 Jan '07

On Jan 29, 2007, at 1:11 AM, nisimura(a)gmail.com wrote: > Full_Name: Kazu Nisumura > Version: 2.3.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (211.120.78.45) > > > When I was trying to add an entry like this using ldapadd(1): > > dn: cn=name,dc=example,dc=com > objectClass: inetOrgPerson > cn: name > sn: name > mail: > > slapd returned invalidAttributeSyntax(21) error on the mail (IA5 > String) > attribute. According to RFC4517, zero-length IA5 String should be > allowed. I note that while the directory service should allow such values, directory applications (e.g., client programs) and users should only provide values which make sense. An empty string (or a string consisting of just spaces) is not a valid email address and will likely lead to ill behavior. If the user represented by this entry has no email address, the mail attribute should have no value (as opposed to an empty value). But I digress...

1 0

(ITS#4824) configure does not recognise --enable-dynamic
by dieter＠dkluenter.de 29 Jan '07

29 Jan '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.187.149.11) Hello, calling ./configure results in following error --enable-dynamic=yes: command not found neither --enable-dynamic nor --enable-dynamic=yes will allow dynamic linking.

1 0

Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 29 Jan '07

29 Jan '07

Hello, >> Slurpd has a bug when replicating, in the way it generates the LDAPMod array of >> the add and modify operations : if the same attribute is present several times >> (for add) or in multiple change blocks (for modify) in the replication log, it >> simply adds all occurences to the LDAPMod array, hence having one or more >> attributes repeated serveral times which violates the protocol. >> [...] > As far as I can see, slurpd merely processes the changes in the replog. If it > is generating requests out of sequence, then they must have been recorded > out-of-sequence in the log. And yet I don't see any reason why slapd would > generate the modifications out of sequence. That's right for changetype=modify, since the original code aggregates multiple values of the same attributes in a signle LDAPmod if they're given in order in the replog file. But it doesn't do that for changetype=add, which toggled the bug. I choosed to use the same code path for both for simplicity when fixing add. > What are the circumstances that cause these improper sequences to get into > the replog in the first place? In our case, it was just "add" that was problematic. Although I could imagine the replog to be generated by something else than slapd, and I'd expect slurpd to be able to process it as long as it is valid ldif ? > As for copying the code from ldapmodify.c into slurpd - probably the better > solution would be to move the relevant code from ldapmodify.c into a library. Well, the relevant code is about 20 lines long, and adapted to the way slurpd handles memory. But sure, that could be shared. For the record, the patch I uploaded has an issue with empty changes blocks, so I uploaded a fixed version as ftp://ftp.openldap.org/incoming/gael.roualland-070129.diff -- Gaël Roualland -+- gael.roualland(a)oleane.net

1 0

Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests
by hyc＠symas.com 28 Jan '07

28 Jan '07

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/gael.roualland-070126.diff > Submission from: (NULL) (213.56.0.199) > > > Hello, > > Slurpd has a bug when replicating, in the way it generates the LDAPMod array of > the add and modify operations : if the same attribute is present several times > (for add) or in multiple change blocks (for modify) in the replication log, it > simply adds all occurences to the LDAPMod array, hence having one or more > attributes repeated serveral times which violates the protocol. > > This is usually fine with slapd because there is code there to accept invalid > queries from the updatedn, but it is rejected if you're not using updatedn > (which happens to be our case in a custom floating master scenario). > > The uploaded patch fixes this in slurpd by replacing its LDAPmod logic by one > based on ldapmodify which generates proper requests. I know slurpd is considered > deprecated, however this might be useful to others still using it and would > allow to remove the exception from slapd code. > > Regards, As far as I can see, slurpd merely processes the changes in the replog. If it is generating requests out of sequence, then they must have been recorded out-of-sequence in the log. And yet I don't see any reason why slapd would generate the modifications out of sequence. What are the circumstances that cause these improper sequences to get into the replog in the first place? As for copying the code from ldapmodify.c into slurpd - probably the better solution would be to move the relevant code from ldapmodify.c into a library. When we still maintained libldif as its own entity it would have made sense to put it there, but now it would seem to best fit in libldap, and perhaps the other LDIF routines in liblutil should move there as well. This would also partially address ITS#4033. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by daniel＠ncsu.edu 28 Jan '07

28 Jan '07

After talking with Howard some more, here is what we discovered: The reason I was having problems stemmed from two things: A. I am not writing out my attributes in a grouped (all ou's together) order B. I started using -q with slapadd as of the 2.3 series B explains why I didn't see it until 2.3. ;D I'm going to adjust my scripts to write out the ldif import files in proper order (easy enough) because I quite value the functionality of -q. ;D Didn't realize the ordering of attributes was important until now though, good to know! That combined with Howard's fix to the case sensitivity, I believe we're golden. Thanks much for your help with this!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs