openldap-bugs

openldap-bugs@openldap.org

1 participants
20958 discussions

Re: (ITS#4883) test000 fails
by ando＠sys-net.it 21 Mar '07

21 Mar '07

Ralf Haferkamp wrote: > unintended or incomplete. Both. Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4883) test000 fails
by rhafer＠suse.de 21 Mar '07

21 Mar '07

It seems that the last change in back-monitor.h was either unintended or incomplete. Reverting that change make the test suite working again. Ando, as that was your change, could you please take a deeper look? -- thanks, Ralf

1 0

(ITS#4885) incorrect response macro in ldap_result(3)
by ando＠sys-net.it 21 Mar '07

21 Mar '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando In ldap_result(3) there is mention of LDAP_RES_EXTENDED_PARTIAL, which apparently was replaced by LDAP_RES_INTERMEDIATE since 2.2 or so. p.

1 0

Re: (ITS#4884) Back-config inheritance issue
by ando＠sys-net.it 20 Mar '07

20 Mar '07

I've committed to HEAD a fix that exploits inheritance. The rationale is: - lookup the structural objectClass; starting from it, check it and subordinates for a function that successfully adds the entry - using all objectClass values, collect all, including ancestors, that may be of use in checking configuration. Passes all tests (049->051), and allows to add an overlay using only the overlay's objectClass, provided it's derived from olcOverlayConfig. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4853) A debug message is printed, from the released version
by ando＠sys-net.it 20 Mar '07

20 Mar '07

Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4853) A debug message is printed, from the released version
by Frank.Swasey＠uvm.edu 20 Mar '07

20 Mar '07

This is a cryptographically signed message in MIME format. --------------ms010006030808080804010404 Content-Type: multipart/mixed; boundary="------------080104090705040602090506" This is a multi-part message in MIME format. --------------080104090705040602090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The patch applied in version 1.7.2.12 of refint.c is not complete. It does remove the notice of refint_attribute values, but it leaves the refint_nothing and refint_base using LDAP_DEBUG_ANY instead of also limiting those prints to when LDAP_DEBUG_CONFIG is specified. Attached is a patch deck to correct all three Debug() calls. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------080104090705040602090506 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ITS4853_full.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ITS4853_full.patch" --- refint.c.UVM_refint-head 2007-01-02 16:44:08.000000000 -0500 +++ refint.c 2007-03-20 09:43:17.000000000 -0400 @@ -144,14 +144,14 @@ ip->attr = ad; ip->next = id->attrs; id->attrs = ip; - Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n", + Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new attribute <%s>\n", fname, lineno, argv[i]); } } else if(!strcasecmp(*argv, "refint_base")) { /* XXX only one basedn (yet) - need validate argument! */ if(id->dn.bv_val) ch_free(id->dn.bv_val); ber_str2bv( argv[1], 0, 0, &dn ); - Debug(LDAP_DEBUG_ANY, "%s: line %d: new baseDN <%s>\n", + Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new baseDN <%s>\n", fname, lineno, argv[1]); if(dnNormalize(0, NULL, NULL, &dn, &id->dn, NULL)) { Debug(LDAP_DEBUG_ANY, "%s: line %d: bad baseDN!\n", fname, lineno, 0); @@ -165,7 +165,7 @@ Debug(LDAP_DEBUG_ANY, "%s: line %d: bad nothingDN!\n", fname, lineno, 0); return(1); } - Debug(LDAP_DEBUG_ANY, "%s: line %d: new nothingDN<%s>\n", + Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new nothingDN<%s>\n", fname, lineno, argv[1]); } else { return(SLAP_CONF_UNKNOWN); --------------080104090705040602090506-- --------------ms010006030808080804010404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0 /joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN 0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy +z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7 ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMDEzNTE0NlowIwYJKoZIhvcNAQkEMRYEFH3P vHIi8xXKD1kPu1urTjvGs7UyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQCKsfzObajHIgMefZW2QJwF0uhq3rkjCMyMCcWmuRi8jMBu1E8K 5HaZVQHExEyiDeqD+eGW1lDps4u1nP4/pIjVh94RlXUzpG0gE5zW0d56Oz+FUrjavTN2UkcX CBpYUYDjlQ9TneqvUXRWwLcJBo9JGnCElVy7o4gm/hJObB28xaxIrNv6cYmWV0khianRwtS2 cfystVgiI19NlBHPJIO8MZv6J/Do75tfaJpQBqIiSaT+XABWrtww6sjpTw9ooUzczWQEjoOF dXVjSZE+1EeWmPflbE/6qE2KCRiX8pxgswWztgLnm7lvO3qxONysME/Wc9zGqlWTHZHYHium qrEvAAAAAAAA --------------ms010006030808080804010404--

1 0

(ITS#4884) Back-config inheritance issue
by ando＠sys-net.it 20 Mar '07

20 Mar '07

Full_Name: Pierangelo Masarati Version: HEAD (re23,...) OS: irrelevant URL: Submission from: (NULL) (87.28.220.33) Submitted by: ando I think I've spotted a potential issue in back-config. When creating a custom object, say an overlay, the configuration objectClass should inherit from olcOverlayConfig. While adding the object via LDAP, however, if the ancestor class is not explicitly listed, the derived object must provide a co_ldadd() hook, otherwise addition fails. It would be more sound, IMHO, to have something like: - if the structural objectClass provides a co_ldadd() hook, use it; it is that hook's responsibility to call the superior's one if required; - if it doesn't, then climb the inheritance tree and call co_ldadd() for the first occurrence of a valid one. In case of multiple inheritance, issues may arise. In those cases, we could: - require an explicit co_ldadd() in the derived object to resolve the ambiguity (this is basically what C++ does) - otherwise, co_ldadd() should perhaps be called for the first occurrence in all branches of multiple inheritance, and it should be able to either create the entry, or modify an existing entry. handlers should be called in order of inheritance. Currently, the code uses all defined objectClasses and stops the first time a hook is available and it does not fail. p.

1 0

(ITS#4883) test000 fails
by dieter＠dkluenter.de 20 Mar '07

20 Mar '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.187.212.14) I checked out todays cvs and failed with test000, slapd.1.log shows @(#) $OpenLDAP: slapd 2.X (Mar 20 2007 11:57:18) $ dieter@magenta:/work/ldap-src/servers/slapd ldap_pvt_gethostbyname_a: host=magenta, r=0 daemon_init: ldap://localhost:9011/ daemon_init: listen on ldap://localhost:9011/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://localhost:9011/) daemon: listener initialized ldap://localhost:9011/ daemon_init: 2 listeners opened ldap_create lt-slapd init: initiated server. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006) => str2entry: "dn: vendorName: The OpenLDAP Project <http://www.openldap.org/> " >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> <= str2entry() -> 0x822002c bdb_db_init: Initializing BDB database >>> dnPrettyNormal: <o=OpenLDAP Project,l=Internet> => ldap_bv2dn(o=OpenLDAP Project,l=Internet,0) <= ldap_bv2dn(o=OpenLDAP Project,l=Internet)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=OpenLDAP Project,l=Internet)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=openldap project,l=internet)=0 <<< dnPrettyNormal: <o=OpenLDAP Project,l=Internet>, <o=openldap project,l=internet> >>> dnPrettyNormal: <cn=Monitor> => ldap_bv2dn(cn=Monitor,0) <= ldap_bv2dn(cn=Monitor)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Monitor)=0 > ldap_dn2bv(272) <= ldap_dn2bv(cn=monitor)=0 <<< dnPrettyNormal: <cn=Monitor>, <cn=monitor> >>> dnNormalize: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnNormalize: <cn=subschema> matching_rule_use_init [...] t-slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}duaconf" config_build_entry: "cn={9}dyngroup" config_build_entry: "cn={10}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory /work/ldap-src/tests/testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(/work/ldap-src/tests/testrun/db.1.a) ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (1) lt-slapd shutdown: initiated ====> bdb_cache_release_all bdb_db_close: alock_close failed lt-slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. my configure parameters export CFLAGS="-DLDAP_DEVEL" ./configure \ --prefix=/opt/openldap \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-java=mod \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-sql=mod \ --enable-overlays=mod -Dieter

1 0

Re: (ITS#4882) Add doesnt work <OpenStruct message="unknown result (64)", code=64>
by ando＠sys-net.it 20 Mar '07

20 Mar '07

sxm20(a)yahoo.com wrote: > Full_Name: Shailesh Mangal > Version: 2.2.29 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.228.83.104) > > > While trying to add entry from Ruby's netLdap library. > > [result = @ldap_con.add(:dn => dn, :attributes => attr)] > > I get following error message. > <OpenStruct message="unknown result (64)", code=64> > > I have also tried it on Linux (debian), getting the same error message The ITS is not for help on software usage; please direct software usage questions to openldap-software. In any case, 2.2.29 is ancient, so even in the case of a bug there are no chances it gets fixed unless it is still present in currently released code. In your case, the error is likely to be on the user's side; see the FAQ for directions about typical user errors; see RFC4511 (or ldap.h) for mapping between result codes and diagnostics. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4882) Add doesnt work <OpenStruct message="unknown result (64)", code=64>
by sxm20＠yahoo.com 19 Mar '07

19 Mar '07

Full_Name: Shailesh Mangal Version: 2.2.29 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.228.83.104) While trying to add entry from Ruby's netLdap library. [result = @ldap_con.add(:dn => dn, :attributes => attr)] I get following error message. <OpenStruct message="unknown result (64)", code=64> I have also tried it on Linux (debian), getting the same error message

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs