- openldap-bugs - openldap.org

(ITS#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 12 Mar '07

12 Mar '07

Full_Name: Kevin Vargo Version: 2.3.32 OS: Linux (RH-EL4) URL: ftp://ftp.openldap.org/incoming/openldap-2.3.32-kv1-patch_support-binary-at… Submission from: (NULL) (128.237.242.55) These address the use of Binary-valued attributes (#3113, #3386): For example, inetOrgPerson.userCertificate is usually transferred with the ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. As well, the data itself, when stored in the database is not properly read out -- all data is read as SQL_C_CHAR data. This supports SQL_C_BINARY-based data. There remains an issue with selecting attributes using, e.g., "userCertificate;binary" -- nothing is returned. Someone with a better understanding of the attribute-processing method would be much more effective in terms of finding the correct place to remove the ";binary" from the "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; "userCertificate" is the attribute-name, ";binary" is a transport directive (see #3113). Additionally, I included to the patch to remove the "assert(0)" in Back-SQL's verification that a search filter and ldap-data don't mis-match on suffix. Tags: OpenLDAP, Back-SQL, MySQL, userCertificate, Binary Attributes, Client Certificates (1) ./servers/slapd/back-sql/search.c.patch Addressed ITS#4856 -- I think you already fixed this (2) ./servers/slapd/back-sql/back-sql.h.patch ./servers/slapd/back-sql/entry-id.c.patch ./servers/slapd/back-sql/sql-wrap.c.patch Address ITS#3113, ITS#3386 Support for binary attribute values (3) ./servers/slapd/back-sql/schema-map.c.patch Addresses issue with accessing attributes that have been provided with ";binary" directive note that I have no doubts whatso ever that there are many better ways to do (3).

1 0

(ITS#4867) example: OpenLDAP with SASL/DIGEST-MD5 authentication
by Piotr.Golonka＠CERN.CH 12 Mar '07

12 Mar '07

Full_Name: Piotr.Golonka(a)CERN.CH Version: 2.2.13 OS: Linux URL: ftp://ftp.openldap.org/incoming/golonka-pkg-070312.tgz Submission from: (NULL) (137.138.170.170) Hi, the documentation of the ldap_sasl_bind* family of functions is missing, and getting the actual DIGEST-MD5 authentication in your C code working seems to be completely undocumented. I went through the complete code of ldapsearch.c and extracted the minimal code that succesfully demonstrates DIGEST-MD5 authentication. In my case, I authenticated against ActiveDirectory server. I uploaded the example into your FTP server as golonka-pkg-070312.tgz I hope it may be useful to publish it as a short "Howto" material... regards Piotr Golonka CERN

1 0

(ITS#4866) Can we list Null Value Attributes
by maruthigsr＠gmail.com 12 Mar '07

12 Mar '07

Full_Name: Maruthi Gullapudi Version: OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.221.133.211) Hi, I wanted to list all the users based on the value of one attribute using the LDAPSEARCH Command. The value of that attribute is NULL. I dont know whether LDAPSEARCH will capture null values. Can anyone tell me how to list users from an LDAP directory based on a NUll valued attribute. Thanks in Advance Maruthi

1 0

Re: (ITS#4864) -r option "redirects" to logfile, breaks replication
by ando＠sys-net.it 12 Mar '07

12 Mar '07

[please keep the ITS in CC] Eubank, Chris LCS:EX wrote: > Am running Solaris 10, and the version I stuck in the log. > > When I created an "openldaprc" and used the variable for the > replication log, What is the "variable for the replication log"? All one usually needs to do is define a replogfile in slapd.conf(5) > (which ends up obviously running the slurpd daemon > with the -r switch), Again: there's no need to use -r if replogfile is in slapd.conf(5); if there is no replogfile in slapd.conf(5), slapd(8) will not generate any log, so slurpd(8) will have nothing to do > it sent the replication data to the logfile and > not to the replication hosts being specified. Who sent the replication data to the logfile? slapd(8) is supposed to write replication data to the file specified in replogfile (sladp.conf(5)); slurpd(8) is supposed to read that file (whose existence and location is known by parsing slapd.conf(5)), copy the content it is able to process to its own replication log, which resides in slurpd's working directory (default or passed with -t) and is called slurpd.replog, send that content to the slaves, and remove the data that has been handled from slapd's replication log. This is how things are expected to work. As you may see, -r never comes into play; it's intended to be used to force slurpd processing of a different file, which may be required for special purposes. Do you have any special needs, or are you simply trying to set up usual replication? > Does that make more sense? See comments above. 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#4860) Sets' enhancement
by ando＠sys-net.it 12 Mar '07

12 Mar '07

raphael.ouazana(a)linagora.com wrote: > Fixing these issues, I saw that set_parent will be very similar to > set_chase. Do you think I should create a new gatherer instead of ? I don't see so much similarity: set_chase() is intended to use the gatherer to fetch objects and extract a value from them, including "closure" (recursion). Sublevel does not require fetching, and takes a negative digit as extra argument, rather than an attribute type, so you'd need to add an outer test before calling set_chase() anyway, extend the interface of set_chase() to allow an AttributeDescription and an integer, and so on, while you don't need any callback capability to fetch an object or expand values or so. I'd keep it simple as it is now. 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#4864) -r option "redirects" to logfile, breaks replication
by ando＠sys-net.it 10 Mar '07

10 Mar '07

chris.eubank(a)gov.bc.ca wrote: > Full_Name: Chris Eubank > Version: 2.3.31 (Jan 7 2007 08:51:37) > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (142.32.230.251) > > > If the -r option is used with the 'slurpd' daemon it breaks the replication > function and sends the replication data to the specified logfile instead. What does this mean? According to the documentation, -r must point to slapd's replog file, namely the file where replications are logged by the producer. Of course, if you point it to a file that is not a valid replication log, the behavior will be unexpected. > This behaviour is not documented in the manpage for slurpd. Please describe what behavior you obtain and how it differs from documented. Note that regular users are not supposed to use the -r switch, since slurpd typically knows where to get the replog file. Also, note that slurpd is deprecated; syncrepl should be used instead. 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#4865) double declaration of variable in slapd/main.c
by bret.lambert＠gmail.com 10 Mar '07

10 Mar '07

Full_Name: Bret Lambert Version: -HEAD OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/bret-lambert-070309.patch Submission from: (NULL) (70.179.123.124) There are two declarations of "int i;" in main.c main(). The patch listed removes the second (spurious) declaration of the variable. Found via lint(1) on OpenBSD

1 0

(ITS#4864) -r option "redirects" to logfile, breaks replication
by chris.eubank＠gov.bc.ca 09 Mar '07

09 Mar '07

Full_Name: Chris Eubank Version: 2.3.31 (Jan 7 2007 08:51:37) OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (142.32.230.251) If the -r option is used with the 'slurpd' daemon it breaks the replication function and sends the replication data to the specified logfile instead. This behaviour is not documented in the manpage for slurpd.

1 0

(ITS#4863) 2.3 Administrator's Guide uses deprecated "attr=" statement (typo)
by meburr＠gmail.com 09 Mar '07

09 Mar '07

Full_Name: Michael Burr Version: 2.3.30 OS: Debian 4.0 (sid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.145.225.250) Referring to the Administrator's Guide hosted at openldap.org, in the "Access Control" section (http://www.openldap.org/doc/admin23/slapdconf2.html#Access%20Control), if I copy this statement: olcAccess: to attr=member,entry by dnattr=member selfwrite directly into my configuration (replacing "olcAccess: " with "access to"), slaptest complains: slapd.conf: line 40: "attr" is deprecated (and undocumented); use "attrs" instead. config file testing succeeded As is suggested by the output, slaptest returns with success (0).

1 0

Re: (ITS#4857) Subtree accesslog support
by Frank.Swasey＠uvm.edu 09 Mar '07

09 Mar '07

This is a cryptographically signed message in MIME format. --------------ms080906050304010303040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/7/07 5:29 PM, hyc(a)symas.com wrote: > ---- <quanah(a)stanford.edu> wrote: >> What I want to do, is put subtree based accesslog's on my replica servers. >> We have multiple downstream systems that pull data from the directory. >> This would allow them to "sit and listen" to the changes made in their >> subtrees of interest, using the syncrepl protocol. > > Uh huh. That's what search filters are for. If that's the only motivation for this ITS, then we can close it right now. If that's the only original motivation... then I'd like to hijack this to get the ability to expire different subtree's out of the log at different rates... can I do that? -- 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) --------------ms080906050304010303040408 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwOTE0MDYxMFowIwYJKoZIhvcNAQkEMRYEFCiK 6zalxLVu83Mrwb6GWBRfSXOYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQCc8+iSw5QIRwppDoDmleLlwBqS/QpcRbyraKL58bvYQh2GFw+o 9W7fBsV7Kt6Vt4AqaWkn+5RZ4NqlIeOIzck/utkki59zSci3mcOUOZ0DHQsmWGmyiSPPohzN CtupvRWo5viTrBr5fPAWeAiTlNfg4B2G3Ic81e2VPixWUScgLy8TlvFJmopH3yK64lqkAU7E 71L3SXe5n2ZB3O2WLsPtlVHTp9fo+AbU+/WYEMbpgR5vkAxYM6noOyhw3+W632b0hnKICtbP 6HGjZ7EZt1VyowOk95Q5x01EIo6wOBOAkOUQ/Ax+ZatZTosxpuFL87kMv1M+DuyQNzljK29V GQwtAAAAAAAA --------------ms080906050304010303040408--

1 0

Re: (ITS#4862) Doxygen support
by ghenry＠suretecsystems.com 09 Mar '07

09 Mar '07

<quote who="ando(a)sys-net.it"> > Full_Name: Pierangelo Masarati > Version: HEAD (almost irrelevant) > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/openldap-doxygen.tar.gz > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > I've updated a simple doxygen configuration file that allows to create a > (hopefully) complete and useful browsable tree of OpenLDAP software. The > current configuration is quite redundant, since it includes sources in the > tree, > and may take a while to process. It needs "doxygen" and "dot" (the latter > can > be disabled by setting HAVE_DOT to "no", if unavailable, at the expense of > loosing the graphical description of relations between data types and > files). > > To "install": > - cd into the root of the source tree > - untar openldap-doxygen.tar.gz > > this puts a couple .html files in doc/devel, and Doxyfile in the root of > the > source tree. Edit this to customize. > > Finally, run doxygen from the root of the source tree (and be patient). > > Documents will be installed in doc/source_html. Edit Doxyfile to > customize. > Enjoy. > > p. Wow! That rules and looks great. Brilliant work. Thoughts on polishing this up and adding something to the main site with an announcement sometime? "OpenLDAP goes Doxygen" ;-) Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#4862) Doxygen support
by ando＠sys-net.it 08 Mar '07

08 Mar '07

Full_Name: Pierangelo Masarati Version: HEAD (almost irrelevant) OS: irrelevant URL: ftp://ftp.openldap.org/incoming/openldap-doxygen.tar.gz Submission from: (NULL) (81.72.89.40) Submitted by: ando I've updated a simple doxygen configuration file that allows to create a (hopefully) complete and useful browsable tree of OpenLDAP software. The current configuration is quite redundant, since it includes sources in the tree, and may take a while to process. It needs "doxygen" and "dot" (the latter can be disabled by setting HAVE_DOT to "no", if unavailable, at the expense of loosing the graphical description of relations between data types and files). To "install": - cd into the root of the source tree - untar openldap-doxygen.tar.gz this puts a couple .html files in doc/devel, and Doxyfile in the root of the source tree. Edit this to customize. Finally, run doxygen from the root of the source tree (and be patient). Documents will be installed in doc/source_html. Edit Doxyfile to customize. Enjoy. p.

1 0

(ITS#4861) Issue with referrals in proxy backends
by ando＠sys-net.it 08 Mar '07

08 Mar '07

Full_Name: Pierangelo Masarati Version: re23 + patches from HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando I've received reports of issues with referrals returned from a third-party DSA to OpenLDAP's proxy backends. Apparently, in some cases the response contained referrals with a return code different from LDAP_REFERRAL. Although I can't prove it (it seems to be non-deterministic), I've strenghtened the proxy backends code so that it rejects those responses instead of sending them thru send_ldap_result(), which triggers an assertion. p.

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 08 Mar '07

08 Mar '07

On Jeu 8 mars 2007 01:00, Pierangelo Masarati wrote: > raphael.ouazana(a)linagora.com wrote: > > I see at least 2 issues in this patch: > > 1) the use of dnParent() in place on malloc'd data would lead to memory > corruption, because at some point the value of the set will be freed, > but the bv_val of that value would no longer point to the beginning of a > malloc()'ed block. You should rather use AC_MEMCPY() to move the > parent's DN at the beginning of the malloc()'ed memory block. > > 2) when trimming a set of DNs to some ancestor, DNs with common > ancestors could result in duplicate set values. I'm not sure this > currently has any adverse effect on set evaluation, but I'd consider it > bad anyway. You should eliminate duplicates, in case any arises. Fixing these issues, I saw that set_parent will be very similar to set_chase. Do you think I should create a new gatherer instead of ? Regards, Raphael Ouazana.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 08 Mar '07

08 Mar '07

raphael.ouazana(a)linagora.com wrote: I see at least 2 issues in this patch: 1) the use of dnParent() in place on malloc'd data would lead to memory corruption, because at some point the value of the set will be freed, but the bv_val of that value would no longer point to the beginning of a malloc()'ed block. You should rather use AC_MEMCPY() to move the parent's DN at the beginning of the malloc()'ed memory block. 2) when trimming a set of DNs to some ancestor, DNs with common ancestors could result in duplicate set values. I'm not sure this currently has any adverse effect on set evaluation, but I'd consider it bad anyway. You should eliminate duplicates, in case any arises. 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#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 07 Mar '07

07 Mar '07

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-070307.patch Submission from: (NULL) (82.225.231.106) Hi, This patch creates a new operator for sets : /- It allows to get the nth parent of all the elements of a set. For example, if user is cn=user,ou=people,dc=example,dc=com : user/-1 : resolves to set {ou=people,dc=example,dc=com} user/-2 : resolves to set {dc=example,dc=com} Of course it works the same for sets of more than 1 element. It is very useful when ACLs depends on hierarchy. Legal notice : This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2007 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

--On Wednesday, March 07, 2007 2:32 PM -0800 Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: > > > --On Wednesday, March 07, 2007 2:28 PM -0800 Howard Chu <hyc(a)symas.com> > wrote: > >> >> ---- <quanah(a)stanford.edu> wrote: >>> What I want to do, is put subtree based accesslog's on my replica >>> servers. We have multiple downstream systems that pull data from the >>> directory. This would allow them to "sit and listen" to the changes >>> made in their subtrees of interest, using the syncrepl protocol. >> >> Uh huh. That's what search filters are for. If that's the only motivation >> for this ITS, then we can close it right now. >> >> ldapsearch -b cn=log >> (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu) > > That doesn't do a never ending search that catches every write as it > occurs. Although I guess a syncrepl search could use the filter ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

--On Wednesday, March 07, 2007 2:28 PM -0800 Howard Chu <hyc(a)symas.com> wrote: > > ---- <quanah(a)stanford.edu> wrote: >> What I want to do, is put subtree based accesslog's on my replica >> servers. We have multiple downstream systems that pull data from the >> directory. This would allow them to "sit and listen" to the changes >> made in their subtrees of interest, using the syncrepl protocol. > > Uh huh. That's what search filters are for. If that's the only motivation > for this ITS, then we can close it right now. > > ldapsearch -b cn=log > (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu) That doesn't do a never ending search that catches every write as it occurs. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4857) Subtree accesslog support
by hyc＠symas.com 07 Mar '07

07 Mar '07

---- <quanah(a)stanford.edu> wrote: > What I want to do, is put subtree based accesslog's on my replica servers. > We have multiple downstream systems that pull data from the directory. > This would allow them to "sit and listen" to the changes made in their > subtrees of interest, using the syncrepl protocol. Uh huh. That's what search filters are for. If that's the only motivation for this ITS, then we can close it right now. ldapsearch -b cn=log (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

--On Wednesday, March 07, 2007 5:09 PM +0000 Frank.Swasey(a)uvm.edu wrote: > This is a cryptographically signed message in MIME format. > > --------------ms050409020803020407000508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote: >> I was looking at adding access log configurations to my main database >> that would log operations based on subtree. For example, I'd like to >> have all operations on "cn=accounts,dc=stanford,dc=edu" go into one >> accesslog, and operations on "cn=people,dc=stanford,dc=edu" go into >> another accesslog. My root is "dc=stanford,dc=edu". There doesn't seem >> to be a way with the way accesslog is currently designed to do this. I >> believe it would be a useful feature. > > I have wished for a similar capability. However, have always been > stopped from proceeding to look at modifying the code because all my > consumers need to replicate the full database. > > However, it would be nice to be able to break things apart and have > them expire out of the accesslog at different times. For instance, our > sendmail spam blocking rules live for a max of several hours and so I > could expire those from the accesslog after 8 hours, but the core > (people, groups, accounts) I'd like to keep for a couple days to make > certain they get to the replica servers. > > Is that the same kind of thing you are thinking of Quanah? Hi Frank, Actually, no, it isn't. ;) What I want to do, is put subtree based accesslog's on my replica servers. We have multiple downstream systems that pull data from the directory. This would allow them to "sit and listen" to the changes made in their subtrees of interest, using the syncrepl protocol. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4857) Subtree accesslog support
by hyc＠symas.com 07 Mar '07

07 Mar '07

Frank.Swasey(a)uvm.edu wrote: > This is a cryptographically signed message in MIME format. > > --------------ms050409020803020407000508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote: >> I was looking at adding access log configurations to my main database that would >> log operations based on subtree. For example, I'd like to have all operations >> on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on >> "cn=people,dc=stanford,dc=edu" go into another accesslog. My root is >> "dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is >> currently designed to do this. I believe it would be a useful feature. > > I have wished for a similar capability. However, have always been > stopped from proceeding to look at modifying the code because all my > consumers need to replicate the full database. Usually when you have a logging requirement, you need to see everything... Breaking out options by subtree does seem to be a pretty common need though. It strikes me that we need to solve this once, generically, instead of doing it over and over again in each overlay. That sounds an awful lot like getting full subentry support implemented, or at least a generic subtree search specification handler. > However, it would be nice to be able to break things apart and have > them expire out of the accesslog at different times. For instance, our > sendmail spam blocking rules live for a max of several hours and so I > could expire those from the accesslog after 8 hours, but the core > (people, groups, accounts) I'd like to keep for a couple days to make > certain they get to the replica servers. > > Is that the same kind of thing you are thinking of Quanah? > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4858) sasl_client_init Problem
by hyc＠symas.com 07 Mar '07

07 Mar '07

The OpenLDAP ITS is for tracking issues in OpenLDAP software. Your problem appears to be in a package produced by someone else; you should contact whoever provided that package for support. We have no way of knowing what build or configuration options someone else used to create their package, so we cannot track down problems in their package. Note that OpenLDAP 2.1 was moved to Historic status a number of years ago. You should consider using a more recent version. Symas Corporation provides professional support for OpenLDAP 2.3 packaged for HPUX and many other platforms. m.birkenkamp(a)e-fact-gmbh.de wrote: > Full_Name: Marcel Birkenkamp > Version: 2.1.22 > OS: HP UX 11.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.63.24.153) > > > Hi, > > i have a Problem, i've implemented a c program using OpenLDAP to connect to an > ActiveDirectory for uservalidation, the Problem is that whenever i use one of > the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following > error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from > /opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but > the Problem persists. > Does anyone have an idea what might be causing this or how i can find out where > this Problem originates? > > thanks in advance > > Marcel > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4857) Subtree accesslog support
by Frank.Swasey＠uvm.edu 07 Mar '07

07 Mar '07

This is a cryptographically signed message in MIME format. --------------ms050409020803020407000508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote: > I was looking at adding access log configurations to my main database that would > log operations based on subtree. For example, I'd like to have all operations > on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on > "cn=people,dc=stanford,dc=edu" go into another accesslog. My root is > "dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is > currently designed to do this. I believe it would be a useful feature. I have wished for a similar capability. However, have always been stopped from proceeding to look at modifying the code because all my consumers need to replicate the full database. However, it would be nice to be able to break things apart and have them expire out of the accesslog at different times. For instance, our sendmail spam blocking rules live for a max of several hours and so I could expire those from the accesslog after 8 hours, but the core (people, groups, accounts) I'd like to keep for a couple days to make certain they get to the replica servers. Is that the same kind of thing you are thinking of Quanah? -- 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) --------------ms050409020803020407000508 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMwNzE3MDkyMFowIwYJKoZIhvcNAQkEMRYEFO+D /RPLcK9KWgTC5ESQ348qOn2BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQBWlKbCnxB4o7stfK+pDIAWxonGW8d4AKZr0IU/76SqFqlSQQAx sBSrw2Dg+NHLPsTlBlqe6tseFGjg3EL2436XOY75dbResLsyVffIxE25bVu12P6TpXe6d4xv B6/EvCxlJAjk0UP/ahjmxRCEofnPZybSfd2XIvgbfCstuV8U7ioJolTJZnTq4NhLcliSelyN AjLuBLWGlQj7FxoP7I4KQruZftPu5GVgrj1gpYCUWG457agxEi8w/0mDPUh6gtp5wcN6t+NH 6lYkBoDgb1HuHCrg6Wq/PInNYIxipqcs2Ls7YtR2OpjVJry+8nGlw/N6ueZZWqdSFlQghAk2 xkDXAAAAAAAA --------------ms050409020803020407000508--

1 0

(ITS#4859) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de 07 Mar '07

07 Mar '07

Full_Name: Marcel Birkenkamp Version: 2.1.22 OS: HP UX 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.63.24.153) Hi, i have a Problem, i've implemented a c program using OpenLDAP to connect to an ActiveDirectory for uservalidation, the Problem is that whenever i use one of the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from /opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but the Problem persists. Does anyone have an idea what might be causing this or how i can find out where this Problem originates? thanks in advance Marcel

1 0

(ITS#4858) sasl_client_init Problem
by m.birkenkamp＠e-fact-gmbh.de 07 Mar '07

07 Mar '07

Full_Name: Marcel Birkenkamp Version: 2.1.22 OS: HP UX 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.63.24.153) Hi, i have a Problem, i've implemented a c program using OpenLDAP to connect to an ActiveDirectory for uservalidation, the Problem is that whenever i use one of the OpenLDAP functions (i.e. ldap_init, ldap_initialize) i get the following error: "/usr/lib/dld.sl: Unresolvable symbol: sasl_client_init (code) from /opt/iexpress/openldap/lib/libldap.sl - IOT trap". I've reinstalled OpenLDAP but the Problem persists. Does anyone have an idea what might be causing this or how i can find out where this Problem originates? thanks in advance Marcel

1 0

(ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3/2.4/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) I was looking at adding access log configurations to my main database that would log operations based on subtree. For example, I'd like to have all operations on "cn=accounts,dc=stanford,dc=edu" go into one accesslog, and operations on "cn=people,dc=stanford,dc=edu" go into another accesslog. My root is "dc=stanford,dc=edu". There doesn't seem to be a way with the way accesslog is currently designed to do this. I believe it would be a useful feature. --Quanah

1 0

Re: slapd segfaults with certain ACL's (ITS#4854)
by ando＠sys-net.it 06 Mar '07

06 Mar '07

hjensen(a)gmx.de wrote: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 16160)] > 0x4043e049 in free () from /lib/libc.so.6 > (gdb) bt > #0 0x4043e049 in free () from /lib/libc.so.6 > #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0 > #2 0x0809d4b6 in ch_free () > #3 0x080be84d in str2anlist () > #4 0x080ab33e in parse_acl () > #5 0x08070c5c in config_generic () > #6 0x0807b0f6 in config_set_vals () > #7 0x0807cdd9 in read_config_file () > #8 0x08075d1d in config_include () > #9 0x0807b0f6 in config_set_vals () > #10 0x0807cdd9 in read_config_file () > #11 0x0807667b in read_config () > #12 0x0806ffce in main () OK, then it should be fixed; you can pull servers/slapd/ad.c from the CVS under the OPENLDAP_REL_ENG_2_3 tag and rebuild. Note that this confirms that your schema is missing either or both the offending objectClasses mozillaAbPersonAlpha, evolutionPerson. Please test and feedback. 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: slapd segfaults with certain ACL's (ITS#4854)
by hjensen＠gmx.de 06 Mar '07

06 Mar '07

Hello, here the additional information: configure command line: ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/sbin \ --localstatedir=/var/openldap \ --disable-nls \ --enable-debug \ --enable-syslog \ --with-threads \ --with-tls \ --with-cyrus-sasl \ --enable-spasswd \ --enable-dynamic \ --enable-ipv6 \ --enable-modules \ --enable-crypt \ --enable-rewrite \ --enable-ldbm \ --enable-ldbm-api=berkeley \ --enable-ldbm-type=btree \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-dnssrv \ --enable-null \ --enable-perl \ --with-dyngroup \ --with-proxycache \ --enable-wrappers \ --enable-slurpd \ --enable-aci \ --enable-shared Backtrace of the segfault: (gdb) run Starting program: /ports/openldap/work/src/openldap-2.3.34/servers/slapd/.libs/slapd [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 16160)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16160)] 0x4043e049 in free () from /lib/libc.so.6 (gdb) bt #0 0x4043e049 in free () from /lib/libc.so.6 #1 0x40069ef8 in ber_memfree_x () from /usr/lib/liblber-2.3.so.0 #2 0x0809d4b6 in ch_free () #3 0x080be84d in str2anlist () #4 0x080ab33e in parse_acl () #5 0x08070c5c in config_generic () #6 0x0807b0f6 in config_set_vals () #7 0x0807cdd9 in read_config_file () #8 0x08075d1d in config_include () #9 0x0807b0f6 in config_set_vals () #10 0x0807cdd9 in read_config_file () #11 0x0807667b in read_config () #12 0x0806ffce in main () Regards, Henry

1 0

Re: (ITS#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it 05 Mar '07

05 Mar '07

Kevin Vargo wrote: > Hi Pierangelo, Please keep replies in CC to the ITS system. > Thanks for the quick response. I just want to make sure I understand: you're saying that removing the assertion (as I did) is the correct solution? Well, removing the assert(0) prevents the crash; the right fix is to disallow the "subtree shortcut" in slapd.conf (slapd-sql(5)), which causes the extra filtering on the DN to take place, so no false hits show up. But yes, the assert(0) was overparanoid, and I removed it from the code. 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#4856) Back-SQL + Subtree search hits 'assert(0)'
by ando＠sys-net.it 05 Mar '07

05 Mar '07

vargok(a)yahoo.com wrote: > Full_Name: K Vargo > Version: 2.3.32 > OS: Linux (RH-EL4) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.237.233.195) > > > Given a Base-DN, Subtree scoped ldapsearch, while the database contains > non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c > +2186. > > Based on how the selection works, there doesn't appear to be a reason for the > assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail: > the comparison in dnIsSuffix tries to compare incompatible-dn records and fails > -- as it should. > > Removing the assertion provides for the expected behavior in my simple case. > Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL > selection search, so it needs to be filtered by the dnIsSuffix check. > > While I could certainly see that my metadata is not correct (stock metadata from > 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is > appropriate. > > Additionally, there's no indication that back-sql can't support data with > multiple DNs. Actually, your assumption is partially incorrect, since back-sql doesn't do prefiltering of the DN if the search is rooted at the database's suffix (it's called the "subtree shortcut") unless you tell it otherwise, by using "use_subtree_shortcut no" (the docs state it's the default; this is wrong). I admit assert(0) there is a bit too strong, but I believe it was put there to catch this type of problems. I think the "right" solution, apart from fixing the docs, consists in removing the assertion. 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#4856) Back-SQL + Subtree search hits 'assert(0)'
by vargok＠yahoo.com 05 Mar '07

05 Mar '07

Full_Name: K Vargo Version: 2.3.32 OS: Linux (RH-EL4) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.237.233.195) Given a Base-DN, Subtree scoped ldapsearch, while the database contains non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c +2186. Based on how the selection works, there doesn't appear to be a reason for the assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail: the comparison in dnIsSuffix tries to compare incompatible-dn records and fails -- as it should. Removing the assertion provides for the expected behavior in my simple case. Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL selection search, so it needs to be filtered by the dnIsSuffix check. While I could certainly see that my metadata is not correct (stock metadata from 2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is appropriate. Additionally, there's no indication that back-sql can't support data with multiple DNs.

1 0

Re: (ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net 05 Mar '07

05 Mar '07

Pierangelo Masarati a écrit : > gael.roualland(a)oleane.net wrote: >> Full_Name: Gaël Roualland >> Version: 2.3.34 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.56.0.199) > > Good catch. This is a re23-only bug; fixed, will appear in next > release. Please test re23 out of the CVS, if you can. It works fine with the version from CVS. Thanks, -- Gaël Roualland -+- gael.roualland(a)oleane.net

1 0

Re: (ITS#4855) slapd crash on exit (tpool)
by ando＠sys-net.it 05 Mar '07

05 Mar '07

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.34 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.56.0.199) Good catch. This is a re23-only bug; fixed, will appear in next release. Please test re23 out of the CVS, if you can. 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#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net 05 Mar '07

05 Mar '07

Erratum : the changed line is "( ctx[i].ltk_key == NULL )" and not "( ctx[i].ltk_key != NULL )" which is the same as the release... -- Gaël Roualland -+- gael.roualland(a)oleane.net

1 0

(ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net 05 Mar '07

05 Mar '07

Full_Name: Gaël Roualland Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) Hello, Upgrading 2.3.33 to 2.3.34 introduced a bug on slapd stop: the daemon segfaults while waiting for threads to stop. This is reproducible on every run, and without any queries processed. Running under gdb on a test system, the following is reported: slapd starting [New Thread 32769 (LWP 22877)] [New Thread 16386 (LWP 22878)] daemon: added 7r listener=(nil) daemon: added 9r listener=0x813df78 [New Thread 32771 (LWP 22879)] daemon: select: listen=9 active_threads=0 tvp=zero Program received signal SIGTERM, Terminated. [Switching to Thread 16384 (LWP 22876)] 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) n Single stepping until exit from function __pthread_wait_for_restart_signal, which has no line number information. daemon: shutdown requested and initiated. daemon: closing 9 slapd shutdown: waiting for 0 threads to terminate Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 22879)] 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 (gdb) bt #0 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 #1 0x080c3c36 in ldap_pvt_thread_pool_context_reset (vctx=0xbf5ff94c) at tpool.c:670 #2 0x080c38df in ldap_int_thread_pool_wrapper (xpool=0x814aa78) at tpool.c:494 #3 0x4006de51 in pthread_start_thread () from /lib/libpthread.so.0 #4 0x4006decf in pthread_start_thread_event () from /lib/libpthread.so.0 #5 0x401908aa in clone () from /lib/libc.so.6 (gdb) info threads * 4 Thread 32771 (LWP 22879) 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 3 Thread 16386 (LWP 22878) 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 2 Thread 32769 (LWP 22877) 0x40187a5a in poll () from /lib/libc.so.6 1 Thread 16384 (LWP 22876) 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 Looking at ldap_pvt_thread_pool_context_reset, it seems that the test "if ( ctx[i].ltk_key )" should be reversed as "if ( ctx[i].ltk_key != NULL )". This change fixed the bug. Regards,

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 05 Mar '07

05 Mar '07

For the records: I'm sort of working at this. What I'm trying to do is add some specialized calls to monitor_extra_t that allow to register backends, databases, overlays, overlay instances and so. This would allow entity registration/deregistration routines to provide the related monitor entry registration/deregistration as appropriate from within back-config, with all sorts of atomicity issues one can imagine... Cheers, 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#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 01 Mar '07

01 Mar '07

This is a multi-part message in MIME format. --------------090002080605050903080106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hello, >> As far as I can see, slurpd merely processes the changes in the replog. If it >> is generating requests out of sequence, then they must have been recorded >> out-of-sequence in the log. And yet I don't see any reason why slapd would >> generate the modifications out of sequence. > > That's right for changetype=modify, since the original code aggregates > multiple values of the same attributes in a signle LDAPmod if they're > given in order in the replog file. > But it doesn't do that for changetype=add, which toggled the bug. I > choosed to use the same code path for both for simplicity when fixing add. > >> What are the circumstances that cause these improper sequences to get into >> the replog in the first place? > > In our case, it was just "add" that was problematic. Although I could > imagine the replog to be generated by something else than slapd, and I'd > expect slurpd to be able to process it as long as it is valid ldif ? The second patch I uploaded has an issue with deleting whole attributes. I have a fixed version of it, but I also wrote another patch to fix the initial issue only on the problematic case (entry adding), so that's a less intrusive change : instead of adding a new LDAPMod for each attribute/value pair, the previous LDAPMod (if any) is reused and the current value added to it if it's for the same attribute. The new patch is attached (no space left on ftp). Would it be possible for such a fix to be in mainline ? Thanks, -- Gaël Roualland -+- gael.roualland(a)oleane.net --------------090002080605050903080106 Content-Type: text/x-patch; name="openldap2.3-slurpd-ldapadd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="openldap2.3-slurpd-ldapadd.diff" --- openldap-2.3.33/servers/slurpd/ldap_op.c.orig 2007-01-25 12:01:46.000000000 +0100 +++ openldap-2.3.33/servers/slurpd/ldap_op.c 2007-03-01 18:05:44.315232000 +0100 @@ -52,7 +52,6 @@ #include "slurp.h" /* Forward references */ -static struct berval **make_singlevalued_berval LDAP_P(( char *, int )); static int op_ldap_add LDAP_P(( Ri *, Re *, char **, int * )); static int op_ldap_modify LDAP_P(( Ri *, Re *, char **, int * )); static int op_ldap_delete LDAP_P(( Ri *, Re *, char **, int * )); @@ -183,28 +182,42 @@ ) { Mi *mi; - int nattrs, rc = 0, i; + int nattrs, nvals, rc = 0, i; LDAPMod *ldm, **ldmarr; int lderr = 0; nattrs = i = 0; ldmarr = NULL; + ldm = NULL; /* * Construct a null-terminated array of LDAPMod structs. */ mi = re->re_mods; while ( mi[ i ].mi_type != NULL ) { - ldm = alloc_ldapmod(); - ldmarr = ( LDAPMod ** ) ch_realloc( ldmarr, - ( nattrs + 2 ) * sizeof( LDAPMod * )); - ldmarr[ nattrs ] = ldm; - ldm->mod_op = LDAP_MOD_BVALUES; - ldm->mod_type = mi[ i ].mi_type; - ldm->mod_bvalues = - make_singlevalued_berval( mi[ i ].mi_val, mi[ i ].mi_len ); + if (ldm == NULL || strcmp(ldm->mod_type, mi[ i ].mi_type) != 0) { + /* not the same attribute, add a new ldm */ + ldm = alloc_ldapmod(); + ldmarr = ( LDAPMod ** ) ch_realloc( ldmarr, + ( nattrs + 2 ) * sizeof( LDAPMod * )); + ldmarr[ nattrs ] = ldm; + nattrs++; + ldm->mod_op = LDAP_MOD_BVALUES; + ldm->mod_type = mi[ i ].mi_type; + nvals = 0; + } + + ldm->mod_bvalues = ( struct berval ** ) + ch_realloc( ldm->mod_bvalues, + ( nvals + 2 ) * sizeof( struct berval * )); + ldm->mod_bvalues[ nvals + 1 ] = NULL; + ldm->mod_bvalues[ nvals ] = ( struct berval * ) + ch_malloc( sizeof( struct berval )); + ldm->mod_bvalues[ nvals ]->bv_val = mi[ i ].mi_val; + ldm->mod_bvalues[ nvals ]->bv_len = mi[ i ].mi_len; + nvals++; + i++; - nattrs++; } if ( ldmarr != NULL ) { @@ -579,25 +592,6 @@ /* - * Create a berval with a single value. - */ -static struct berval ** -make_singlevalued_berval( -char *value, -int len ) -{ - struct berval **p; - - p = ( struct berval ** ) ch_malloc( 2 * sizeof( struct berval * )); - p[ 0 ] = ( struct berval * ) ch_malloc( sizeof( struct berval )); - p[ 1 ] = NULL; - p[ 0 ]->bv_val = value; - p[ 0 ]->bv_len = len; - return( p ); -} - - -/* * Given a modification type (string), return an enumerated type. * Avoids ugly copy in op_ldap_modify - lets us use a switch statement * there. --------------090002080605050903080106--

1 0

Re: ITS#4853
by ando＠sys-net.it 27 Feb '07

27 Feb '07

Richard Bos wrote: > Hello Pierangelo, > > Op dinsdag 27 februari 2007 22:27, schreef u: >> Fixed in re23; please test. >> >> I note that the name of the macro may have tricked you; Debug() is >> actually the logging system of OpenLDAP software, not a mere debug >> statement. > > I assume I may not update the ticket, You should never __assume__, when the system is self-documented: > Replies and Followups > --------------------- > > A reply is a message that has been sent from JitterBug to answer an > incoming message. > > A followup is a reply to a reply. Followups are created when a user > sends a email reply to a JitterBug generated message. Followups are > detected by looking for the PR# automatically added to the subject > line in replies. > hence this email to you: > > What do you mean with fixed in "re23". The code has been fixed in the release engineering branch of 2.3 code, and will thus appear in the next release. > Which release is that exactly? Likely, 2.3.35, if any. > What does the change involve? Look at the code from the CVS. > Is the message now sent to a log file? > < Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n", >> Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new attribute <%s>\n", It's sent wherever configured, like it was before (see slapd(8) and slapd.conf(5) for details about logging). The difference is that earlier that message was being always issued, while now it's only issued if expressly requested, since it's just informative and not indicative of any bug. The macros seem pretty self-esplicative. I hope that bug didn't cause any harm to your system, though. 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#4853
by ando＠sys-net.it 27 Feb '07

27 Feb '07

Fixed in re23; please test. I note that the name of the macro may have tricked you; Debug() is actually the logging system of OpenLDAP software, not a mere debug statement. 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#4853) A debug message is printed, from the released version
by ml＠radoeka.nl 27 Feb '07

27 Feb '07

Full_Name: Richard Bos Version: 2.3.27 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.126.75.243) I just upgraded to the new slapd.conf file from cvs and now when I run slapcat I get the following output: # slapcat >/dev/null /etc/openldap/slapd.conf: line 67: new attribute <member> The config file contains: 63 #### Using overlays to improve data consistency 64 # Ensure that we never get dangling member attributes 65 # Checked on rename and delete 66 overlay refint 67 refint_attributes member 68 The code in servers/slapd/overlays/refint.c reads as follows: if(!strcasecmp(*argv, "refint_attributes")) { for(i = 1; i < argc; i++) { ... some checks for error conditions here but if all is fine we fall through to the following section ... ip = ch_malloc(sizeof(refint_attrs)); ip->attr = ad; ip->next = id->attrs; id->attrs = ip; Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n", fname, lineno, argv[i]); The final debug message results seems to be the message that is printed. It's my assumption that no debug messages should be printed in a released product/version/project. The initial bug report is located at: https://intevation.de/roundup/kolab/issue1622

1 0

Re: (ITS#4845) Back-perl is non working
by hyc＠symas.com 27 Feb '07

27 Feb '07

kiwi(a)oav.net wrote: >> No surprise that such a careful redesign resulted, as a side >> effect, in a stricter compliance with RFC2589. The fact that >> nobody complained up to now indicates that strict adherence to >> specs usually helps in code portability. > > Yeah. But I didn't know that RFC2589 is used inside back_<whatever>. > Now I am aware of that and I really thanks about your help and your > kindness to take some time to find where my error was. I think he meant RFC2849, which is the LDIF specification. > Maybe a little not in slapd-perl man page that entry sent to openldap > have to conform to RFC2589 should be a point to avoid such loss of time. The slapd-perl(5) man page says that it expects LDIF entries to be returned. As such, it is already a given that they must actually conform to the LDIF spec. > Thanks again, and this bug is closed for me. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Potential bug (schema or ldap add?)
by Andrew Seguin 27 Feb '07

27 Feb '07

I'm not too sure of the details yet, I wanted to check with this list first, but here's the story. In general, I'm using phpLDAPadmin to work with the ldap directory. I added the iaaa-radius.schema from Interlink. I found it was missing the EQUALITY statements, so phpLDAPadmin couldn't "add" new aaaReply items once the first one was added. Via import and adding a user all at once was not a problem. I modified the iaaa-radius.schema file, found the aaaReply attribute and added the lines "EQUALITY caseIgnoreMatch" and "SUBSTR caseIgnoreSubstringsMatch". I went into phpLDAPadmin, created a new aaaPerson with one initial aaaReply attribute, then added a second aaaReply value without problem. To date all is good. I went to a user which already exists, which already has three aaaReply attributes/values, and tried to add a new aaaReply value - at which point it would seem that slapd either crashed or shutdown. I turned on logging and couldn't see anything really abnormal... nor did I find any core dump file. Any ideas if this is a bug or possibly just some kind of internal consistency check on records created before the Schema was modified? Thank you, Andrew

3 3

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

27 Feb '07

--Apple-Mail-13-1003230263 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, >> By the way, I still don't understand why this kind of script was >> working on >> openldap 2.1 and 2.2.... ? >> Does str2entry() is more picky since openldap 2.3 ? > > The fact that something __worked__ doesn't mean it was correct. > That code working was apparently the consequence of two bugs > canceling each other. I totaly agree with you :) > str2entry() is not just more picky: it has been __entirely__ > rewritten, to reduce the performance impact of the related memory > allocation, which guaranteed orders of magnitude of improvement > from 2.0 to 2.3 (the amount of fragmented malloc()s was a > considerable bottleneck). Redesigning code for performance, as well > as for stricter adherence to specs, is part of its natural evolution. Again I agree with you. I am also maintainer of some opensource project and sometimes we need to recode something that is slow to have better performances. > No surprise that such a careful redesign resulted, as a side > effect, in a stricter compliance with RFC2589. The fact that > nobody complained up to now indicates that strict adherence to > specs usually helps in code portability. Yeah. But I didn't know that RFC2589 is used inside back_<whatever>. Now I am aware of that and I really thanks about your help and your kindness to take some time to find where my error was. Maybe a little not in slapd-perl man page that entry sent to openldap have to conform to RFC2589 should be a point to avoid such loss of time. Thanks again, and this bug is closed for me. /Xavier --Apple-Mail-13-1003230263 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjcxMzQ1NThaMCMGCSqGSIb3DQEJBDEWBBQ9bmnTVofdoSRh 8583ZE8AFNXOujCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAB98WnfO9tT2nVJIJ8FVh9+MiP9A 1tC2CirbtmCIgimXAC9A3briBvInedOr85WLpisE2M+VSmownkh9qkVtyIBdPs/M/7qfqvSD3Rlf FkEuIBSGKgU1AcYFmN/XoRTtetDnTgZNDe5aIh6rxd0s1juilxMsJiL4iCSBfk4cGVKpxCXsZlAp 3/QfI3yGscc9sZG2MoROANqAo6JU6vg6D+obhhXfgQqluahRk4LkPdqlgTVuhdaJADGuvQv0y/fY UDEYz3X5w5dDJG/HdECrgzPhRLNygcwUqANuUGXDI5vdrBSsmXOb4raeTfR0FSGjVssdPRMx3Nvc Elughcf1ZlsAAAAAAAA= --Apple-Mail-13-1003230263--

1 0

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

27 Feb '07

Xavier Beaudouin wrote: > By the way, I still don't understand why this kind of script was working on > openldap 2.1 and 2.2.... ? > > Does str2entry() is more picky since openldap 2.3 ? The fact that something __worked__ doesn't mean it was correct. That code working was apparently the consequence of two bugs canceling each other. str2entry() is not just more picky: it has been __entirely__ rewritten, to reduce the performance impact of the related memory allocation, which guaranteed orders of magnitude of improvement from 2.0 to 2.3 (the amount of fragmented malloc()s was a considerable bottleneck). Redesigning code for performance, as well as for stricter adherence to specs, is part of its natural evolution. No surprise that such a careful redesign resulted, as a side effect, in a stricter compliance with RFC2589. The fact that nobody complained up to now indicates that strict adherence to specs usually helps in code portability. 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#4845) Back-perl is non working
by kiwi＠oav.net 27 Feb '07

27 Feb '07

--Apple-Mail-8-1002308974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hello, Le 26 f=E9vr. 07 =E0 09:35, Pierangelo Masarati a =E9crit : > Xavier Beaudouin wrote: > > >>> Unless you can prove that back-perl LDIF parser doesn't work with >>> decently >>> formatted LDIF, I'll consider this ITS closed. >> >> It *is* buggy proove me the contrary and be not so arrogant. > > OK, I'll be less "arrogant". I've tested back-perl with your script > corrected, and it works exactly as expected both with OpenLDAP 2.3 and > with OpenLDAP 2.4. What are corrections? > > 1) > > <attr>: <value> > > 2) eliminate nonsensical "\t" at end of each line. What is really > offending is the space between "attr" and ":" and the last "\t", while > the other "\t" seem to be tolerated (I suggest to fix str2entry() in > order to detect this malformation as well). > > It took me 5 minutes to rebuild with back-perl and find the error, and > it's the first time in my life that I program perl. Thanks to helped me on that. You can close the bug and sorry to have bother you for such "easy" fix. By the way, I still don't understand why this kind of script was =20 working on openldap 2.1 and 2.2.... ? Does str2entry() is more picky since openldap 2.3 ? /Xavier= --Apple-Mail-8-1002308974 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjcxMzMwMzdaMCMGCSqGSIb3DQEJBDEWBBS7xwRCcJciq2f1 0nv+lAcwXB/WaTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAECl4VHgzjlhaIgC+ynI6fwsEig0 G2rw/NLSqYGw8cLsMx2iqXSnlQWVV8oLUe5gMGHV0eE65yfKx+vnXTUyJnUN08ECvHx+eM4bxxgV c1cvP6XqqR+nHRUVucriSGrMKqTfI9Qg9DyxPAdF1znIF2TrMwytcVHq+RptaREhEPrpH6+Klnp+ oT9HZwHIRC5tDkZ64uCisHno5QnvwRkT3V2PaSYK5wYtZBHOSchVWWPLeAA9yEzEeMbo07cHWVbj LAxwKoLF+ckJbQRSjWekQ7YwmOkRGVhb4hjtq17b4f6k3Cs3PSOPBOxhktJtinBgU9wSaBYzR5f3 i66IZQDPpkIAAAAAAAA= --Apple-Mail-8-1002308974--

1 0

Re: (ITS#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com 27 Feb '07

27 Feb '07

2.3.34 solves the problem. Thanks. -- ____________________________________ Ulf Möller Senior Consultant Secardeo GmbH Office +49 (0)89 - 18 93 589-5 Fax +49 (0)89 - 18 93 589-9 E-mail ulf.moeller(a)secardeo.com Secardeo GmbH Betastrasse 9a D-85774 Unterföhring Web http://www.secardeo.de Geschäftsführer: Dr. Gunnar Jacobson Amtsgericht München HRB 137969 ____________________________________

1 0

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

26 Feb '07

I placed an updated version in ftp://ftp.openldap.org/incoming/changelog-rieger-070226.c <ftp://ftp.openldap.org/incoming/changelog-rieger-060925.c> that compiles and works with CVS HEAD Sebastian Rieger

1 0

Re: (ITS#4852) back-perl/str2entry odd interaction
by ando＠sys-net.it 26 Feb '07

26 Feb '07

ando(a)sys-net.it wrote: > Malformed perl can cause a double free in str2entry2(). Steps to reproduce: > from back-perl's "search" routine, generate a malformed entry that begins with > "dn : ..." ends with "...\n\t". Fixed in HEAD/re23; 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

(ITS#4852) back-perl/str2entry odd interaction
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Malformed perl can cause a double free in str2entry2(). Steps to reproduce: from back-perl's "search" routine, generate a malformed entry that begins with "dn : ..." ends with "...\n\t". Backtrace (from HEAD; similar in re23) follows: (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003d57a5 in raise () from /lib/tls/libc.so.6 #2 0x003d7209 in abort () from /lib/tls/libc.so.6 #3 0x0040971a in __libc_message () from /lib/tls/libc.so.6 #4 0x0040ffbf in _int_free () from /lib/tls/libc.so.6 #5 0x0041033a in free () from /lib/tls/libc.so.6 #6 0x08226022 in ber_memfree_x (p=0x84e5960, ctx=0x0) at memory.c:149 #7 0x080a11fe in ch_free (ptr=0x84e5960) at ch_malloc.c:139 #8 0x0808d12a in str2entry2 (s=0x0, checkvals=1) at entry.c:374 #9 0x0808c1a0 in str2entry (s=0x84e5838 "dn") at entry.c:100 #10 0x0813c7c8 in perl_back_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:78 #11 0x080846f4 in fe_op_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:374 #12 0x08084078 in do_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:217 #13 0x08081083 in connection_operation (ctx=0xb78f02a4, arg_v=0x84e50f8) at connection.c:1129 #14 0x08081550 in connection_read_thread (ctx=0xb78f02a4, argv=0x9) at connection.c:1257 #15 0x081f38d4 in ldap_int_thread_pool_wrapper (xpool=0x8364c08) at tpool.c:704 #16 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 #17 0x00475ffe in clone () from /lib/tls/libc.so.6

1 0

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

26 Feb '07

Xavier Beaudouin wrote: >> Unless you can prove that back-perl LDIF parser doesn't work with >> decently >> formatted LDIF, I'll consider this ITS closed. > > It *is* buggy proove me the contrary and be not so arrogant. OK, I'll be less "arrogant". I've tested back-perl with your script corrected, and it works exactly as expected both with OpenLDAP 2.3 and with OpenLDAP 2.4. What are corrections? 1) <attr>: <value> 2) eliminate nonsensical "\t" at end of each line. What is really offending is the space between "attr" and ":" and the last "\t", while the other "\t" seem to be tolerated (I suggest to fix str2entry() in order to detect this malformation as well). It took me 5 minutes to rebuild with back-perl and find the error, and it's the first time in my life that I program perl. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs