- openldap-bugs - openldap.org

Re: (ITS#7322) Problem in LDAP Server
by quanah＠zimbra.com 06 Jul '12

06 Jul '12

--On Friday, July 06, 2012 5:20 AM +0000 kashif.hameed(a)vopium.com wrote: > Full_Name: Kashif Hameed > Version: openldap-2.3.43 > OS: Centos 32 Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.215.176.22) > > > Dear All > please help me its my first job and its my final assignment my job is > totally on this assignment. The ITS system is for reporting bugs. You have not reported a bug, this ITS will be closed. If you want the help you are desperately seeking, I would advise you to use the openldap-technical(a)openldap.org mail list, as advised on the openldap.org website for use when seeking help. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7322) Problem in LDAP Server
by kashif.hameed＠vopium.com 06 Jul '12

06 Jul '12

Full_Name: Kashif Hameed Version: openldap-2.3.43 OS: Centos 32 Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.215.176.22) Dear All please help me its my first job and its my final assignment my job is totally on this assignment. We have multiple servers of linux, Centos and Ubuntu, Debian my boss want to implement openldap in this situation that user will manage from central location. so i have started work on this and successfull to implement 1 case that is if we will create a simple user its authanticate but when we want to give sudo rights then it will return error here is the eroor please help me how to resolve this issue [root@ldapprod ~]# service ldap restart Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] /etc/openldap/schema/sudo.schema: line 1: AttributeType SYNTAX or SUPerior required: "sudoUser" slaptest: bad configuration file! Here is the file for your reference please look into this where syntax is wrong attributetype ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' ) DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoOption $ description ) X-ORIGIN 'SUDO' ) Thanks

1 0

(ITS#7321) Subtree replication: when removing object outside of subtree, contextCSN is not updating!
by kostjnspb＠yandex.ru 05 Jul '12

05 Jul '12

Full_Name: Konstantin Menshikov Version: 2.4.31 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/kmenshikov-120705.ext Submission from: (NULL) (212.116.101.94) I have replication setup, when i replicate not entire tree, but only part of it. Configuration provider and consumer attached. I use openldap-server-2.4.31 and db47-4.7.25.4 While adding object outside of the replicated subtree: e.g. ou=TestBranch1,dc=example,dc=com contextCSN of dn dc=example,dc=com on consumer server updated, ok. But while removing object, contextCSN not updated! Is it expected behavior or not? At first I added object *ou=hosts,ou=TestBranch2,dc=example,dc=com*.1 After I removed object. Provider log: Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SRCH base="ou=hosts,ou=TestBranch2,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SRCH attr=hasSubordinates objectClass Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SEARCH RESULT tag=101 err=32 nentries=0 text= Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=53 ADD dn="ou=hosts,ou=TestBranch2,dc=example,dc=com" Jun 22 06:37:54 ro1 slapd[62268]: slap_queue_csn: queing 0x7ffffe3fb100 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=53 RESULT tag=105 err=0 text= Jun 22 06:37:54 ro1 slapd[62268]: slap_graduate_commit_csn: removing 0x80191bfd0 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SRCH base="ou=hosts,ou=TestBranch2,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SRCH attr=hasSubordinates objectClass Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 22 06:38:01 ro1 slapd[62268]: conn=1002 op=55 DEL dn="ou=hosts,ou=TestBranch2,dc=example,dc=com" Jun 22 06:38:01 ro1 slapd[62268]: slap_queue_csn: queing 0x7ffffebfc590 20120622063801.799710Z#000000#000#000000 Jun 22 06:38:01 ro1 slapd[62268]: conn=1002 op=55 RESULT tag=107 err=0 text= Jun 22 06:38:01 ro1 slapd[62268]: slap_graduate_commit_csn: removing 0x802738970 20120622063801.799710Z#000000#000#000000 Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SRCH base="ou=TestBranch2,dc=example,dc=com" scope=1 deref=3 filter="(objectClass=*)" Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SRCH attr=hasSubordinates objectClass Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SEARCH RESULT tag=101 err=0 nentries=2 text= Consumer log: Jun 22 06:37:54 ro2 slapd[62298]: do_syncrep2: rid=111 LDAP_RES_INTERMEDIATE - NEW_COOKIE Jun 22 06:37:54 ro2 slapd[62298]: do_syncrep2: rid=111 NEW_COOKIE: rid=111,csn=20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro2 slapd[62298]: slap_queue_csn: queing 0x8019eca90 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro2 slapd[62298]: slap_graduate_commit_csn: removing 0x8019ec2b0 20120622063754.599740Z#000000#000#000000

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by Gavin Henry 05 Jul '12

05 Jul '12

Do we want to document this or change behavior?

1 0

Re: ITS#7317
by hyc＠symas.com 04 Jul '12

04 Jul '12

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Hmm, another 100 iterations without a problem. Not sure whether it's related >>> to back-mdb or whether this may happen occasionally with other backends too. >>> Trying more... >> >> Looks like a simple timing dependency in the test script. slapcat of the DB in >> your testrun directory shows that the correct value is present. The refint >> overlay does its work in a separate task, so there's no guarantee it will be >> done by the time the original modrdn request finishes. > > Ok, noted. > >> We could add a SLEEP in the script here but it seems to be such a rare >> occurrence I'm inclined to ignore it. > > Hmm, I'd argue that a SLEEP would be helpful to avoid further questions about > it. A OpenLDAP packager might run "make test" routinely and this issue aborts it. I've replaced the hardcoded "sleep 1" in the script with "sleep $SLEEP0" so it can be overridden along with the other SLEEP1/SLEEP2 values. Packagers running the tests should either ensure they're on an idle enough machine, or set larger values in their environment... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7320) ldap failed to bind
by rajeshece447＠gmail.com 29 Jun '12

29 Jun '12

Full_Name: raj kas Version: e16 OS: oracle linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.135.212.242) Today while working on APIGEE installation i ran into an ldap issue, clearly explained below. first installed apigee successfully and then i have to configure that apigee with openldap. For that i downloaded some openldap-clients and server rpms. After that changed password using SHA updated the slapd.conf file then restarted the ldap. Then i try to run a curl command {curl -v -X POST 'http://localhost:8080/v1/securityprofile' -H'content-type: application/xml' -d '<SecurityProfile><UserAccessControl enabled="true"/></SecurityProfile>'} to enable the user access, the response i got is 200ok but try to look in to apigee logs found an error as below 17:18:25.778 qtp60863806-35 INFO SERVICES.SECURITY - LDAPClient.createOrganizationalUnit() : LDAPClient.createOrganizationalUnit : Look up failed. Binding ou=users,dc=apigee,dc=com 17:18:25.783 qtp60863806-35 INFO SERVICES.SECURITY - LDAPClient.createOrganizationalUnit() : LDAPClient.createOrganizationalUnit : Look up failed. Binding ou=userroles,dc=apigee,dc=com 17:18:25.808 qtp60863806-35 INFO SERVICES.SECURITY - LDAPClient.initRoles() : LDAPClient.init() : Roles are not defined in ldap store. Initializing roles under dir ou=roles,dc=apigee,dc=com 17:47:11.259 qtp60863806-38 WARN SERVICES.SECURITY - UserAccessController.authorize() : UserAccessController.authorize : User name is not populated in the subject. Skipping authorization. 17:47:11.322 qtp60863806-39 WARN SERVICES.SECURITY - UserAccessController.authorize() : UserAccessController.authorize : User name is not populated in the subject. Skipping authorization. 17:47:11.324 qtp60863806-39 INFO SERVICES.SECURITY - LDAPClient.createOrganizat ionalUnit() : LDAPClient.createOrganizationalUnit : Look up failed. Binding ou=g lobal,ou=userroles,dc=apigee,dc=com

1 0

(ITS#7318) Error in slapd-config man page
by riggs＠umn.edu 26 Jun '12

26 Jun '12

Full_Name: Benjamin Riggs Version: 2.4.23 OS: http://ftp.scientificlinux.org/linux/scientific/6x/i386/os/Packages/openlda… URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.101.155.71) The example LDIF suitable for slapadd contains the line: include: /etc/openldap/schema/core.ldif This results in an error running slapadd. It should read (and does on the website): include: file:///etc/openldap/schema/core.ldif

1 0

Re: ITS#7317
by michael＠stroeder.com 26 Jun '12

26 Jun '12

This is a cryptographically signed message in MIME format. --------------ms040404000804090204020205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > michael(a)stroeder.com wrote: >> Hmm, another 100 iterations without a problem. Not sure whether it's r= elated >> to back-mdb or whether this may happen occasionally with other backend= s too. >> Trying more... >=20 > Looks like a simple timing dependency in the test script. slapcat of th= e DB in > your testrun directory shows that the correct value is present. The ref= int > overlay does its work in a separate task, so there's no guarantee it wi= ll be > done by the time the original modrdn request finishes. Ok, noted. > We could add a SLEEP in the script here but it seems to be such a rare > occurrence I'm inclined to ignore it. Hmm, I'd argue that a SLEEP would be helpful to avoid further questions a= bout it. A OpenLDAP packager might run "make test" routinely and this issue ab= orts it. Ciao, Michael. --------------ms040404000804090204020205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjI2MTYwMzUzWjAjBgkq hkiG9w0BCQQxFgQUb8fucJFt8qQlWtfGqjItIP13+dcwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAdsYRVP5QgW6lXnu7ux2qIN8RhWjPwiJ0c5CmFK/aNhPisi56lBwsi3eA46jisXo607ch gGR3qNA05xxNx03VfCsIk2Fbwfh5sA0dsf4Gf9J7vToUgBkmCYAeDbS6ngIVtinTUUpK3yjm 9xfo0JBvjy+g2BomwwFSkbbbw0jT/C/Ugfur9HiOArNpdL6mdmZ4jLQUrlhF1MPB6RMgexSB tuMnZj0lmwDizeyZzWu6ntkW1eiz7sK3xjTWKJpyVwa0ff4WBPom+/6gX1QwT0JohZC5NDFB cBl1mw/QCgLHG8EICHytxHoRnO4R14w9vrVJiSGIuZGiNbCJ3Q3SuDEFRAAAAAAAAA== --------------ms040404000804090204020205--

1 0

Re: (ITS#7308) [PATCH] contrib/slapd-modules: Add missing missing Makefiles
by hyc＠symas.com 26 Jun '12

26 Jun '12

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master, 2.4.31 > OS: > URL: https://gist.github.com/2931574 > Submission from: (NULL) (114.48.132.80) > > > In contrib/slapd-modules, some modules have no Makefile to build and install > itself. > I've created a patch to add Makefile and update README for that. Thanks for the patches, applied to master. This also seems to obsolete ITS#6883. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#7317
by hyc＠symas.com 26 Jun '12

26 Jun '12

michael(a)stroeder.com wrote: > Hmm, another 100 iterations without a problem. Not sure whether it's related > to back-mdb or whether this may happen occasionally with other backends too. > Trying more... Looks like a simple timing dependency in the test script. slapcat of the DB in your testrun directory shows that the correct value is present. The refint overlay does its work in a separate task, so there's no guarantee it will be done by the time the original modrdn request finishes. We could add a SLEEP in the script here but it seems to be such a rare occurrence I'm inclined to ignore it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#7317
by michael＠stroeder.com 25 Jun '12

25 Jun '12

Hmm, another 100 iterations without a problem. Not sure whether it's related to back-mdb or whether this may happen occasionally with other backends too. Trying more...

1 0

ITS#7317
by michael＠stroeder.com 25 Jun '12

25 Jun '12

This is a cryptographically signed message in MIME format. --------------ms070207060701040109000201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See testrun/ here: http://www.stroeder.com/temp/openldap-its7317-testrun.tar.bz2 --------------ms070207060701040109000201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjI1MjAwMDI3WjAjBgkq hkiG9w0BCQQxFgQUtiyKRxKgXS5VtfqjZUVjAHIMNoowbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAalN+30Ry/SMDuQg90TiynKL+uJZW/M83Nzy0FgsmpXuv/I7RaL6RELxMHA5sAbtdcIGu PDOSIemgQisdHNgkbh4PEsCR86wT++zd+UVYQHhsTxCsf9+BTSOoU/OxovwvIag4ww4shC8v 4OPAobZOWflcYgP//7OhEkDc8rwKx4nuLTfcEeqOm+mvZWjIl0Il/KltUme3xJ7xWMTmGFs+ D7P1OUUGs/X2sAWC+2dCHWcfnhINvGG+28TeuKNXJQdPusrFsIGynYMrbpx2eU0UMvhWoGyh Lk76onqKzeBBW0hs1cWU2soOnRzVC43Eyk8itxlswEoSk4EyNPx4vTmMdAAAAAAAAA== --------------ms070207060701040109000201--

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by hyc＠symas.com 25 Jun '12

25 Jun '12

Jan Synacek wrote: > On 06/07/2012 03:00 PM, Howard Chu wrote: >> This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) > I've updated the patch: > http://jsynacek.fedorapeople.org/openldap/jsynacek-20120619-constraint-coun… Thanks, committed to master with additional tweaks. > > Also, I've uploaded the tests I use: > http://jsynacek.fedorapeople.org/openldap/constraint-count-tests.tar.bz2 Looks like a nice start but you should look at the existing test script infrastructure, particularly the shell variables we already define, and make it conform. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7293) [PATCH] Add missing function declarations and make some functions static
by fumiyas＠osstech.jp 23 Jun '12

23 Jun '12

At Sat, 23 Jun 2012 05:42:15 -0700, Howard Chu wrote: > > Full_Name: SATOH Fumiyasu > > Version: master, 2.4.31 > > OS: > > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-function-declarations.patch > > Submission from: (NULL) (220.100.28.128) > > > > > > This patch adds missing function declarations to *.h, and make some > > functions and a global variable static. > > Thanks for the patch. In reviewing it, I see no reason to publish > ldap_pvt_sasl_getmechs or ldap_pvt_tls_check_hostname since neither is ever > referenced outside their defining source file. It looks like your addition of Thanks. > ldap_create_session_tracking_control is also a mistake, you should simply have > fixed the declaration ldap_create_session_tracking (which is a nonexistent name). Ah, right. > Did you have a particular need to use these functions? Aside from the No. I'm not an LDAP API user, thus I don't know which functions should be public or not. :-) > ldap_create_session_tracking_control typo I don't think it's worth the trouble > to tweak the others. -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7293) [PATCH] Add missing function declarations and make some functions static
by hyc＠symas.com 23 Jun '12

23 Jun '12

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master, 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-function-declarations.patch > Submission from: (NULL) (220.100.28.128) > > > This patch adds missing function declarations to *.h, and make some > functions and a global variable static. Thanks for the patch. In reviewing it, I see no reason to publish ldap_pvt_sasl_getmechs or ldap_pvt_tls_check_hostname since neither is ever referenced outside their defining source file. It looks like your addition of ldap_create_session_tracking_control is also a mistake, you should simply have fixed the declaration ldap_create_session_tracking (which is a nonexistent name). Did you have a particular need to use these functions? Aside from the ldap_create_session_tracking_control typo I don't think it's worth the trouble to tweak the others. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7316) [PATCH 5/5] MozNSS: do not retry when reading the pin from file
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0005-MozNSS… Submission from: (NULL) (209.132.186.34) If the password file contains invalid PIN for a certain token we should not retry the authentication, otherwise we can lock the token. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7315) [PATCH 4/5] MozNSS: do not authenticate to a slot manually
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0004-MozNSS… Submission from: (NULL) (209.132.186.34) We cannot rely on the value of ctx->tc_certificate->slot because it might refer to a wrong slot when the certificate is loaded multiple times. This can happen in multi-threaded applications. Instead of authenticating to a slot implicitly, we can leave the decision on Mozilla NSS library, which will initiate authentication to a proper slot when needed. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7314) [PATCH 3/5] MozNSS: lock whole init and clenaup process
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0003-MozNSS… Submission from: (NULL) (209.132.186.34) This patch changes the mutex locking during Mozilla NSS context initialization and shutdown. When multiple TLS contexts are created in multi-threaded application (like slapd with syncrepl), certificate, private key, or slot lookup errors appeared from time to time when other thread was loading the certificates. This patch makes the process safe as much as possible by protecting the whole context initialization and shutdown. Unfortunatelly, identifying the unsafe operations can be tricky with MozNSS. This patch should not cause any performance drawback, because the initialization is run just once per context. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7313) [PATCH 2/5] MozNSS: store certificate object instead of nickname in ctx
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0002-MozNSS… Submission from: (NULL) (209.132.186.34) PEM certificates should not be referenced by nicknames, because the nicknames are derived from basename of the cerificate file and in general are not easy-predictable. The code of Mozilla NSS backend depends on some aspects of PEM module and tries to guess the nicknames correctly. In some cases the guessing is wrong. This patch changes this approach and the PEM certificates are no longer referenced by nicknames. DER value of the certificate is extracted when the PEM file is loaded into the database and this DER value is then used to retrieve the certificate object. When certificate database is used (not PEM), certificates are retrieved using nickname as before. The retrieved certificate objects (and associated private keys) are now stored directly in the tlsm_ctx structure and the nickname (certname) disappears. The changes are quite broad, but the code was simplified on many places. This approach was recommended by Mozilla NSS developers and was recently implemented for example in CURL. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7312) [PATCH 1/5] MozNSS: context specific token description for certdb
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0001-MozNSS… Submission from: (NULL) (209.132.186.34) Prior to this patch, certificate lookup in Mozilla NSS certificate database by certificate nickname failed, if multiple certdbs were opened. This can happen in certain configurations of replication. Or when an application which links libldap, uses Mozilla NSS library as well. With this patch, all certdbs are opened explicitly with SECMOD_OpenUserDB() call. This allows us to specify a token description, which is later used as a prefix for the certificate nickname. The token description is unique for each TLS context created in OpenLDAP. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7311) Use JDBC-LDAP driver with Sybase Unwired Platform
by quanah＠zimbra.com 21 Jun '12

21 Jun '12

--On Thursday, June 21, 2012 10:31 AM +0000 iavdeev(a)nvg.ru wrote: > Full_Name: Igor G. Avdeev > Version: 2.4.21 > OS: Linux 2.6.32-41-server x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.221.17.130) > > Could you help me create such a properties file for the jdbc-ldap driver? > This ITS system is for filing bug reports. If you have questions, then use the openldap-technical mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7311) Use JDBC-LDAP driver with Sybase Unwired Platform
by iavdeev＠nvg.ru 21 Jun '12

21 Jun '12

Full_Name: Igor G. Avdeev Version: 2.4.21 OS: Linux 2.6.32-41-server x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.221.17.130) Hello, I use the jdbc-ldap driver to connect to the OpenLDAP server with Sybase Unwired Platform. Sybase Unwired Platform to create the data source uses a properties file. Here is an example of such a file: #Instance Properties #Mon Jun 18 12:06:21 MSD 2012 driverClass=com.extendedsystems.jdbc.advantage.ADSDriver ant.project=default-jmsbridge databaseURL=jdbc\:extendedsystems\:advantage\://${serverName}\:${portNumber};catalog \= ${databaseName} Could you help me create such a properties file for the jdbc-ldap driver?

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by jsynacek＠redhat.com 19 Jun '12

19 Jun '12

On 06/07/2012 03:00 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.29 >> OS: Fedora 16 >> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> Submission from: (NULL) (209.132.186.34) >> >> >> Constraint overlay doesn't take into account multiple modifications when using >> count. >> >> Example: If count for 'description' attribute is set e.g. to 2, the following >> results in a constraint violation: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> description: d2 >> description: d3-viol >> >> However, this passes: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> - >> add: description >> description: d2 >> - >> add: description >> description: d3 >> >> This patch fixes the behavior in case multiple modifications are used. >> >> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 >> >> The patch is uploaded on fedorapeople.org: >> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> >> I wasn't able to use ftp.openldap.org due to 'No space left' error. > > This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) > I've updated the patch: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120619-constraint-coun… Also, I've uploaded the tests I use: http://jsynacek.fedorapeople.org/openldap/constraint-count-tests.tar.bz2 -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by jsynacek＠redhat.com 18 Jun '12

18 Jun '12

On 06/07/2012 03:00 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.29 >> OS: Fedora 16 >> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> Submission from: (NULL) (209.132.186.34) >> >> >> Constraint overlay doesn't take into account multiple modifications when using >> count. >> >> Example: If count for 'description' attribute is set e.g. to 2, the following >> results in a constraint violation: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> description: d2 >> description: d3-viol >> >> However, this passes: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> - >> add: description >> description: d2 >> - >> add: description >> description: d3 >> >> This patch fixes the behavior in case multiple modifications are used. >> >> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 >> >> The patch is uploaded on fedorapeople.org: >> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> >> I wasn't able to use ftp.openldap.org due to 'No space left' error. > > This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) I'll fix the patch. I tested only deletes with no additional values. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by hyc＠symas.com 18 Jun '12

18 Jun '12

Jan Synacek wrote: > On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: >> jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: git (c73ec15) >>> OS: linux-fedora17 >>> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >>> Submission from: (NULL) (209.132.186.34) >>> >>> >>> I'm using a 2-node mmr setup on my local machine - configuration files and >>> 'uploader' scripts are provided in the archive. >>> >>> 1) I have the two nodes running. >>> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >>> slapd's memory usage. >>> 3) After some time (at about 2k users on my system), slapd consumes a large >>> amount of memory which is still growing >>> >>> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >>> using it e.g. for modifying each user's email, does NOT result in any memory >>> leakage. >>> >>> I have also created a massif output using valgrind's massif tool: >>> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >>> >>> I found a very similar bug (#7292), but I'm not sure if it's related. >> >> Running RE24 with valgrind --leak-check=full I see no leak when running your >> test. That should be the same as git c73ec15. No idea what leak you're seeing. >> > > The memory consumption still grows and slapd eventually gets killed by oom-killer. Perhaps you're seeing fragmentation in the glibc malloc library. Please test RE24, and try with some other malloc (e.g. tcmalloc). I've run your entire test with both valgrind and with tcmalloc's heap checker and neither one shows any leak. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs