- openldap-bugs - openldap.org

(ITS#7798) back-mdb can crash if slapadd runs with slapd
by hyc＠OpenLDAP.org 07 Feb '14

07 Feb '14

Full_Name: Howard Chu Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.197.231.190) Submitted by: hyc back-mdb is supposed to work for slapd/slapadd etc all running concurrently. slapd can crash if slapadd runs and the newly added entries use attributes that weren't in the database when slapd was started, because mdb_entry_decode() doesn't check for attribute validity. A fix is coming shortly.

1 0

(ITS#7797) crash with slapo-collect with existing attribute
by danno＠umich.edu 06 Feb '14

06 Feb '14

Full_Name: Dan Pritts Version: 2.4.39 OS: centos 6.x x64 URL: ftp://ftp.openldap.org/incoming/bugreport-danno-20140206.tgz Submission from: (NULL) (141.211.81.142) Hi, I'm attempting to use slapo-collect. In actual use I want to combine it with the translucent overlay, but for the purposes of debugging I am just using a bdb with local info. If the collective attribute is defined already in a dn, slapd crashes hard. Even with "any" logging enabled, nothing useful appears to be logged. I made some small hacks on the nis.schema and core.schema so that the attributes I want to be "collectives" can be defined on the parent OU's. (homeDirectory, loginShell,gecos) I've uploaded the config file, an ldif i used to populate the db, session output showing a successful search and a failed one, and the syslog from the deceased slapd. thanks danno

1 0

Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by pierangelo.masarati＠polimi.it 06 Feb '14

06 Feb '14

On 02/06/2014 11:25 PM, Howard Chu wrote: > Howard Chu wrote: >> pierangelo.masarati(a)polimi.it wrote: >>> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: >>>> Full_Name: Raphael Ouazana >>>> Version: 2.4.38 >>>> OS: Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (88.173.78.196) >>>> >>>> >>>> Hi, >>>> >>>> I have an old configuration that I would like to export/reimport. The >>>> olcDbDirectory item of this configuration contains a directory that >>>> does not >>>> longer exist. >>>> It it then impossible to modify the parameter: >>>> - I was told not to edit directly LDIF config files >>>> - if i try a slapcat -n0 I get: >>>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or >>>> directory >>>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: >>>> olcDbDirectory: >>>> value #0: invalid path: No such file or directory >>>> slapcat: bad configuration directory! >>>> >>>> I think slapcat should always allow to export a configuration. >>> >>> I see the point; slapcat is failing because to export the configuration >>> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, >>> and it reads the whole config tree. >>> >>> Perhaps when slapcat of only the config database is requested, config >>> parsing should skip other databases, or at least ignore errors, if >>> possible. >> >> Agreed, we definitely need this. > > But it's not clear that it's entirely feasible without major > structural changes to back-config. In particular, later config items > may depend on earlier ones succeeding (e.g., loading a module or > reading a schema definition). So we can't simply no-op everything > while running slapcat, nor can we safely ignore all errors, because we > must still be able to parse all of the underlying config LDIF and some > of it will be unparseable without appropriate schema being loaded. In the specific case, the fix is trivial: the user must create the folder. In principle, when a "ignore non-blocking errors" flag is set, parsing of olcDbDirectory should not cause a failure. Such flag would only be set for, say, database entries that are not strictly required for that slapcat (for any tool operation that does not need such database, for example). However, in this specific case, the user could simply find the directory name by manually inspecting the offending LDIF file... p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by hyc＠symas.com 06 Feb '14

06 Feb '14

Howard Chu wrote: > pierangelo.masarati(a)polimi.it wrote: >> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: >>> Full_Name: Raphael Ouazana >>> Version: 2.4.38 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (88.173.78.196) >>> >>> >>> Hi, >>> >>> I have an old configuration that I would like to export/reimport. The >>> olcDbDirectory item of this configuration contains a directory that does not >>> longer exist. >>> It it then impossible to modify the parameter: >>> - I was told not to edit directly LDIF config files >>> - if i try a slapcat -n0 I get: >>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory >>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: >>> value #0: invalid path: No such file or directory >>> slapcat: bad configuration directory! >>> >>> I think slapcat should always allow to export a configuration. >> >> I see the point; slapcat is failing because to export the configuration >> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, >> and it reads the whole config tree. >> >> Perhaps when slapcat of only the config database is requested, config >> parsing should skip other databases, or at least ignore errors, if possible. > > Agreed, we definitely need this. But it's not clear that it's entirely feasible without major structural changes to back-config. In particular, later config items may depend on earlier ones succeeding (e.g., loading a module or reading a schema definition). So we can't simply no-op everything while running slapcat, nor can we safely ignore all errors, because we must still be able to parse all of the underlying config LDIF and some of it will be unparseable without appropriate schema being loaded. -- -- 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#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com 06 Feb '14

06 Feb '14

This is a cryptographically signed message in MIME format. --------------ms030804020205040903090604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I, Michael Str=F6der, hereby place the attached modifications to OpenLDAP= Software (and only these modifications) into the public domain. Hence, th= ese modifications may be freely used and/or redistributed for any purpose wit= h or without attribution and/or other notice. Resent as readable ASCII diff for ITS. diff --git a/servers/slapd/back-bdb/filterindex.c b/servers/slapd/back-bdb/filterindex.c index 71e3ea4..bafef72 100644 --- a/servers/slapd/back-bdb/filterindex.c +++ b/servers/slapd/back-bdb/filterindex.c @@ -741,7 +741,7 @@ equality_candidates( &db, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D bdb_equality_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; @@ -858,7 +858,7 @@ approx_candidates( &db, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D bdb_approx_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; @@ -978,7 +978,7 @@ substring_candidates( &db, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D bdb_substring_candidates: (%s) not indexed\n", sub->sa_desc->ad_cname.bv_val, 0, 0 ); return 0; @@ -1095,7 +1095,7 @@ inequality_candidates( &db, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D bdb_inequality_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; diff --git a/servers/slapd/back-mdb/filterindex.c b/servers/slapd/back-mdb/filterindex.c index 58c1cc8..20c58b7 100644 --- a/servers/slapd/back-mdb/filterindex.c +++ b/servers/slapd/back-mdb/filterindex.c @@ -709,7 +709,7 @@ equality_candidates( &dbi, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D mdb_equality_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; @@ -825,7 +825,7 @@ approx_candidates( &dbi, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D mdb_approx_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; @@ -944,7 +944,7 @@ substring_candidates( &dbi, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D mdb_substring_candidates: (%s) not indexed\n", sub->sa_desc->ad_cname.bv_val, 0, 0 ); return 0; @@ -1060,7 +1060,7 @@ inequality_candidates( &dbi, &mask, &prefix ); if ( rc =3D=3D LDAP_INAPPROPRIATE_MATCHING ) { - Debug( LDAP_DEBUG_ANY, + Debug( LDAP_DEBUG_TRACE, "<=3D mdb_inequality_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; --------------ms030804020205040903090604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA2MTg0MDE4WjAj BgkqhkiG9w0BCQQxFgQUwLSiF3mKOJ8HENymkcl0lWAoDp8wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAgcpUZTuD+GEImrl5X5xOVLPuJcsHlLmr JWLrnLpOWBCd+caLEZjPcHge/3qSJB3BABOMK5VMV80LfesV9kQiolB6T9nMCD3CuLgAJRHD IgkZFb06osWxvzKbvvdWfs/7Z1X/pMGlpnSMGOePq5tYnaZXY5oUbElmkbna8mrclRM+TY4r mb4kcEskqLFScpl558H5EN6RWHsOYT3qaiyhhrSRUFu9tiVgJ5JpiNgdvpTofQpNt2m/WjZO SRGRfFxRysiEP8SaZ8+KzwxEj+Kr7/ZxE0L0VtElapE8YIRFxWQbNVYHyfyD1PbYy5LcczEK lkY7VvNTUS2tiN8Vj9QXaAAAAAAAAA== --------------ms030804020205040903090604--

1 0

Re: (ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com 06 Feb '14

06 Feb '14

----==67b6fd74c7313eed06f01db906d1b2a0 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit I, Michael Ströder, hereby place the attached 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. ----==67b6fd74c7313eed06f01db906d1b2a0 Content-Type: text/x-patch; name="openldap-master-its7796.patch" Content-Disposition: attachment; filename="openldap-master-its7796.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvYmFjay1iZGIvZmlsdGVyaW5kZXguYyBiL3NlcnZl cnMvc2xhcGQvYmFjay1iZGIvZmlsdGVyaW5kZXguYwppbmRleCA3MWUzZWE0Li5iYWZlZjcyIDEw MDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL2JhY2stYmRiL2ZpbHRlcmluZGV4LmMKKysrIGIvc2Vy dmVycy9zbGFwZC9iYWNrLWJkYi9maWx0ZXJpbmRleC5jCkBAIC03NDEsNyArNzQxLDcgQEAgZXF1 YWxpdHlfY2FuZGlkYXRlcygKIAkJJmRiLCAmbWFzaywgJnByZWZpeCApOwogCiAJaWYgKCByYyA9 PSBMREFQX0lOQVBQUk9QUklBVEVfTUFUQ0hJTkcgKSB7Ci0JCURlYnVnKCBMREFQX0RFQlVHX0FO WSwKKwkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsCiAJCQkiPD0gYmRiX2VxdWFsaXR5X2NhbmRp ZGF0ZXM6ICglcykgbm90IGluZGV4ZWRcbiIsIAogCQkJYXZhLT5hYV9kZXNjLT5hZF9jbmFtZS5i dl92YWwsIDAsIDAgKTsKIAkJcmV0dXJuIDA7CkBAIC04NTgsNyArODU4LDcgQEAgYXBwcm94X2Nh bmRpZGF0ZXMoCiAJCSZkYiwgJm1hc2ssICZwcmVmaXggKTsKIAogCWlmICggcmMgPT0gTERBUF9J TkFQUFJPUFJJQVRFX01BVENISU5HICkgewotCQlEZWJ1ZyggTERBUF9ERUJVR19BTlksCisJCURl YnVnKCBMREFQX0RFQlVHX1RSQUNFLAogCQkJIjw9IGJkYl9hcHByb3hfY2FuZGlkYXRlczogKCVz KSBub3QgaW5kZXhlZFxuIiwKIAkJCWF2YS0+YWFfZGVzYy0+YWRfY25hbWUuYnZfdmFsLCAwLCAw ICk7CiAJCXJldHVybiAwOwpAQCAtOTc4LDcgKzk3OCw3IEBAIHN1YnN0cmluZ19jYW5kaWRhdGVz KAogCQkmZGIsICZtYXNrLCAmcHJlZml4ICk7CiAKIAlpZiAoIHJjID09IExEQVBfSU5BUFBST1BS SUFURV9NQVRDSElORyApIHsKLQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQlEZWJ1ZyggTERB UF9ERUJVR19UUkFDRSwKIAkJCSI8PSBiZGJfc3Vic3RyaW5nX2NhbmRpZGF0ZXM6ICglcykgbm90 IGluZGV4ZWRcbiIsCiAJCQlzdWItPnNhX2Rlc2MtPmFkX2NuYW1lLmJ2X3ZhbCwgMCwgMCApOwog CQlyZXR1cm4gMDsKQEAgLTEwOTUsNyArMTA5NSw3IEBAIGluZXF1YWxpdHlfY2FuZGlkYXRlcygK IAkJJmRiLCAmbWFzaywgJnByZWZpeCApOwogCiAJaWYgKCByYyA9PSBMREFQX0lOQVBQUk9QUklB VEVfTUFUQ0hJTkcgKSB7Ci0JCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKKwkJRGVidWcoIExEQVBf REVCVUdfVFJBQ0UsCiAJCQkiPD0gYmRiX2luZXF1YWxpdHlfY2FuZGlkYXRlczogKCVzKSBub3Qg aW5kZXhlZFxuIiwgCiAJCQlhdmEtPmFhX2Rlc2MtPmFkX2NuYW1lLmJ2X3ZhbCwgMCwgMCApOwog CQlyZXR1cm4gMDsKZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvYmFjay1tZGIvZmlsdGVyaW5k ZXguYyBiL3NlcnZlcnMvc2xhcGQvYmFjay1tZGIvZmlsdGVyaW5kZXguYwppbmRleCA1OGMxY2M4 Li4yMGM1OGI3IDEwMDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL2JhY2stbWRiL2ZpbHRlcmluZGV4 LmMKKysrIGIvc2VydmVycy9zbGFwZC9iYWNrLW1kYi9maWx0ZXJpbmRleC5jCkBAIC03MDksNyAr NzA5LDcgQEAgZXF1YWxpdHlfY2FuZGlkYXRlcygKIAkJJmRiaSwgJm1hc2ssICZwcmVmaXggKTsK IAogCWlmICggcmMgPT0gTERBUF9JTkFQUFJPUFJJQVRFX01BVENISU5HICkgewotCQlEZWJ1Zygg TERBUF9ERUJVR19BTlksCisJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLAogCQkJIjw9IG1kYl9l cXVhbGl0eV9jYW5kaWRhdGVzOiAoJXMpIG5vdCBpbmRleGVkXG4iLCAKIAkJCWF2YS0+YWFfZGVz Yy0+YWRfY25hbWUuYnZfdmFsLCAwLCAwICk7CiAJCXJldHVybiAwOwpAQCAtODI1LDcgKzgyNSw3 IEBAIGFwcHJveF9jYW5kaWRhdGVzKAogCQkmZGJpLCAmbWFzaywgJnByZWZpeCApOwogCiAJaWYg KCByYyA9PSBMREFQX0lOQVBQUk9QUklBVEVfTUFUQ0hJTkcgKSB7Ci0JCURlYnVnKCBMREFQX0RF QlVHX0FOWSwKKwkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsCiAJCQkiPD0gbWRiX2FwcHJveF9j YW5kaWRhdGVzOiAoJXMpIG5vdCBpbmRleGVkXG4iLAogCQkJYXZhLT5hYV9kZXNjLT5hZF9jbmFt ZS5idl92YWwsIDAsIDAgKTsKIAkJcmV0dXJuIDA7CkBAIC05NDQsNyArOTQ0LDcgQEAgc3Vic3Ry aW5nX2NhbmRpZGF0ZXMoCiAJCSZkYmksICZtYXNrLCAmcHJlZml4ICk7CiAKIAlpZiAoIHJjID09 IExEQVBfSU5BUFBST1BSSUFURV9NQVRDSElORyApIHsKLQkJRGVidWcoIExEQVBfREVCVUdfQU5Z LAorCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwKIAkJCSI8PSBtZGJfc3Vic3RyaW5nX2NhbmRp ZGF0ZXM6ICglcykgbm90IGluZGV4ZWRcbiIsCiAJCQlzdWItPnNhX2Rlc2MtPmFkX2NuYW1lLmJ2 X3ZhbCwgMCwgMCApOwogCQlyZXR1cm4gMDsKQEAgLTEwNjAsNyArMTA2MCw3IEBAIGluZXF1YWxp dHlfY2FuZGlkYXRlcygKIAkJJmRiaSwgJm1hc2ssICZwcmVmaXggKTsKIAogCWlmICggcmMgPT0g TERBUF9JTkFQUFJPUFJJQVRFX01BVENISU5HICkgewotCQlEZWJ1ZyggTERBUF9ERUJVR19BTlks CisJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLAogCQkJIjw9IG1kYl9pbmVxdWFsaXR5X2NhbmRp ZGF0ZXM6ICglcykgbm90IGluZGV4ZWRcbiIsIAogCQkJYXZhLT5hYV9kZXNjLT5hZF9jbmFtZS5i dl92YWwsIDAsIDAgKTsKIAkJcmV0dXJuIDA7Cg== ----==67b6fd74c7313eed06f01db906d1b2a0--

1 0

(ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log messages
by michael＠stroeder.com 06 Feb '14

06 Feb '14

Full_Name: Version: HEAD and RE24 OS: URL: Submission from: (NULL) (212.227.35.93) Especially when using set-based ACLs the amount of "not indexed" messages is really annoying even when only "loglevel stats" is used. Since those messages are useless even for beginners the log-level should be changed to LDAP_DEBUG_TRACE instead of LDAP_DEBUG_ANY.

1 0

Re: (ITS#7795) "manage" access right needs better description
by michael＠stroeder.com 31 Jan '14

31 Jan '14

pierangelo.masarati(a)polimi.it wrote: > On 01/31/2014 06:44 PM, michael(a)stroeder.com wrote: >> pierangelo.masarati(a)polimi.it wrote: >>> On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: >>>> What does administrative access mean? >>> >>> It allows write when write is granted and the "relax" control is >>> present. In practice, those who have "manage" access can perform those >>> normally "prohibited" operations described in draft-zeilenga-ldap-relax. >> >> I wish this explanation would catch all cases. >> >> I vaguely remember that before the birth of draft-zeilenga-ldap-relax some >> (overlays?) misused the Manage DSA IT control for that purpose. > > "manageDIT" was renamed to "relax" because it was too similar to > "manageDSAit". Yes, I know. I meant it literally mentioning "Manage DSA IT control". Ciao, Michael.

1 0

Re: (ITS#7795) "manage" access right needs better description
by pierangelo.masarati＠polimi.it 31 Jan '14

31 Jan '14

On 01/31/2014 06:44 PM, michael(a)stroeder.com wrote: > pierangelo.masarati(a)polimi.it wrote: >> On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: >>> What does administrative access mean? >> >> It allows write when write is granted and the "relax" control is >> present. In practice, those who have "manage" access can perform those >> normally "prohibited" operations described in draft-zeilenga-ldap-relax. > > I wish this explanation would catch all cases. > > I vaguely remember that before the birth of draft-zeilenga-ldap-relax some > (overlays?) misused the Manage DSA IT control for that purpose. "manageDIT" was renamed to "relax" because it was too similar to "manageDSAit". Besides, although its use is intrinsically related to performing administrative operations, it is specifically meant to work around rules that make sense from a data model point of view but may need to be circumvented *during* "special" operations. A clear example is the one in the draft, about turning a "person" objectClass into an "account" objectClass. Changing the structuralObjectClass of an object is not allowed by the data model; however, an administrator (i.e. someone with "manage" privileges) can do it using the "relax" control, thus making the entry inconsistent during the operation but perfectly consistent before *and* after. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7795) "manage" access right needs better description
by quanah＠zimbra.com 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 5:36 PM +0000 quanah(a)zimbra.com wrote: Additional notes: [09:07] <hyc> manage access gives you permission to use the Relax control on a modify request [09:07] <hyc> to write to an attribute that is otherwise not user-writable [09:07] <hyc> only a small set of operational attributes are manageable [09:08] <hyc> createtimestamp, modifytimestamp, creatorsname, modifiersname, entryUUID, entryTTL [09:09] <hyc> otherwise, the relax control is useless [09:09] <hyc> hm, the ppolicy opattrs are also manageable -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7795) "manage" access right needs better description
by michael＠stroeder.com 31 Jan '14

31 Jan '14

pierangelo.masarati(a)polimi.it wrote: > On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: >> What does administrative access mean? > > It allows write when write is granted and the "relax" control is > present. In practice, those who have "manage" access can perform those > normally "prohibited" operations described in draft-zeilenga-ldap-relax. I wish this explanation would catch all cases. I vaguely remember that before the birth of draft-zeilenga-ldap-relax some (overlays?) misused the Manage DSA IT control for that purpose. Ciao, Michael.

1 0

Re: (ITS#7795) "manage" access right needs better description
by quanah＠zimbra.com 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 5:11 PM +0000 michael(a)stroeder.com wrote: > quanah(a)OpenLDAP.org wrote: >> What does administrative access mean? > > I can't describe the full meaning, only a specific use case: > > In some deployments I grant certain admins the right to remove > 'pwdHistory' attribute from an entry. Since this is an operational > attribute one has to grant also manage privilege for letting the client > remove the attribute in case it sends the Relax Rules control along with > the modify request. > > (yes, web2ldap implements this particular use case ;-) > > Example: > > access to > attrs=pwdHistory > by group="cn=all-mighty admins,dc=example,dc=com" =zm > by * none > > AFAIK this also applies to altering other operational attributes by using > Relax Rules control. > > Maybe you can take this as a start for a more general text. Great example, thanks! --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7795) "manage" access right needs better description
by quanah＠zimbra.com 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 6:08 PM +0100 Pierangelo Masarati <pierangelo.masarati(a)polimi.it> wrote: > On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.39 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.58.125) >> >> >> The documentation in the Admin guide and the man pages for the "manage" >> ACL setting has virtual no documentation. The only definitive statement >> is a very vague: >> >> " thus manage grants all access including administrative access" >> >> What does administrative access mean? > > It allows write when write is granted and the "relax" control is present. > In practice, those who have "manage" access can perform those normally > "prohibited" operations described in draft-zeilenga-ldap-relax. Excellent, thank you very much. ;) --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7795) "manage" access right needs better description
by michael＠stroeder.com 31 Jan '14

31 Jan '14

quanah(a)OpenLDAP.org wrote: > What does administrative access mean? I can't describe the full meaning, only a specific use case: In some deployments I grant certain admins the right to remove 'pwdHistory' attribute from an entry. Since this is an operational attribute one has to grant also manage privilege for letting the client remove the attribute in case it sends the Relax Rules control along with the modify request. (yes, web2ldap implements this particular use case ;-) Example: access to attrs=pwdHistory by group="cn=all-mighty admins,dc=example,dc=com" =zm by * none AFAIK this also applies to altering other operational attributes by using Relax Rules control. Maybe you can take this as a start for a more general text. Ciao, Michael.

1 0

Re: (ITS#7795) "manage" access right needs better description
by pierangelo.masarati＠polimi.it 31 Jan '14

31 Jan '14

On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > The documentation in the Admin guide and the man pages for the "manage" ACL > setting has virtual no documentation. The only definitive statement is a very > vague: > > " thus manage grants all access including administrative access" > > What does administrative access mean? It allows write when write is granted and the "relax" control is present. In practice, those who have "manage" access can perform those normally "prohibited" operations described in draft-zeilenga-ldap-relax. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7795) "manage" access right needs better description
by quanah＠OpenLDAP.org 31 Jan '14

31 Jan '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) The documentation in the Admin guide and the man pages for the "manage" ACL setting has virtual no documentation. The only definitive statement is a very vague: " thus manage grants all access including administrative access" What does administrative access mean?

1 0

(ITS#7794) RFE: Versioned LMDB shared library
by jstanek＠redhat.com 29 Jan '14

29 Jan '14

Full_Name: Jan Stanìk Version: LMDB 0.9.11 OS: Fedora 20 URL: Submission from: (NULL) (209.132.186.34) I'm trying to package LMDB for Fedora as possible system-wide replacement for Oracle's BerkeleyDB. The main trouble is that in current state the LMDB builds an unversioned liblmdb.so. I would like to propose to start versioning of liblmdb.so, so it would be possible to include it into ditribution without the possibility of sudden ABI break.

1 0

(ITS#7793) mdb_cursor_put(,,,MDB_CURRENT) should ignore key
by h.b.furuseth＠usit.uio.no 27 Jan '14

27 Jan '14

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.11 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-140128.c Submission from: (NULL) (81.191.45.35) Submitted by: hallvard The doc for mdb_cursor_put:MDB_CURRENT says "The key parameter is ignored". However: - key==NULL gives EINVAL after a thinko in the assert cleanup. 5bda3565a9bfaa6cd54053faeafcc06da15bc00c moved assert(key) from mdb_cursor_set() to the wrong place in the one relevant caller. - A huge key.mv_size triggers mdb_page_spill(). - If data.mv_size==0, the record's key instead of data is modified (so you can modify e.g. key:"foo" to key:"bar"). I expect the test should be (mc->mc_flags & C_SUB). Changing that has a side effect on a non-MDB_CURRENT case: With a cmp function like strncasecmp, changing "KEY" to "key" currently works with if old datasize = new datasize = 0. After this it won't, as with non-empty data of the same size. Test program enclosed.

1 0

(ITS#7792) slapd problems - ldap_result: Can't contact LDAP server (-1) result.c:813
by warron.french＠aero.org 27 Jan '14

27 Jan '14

Full_Name: Warron French Version: 2.4.38 LTB Project OS: CentOS-6.5 URL: Submission from: (NULL) (130.221.145.5) LTB-Project.org or OpenLDAP.org developers, please help: I am running CentOS-6.5 (on all machines in my little lab) and attempting to setup an LDAP server for user-account authentication, which requires TLS. My CentOS-6.5 machines are all running kernel 2.6.32-431.3.1.el6.x86_64. Also, the version of OpenLDAP I am running based on a suggestion from a user is LTB-Project.org's OpenLDAP-2.4.38, because the version that came natively available with CentOS-6.5's repos was a very old 2.4.23. I am writing a document in order to successfully repeat the build/configuration steps from my lab and lessons learned into a production system. The following is where I am... I am still having problems with adding (via .ldif file) the following LDIF file contents of /tmp/LDAP-CONFIG-TLS.ldif: dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: TLSv1+RSA:\!EXP:\!MD5:\!NULL (<- not sure if that argument is valid for that CipherSuite selection either) I use the following ldapmodify command: ldapmodify -x -D "cn=admin,cn=config" -W -f /tmp/LDAP-CONFIG-TLS.ldif Because I have debugging turned up (to -d 32768), the results now look like: modifying entry "cn=config" 52e68423 connection_input: conn=1000 deferring operation: binding slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. ldap_result: Can't contact LDAP server (-1) I saw a thread on openldap.org on the following link, http://www.openldap.org/lists/openldap-bugs/201308/msg00066.html , that has the exact same error. I can see that Howard Chu from Symas fixed the problem for Symas, did LTB Project fix this problem? I cannot find any threads via websearch for this issue. My /var/log/openldap.log file does not show anything extra. In fact a tail of the log file doesn't even show any errors really. What do I need to do in order to get my LDAP running with TLS? Thank you for any help, I am losing my sanity.

1 0

RE: (ITS#7791) 3-Way delta MMR segfault
by Marvin.Mundry＠uni-hamburg.de 24 Jan '14

24 Jan '14

------=_NextPart_000_02BE_01CF1907.2AD0DBB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > Hard to tell what's going on without seeing the configuration. config is contained in slapd.conf > I'd disable overlays one by one Unfortunately I'm lacking the time to create a miminalistic config that still shows the problem right now. I hope that the core dump is sufficient to determine what's going on here's the interesting part: Core was generated by `/usr/local/openldap/libexec/slapd -h ldap://zd-ldap-next-3/ ldaps://zd-ldap-nex'. Program terminated with signal 11, Segmentation fault. #0 0x00007f0a41327497 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) backtrace #0 0x00007f0a41327497 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00000000004b2ec1 in avl_find () #2 0x0000000000475094 in oc_bvfind () #3 0x000000000046def4 in ?? () #4 0x000000000044ae4e in ordered_value_match () #5 0x000000000044d1b7 in ?? () #6 0x000000000044d8e1 in test_filter () #7 0x000000000044dd12 in test_filter () #8 0x00007f0a3d8379a6 in syncprov_matchops (op=0x7f0a34a43ea0, opc=0x7f0a24000a90, saveit=0) at syncprov.c:1317 #9 0x00007f0a3d8386ce in syncprov_op_response (op=0x7f0a34a43ea0, rs=<optimized out>) at syncprov.c:1940 #10 0x000000000043e3b7 in ?? () #11 0x000000000043e8ba in ?? () #12 0x000000000043f2eb in slap_send_ldap_result () #13 0x00007f0a3e51101c in hdb_add (op=0x7f0a34a43ea0, rs=0x7f0a34a43e10) at add.c:515 #14 0x0000000000498637 in overlay_op_walk () #15 0x0000000000498718 in ?? () #16 0x00007f0a3da451d1 in accesslog_response (op=<optimized out>, rs=<optimized out>) at accesslog.c:1835 #17 0x0000000000497a68 in ?? () #18 0x000000000043e3b7 in ?? () #19 0x000000000043e8ba in ?? () #20 0x000000000043f2eb in slap_send_ldap_result () #21 0x00007f0a3e51101c in hdb_add (op=0x7f0a34a452c0, rs=0x7f0a34a449d0) at add.c:515 #22 0x0000000000498637 in overlay_op_walk () #23 0x0000000000498718 in ?? () #24 0x000000000048cbbe in ?? () #25 0x0000000000491024 in ?? () #26 0x00007f0a4204689a in ldap_int_thread_pool_wrapper (xpool=0x219c1d0) at tpool.c:688 #27 0x00007f0a415b2e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #28 0x00007f0a412df3fd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #29 0x0000000000000000 in ?? () Best regards, Marvin ------=_NextPart_000_02BE_01CF1907.2AD0DBB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS+zCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBUIwggQq oAMCAQICBArhMiEwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wNzA4MTQxMzU2MzVaFw0xOTA2MzAwMDAwMDBaMIGwMQswCQYDVQQGEwJERTEQMA4G A1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsGA1UEChMUVW5pdmVyc2l0YWV0IEhh bWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVudHJ1bTEVMBMGA1UEAxMMVUhIIENB IC0gRzAyMSQwIgYJKoZIhvcNAQkBFhV1aGgtY2FAdW5pLWhhbWJ1cmcuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9cJqgL8A8Sogf7u7EjbM2qEdN3S4JE7cHe7LuBbWE4c0/rBxj xChYBKUNlSzmlx4MulrkTtIjqmPY+tX4I/2vJGhxP4EksW+rMmjm/8xz1NanCk4Q7EhD9btiGHgs EZc0SQ4iWWCsV/zRhptvlNvas67IDz7fdyU3lp1nZmMgO1y5liQxMMhBtZ3PxLQBapWvOZ5t6cOa gvjfAmiVAC4ViWTQPwy5n7BvwtqrZ5NEiX+BbRC+akn2DepSWE2DxaZNQtX1/J2yAOhqZGM83Kaz qlE3ycL0o5AKhJjOt7R5/5bgggHVVxjI6qGx7Y6NJ/MNJJaO8r/H3OqlLRVLHNLvAgMBAAGjggG3 MIIBszASBgNVHRMBAf8ECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUJqBqAaj//BLr 9xSJ48UwNtEuObIwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwIAYDVR0RBBkwF4EV dWhoLWNhQHVuaS1oYW1idXJnLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNh LmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2Nk cDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUH AQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOC AQEAkGLlBHOj0MmD6zpgVmwZBBYGN4gN2XpN06HcZUGzvULVW31sNQUur4+0iBwIGcrCQ8EBBcQ5 9CU/tABVoL7JCJQlsZVLyjKvo6n0cRa3TM8V0Ia3CE67N9ALUhFNK7RKUUXDWrfrrzYV2fHLL9XZ MGpBH3obIcjd6yeGZ4fve2zTYi6PZX/g/lX3F+r8hcn7tcwoZEnWzaX1CmlJZX4ThvPAst+lm0bQ PUbchpktYXwToIXXKY3c0knV5w9j3ZaKR1aEko++uNskcXH1cmf+rZoZrk23Bqdc9ItWJQpWe4Xs CpL/G6jj7Bzx30zSLEMM5mbs+jtcTdQbEkQCiJtgxjCCBekwggTRoAMCAQICBxQ5wIYHEsswDQYJ KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdI YW1idXJnMR0wGwYDVQQKExRVbml2ZXJzaXRhZXQgSGFtYnVyZzEhMB8GA1UECxMYUmVnaW9uYWxl cyBSZWNoZW56ZW50cnVtMRUwEwYDVQQDEwxVSEggQ0EgLSBHMDIxJDAiBgkqhkiG9w0BCQEWFXVo aC1jYUB1bmktaGFtYnVyZy5kZTAeFw0xMjA4MDIwOTA1NThaFw0xNTA4MDIwOTA1NThaMIGmMQsw CQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsGA1UEChMU VW5pdmVyc2l0YWV0IEhhbWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVudHJ1bTEZ MBcGA1UECxMQWmVudHJhbGUgRGllbnN0ZTEWMBQGA1UEAxMNTWFydmluIE11bmRyeTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANkmwZKoyWJxCLKuLk9zlw9cZFbjEZvdLe572RXVPJ07 F0c4l6+bp58GIDBg8zfIxphXLAf+4L+6DFcTpg3B9iigF7U8UqcSDrTa/V5NZuveLvtcT+VjjymX NgRMnpDY2pAUfA2ETWEvle13SPrpHnoGFhZEpE3npClanWCfam8bwR5voaGTmzD3goaWuQ5Kfn6l gXTw0bX/F2ku+gppOcYRoMfA1W7tcnSwxaL4KA0urREStYv8XZvnxkONB/9Vb4cg6yNn1nf4sQoQ QcgiDaEFINTK2f+nGUXqSZ7nG9ls264pbehGhEVhY8njfkYQyYP4Nce34+kZXxWxrslgRaMCAwEA AaOCAg4wggIKMC8GA1UdIAQoMCYwEQYPKwYBBAGBrSGCLAEBBAIDMBEGDysGAQQBga0hgiwCAQQC AzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFH8iwhosgijkf5gL/pW70+giiyfyMB8GA1UdIwQYMBaAFCagagGo//wS6/cUiePF MDbRLjmyMCcGA1UdEQQgMB6BHG1hcnZpbi5tdW5kcnlAdW5pLWhhbWJ1cmcuZGUwgY0GA1UdHwSB hTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktaGFtYnVyZy1jYS9wdWIvY3Js L2dfY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLWNh L3B1Yi9jcmwvZ19jYWNybC5jcmwwgaYGCCsGAQUFBwEBBIGZMIGWMEkGCCsGAQUFBzAChj1odHRw Oi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLWNhL3B1Yi9jYWNlcnQvZ19jYWNlcnQuY3J0 MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLWNhL3B1Yi9j YWNlcnQvZ19jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBaBFnNZ5cjukq0beAbtezCWpGg bftTZo5dXocYo/uig+1q07Qdq4Hh8satTApZBuRVXKxRhJR6mfaoB7Czo6dyWn5JyvyTP8++9hOv LwXGhf4Xje+ExAzC5am6X0QqMBzRxro9B09WTzAwESrj1p5sik2UGNdRKa6E8zL3jW23EPrsqpR7 rUq+96vq3uvIl0yGw1TN6s0ROWHTqbwujX+jE1iDkAom8YrESuk8zc6nEF1PKMMXpzkoDQpsAczZ L7oBSaCIwNlZKG2SVIsJT29aEbaPpFa1rhjrX3+N0yw4TqG67Aen0x+xHoCg/og0VPTn/5myYZYl ki2kaqvq368xMYIElTCCBJECAQEwgbwwgbAxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJn MRAwDgYDVQQHEwdIYW1idXJnMR0wGwYDVQQKExRVbml2ZXJzaXRhZXQgSGFtYnVyZzEhMB8GA1UE CxMYUmVnaW9uYWxlcyBSZWNoZW56ZW50cnVtMRUwEwYDVQQDEwxVSEggQ0EgLSBHMDIxJDAiBgkq hkiG9w0BCQEWFXVoaC1jYUB1bmktaGFtYnVyZy5kZQIHFDnAhgcSyzAJBgUrDgMCGgUAoIICrTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAxMjQxMjIxMTlaMCMG CSqGSIb3DQEJBDEWBBRXXrSEAUI6UEtYiMPUNBXE9r4r3DCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBzQYJKwYBBAGCNxAEMYG/MIG8 MIGwMQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsG A1UEChMUVW5pdmVyc2l0YWV0IEhhbWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVu dHJ1bTEVMBMGA1UEAxMMVUhIIENBIC0gRzAyMSQwIgYJKoZIhvcNAQkBFhV1aGgtY2FAdW5pLWhh bWJ1cmcuZGUCBxQ5wIYHEsswgc8GCyqGSIb3DQEJEAILMYG/oIG8MIGwMQswCQYDVQQGEwJERTEQ MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsGA1UEChMUVW5pdmVyc2l0YWV0 IEhhbWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVudHJ1bTEVMBMGA1UEAxMMVUhI IENBIC0gRzAyMSQwIgYJKoZIhvcNAQkBFhV1aGgtY2FAdW5pLWhhbWJ1cmcuZGUCBxQ5wIYHEssw DQYJKoZIhvcNAQEBBQAEggEAPEo25BIwqMNdmpVqfLfg/kg3xePliQAn0bBSm0E6DVKPM1J9NJRT qu135n5LGG+PzMaOee9zr3DWpcQML4zas+VQdNCgSFVmo8AyUAiJi/nulqqVbTIAUUlYnqeZ2ifu mR29/6HC4ySwXL1svtIvqCLHkQLxHUPPJKCvWNb1QbMd1TUbZD4OMbXXrUx+DI501nie2ZfUnOa1 tQ3x/ApUzuZESAdJGCmkzNzXyQW0ue941n5xIj/O7+VKBJnIEctZOjwGy3SoJusKPiqk4sgDFEIe 9ihmRV/NptAsvZO1FANGz9RXiN7hDGIdoU3Bg+3B8W2ZpRmZ1Fd24zoR28vJ5wAAAAAAAA== ------=_NextPart_000_02BE_01CF1907.2AD0DBB0--

1 0

Re: (ITS#7791) 3-Way delta MMR segfault
by jsynacek＠redhat.com 24 Jan '14

24 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2014 11:57 AM, michael(a)stroeder.com wrote: > Hard to tell what's going on without seeing the configuration. > > I'd disable overlays one by one to check whether one of those causes the seg > fault. > slapo-rwm is one such candidate. If it really turns out that slapo-rwm is the culprit, consider checking the latest patch in ITS#7723. - -- Jan Synacek Software Engineer, Red Hat -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS4k1TAAoJEL3BmMJQOtjBxU0QAJPHFtx9mcEIi52JJQgVX3Ju I6kc1J+17ZaifuwS3wfBDAWy373oBUnmjcX17Sl0hPug3IoWLQ0alX5FO4ppCEwJ /fnbFpm7oXaP6xMqoZTUGAZ4pAk/fidXd/aGov3kIVIh89ZlA7OmsH9yCXqpLw8Z 2F4uZI54Gap5ZjCaQ5TCXynP+bpNiu3IImp3Co5TgOdAWrRxgfKnNz2zfjZSRnLt /jMOjcsEOuKJzK8CWIrA/ihH2Es8QPHXQ+bnnG9UtjIJJF3D22qn7Fu3qXOA1IDd RTqXXMsy1djmwi8idayFZpp2SzTMSYNAQ+81bPKhIKRzZvPq6mX1AFhjM6c4PqHK eIA5km37wfM5Es9+d6Z0MwYELkFdtMz/TGPy5KB79SkJ+rnK7TGyZG2Ojpl0XdG2 VcqW0oYCpPfKj5mH5J7zaJfdWPHF8ymbSruX0dcyGxZcoK2YMqU3bVzg/GW6Gbos nRG9G/ZglB4lRhztJOnjij8Vn964fKaPFzJhVAnWQIt2+3fExuGoWuU15brwMySW iHVy4kM8U9ON/fYpFkBGJDr1LcgtuOb6ERSyRcIkp5QVVKVfSLFP85gQJAn0XPDq 06ReRV3qu+Epao5yW+lrLb1HhFZ983NZzjH2nxkyJJ9DqooKuwqFVBAwuFp/ryEn xScRkMGLPCO5ksKj71UW =ZHqA -----END PGP SIGNATURE-----

1 0

Re: (ITS#7791) 3-Way delta MMR segfault
by michael＠stroeder.com 24 Jan '14

24 Jan '14

Hard to tell what's going on without seeing the configuration. I'd disable overlays one by one to check whether one of those causes the seg fault. slapo-rwm is one such candidate. Ciao, Michael.

1 0

(ITS#7791) 3-Way delta MMR segfault
by marvin.mundry＠uni-hamburg.de 24 Jan '14

24 Jan '14

Full_Name: Marvin Mundry Version: slapd 2.4.38 OS: Ubuntu 12.04 URL: http://attachment.rrz.uni-hamburg.de/rzrv002/bug.tar.bz Submission from: (NULL) (134.100.2.183) i have set up a 3-Way delta MMR replication. when i add the third machine to the replication (zd-ldap-3) that machine starts replicating objects but segfaults at some point during replication. i have * build openldap slapd 2.4.38 with the configuration shown in build.txt (in the attached file) * slapadd -S 1 -l /usr/local/openldap/etc/openldap/slapd.ldif -F /usr/local/openldap/etc/openldap/slapd.d -bcn=config (slapd.ldif is contained in the attached file) * started up zd-ldap-next-1 * imported ~67'000 objects via ldapadd * on zd-ldap-next-1: slapcat -bcn=config -F /usr/local/openldap/etc/openldap/slapd.d/ -l /tmp/configbk.ldif * scp /tmp/configbk.ldif from zd-ldap-1 --to--> zd-ldap-2 and zd-ldap-3 * on zd-ldap 2 and 3: slapadd -b cn=config -l /tmp/configbk.ldif -F /usr/local/openldap/etc/openldap/slapd.d * started up slapd on zd-ldap-2 * waited for the replication to finish (worked fine) * started up slapd on zd-ldap-3 * waited for the replication to finish ==> segfault after replication of ~40'000 objects (the number differs when i try to reproduce the bug (i.e. replication does not always fail at the same object))

1 0

Re: (ITS#7789) Unreliable mdb_env_set_mapsize()
by h.b.furuseth＠usit.uio.no 23 Jan '14

23 Jan '14

Should have enclosed a test program. Here: http://folk.uio.no/hbf/testsize.c Output: process #0: open env process #1: open env process #0: write txn, mapsize 204800 process #1: write txn, mapsize 40960 process #2: open env, write txn, mapsize 40960 process #3: open env, write txn, mapsize 204800 Summarizing a reply which got sent privately instead of to ITS: On 2014-01-24 00:07, Howard Chu wrote: > The doc says the caller of set_mapsize is required to make sure there > are no active transactions when it is called. As such, X failed this > requirement, and this sequence of events is explicitly unsupported. No, I'm talking about X changing the mapsize when there is no txn, then afterwards doing a write txn so the mapsize gets written. > If Y doesn't start its write txn until after X finishes, then Y will > see the new size. It doesn't, that's the point. Only txn_commit pays attention, and it checks the size which existed in the wrong metapage. Come to think of it, set_mapsize(); env_open(); txn begin/end should do the same. Y will either way not pay attention to the new mapsize. -- Hallvard

1 0

Re: (ITS#7789) Unreliable mdb_env_set_mapsize()
by hyc＠symas.com 23 Jan '14

23 Jan '14

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB 0.9.11 > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.254) > Submitted by: hallvard > > > Mapsize changes do not work as described, do not reliably store the > mapsize in the map, and it's hard to see how it is supposed to work. > E.g.: > - Open an environment twice, in processes X and Y. > - X grows the map and writes (commits) something to the DB. That > MDB_meta gets the new mapsize. > - Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc > says, nor does it carry forward X's MDB_meta.mm_mapsize change. The doc says the caller of set_mapsize is required to make sure there are no active transactions when it is called. As such, X failed this requirement, and this sequence of events is explicitly unsupported. If Y doesn't start its write txn until after X finishes, then Y will see the new size. > - Process Z opens the environment without doing set_mapsize(), > and gets the original mapsize from the MDB_meta written by Y. > > For that matter, from reading the doc I'd expect a mapsize change to > commit a txn with the new mapsize. There's no mention that the change > (and the MDB_MAP_RESIZED) will wait for something to be committed. > > mdb_txn_commit() writes nothing if the txn didn't change anything. > It needs to notice that there is a mapsize change to write. > > The doc talks about shrinking the map, but reduced mapsizes are not > written to the datafile. Only increases are written. > > All in all, it looks to me like _changing_ the mapsize should be an > operation on a write transaction or invoke a write transaction, while > setting the size or catching up with a mapsize change can be an > environment operation. That way it would be possible to make sense of > it. A txn can do it when it has no cursors and no dirty WRITEMAP > pages (or WRITEMAP could spill all pages first). > > BTW, I don't see the point of conditionally avoiding to write the > mapsize in mdb_env_write_meta() when full page gets written to disk > anyway - as long as txn_begin() stashes the mapsize from the original > meta so it knows what to write. (It need not obey the mapsize at that > point, but it must carry a change forward.) > > -- -- 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#7790) config.h filename clash. include path broken.
by mark＠ibiblio.org 23 Jan '14

23 Jan '14

Full_Name: Mark Version: 2.4.35 OS: Solaris 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.63.89.15) openldap-2.4.35/servers/slapd/back-ldif root# cc -I/usr/local/include -I../../../include -I../../../include -I.. -I./.. -I/usr/local/include -c ldif.c -o ldif.o "ldif.c", line 166: warning: no explicit type given "ldif.c", line 166: syntax error before or at: ldifcfg This happens because there is a /usr/local/include/config.h from libstdc++ which is included before openldap-2.4.35/servers/slapd/config.h, according to the -I include path order. The Makefile sets CFLAGS to "AC_CFLAGS DEFS". DEFS includes XINCPATH which should precede AC_CFLAGS, not succeed it. Either the order needs to be fixed, or more usefully config.h renamed to slapd_config.h To have configure work correctly, CPPFLAGS needs to be set to "-I/usr/local/include" otherwise /usr/local/include isn't searched for db.h, it picks up /usr/include/db.h which is not the one it needs to link against. + print -r -- 'configure:20296: checking for Berkeley DB major version in db.h' [...] 1> conftest.c + /bin/ggrep -E __db_version + eval '$CPP $CPPFLAGS conftest.c' + cc -E conftest.c + set X __db_version 5 none none + ol_cv_bdb_major=5 You can see it's only using CPP and CPPFLAGS in the eval command. Not CFLAGS which has the path for the correct db.h to use. To fix that, CPPFLAGS also needs to point to /usr/local/include. I'm using these fixes to move past both problems and get a properly working build: ./configure --prefix=/usr/local \ --with-cyrus-sasl \ --enable-bdb=yes \ --enable-spasswd=yes \ --enable-modules \ --enable-wrappers \ --enable-shared \ --with-tls=openssl \ ol_cv_berkeley_db_version=4.8.30 mv servers/slapd/config.h servers/slapd/slapd_config.h perl -pe 's#config.h#slapd_config.h#' -i servers/slapd/*.c perl -pe 's#"config.h"#"slapd_config.h"#' -i servers/slapd/*/*.c gmake depend gmake

1 0

(ITS#7789) Unreliable mdb_env_set_mapsize()
by h.b.furuseth＠usit.uio.no 22 Jan '14

22 Jan '14

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.11 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.254) Submitted by: hallvard Mapsize changes do not work as described, do not reliably store the mapsize in the map, and it's hard to see how it is supposed to work. E.g.: - Open an environment twice, in processes X and Y. - X grows the map and writes (commits) something to the DB. That MDB_meta gets the new mapsize. - Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc says, nor does it carry forward X's MDB_meta.mm_mapsize change. - Process Z opens the environment without doing set_mapsize(), and gets the original mapsize from the MDB_meta written by Y. For that matter, from reading the doc I'd expect a mapsize change to commit a txn with the new mapsize. There's no mention that the change (and the MDB_MAP_RESIZED) will wait for something to be committed. mdb_txn_commit() writes nothing if the txn didn't change anything. It needs to notice that there is a mapsize change to write. The doc talks about shrinking the map, but reduced mapsizes are not written to the datafile. Only increases are written. All in all, it looks to me like _changing_ the mapsize should be an operation on a write transaction or invoke a write transaction, while setting the size or catching up with a mapsize change can be an environment operation. That way it would be possible to make sense of it. A txn can do it when it has no cursors and no dirty WRITEMAP pages (or WRITEMAP could spill all pages first). BTW, I don't see the point of conditionally avoiding to write the mapsize in mdb_env_write_meta() when full page gets written to disk anyway - as long as txn_begin() stashes the mapsize from the original meta so it knows what to write. (It need not obey the mapsize at that point, but it must carry a change forward.)

1 0

(ITS#7788) pwdFailureTime and pwdChangedTime registered in user entry even if no ppolicy associated with the entry
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Full_Name: Clement OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hi, I have configured a ppolicy overlay without olcPPolicyDefault value. So I use pwdPolicySubentry in user entries to bind them to their policy configuration entry. Overlay ppolicy is compiled in slapd, not as module. I use LTB package. If I create an account without pwdPolicySubentry, the attributes pwdChangedTime and pwdFailureTime are generated for this entry. And as the entry is never locked (which is a normal behavior, fixed in http://www.openldap.org/its/index.cgi?findid=6168), the number of values in pwdFailureTime can grow indefinitely. IMHO, no ppolicy operational attributes should be present in an entry not linked to a password policy.

1 0

Re: (ITS#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Le 16/01/2014 16:42, Howard Chu a écrit : > coudot(a)linagora.com wrote: >> >> >> Le 16/01/2014 15:31, Howard Chu a écrit : >>> coudot(a)linagora.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.38 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.145.72.122) >>>> >>>> >>>> Here is the situation : a user account is >>>> 1/ expired (the password age is more that the one configured in >>>> pwdMaxGae) >>>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy >>>> configuration >>>> object is TRUE) >>>> >>>> In this case, when doing a BIND, the result code is 0: >>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret >>>> -e >>>> ppolicy >>>> ldap_bind: Success (0); Password must be changed (Password expires >>>> in >>>> 0 >>>> seconds) >>>> dn: uid=coudot,ou=users,dc=example,dc=com >>>> >>>> If I remove pwdReset attribute, then: >>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret >>>> -e >>>> ppolicy >>>> ldap_bind: Invalid Credentials (49); Password expired >>>> >>>> According to password policy draft, the password must change flag >>>> should not >>>> affect the BIND result code. >>> >>> The draft specifies the policy checks in the order in which they are >>> to be performed. The PasswordMustBeChanged check occurs before the >>> PasswordExpired check. >>> >>> The code works as designed. >> >> >> Well, I understand. If this is not a bug in the OpenLDAP >> implementation, it is maybe a point to discuss in the draft. Indeed, >> a >> simple LDAP client (that don't use ppolicy control) will get a >> successful BIND response even if the password is expired. > > How can the password be expired if the admin has just reset it? > I never said it was *just* reset, we can imagine the password was reset a year ago and that the user never changed it. What I point here is that a reset password never expires, whatever you configure in pwdMaxAge. People using the password reset feature must be aware of this, and be sure to have an application that will force the user to change its password. >> Maybe it is the wanted behavior, maybe not. > >> The fact is that if an administator reset the password (by changing >> password value and setting pwdReset to TRUE), this reseted password >> will >> never expire. From my point of view, this is a security flaw in the >> password policy system, as a lot of applications just use the BIND >> operation on LDAP server (searches and other operations are done by >> application LDAP accounts). > > I agree that the MustChange feature doesn't mesh well with > applications that simply perform a Bind and then do nothing else. Feel > free to raise this point on the ldapext mailing list. Yes I will give a try. You can close this ITS, thanks for the answers. Clement.

1 0

Re: (ITS#7787) Authentication success if password is expired and password must be changed
by hyc＠symas.com 16 Jan '14

16 Jan '14

coudot(a)linagora.com wrote: > > > Le 16/01/2014 15:31, Howard Chu a écrit : >> coudot(a)linagora.com wrote: >>> Full_Name: Clement OUDOT >>> Version: 2.4.38 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.145.72.122) >>> >>> >>> Here is the situation : a user account is >>> 1/ expired (the password age is more that the one configured in >>> pwdMaxGae) >>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy >>> configuration >>> object is TRUE) >>> >>> In this case, when doing a BIND, the result code is 0: >>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >>> ppolicy >>> ldap_bind: Success (0); Password must be changed (Password expires in >>> 0 >>> seconds) >>> dn: uid=coudot,ou=users,dc=example,dc=com >>> >>> If I remove pwdReset attribute, then: >>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >>> ppolicy >>> ldap_bind: Invalid Credentials (49); Password expired >>> >>> According to password policy draft, the password must change flag >>> should not >>> affect the BIND result code. >> >> The draft specifies the policy checks in the order in which they are >> to be performed. The PasswordMustBeChanged check occurs before the >> PasswordExpired check. >> >> The code works as designed. > > > Well, I understand. If this is not a bug in the OpenLDAP > implementation, it is maybe a point to discuss in the draft. Indeed, a > simple LDAP client (that don't use ppolicy control) will get a > successful BIND response even if the password is expired. How can the password be expired if the admin has just reset it? > Maybe it is the wanted behavior, maybe not. > The fact is that if an administator reset the password (by changing > password value and setting pwdReset to TRUE), this reseted password will > never expire. From my point of view, this is a security flaw in the > password policy system, as a lot of applications just use the BIND > operation on LDAP server (searches and other operations are done by > application LDAP accounts). I agree that the MustChange feature doesn't mesh well with applications that simply perform a Bind and then do nothing else. Feel free to raise this point on the ldapext mailing list. -- -- 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#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Le 16/01/2014 15:31, Howard Chu a écrit : > coudot(a)linagora.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.38 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.145.72.122) >> >> >> Here is the situation : a user account is >> 1/ expired (the password age is more that the one configured in >> pwdMaxGae) >> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy >> configuration >> object is TRUE) >> >> In this case, when doing a BIND, the result code is 0: >> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >> ppolicy >> ldap_bind: Success (0); Password must be changed (Password expires in >> 0 >> seconds) >> dn: uid=coudot,ou=users,dc=example,dc=com >> >> If I remove pwdReset attribute, then: >> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >> ppolicy >> ldap_bind: Invalid Credentials (49); Password expired >> >> According to password policy draft, the password must change flag >> should not >> affect the BIND result code. > > The draft specifies the policy checks in the order in which they are > to be performed. The PasswordMustBeChanged check occurs before the > PasswordExpired check. > > The code works as designed. Well, I understand. If this is not a bug in the OpenLDAP implementation, it is maybe a point to discuss in the draft. Indeed, a simple LDAP client (that don't use ppolicy control) will get a successful BIND response even if the password is expired. Maybe it is the wanted behavior, maybe not. The fact is that if an administator reset the password (by changing password value and setting pwdReset to TRUE), this reseted password will never expire. From my point of view, this is a security flaw in the password policy system, as a lot of applications just use the BIND operation on LDAP server (searches and other operations are done by application LDAP accounts). Clément.

1 0

Re: (ITS#7787) Authentication success if password is expired and password must be changed
by hyc＠symas.com 16 Jan '14

16 Jan '14

coudot(a)linagora.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > > Here is the situation : a user account is > 1/ expired (the password age is more that the one configured in pwdMaxGae) > 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration > object is TRUE) > > In this case, when doing a BIND, the result code is 0: > $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy > ldap_bind: Success (0); Password must be changed (Password expires in 0 > seconds) > dn: uid=coudot,ou=users,dc=example,dc=com > > If I remove pwdReset attribute, then: > $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy > ldap_bind: Invalid Credentials (49); Password expired > > According to password policy draft, the password must change flag should not > affect the BIND result code. The draft specifies the policy checks in the order in which they are to be performed. The PasswordMustBeChanged check occurs before the PasswordExpired check. The code works as designed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Full_Name: Clement OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Here is the situation : a user account is 1/ expired (the password age is more that the one configured in pwdMaxGae) 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration object is TRUE) In this case, when doing a BIND, the result code is 0: $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy ldap_bind: Success (0); Password must be changed (Password expires in 0 seconds) dn: uid=coudot,ou=users,dc=example,dc=com If I remove pwdReset attribute, then: $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy ldap_bind: Invalid Credentials (49); Password expired According to password policy draft, the password must change flag should not affect the BIND result code.

1 0

Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by hyc＠symas.com 15 Jan '14

15 Jan '14

pierangelo.masarati(a)polimi.it wrote: > On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: >> Full_Name: Raphael Ouazana >> Version: 2.4.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> Hi, >> >> I have an old configuration that I would like to export/reimport. The >> olcDbDirectory item of this configuration contains a directory that does not >> longer exist. >> It it then impossible to modify the parameter: >> - I was told not to edit directly LDIF config files >> - if i try a slapcat -n0 I get: >> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory >> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: >> value #0: invalid path: No such file or directory >> slapcat: bad configuration directory! >> >> I think slapcat should always allow to export a configuration. > > I see the point; slapcat is failing because to export the configuration > (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, > and it reads the whole config tree. > > Perhaps when slapcat of only the config database is requested, config > parsing should skip other databases, or at least ignore errors, if possible. Agreed, we definitely need this. > > p. > > -- -- 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#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by pierangelo.masarati＠polimi.it 15 Jan '14

15 Jan '14

On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > Hi, > > I have an old configuration that I would like to export/reimport. The > olcDbDirectory item of this configuration contains a directory that does not > longer exist. > It it then impossible to modify the parameter: > - I was told not to edit directly LDIF config files > - if i try a slapcat -n0 I get: > 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory > 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: > value #0: invalid path: No such file or directory > slapcat: bad configuration directory! > > I think slapcat should always allow to export a configuration. I see the point; slapcat is failing because to export the configuration (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, and it reads the whole config tree. Perhaps when slapcat of only the config database is requested, config parsing should skip other databases, or at least ignore errors, if possible. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by raphael.ouazana＠linagora.com 15 Jan '14

15 Jan '14

Full_Name: Raphael Ouazana Version: 2.4.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) Hi, I have an old configuration that I would like to export/reimport. The olcDbDirectory item of this configuration contains a directory that does not longer exist. It it then impossible to modify the parameter: - I was told not to edit directly LDIF config files - if i try a slapcat -n0 I get: 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: value #0: invalid path: No such file or directory slapcat: bad configuration directory! I think slapcat should always allow to export a configuration. Regards, Raphaël Ouazana.

1 0

Re: (ITS#7785) ContextCSN not updated
by michael＠stroeder.com 14 Jan '14

14 Jan '14

badguy9588(a)hotmail.com wrote: > Full_Name: > Version: 2.4.11 > OS: Redhat Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.82.28.193) > > > We are using 4 ways multimaster openldap 2.4.11 for more than 5 years. > > On Jan 3, 2014, one of the openldap contextCSN is not updated, always stay at > Jan 3 01:xx:xx, all the other servers are already updated to Jan 6. Any reason why you insist on using such an ancient release? In 5,5 years since 2.4.11 release there have been numerous important contextCSN related fixes to OpenLDAP 2.4.x code. You should definitely upgrade! Everything else is wasting your own time and the OpenLDAP project people's resources. Ciao, Michael.

1 0

(ITS#7785) ContextCSN not updated
by badguy9588＠hotmail.com 13 Jan '14

13 Jan '14

Full_Name: Version: 2.4.11 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.82.28.193) We are using 4 ways multimaster openldap 2.4.11 for more than 5 years. On Jan 3, 2014, one of the openldap contextCSN is not updated, always stay at Jan 3 01:xx:xx, all the other servers are already updated to Jan 6. So, this introduce large amount of sync data between the 4 openldap servers finally, cause the slapd process memory increase from 500mb to 4Gb and finally, all memory used up and all 4 servers hanged and error message in KVM shows "Kernel panic, out of memory". The servers needed to reboot in order to resume access. However, after some time, it will happen again. We finally find that the contextCSN in one server is not updated. What we do is stop the slapd process in that server, delete the data files and the do a backup in other 3 servers. Then restore the backup in the problem server from the backup using slapadd and finally, all the data is synced. What's the root cause of this problem ? We have been using it for over 5 years already and this is the first time that this problem occurs. Thanks

1 0

Re: (ITS#7784) Client stores bindpw in cleartext
by fumiyas＠osstech.co.jp 13 Jan '14

13 Jan '14

At Tue, 14 Jan 2014 01:12:55 GMT, ylau(a)huawei.com wrote: > When nss_ldap uses LDAP authentication with binding method, the bindpw stored in > ldap.conf is clear text. > However on Solaris NS_LDAP_BINDPASSWD could be stored in encrypted string. There > is no password obfuscation with nss_ldap. > So we considered it is a security issue and will affect the result of security > audit. {NS1} format is not safe. You can decrypt it without any other secret. http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0

Re: (ITS#7784) Client stores bindpw in cleartext
by hyc＠symas.com 13 Jan '14

13 Jan '14

ylau(a)huawei.com wrote: > Full_Name: Yo Lau > Version: 2.3.32 > OS: SUSE Linux Enterprise Server 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.130.146.228) > OpenLDAP 2.3.32 is over 6 years old and long since unsupported. nss_ldap is not a piece of OpenLDAP software. Contact SuSE for support, this ITS will be closed. > When nss_ldap uses LDAP authentication with binding method, the bindpw stored in > ldap.conf is clear text. > However on Solaris NS_LDAP_BINDPASSWD could be stored in encrypted string. There > is no password obfuscation with nss_ldap. > So we considered it is a security issue and will affect the result of security > audit. > > -- -- 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#7784) Client stores bindpw in cleartext
by ylau＠huawei.com 13 Jan '14

13 Jan '14

Full_Name: Yo Lau Version: 2.3.32 OS: SUSE Linux Enterprise Server 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.130.146.228) When nss_ldap uses LDAP authentication with binding method, the bindpw stored in ldap.conf is clear text. However on Solaris NS_LDAP_BINDPASSWD could be stored in encrypted string. There is no password obfuscation with nss_ldap. So we considered it is a security issue and will affect the result of security audit.

1 0

Re: (ITS#7778) Index and derived attribute bug
by hyc＠symas.com 13 Jan '14

13 Jan '14

yann.cezard(a)univ-pau.fr wrote: > Full_Name: Yann Cezard > Version: 2.4.38 > OS: Debian GNU/Linux Wheezy / amd64 > URL: ftp://ftp.openldap.org/incoming/Yann-Cezard-130109.tgz > Submission from: (NULL) (2001:660:6701:14:225:64ff:fe92:685b) > > > Hello, > > I hit a bug with the latest version of OpenLDAP (2.4.38) that was not present, > at least in 2.4.17 (made a test on an older server that we were using before I > discovered this). > This happens on both lmdb and bdb backend (as we were using BDB before upgrading > to 2.4.38, I tested with both on 2.4.38 to ensure that the problem was not LMDB > related). > The only ways to make the '(mail=*)' filter matches again the modified entry, is > to modify the mail attribute, or to run slapindex. > If you remove the index on the mail attribute, then there is no such problem. > It only happens when deleting all/the last derived attributes (supannAutreMail > here) from the entry. > > Sounds to me like a bug, isn't it ? Thanks for the report, fixed now in git master. > > Regards. > > -- -- 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#7783) tlsm_ctx_free crashes if ctx->tc_pin_file is null
by hyc＠symas.com 12 Jan '14

12 Jan '14

chris.w.martin(a)oracle.com wrote: > Full_Name: Chris Martin > Version: 2.4.23-32.el6_4.1 but also present in git repository version > OS: Oracle Linux 6 > URL: > Submission from: (NULL) (148.87.19.206) > > > If tlsm_ctx_free is entered with ctx->tc_pin_file null it will crash when it > calls PL_strfree with that null pointer. > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > 2039 static void > 2040 tlsm_ctx_free ( tls_ctx *ctx ) > 2041 { > ... > 2069 PL_strfree( c->tc_pin_file ) > > I propose that an "if ( c->tc_pin_file )" be added before this line to protect > against this. > > > The specific use case when we hit this involves automount calling openldap > ldap_start_tls_s which fails with LDAP_CONNECT_ERROR. automount then calls > openldap ldap_unbind_ext which calls ldap_ld_free which calls > ldap_int_tls_destroy which triggers this crash above. Thanks for the report. This is now fixed in git master, plus another potential instance of the same issue. You guys are crazy to even be using this MozNSS POS. -- -- 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#7778) Index and derived attribute bug
by quanah＠zimbra.com 10 Jan '14

10 Jan '14

--On Thursday, January 09, 2014 2:55 PM +0000 yann.cezard(a)univ-pau.fr wrote: > Full_Name: Yann Cezard > Version: 2.4.38 > OS: Debian GNU/Linux Wheezy / amd64 > URL: ftp://ftp.openldap.org/incoming/Yann-Cezard-130109.tgz > Submission from: (NULL) (2001:660:6701:14:225:64ff:fe92:685b) > > > Hello, > > I hit a bug with the latest version of OpenLDAP (2.4.38) that was not > present, at least in 2.4.17 (made a test on an older server that we were > using before I discovered this). > This happens on both lmdb and bdb backend (as we were using BDB before > upgrading to 2.4.38, I tested with both on 2.4.38 to ensure that the > problem was not LMDB related). <hbf> ITS#7778: Broken in 2.4.37 by 96f35c08944a "ITS#7329 optimize index update for simple add". -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7783) tlsm_ctx_free crashes if ctx->tc_pin_file is null
by chris.w.martin＠oracle.com 10 Jan '14

10 Jan '14

Full_Name: Chris Martin Version: 2.4.23-32.el6_4.1 but also present in git repository version OS: Oracle Linux 6 URL: Submission from: (NULL) (148.87.19.206) If tlsm_ctx_free is entered with ctx->tc_pin_file null it will crash when it calls PL_strfree with that null pointer. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… 2039 static void 2040 tlsm_ctx_free ( tls_ctx *ctx ) 2041 { ... 2069 PL_strfree( c->tc_pin_file ) I propose that an "if ( c->tc_pin_file )" be added before this line to protect against this. The specific use case when we hit this involves automount calling openldap ldap_start_tls_s which fails with LDAP_CONNECT_ERROR. automount then calls openldap ldap_unbind_ext which calls ldap_ld_free which calls ldap_int_tls_destroy which triggers this crash above.

1 0

Re: AW: (ITS#7249) slapd segfault with memberof overlay on frontend db
by michael＠stroeder.com 10 Jan '14

10 Jan '14

harald.winkelmann(a)bertschinnovation.com wrote: >> Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? > > This is the actual openldap version distributed with the actual debian stable version (wheezy). Whatever Debian considers "stable" (for what definition?) is not relevant for OpenLDAP. Personally I consider the Debian packages rather unmaintained. Ciao, Michael.

1 0

AW: (ITS#7249) slapd segfault with memberof overlay on frontend db
by harald.winkelmann＠bertschinnovation.com 10 Jan '14

10 Jan '14

>Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? This is the actual openldap version distributed with the actual debian stable version (wheezy). I just made a full dist-upgrade and run into this problem. This thread is still active. So... Harry

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by michael＠stroeder.com 10 Jan '14

10 Jan '14

harald.winkelmann(a)bertschinnovation.com wrote: > Debian Wheezy > openldap_2.4.31 Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? Ciao, Michael.

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by harald.winkelmann＠bertschinnovation.com 10 Jan '14

10 Jan '14

--_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, is anybody working on this issue? I've the same problem. I tried the following patch and it works for me. Why isn't it applied here. https://bugs.archlinux.org/task/38137?getfile=3D11329 Debian Wheezy openldap_2.4.31 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_bdb moduleload memberof.la overlay memberof ####################################################################### # Specific Backend Directives for @BACKEND@: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb With friendly regards Harald Winkelmann Software Development DAM Group GmbH Planckstra=DFe 7 88677 Markdorf --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hello,<o:p></o:p> <o:p> </o:p> is anybody working on this issu= e?<o:p></o:p> I’ve the same problem.<o:= p></o:p> I tried the following patch and= it works for me. Why isn’t it applied here.<o:p></o:p> <a href=3D"https://bugs.archlin= ux.org/task/38137?getfile=3D11329">https://bugs.archlinux.org/task/38137?ge= tfile=3D11329</a><o:p></o:p> <o:p> </o:p> Debian Wheezy<o:p></o:p>= openldap_2.4.31<o:p></o:p></spa= n> <o:p> </o:p> # Schema and objectClass defini= tions<o:p></o:p> include    =      /etc/ldap/schema/core.schema<o:p></o:p> include    =      /etc/ldap/schema/cosine.schema<o:p></o:p></= p> include       &nb= sp; /etc/ldap/schema/nis.schema<o:p></o:p> include       &nb= sp; /etc/ldap/schema/inetorgperson.schema<o:p></o:p> <o:p> </o:p> pidfile    =      /var/run/slapd/slapd.pid<o:p></o:p> argsfile   &nbsp= ;    /var/run/slapd/slapd.args<o:p></o:p> loglevel   &nbsp= ;    none<o:p></o:p> <o:p> </o:p> modulepath   &nb= sp;  /usr/lib/ldap<o:p></o:p> moduleload   &nb= sp;  back_bdb<o:p></o:p> moduleload   &nb= sp;  memberof.la<o:p></o:p> overlay memberof<o:p></o:p></sp= an> <o:p> </o:p> ###############################= ########################################<o:p></o:p> # Specific Backend Directives f= or @BACKEND@:<o:p></o:p> # Backend specific directives a= pply to this backend until another<o:p></o:p> # 'backend' directive occurs<o:= p></o:p> backend    =      bdb<o:p></o:p> <o:p> </o:p> <o:p> </o:p> With friendly regards<o:p></o:p></= span> Harald Winkelmann<o:p></o:p></span= > Software Development<o:p></o:p></s= pan> <o:p> </o:p> DAM Group GmbH<o:p></o:p= > Planckstra=DFe 7<o:p></o:p> 88677 Markdorf<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_--

1 0

(ITS#7782) [PATCH] contrib/slapd-modules/**/Makefile: LDAP_BUILD=$(LDAP_SRC) by default
by fumiyas＠osstech.co.jp 10 Jan '14

10 Jan '14

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/0001-contrib-slapd-modules-Makefile-LDAP_BU… Submission from: (NULL) (240b:10:2640:bf0:2268:9dff:fec7:5444) The uploaded patch modifies contrib/slapd-modules/**/Makefile to set LDAP_BUILD to $(LDAP_SRC) by default instead of "../../.." (it's the same value of LDAP_SRC). This is bit useful in some minor situation. e.g., without this patch: make LDAP_SRC=/path/to/openldap-source-dir LDAP_BUILD=/path/to/openldap-source-dir with this patch: make LDAP_SRC=/path/to/openldap-source-dir

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs