- openldap-bugs - openldap.org

RE: (ITS#4886) slapd stopping with no error message
by douglas＠gpc.edu 22 Mar '07

22 Mar '07

Thanks for the quick reply. I will try to get some things together in one or more emails. I got the following: "Bis Dienstag, den 2. April bin ich leider nicht erreichbar. Sollte Ihr Anliegen nicht so lange warten können, wenden Sie sich bitte an unsere Hotline unter der Rufnummer 0511-5181188. --------------------------------------------------------------------- Mit freundlichen Grüßen Johannes Königsmann Gutenberg Rechenzentrum GmbH & Co. KG System-Management August-Madsack-Straße 1 30559 Hannover Tel. : +49 511 518-1107 Fax : +49 511 518-1102 e-Mail: koenigsmann(a)gutenberg-rz.de Internet: www.gutenberg-rz.de _________________________________________ Gutenberg Rechenzentrum GmbH & Co. KG Sitz: Hannover Handelsregister: Hannover HRA 21 669 Geschäftsführer: Karl-Rüdiger Garbs, Dr. Claudia Hümpel" I wanted to reply to him letting him know that I did know German (wish I did), but I was a little hesitant this might not be a legitimate response to my its. Is there a way I could find out if he is legitimate or if he is not, then I would ignore it. Thanks for any help with this side question. Thanks! -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, March 22, 2007 4:36 AM To: douglas(a)gpc.edu Cc: Kurt Zeilenga Subject: Re: (ITS#4886) slapd stopping with no error message Also show the output for print *ber at the crash location Seems like something is bad in your build environment if you can get it to crash after only one search. Have you run the test suite successfully? douglas(a)gpc.edu wrote: > Full_Name: Douglas Jones > Version: 2.3.34 > OS: RHEL4 (linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.28.202.22) > > > Without efence, after the server has been runing between 3 and 15 days, > it varies, the sever just stops. Even using ulimit on core size, I did > not have luck getting a core file. Per recomendation of the newgroups, > I used efence and it crashed on the first lookup. I got the following under > gdb: > > (previous -d 1 output cut) > It did return the names to my client, which was good, but just crashed after > (during) that. Please let me know if I can do anythin else. Thanks! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4888) Enhance back-sql with paged results
by ando＠sys-net.it 22 Mar '07

22 Mar '07

hyc(a)symas.com wrote: > adamson(a)cmu.edu wrote: >> Full_Name: Mark Adamson >> Version: HEAD >> OS: Solaris 2.8 >> URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch >> Submission from: (NULL) (128.2.234.24) >> >> >> Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS >> control with the SQL backend. The patch to add this is not hard, and was mostly >> copied from the back-bdb/search.c file. >> >> http://null.andrew.cmu.edu/openldap/sql_paged_results.patch >> >> The only challenge was the contents of the cookie that is used to maintain >> state. The slap.h file defines the PagedResultsCookie type to be an unsigned >> long, so I wanted to fit everything into that. The design idea was to keep the >> ldap_entries.id value of the last returned entry in the cookie so that >> subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to >> the SQL query. However, the gathering of candidate entries is done across all >> objectClasses with avl_apply(), so if one OC returns an entry with a high >> ldap_entries.id, objectClasses that come later in the AVL could miss entries. >> For this reason, I add the oc_map_id of the last returned entry to the cookie, >> and I adjusted the avl_apply() call to run through the objectClasses in numeric >> order. In this way, when subsequent pages of entries are requested, all of the >> objectClasses that were completed by previous pages can be skipped for the new >> page. When we get to the objectClass where the previous page left off, we take >> the ldap_entries.id from the cookie and apply the above mentioned SQL clause. > > A more appropriate change would probably be to change the cookie type to > a berval so that arbitrary data may be used as needed by each backend. > Then you can set both the oc_map_id and the ldap_entries.id. > > Ultimately this sort of thing should be handled almost entirely by the > frontend, with just a single call in the backend to fill a cookie struct > for the current search state. I concur (was about to suggest the same: move parse_paged_cookie() and send_paged_response() to servers/slapd/result.c, adding as much as required to customize it from within the backend specific call. Let me note that the patch doesn't build fine (you need to declare in advance the static functions you're only defining at the end), and it seems to work incorrectly. By running the simple sql-test000 with mysql (which fails because now the order has changed; my fault: should have added -S "" to searches), if I search without the control, I correctly get 6 entries and a referral; if I search with paged results and a page size less than 6, I only get 5 entries. The root entry is missing, but I have no idea of the reason, I couldn't infer anything from the code or the logs. Can you check? 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#4886) slapd stopping with no error message
by hyc＠symas.com 22 Mar '07

22 Mar '07

Also show the output for print *ber at the crash location Seems like something is bad in your build environment if you can get it to crash after only one search. Have you run the test suite successfully? douglas(a)gpc.edu wrote: > Full_Name: Douglas Jones > Version: 2.3.34 > OS: RHEL4 (linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.28.202.22) > > > Without efence, after the server has been runing between 3 and 15 days, > it varies, the sever just stops. Even using ulimit on core size, I did > not have luck getting a core file. Per recomendation of the newgroups, > I used efence and it crashed on the first lookup. I got the following under > gdb: > > (previous -d 1 output cut) > It did return the names to my client, which was good, but just crashed after > (during) that. Please let me know if I can do anythin else. Thanks! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4888) Enhance back-sql with paged results
by hyc＠symas.com 22 Mar '07

22 Mar '07

adamson(a)cmu.edu wrote: > Full_Name: Mark Adamson > Version: HEAD > OS: Solaris 2.8 > URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch > Submission from: (NULL) (128.2.234.24) > > > Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS > control with the SQL backend. The patch to add this is not hard, and was mostly > copied from the back-bdb/search.c file. > > http://null.andrew.cmu.edu/openldap/sql_paged_results.patch > > The only challenge was the contents of the cookie that is used to maintain > state. The slap.h file defines the PagedResultsCookie type to be an unsigned > long, so I wanted to fit everything into that. The design idea was to keep the > ldap_entries.id value of the last returned entry in the cookie so that > subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to > the SQL query. However, the gathering of candidate entries is done across all > objectClasses with avl_apply(), so if one OC returns an entry with a high > ldap_entries.id, objectClasses that come later in the AVL could miss entries. > For this reason, I add the oc_map_id of the last returned entry to the cookie, > and I adjusted the avl_apply() call to run through the objectClasses in numeric > order. In this way, when subsequent pages of entries are requested, all of the > objectClasses that were completed by previous pages can be skipped for the new > page. When we get to the objectClass where the previous page left off, we take > the ldap_entries.id from the cookie and apply the above mentioned SQL clause. A more appropriate change would probably be to change the cookie type to a berval so that arbitrary data may be used as needed by each backend. Then you can set both the oc_map_id and the ldap_entries.id. Ultimately this sort of thing should be handled almost entirely by the frontend, with just a single call in the backend to fill a cookie struct for the current search state. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4888) Enhance back-sql with paged results
by adamson＠cmu.edu 21 Mar '07

21 Mar '07

Full_Name: Mark Adamson Version: HEAD OS: Solaris 2.8 URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch Submission from: (NULL) (128.2.234.24) Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS control with the SQL backend. The patch to add this is not hard, and was mostly copied from the back-bdb/search.c file. http://null.andrew.cmu.edu/openldap/sql_paged_results.patch The only challenge was the contents of the cookie that is used to maintain state. The slap.h file defines the PagedResultsCookie type to be an unsigned long, so I wanted to fit everything into that. The design idea was to keep the ldap_entries.id value of the last returned entry in the cookie so that subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to the SQL query. However, the gathering of candidate entries is done across all objectClasses with avl_apply(), so if one OC returns an entry with a high ldap_entries.id, objectClasses that come later in the AVL could miss entries. For this reason, I add the oc_map_id of the last returned entry to the cookie, and I adjusted the avl_apply() call to run through the objectClasses in numeric order. In this way, when subsequent pages of entries are requested, all of the objectClasses that were completed by previous pages can be skipped for the new page. When we get to the objectClass where the previous page left off, we take the ldap_entries.id from the cookie and apply the above mentioned SQL clause. To fit both the oc_map_id and ldap_entries.id into a 32bit cookie, I had to make a sacrifice. I took 6 bits and used them for oc_map_id and the remaining 26 bits for ldap_entries.id. This means max(oc_map_id) needs to be < 64 and max(ldap_entries.id) needs to be < 134,217,728. If the PagedResultsCookie type is ever expanded to be a berval, we can store both oc_map_id and ldap_entries.id in their full glory. Anyway, try it out. It's a quick patch. -Mark Adamson Carnegie Mellon University

1 0

(ITS#4887) JLDAP - com.novell.sasl.client.DigestMD5SaslClient and RFC2831
by giovannix＠gmail.com 21 Mar '07

21 Mar '07

Full_Name: Giovanni Almeida Santos Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.199.204.60) According to RFC2831 (Using Digest Authentication as a SASL Mechanism), the rules for a "digest-response" is defined as follows: digest-response = 1#( username | realm | nonce | cnonce | nonce-count | qop | digest-uri | response | maxbuf | charset | cipher | authzid | auth-param ) username = "username" "=" <"> username-value <"> username-value = qdstr-val ... authzid = "authzid" "=" <"> authzid-value <"> authzid-value = qdstr-val com.novell.sasl.client.DigestMD5SaslClient class does not implement that RFC at all because it does not use authzid as described above. To correct this, it is necessary modify two methods on DigestMD5SaslClient: DigestCalcHA1 and createDigestResponse. In the DigestCalcHA1 method it is necessary include the code delimited by // -->> as follows: char[] DigestCalcHA1( String algorithm, String userName, String realm, String password, String nonce, String clientNonce) throws SaslException { ... if ("md5-sess".equals(algorithm)) { md.update(hash); md.update(":".getBytes("UTF-8")); md.update(nonce.getBytes("UTF-8")); md.update(":".getBytes("UTF-8")); md.update(clientNonce.getBytes("UTF-8")); // -->> It is necessary to allow Proxy Authorization if(m_authorizationId != null && !"".equals(m_authorizationId)) { md.update(":".getBytes("UTF-8")); md.update(m_authorizationId.getBytes("UTF-8")); } // -->> End hash = md.digest(); } ... } In the createDigestResponse method it is necessary remove <code>digestResponse.append(m_authorizationId)<code> (commented below) and insert the code delimited by // -->> private String createDigestResponse( byte[] challenge) throws SaslException { ... digestResponse.append("username=\""); //digestResponse.append(m_authorizationId); // -->> It is necessary to allow Proxy Authorization digestResponse.append(m_name); if(m_authorizationId != null && !"".equals(m_authorizationId)) { digestResponse.append("\",authzid=\""); digestResponse.append(m_authorizationId); } // -->> End ... } Without these modifications, proxy authorization is not possible.

1 0

(ITS#4886) slapd stopping with no error message
by douglas＠gpc.edu 21 Mar '07

21 Mar '07

Full_Name: Douglas Jones Version: 2.3.34 OS: RHEL4 (linux) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.28.202.22) Without efence, after the server has been runing between 3 and 15 days, it varies, the sever just stops. Even using ulimit on core size, I did not have luck getting a core file. Per recomendation of the newgroups, I used efence and it crashed on the first lookup. I got the following under gdb: (previous -d 1 output cut) >>> dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor> <<< dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor>, <cn=write,cn=waiters,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Write,cn=Waiters,cn=Monitor) -> 0x260d9fd8 backend_startup_one: starting "o=gpc,c=us" slapd starting [New Thread 635861936 (LWP 10061)] [New Thread 631663536 (LWP 10062)] [New Thread 627465136 (LWP 10063)] [New Thread 623266736 (LWP 10064)] [New Thread 619068336 (LWP 10065)] >>> slap_listener(ldap://:389/) connection_get(33): got connid=0 connection_read(33): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 16 contents: ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=30 tag=97 err=0 ber_flush: 14 bytes to sd 33 connection_get(33): got connid=0 connection_read(33): checking for input on id=0 ber_get_next Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 635861936 (LWP 10061)] ber_get_next (sb=0x25f2ffe8, len=0x25e6427c, ber=0x25f65fd4) at io.c:551 551 if (*ber->ber_ptr & 0x80) { /* multi-byte */ (gdb) bt full #0 ber_get_next (sb=0x25f2ffe8, len=0x25e6427c, ber=0x25f65fd4) at io.c:551 l = Variable "l" is not available. (gdb) thread apply all bt Thread 6 (Thread 619068336 (LWP 10065)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e7b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x0812d25b in ldap_int_thread_pool_wrapper (xpool=0xb725df58) at tpool.c:490 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 5 (Thread 623266736 (LWP 10064)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e7b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x0812d25b in ldap_int_thread_pool_wrapper (xpool=0xb725df58) at tpool.c:490 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 4 (Thread 627465136 (LWP 10063)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e7b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #2 0x0812d25b in ldap_int_thread_pool_wrapper (xpool=0xb725df58) at tpool.c:490 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 3 (Thread 631663536 (LWP 10062)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0036ba19 in mprotect () from /lib/tls/libc.so.6 #2 0x0814fb3f in Page_AllowAccess (address=0x25fa8000, size=475136) at page.c:149 #3 0x0814f6be in free (address=0xb7ea4ff0) at efence.c:694 #4 0x003232b5 in tzset_internal () from /lib/tls/libc.so.6 #5 0x00323d0e in tzset () from /lib/tls/libc.so.6 #6 0x003288ae in strftime_l () from /lib/tls/libc.so.6 #7 0x0036af6b in vsyslog () from /lib/tls/libc.so.6 #8 0x0036b4df in syslog () from /lib/tls/libc.so.6 #9 0x0806ab08 in slap_send_ldap_result (op=0x25f61e58, rs=0x25a66230) at result.c:585 #10 0x08075952 in fe_op_bind (op=0x25f61e58, rs=0x25a66230) at bind.c:327 #11 0x0807523d in do_bind (op=0x25f61e58, rs=0x25a66230) at bind.c:200 #12 0x0805eac4 in connection_operation (ctx=0x25a662b0, arg_v=0x25f61e58) at connection.c:1133 #13 0x0812d1df in ldap_int_thread_pool_wrapper (xpool=0xb725df58) ---Type <return> to continue, or q <return> to quit--- at tpool.c:478 #14 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #15 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 2 (Thread 635861936 (LWP 10061)): #0 ber_get_next (sb=0x25f2ffe8, len=0x25e6427c, ber=0x25f65fd4) at io.c:551 #1 0x0805eed0 in connection_read (s=33) at connection.c:1528 #2 0x0805baa2 in slapd_daemon_task (ptr=0x0) at daemon.c:2461 #3 0x004e5371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x0036effe in clone () from /lib/tls/libc.so.6 Thread 1 (Thread -1208731424 (LWP 10058)): #0 0x0028e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x004e60fd in pthread_join () from /lib/tls/libpthread.so.0 #2 0x0805c621 in slapd_daemon () at daemon.c:2572 #3 0x0804dc9f in main (argc=13, argv=0xbff6ac14) at main.c:860 ------------------------------------------------------------------------------------ It did return the names to my client, which was good, but just crashed after (during) that. Please let me know if I can do anythin else. Thanks!

1 0

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 21 Mar '07

21 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 20 Mar '07

20 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

(ITS#4881) ldapsearch, SSL and segmentation fault
by andrej.groups＠gmail.com 20 Mar '07

20 Mar '07

Full_Name: Andrej Ricnik Version: ldapsearch 2.3.21 OS: Slackware 11 URL: Submission from: (NULL) (138.235.105.2) I'm trying to use ldapsearch against Novell eDir 8.7.3.9 (on Solaris) which works fine when used w/o encryption. If I use the self-signed Cert created on the eDir server ldapsearch segfaults. This works fine (returns the expected 46 DNs): ldapsearch -D cn=wpsbind,ou=wcm,ou=systemusers,ou=users,o=myorg -W -h dev4.kdc.myorg.org -x -s sub -LLL '(cn=*)' This one segfaults after the 45th DN: ldapsearch -ZZ -D cn=wpsbind,ou=wcm,ou=systemusers,ou=users,o=myorg -W -h dev4.kdc.myorg.org -x -s sub -LLL '(cn=*)' It looks similar to ITN# 889 ...

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 19 Mar '07

19 Mar '07

vargok(a)yahoo.com wrote: > Additionally, just FYI, it appears that the regular/standard OpenLDAP > (at least as of 2.3.32) BDB-based backend returns > "userCertificate;binary" just fine (and, actually, all the time, even > when requesting "userCertificate"). I would've expected them to > behave the same way. Right. Time permitting, I'll check why back-sql behaves differently and, in case, how to fix it. 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#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 19 Mar '07

19 Mar '07

Additionally, just FYI, it appears that the regular/standard OpenLDAP (at least as of 2.3.32) BDB-based backend returns "userCertificate;binary" just fine (and, actually, all the time, even when requesting "userCertificate"). I would've expected them to behave the same way. ----- Original Message ---- From: Pierangelo Masarati <ando(a)sys-net.it> To: Kevin Vargo <vargok(a)yahoo.com> Cc: openldap-its(a)openldap.org Sent: Wednesday, March 14, 2007 5:05:52 PM Subject: Re: (ITS#4868) Binary Attribute Patch(es) Kevin Vargo wrote: > However, there remains a problem: other LDAP Servers appear to return > the 'attribute-name' requested (userCertificate;binary::) to describe > the data. Now that the data is being returned, it's being returned > without the ";binary" option -- as 'userCertificate::'. Per > ITS#3113, ";binary" is obsoleted? To be honest, I'm not sure I have ever clearly understood that ";binary" issue, and I don't have time to dig out the documentation, learn about it, and check the code, since the whole stuff seems to be obsolete. > Is there a compatibility mode that can be optioned to support this? None that I know of. > Obsoleted and back-wards compatibility being in conflict..... I think compatibility with obsolete stuff is something that may easily get in conflict with open source, volunteer developed software. Volunteers tend to concentrate scarce resources on important things, and preserving compatibility with obsolete (often broken) stuff is first of all a waste of scarce resources, and second, but not least, reduces pressure on obsolete (broken) software makers, which typically are not volunteers but actually get paid for (obsolete/broken stuff). Having said this, you may find volunteers that, pushed by their own needs like to spend time supporting obsolete/broken stuff for the simple reason they need it. > i.e. > is there a way to say "return the attribute by name-requested instead > of schema-name?" No. This question has been raised many times, and the answer has always been like that. All you could do is hack slap_send_search_entry() in servers/slapd/result.c. 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 ------------------------------------------ ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html

1 0

(ITS#4880) HAVE_POSIX_TERMIOS -> HAVE_TERMIOS_H
by ed＠fxq.nl 18 Mar '07

18 Mar '07

Full_Name: Ed Schouten Version: 2.3.x and 2.4.x OS: FreeBSD URL: Submission from: (NULL) (83.180.2.78) The FreeBSD folks are planning on removing the old <sgtty.h> interface from their operating system. On FreeBSD, OpenLDAP still uses this header file, though there is some nice termios code in the source. It isn't used on FreeBSD at the moment, because the code doesn't use the same naming as the definition made by autoconf. A simple %s/HAVE_POSIX_TERMIOS/HAVE_TERMIOS_H/ on the sourcetree fixes this.

1 0

(ITS#4879) URL parse/unparse troubles
by h.b.furuseth＠usit.uio.no 17 Mar '07

17 Mar '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Here are some URLs parsing/building bugs in libldap/url.c. Some may be design bugs. Possibly some fixes will need backwards bug-compatibility. I show URLs converted from string to LDAPURLDesc format with ldap_url_parse(), back to string format with ldap_url_desc2str() when the result differs from the original, back to LDAPURLDesc... ================ The url.c Novell kludge does not work (for the example URL). If the bug is old and nobody has complained, maybe it should be removed. If it's fixed instead, note that the code looks like it'll handle Novell URLs with '/' in components after hostport: ldap_url_parse_ext() does strchr( url, '/' ) very early to find the end of the hostport. ldap://111.222.333.444:389??cn=abc,o=company -> error 5 (LDAP_URL_ERR_BADURL) Example URL without port number: ldap://111.222.333.444??cn=abc,o=company -> host "111.222.333.444??cn=abc,o=company", DN NULL -> ldap://111.222.333.444??cn=abc,o=company:389/??base ================ ldap_url_desc2str() outputs IPv6 host addresses as "addr" rather than "[addr]". (LDAPURLDesc does not contain the '[]'s in .lud_host, nor any flag which says it's an IPv6 host address). I don't know the syntax of such addresses, but I seem to remember they contains ':'s. If so the parser could fail if an IPv6 address does not contains ':', and the URL builder could test for ':' to determine if there should be [] around the host part. Also, what does stuff between the ']' and ':port' mean? Should anything be allowed there? ldap://[::1]what's this:222/ -> host "::1", port 222 -> ldap://::1:222/??base -> error 5 (LDAP_URL_ERR_BADURL) ================ Converting "%00" to char* should return an error, since the char* will not match the source URL: ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> ldapi://a/cn=d??base ================ The RFCs 4516/2255 hostport part has grammar [host [":" port]], but ldap_url_desc2str() produces [host][":" port]. ldap:// -> host NULL, port 389 -> ldap://:389/??base That's OK as an ldap_url_parse() OpenLDAP extension, but not as ldap_url_desc2str() output given to non-OpenLDAP applications. ================ While I'm writing, I wonder if OpenLDAP 2.4 could omit defaults and final "?"s from the ldap_url_desc2str() output. E.g. ldap:// would become ldap:// and not ldap://:389/??base. But maybe we get into trouble if ldap.conf has another port or something. ================ ldapi URL (un)parsing has several problems: ldap_url_parse() always treats ':' as a host:port separator. Thus one can produce an ldapi LDAPURLDesc with a meaningless port. However ldap_url_desc2str() does not URL-escape ':', and it also takes port!=0 to mean it is not an ldapi URL and needs no '/'-escaping. Similarly filenames with initial '[' do not work. ldapi://%2Ftmp%2Ffoo%3A222/ -> host "/tmp/foo:222" (correct) -> ldapi://%2Ftmp%2Ffoo:222/??base -> host "/tmp/foo", port 222 -> ldapi:///tmp/foo:222/??base -> host NULL, DN "tmp/foo:222/" ldapi://%2Ftmp%2Ffoo:000/ -> host "/tmp/foo" -> ldapi://%2Ftmp%2Ffoo/??base ldapi://%2Ftmp%2Ffoo:bar/ -> error 5 (LDAP_URL_ERR_BADURL) ==== The current implementation would handle some non-Unix ldapi filenames wrong. (They'll need well-defined URL-escaping rules if they get implemented, so it might as well be fixed now.) Of course these can also be strange Unix relative filenames... Windows-like filenames: ldapi://C%3A%2Fldapi/ -> host "C:/ldapi" -> ldapi://C:%2Fldapi/??base -> error 5 (LDAP_URL_ERR_BADURL) Tops-20-like filenames resemble IPv6 addresses (not that I expect to port OpenLDAP to Tops-20:-) ldapi://[ldap.var.run]ldapi/ -> host "ldap.var.run" -> ldapi://ldap.var.run/??base URL-escaping the '[' and ']' does not help; the '[' is lost: ldapi://%5Bldap.var.run%5Dldapi/ -> host "ldap.var.run]ldapi" -> ldapi://ldap.var.run%5Dldapi/??base

1 0

Re: (ITS#4872) Non-portable comparison in wait4msg() (result.c) causes infinite loop
by ando＠sys-net.it 17 Mar '07

17 Mar '07

There might be more about this; in daemon.c, difftime() is used to compute the difference between two time_t, but the result is assigned to a time_t. Maybe a negative value cannot be obtained, but in any case that cast would likely be incorrect as well in systems where time_t is unsigned. I'm re-opening this bug. 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#4878) removal of duplicate variables in slapd
by ando＠sys-net.it 17 Mar '07

17 Mar '07

bret.lambert(a)gmail.com wrote: > Unnecessary duplicate variables using the same name have been removed with this > patch. > > Found via lint(1) on OpenBSD. 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#4878) removal of duplicate variables in slapd
by bret.lambert＠gmail.com 17 Mar '07

17 Mar '07

Full_Name: bret lambert Version: HEAD OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/bret-lambert-070317.patch.1 Submission from: (NULL) (70.179.123.124) Unnecessary duplicate variables using the same name have been removed with this patch. Found via lint(1) on OpenBSD.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 14 Mar '07

14 Mar '07

Kevin Vargo wrote: > So, in ad.c [ad_inlist], the AttributeDescription (*desc) does not > have it's flags set 'properly.' That is, apparently within that > structure there are flags and tags, during the parsing of the schema, > the flags and tags get set properly (same file [slap_bv2ad]): > desc.ad_flags |= SLAP_DESC_BINARY; > > That means that, in ad_inlist, the desc's name still has ";binary" in > it, and no flags set. I find that if I map this condition as an > entry in the if/else cascade -- right after checking the flags, but > before the if-fail on flag compare -- the data is properly returned. > (I'll generate a patch, if that's an appropriate thing to do/place to > do it.) Not sure I understood - waiting for your patch... > However, there remains a problem: other LDAP Servers appear to return > the 'attribute-name' requested (userCertificate;binary::) to describe > the data. Now that the data is being returned, it's being returned > without the ";binary" option -- as 'userCertificate::'. Per > ITS#3113, ";binary" is obsoleted? To be honest, I'm not sure I have ever clearly understood that ";binary" issue, and I don't have time to dig out the documentation, learn about it, and check the code, since the whole stuff seems to be obsolete. > Is there a compatibility mode that can be optioned to support this? None that I know of. > Obsoleted and back-wards compatibility being in conflict..... I think compatibility with obsolete stuff is something that may easily get in conflict with open source, volunteer developed software. Volunteers tend to concentrate scarce resources on important things, and preserving compatibility with obsolete (often broken) stuff is first of all a waste of scarce resources, and second, but not least, reduces pressure on obsolete (broken) software makers, which typically are not volunteers but actually get paid for (obsolete/broken stuff). Having said this, you may find volunteers that, pushed by their own needs like to spend time supporting obsolete/broken stuff for the simple reason they need it. > i.e. > is there a way to say "return the attribute by name-requested instead > of schema-name?" No. This question has been raised many times, and the answer has always been like that. All you could do is hack slap_send_search_entry() in servers/slapd/result.c. 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#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 14 Mar '07

14 Mar '07

So, in ad.c [ad_inlist], the AttributeDescription (*desc) does not have it's flags set 'properly.' That is, apparently within that structure there are flags and tags, during the parsing of the schema, the flags and tags get set properly (same file [slap_bv2ad]): desc.ad_flags |= SLAP_DESC_BINARY; That means that, in ad_inlist, the desc's name still has ";binary" in it, and no flags set. I find that if I map this condition as an entry in the if/else cascade -- right after checking the flags, but before the if-fail on flag compare -- the data is properly returned. (I'll generate a patch, if that's an appropriate thing to do/place to do it.) However, there remains a problem: other LDAP Servers appear to return the 'attribute-name' requested (userCertificate;binary::) to describe the data. Now that the data is being returned, it's being returned without the ";binary" option -- as 'userCertificate::'. Per ITS#3113, ";binary" is obsoleted? Is there a compatibility mode that can be optioned to support this? Obsoleted and back-wards compatibility being in conflict..... i.e. is there a way to say "return the attribute by name-requested instead of schema-name?" ----- Original Message ---- From: Kevin Vargo <vargok(a)yahoo.com> To: Pierangelo Masarati <ando(a)sys-net.it> Cc: openldap-its(a)openldap.org Sent: Tuesday, March 13, 2007 10:15:26 AM Subject: Re: (ITS#4868) Binary Attribute Patch(es) >----- Original Message ---- >From: Pierangelo Masarati <ando(a)sys-net.it> >To: vargok(a)yahoo.com >Cc: openldap-its(a)openldap.org >Sent: Monday, March 12, 2007 4:52:04 PM >Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > >> 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. > >Well, the solution you propose is not correct, since you are altering >schema data, which is supposed to be read-only. In any case, the point is: Yeah; I think the actual submission found the ";binary" and reset the reference to it, not actually doing anything to it. >- if we decide that back-sql should ignore tags, then the solution >consists in using the canonical name of the underlying AttributeType >when looking up data; > >- however, this would destroy the possibility to use different storages >for differently encoded data; for example, a column for "cn;lang-en" and >a column for "cn;lang-jp". I don't know how many users would prefer one >solution over another, but in any case either we find a solution that >preserves both capabilities or we choose one. I'd vote in favor of >ignoring ";binary" since it's obsolete and related to transport only, >but in favor of honoring language tags. Sounds great to me. I just want support for ";binary" both on storage and retrieval to be supported. I'll accept that it's obsolete -- I'll also put forth that a lot of things still use it (e.g. Lotus Domino v6). >> 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). > >In fact, "userCertificate;binary" is the attribute description. The >attribute name is in ad_type->sat_cname. And, in fact, none of what I did appears to have been sufficient. I'm still looking at why selecting "userCertificate;binary" as part of an ldapsearch attribute-list doesn't pull the data. "userCertificate" does. The issue appears to be related to the ad_inlist verification on the search-supplied attribute -- "userCertificate;binary" doesn't resolve. If you know where I can look to figure this out, that would help. I've been through some areas and not found exactly where just yet. Thanks for your assistance. Kevin Vargo ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by hyc＠symas.com 14 Mar '07

14 Mar '07

You should have provided this information in the original report. This is a dup of ITS#4848, already fixed in HEAD. In the mean time, don't interleave overlay statements with database statements. Dieter Kluenter wrote: > I just deleted slapd.d and rerun slapd -F -f, this is the relevant output of > olcDatabase={1}hdb.ldif > > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN:: cBcAAGRtaW4sbz1hdmNpLGM9ZGU= > olcRootPW:: aGhkeTAx > olcMonitoring: TRUE > olcDbDirectory: /var/lib/ldap > olcDbCacheSize: 1000 > olcDbCheckpoint: 1024 5 > olcDbConfig: {0}set_cachesize 0 268435456 1 > > and this is part of the slapd.conf in question > > ######### databases ############ > database config > rootdn cn=config > rootpw hhdy01 > # > database hdb > suffix "o=avci,c=de" > rootdn "cn=admin,o=avci,c=de" > rootpw xxxxx > # > overlay dynlist > dynlist-attrset groupOfURLs memberURL > # > checkpoint 1024 5 > cachesize 2000 > idlcachesize 6000 > ... > ... > > -Dieter > -- -- 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#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 14 Mar '07

14 Mar '07

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Howard Chu <hyc(a)symas.com> writes: >> >>> What is the original rootdn? >>> >> cn=admin,o=avci,c=de >> -Dieter >> > I don't see anything like that here. You'll probably have to post your > slapd.conf. Have you checked for extraneous white space in the > original rootdn config? I just deleted slapd.d and rerun slapd -F -f, this is the relevant output of olcDatabase={1}hdb.ldif olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN:: cBcAAGRtaW4sbz1hdmNpLGM9ZGU= olcRootPW:: aGhkeTAx olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_cachesize 0 268435456 1 and this is part of the slapd.conf in question ######### databases ############ database config rootdn cn=config rootpw hhdy01 # database hdb suffix "o=avci,c=de" rootdn "cn=admin,o=avci,c=de" rootpw xxxxx # overlay dynlist dynlist-attrset groupOfURLs memberURL # checkpoint 1024 5 cachesize 2000 idlcachesize 6000 ... ... -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4877) Patch to ldapmodrdn.1
by daveh＠ci.com.au 13 Mar '07

13 Mar '07

Full_Name: Dave Horsfall Version: HEAD OS: FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/dave-horsfall-070314.patch Submission from: (NULL) (192.65.182.30) Trivial patch to ldapmodrdn.1 to document "-s newsup".

1 0

(ITS#4876) Multiple levels of uniqueness
by quanah＠stanford.edu 13 Mar '07

13 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3.33 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In using the uniqueness overlay, I found there are times I want to apply uniqueness rules differently based on (sub)tree. For example, I might like something along these lines where the db starts at dc=stanford,dc=edu: overlay unique unique_base dc=stanford,dc=edu unique_attributes krb5PrincipalName suRegID overlay unique unique_base cn=people,dc=stanford,dc=edu unique_attributes suunivid suproxycardnumber sucardnumber suuniqueidentifier overlay unique unique_base cn=accounts,dc=stanford,dc=edu unique_attributes uid However, I found in testing this, that any instantiation of the uniqueness overlay past the first one is ignored (i.e., not applied to writes). I think being able to do this is useful, becase I only want the uniqueness overlay to intercede when the write applies to the particular (sub)tree where it is necessary to enforce it. It may be worthwhile to update the syntax for the uniqueness overlay to behave more like the valsort overlay, where each attribute defines which tree it is applying weights to, like: overlay valsort valsort-attr ou cn=people,dc=stanford,dc=edu weighted valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted --Quanah

1 0

(ITS#4875) fix for bug in passfile.c -- infinite loop when password file is pipe/FIFO/tty/etc
by pzq_1＠jural.com 13 Mar '07

13 Mar '07

Full_Name: Mark Seecof Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/MARK-SEECOF-070313.patch Submission from: (NULL) (151.152.101.44) When you ask an OpenLDAP tool such as ldapsearch(1) to read a password from a file which is a pipe, FIFO, tty/pty, or other special file, the tool will go into an infinite loop in function lutil_get_filed_password() (from libraries/liblutil/passfile.c). The problem is a bug in lutil_get_filed_password(): it calls fstat() on the password file, then enters a loop attempting to read st_size bytes from the file until it reaches EOF. For pipes, FIFO's, tty's, etc. st_size is typically 0, so the loop never finishes--you may read 0 bytes from the file an infinite number of times without ever reaching the end! (Actually, fread(,,0,) is a no-op.) This bug only requires a one-line fix (though I actually propose to change two lines). We simply eliminate the check on st_size and attempt to read a buffer-full of bytes. The existing code cheerfully copes with that many bytes, fewer, or more... (My second change is to the default buffer size, to make it more efficient.) SIMPLE LINUX 2.6 TEST CASE echo -n "password" | ldapsearch -U user -Y Digest-MD5 -y /dev/stdin '(foo=bar)' GENERIC UNIX/LINUX TEST CASE mknod pw_fifo p echo -n "password" > pw_fifo & ldapsearch -U user -Y Digest-MD5 -y pw_fifo '(foo=bar)' Please retrieve my patch from MARK-SEECOF-070313.patch I, Mark Seecof, hereby place the modifications to OpenLDAP Software I supply in MARK-SEECOF-070313.patch (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#4874) Possible acl_set_cb_gather() bug
by rein＠basefarm.no 13 Mar '07

13 Mar '07

Full_Name: Rein Tollevik Version: 2.3.34 OS: Solaris8 URL: Submission from: (NULL) (81.93.160.250) While looking for a fix for the problem I reported in ITS#4873 I noticed what looks like a minor typo bug in acl_set_cb_gather() in servers/slapd/acl.c. Near the end there is a test for "if ( bvals )" which I suspect should have been "if ( bvalsp )". The bug shouldn't do any more harm than wasting a few cpu cycles though, as bvals should always be true and slap_set_join() with NULL bvalsp should return the same origninal set... Rein Tollevik Basefarm AS

1 0

(ITS#4873) ACL set memory corruption and leak
by rein＠basefarm.no 13 Mar '07

13 Mar '07

Full_Name: Rein Tollevik Version: 2.3.34 OS: Solaris 8 URL: Submission from: (NULL) (81.93.160.250) The fix for ITS#4780 seem to have introduced a memory corruption when ACL sets are used, it causes memory that is still in use to be freed after two sets are or'ed. Furthermore, the fix only frees the value in the first element of a multi-element set, i.e it still leaks memory when the values should be released. Our servers started to seg. faulting shortly after we upgraded from version 2.3.19 to 2.3.34, but have stayed alive after the patched included below was applied. Rein Tollevik Basefarm AS Index: servers/slapd/sets.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/sets.c,v retrieving revision 1.1.1.10 retrieving revision 1.13 diff -u -u -w -r1.1.1.10 -r1.13 --- servers/slapd/sets.c 5 Jan 2007 09:02:42 -0000 1.1.1.10 +++ servers/slapd/sets.c 13 Mar 2007 11:35:18 -0000 1.13 @@ -181,6 +181,12 @@ } } BER_BVZERO( &set[ last ] ); + + /* We have already copied, duplicated or freed + * the values in lset and rset, so don't free + * them again! + */ + op_flags |= SLAP_SET_LREFVAL|SLAP_SET_RREFVAL; } break; @@ -264,21 +270,14 @@ } done:; - if ( !( op_flags & SLAP_SET_LREFARR ) && lset != NULL ) { - if ( !( op_flags & SLAP_SET_LREFVAL )) - cp->set_op->o_tmpfree( lset->bv_val, cp->set_op->o_tmpmemctx ); - cp->set_op->o_tmpfree( lset, cp->set_op->o_tmpmemctx ); - } - - if ( !( op_flags & SLAP_SET_RREFARR ) && rset != NULL ) { - if ( !( op_flags & SLAP_SET_RREFVAL )) - cp->set_op->o_tmpfree( rset->bv_val, cp->set_op->o_tmpmemctx ); - cp->set_op->o_tmpfree( rset, cp->set_op->o_tmpmemctx ); - } + if ( lset != NULL ) + slap_set_dispose( cp, lset, SLAP_SET_LREF2REF( op_flags )); + if ( rset != NULL ) + slap_set_dispose( cp, rset, SLAP_SET_RREF2REF( op_flags )); return set; } static BerVarray set_chase( SLAP_SET_GATHER gatherer,

1 0

RE: (ITS#4864) -r option "redirects" to logfile, breaks replication
by Chris.Eubank＠gov.bc.ca 13 Mar '07

13 Mar '07

OK I understand if the -r switch (to slurpd, not slapd) redirects the output to a file for debugging purposes, this is just not apparent in the man pages. The man pages to not tell me that slurpd will be "redirecting" with the -r switch. It is just usual replication I was setting up originally. This is the variable I was using in an "openldaprc" file: # -r replication-log-file. Directory must be created. #SLURPD_REPL_LOG_FILE=/var/openldap-slurp/log When uncommenting this line, the result is that it does not open network connections to the replication slaves. _All_ data goes to the file, none to the slaves. This isn't documented correctly, it took me a long time to figure out why the replication was not happening. Chris -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Sun, March 11, 2007 11:52 PM To: Eubank, Chris LCS:EX Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4864) -r option "redirects" to logfile, breaks replication [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 raphael.ouazana＠linagora.com 13 Mar '07

13 Mar '07

Le Lun 12 mars 2007 06:37, Pierangelo Masarati a écrit : > 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. OK. You'll find a new version here: ftp://ftp.openldap.org/incoming/raphael-ouazana-070313.patch It takes care of your notices. Regards, Raphael Ouazana.

1 0

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

13 Mar '07

>----- Original Message ---- >From: Pierangelo Masarati <ando(a)sys-net.it> >To: vargok(a)yahoo.com >Cc: openldap-its(a)openldap.org >Sent: Monday, March 12, 2007 4:52:04 PM >Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > >> 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. > >Well, the solution you propose is not correct, since you are altering >schema data, which is supposed to be read-only. In any case, the point is: Yeah; I think the actual submission found the ";binary" and reset the reference to it, not actually doing anything to it. >- if we decide that back-sql should ignore tags, then the solution >consists in using the canonical name of the underlying AttributeType >when looking up data; > >- however, this would destroy the possibility to use different storages >for differently encoded data; for example, a column for "cn;lang-en" and >a column for "cn;lang-jp". I don't know how many users would prefer one >solution over another, but in any case either we find a solution that >preserves both capabilities or we choose one. I'd vote in favor of >ignoring ";binary" since it's obsolete and related to transport only, >but in favor of honoring language tags. Sounds great to me. I just want support for ";binary" both on storage and retrieval to be supported. I'll accept that it's obsolete -- I'll also put forth that a lot of things still use it (e.g. Lotus Domino v6). >> 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). > >In fact, "userCertificate;binary" is the attribute description. The >attribute name is in ad_type->sat_cname. And, in fact, none of what I did appears to have been sufficient. I'm still looking at why selecting "userCertificate;binary" as part of an ldapsearch attribute-list doesn't pull the data. "userCertificate" does. The issue appears to be related to the ad_inlist verification on the search-supplied attribute -- "userCertificate;binary" doesn't resolve. If you know where I can look to figure this out, that would help. I've been through some areas and not found exactly where just yet. Thanks for your assistance. Kevin Vargo ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by hyc＠symas.com 13 Mar '07

13 Mar '07

dieter(a)dkluenter.de wrote: > Howard Chu <hyc(a)symas.com> writes: > >> What is the original rootdn? >> > cn=admin,o=avci,c=de > > -Dieter > I don't see anything like that here. You'll probably have to post your slapd.conf. Have you checked for extraneous white space in the original rootdn config? -- -- 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#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 13 Mar '07

13 Mar '07

Howard Chu <hyc(a)symas.com> writes: > What is the original rootdn? > cn=admin,o=avci,c=de -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4872) Non-portable comparison in wait4msg() (result.c) causes infinite loop
by carsten.agger＠tietoenator.com 13 Mar '07

13 Mar '07

Full_Name: Carsten Agger Version: 2.3.20 OS: OSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.21) On our architecture (OSE running on an AXE processor), time_t is an unsigned int. This means that this code, as found in the wait4msg function in libraries/libldap/result.c, will break: > > if ( rc == LDAP_MSG_X_KEEP_LOOKING && tvp != NULL ) { > tmp_time = time( NULL ); > tv0.tv_sec -= ( tmp_time - start_time ); > if ( tv0.tv_sec <= 0 ) { > rc = 0; /* timed out */ > ld->ld_errno = LDAP_TIMEOUT; > break; > } > tv.tv_sec = tv0.tv_sec; > ... > } Why? Because if (start_time > tmp_time), the condition ( tv0.tv_sec <= 0 ) will never evaluate to TRUE, and the break will never be executed - yielding an infinite loop. Solution: rewrite in a portable way, e.g. (as suggested by Pierangelo Masarati on the bugs mailing list) by testing if the value of tv_sec would be negative after subtracting ( tmp_time - start_time ) before assigning it.

1 0

Bug causing infinite loop in result.c
by Carsten.Agger＠tietoenator.com 13 Mar '07

13 Mar '07

We have found a bug in libraries/libldap/result.c which may cause an infinite loop in some situations. The error is this, in the function wait4msg(): if ( rc == LDAP_MSG_X_KEEP_LOOKING && tvp != NULL ) { tmp_time = time( NULL ); tv0.tv_sec -= ( tmp_time - start_time ); if ( tv0.tv_sec <= 0 ) { rc = 0; /* timed out */ ld->ld_errno = LDAP_TIMEOUT; break; } tv.tv_sec = tv0.tv_sec; ... } The problem is this: The check ( tv0.tv_sec <= 0 ) is always true, since tv_sec (on our system, at least) is an unsigned int. The problem is fixed by casting it to int: if ( (int) tv0.tv_sec <= 0 ) { ... } however this might not be the most suitable way to fix it. best regards, Carsten Agger Software Consultant, TietoEnator A/S, Denmark http://www.tietoenator.dk

2 2

(ITS#4871) index directive & slapd.conf(5)
by quanah＠stanford.edu 13 Mar '07

13 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) The slapd.conf(5) man page talks about the various ways in which indices can be tuned, such as index_substr_if_maxlen, but it does not actually mention the index directive. It may be worthwhile to have text like [b]index[/b] See the man page for the specific backend you are using for more information about the index directive {ex: slapd-bdb(5)} so that users can more easily find that information (and the necessity to run slapindex on bdb, for example) etc.

1 0

(ITS#4870) superfluous int declarations in bconfig.c
by bret.lambert＠gmail.com 13 Mar '07

13 Mar '07

Full_Name: Bret Lambert Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/bret-lambert-070312.patch Submission from: (NULL) (70.179.123.124) Superfluous redeclarations of 'int i' in bconfig.c Found via lint(1) on OpenBSD.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 12 Mar '07

12 Mar '07

vargok(a)yahoo.com wrote: > These address the use of Binary-valued attributes (#3113, #3386): The proposed patches have been applied (with changes) to HEAD code (you should be able to easily generate the diffs between HEAD and re23 code); please test. In detail, please check the solution for the ";binary" issue. If you report the behavior as satisfactory, backporting to re23 could be an option, since the fix should be well isolated, and it configures as borderline between new feature and bug fix. 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#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 12 Mar '07

12 Mar '07

Few preliminary comments follow. vargok(a)yahoo.com wrote: > Version: 2.3.32 You should rather patch HEAD code instead of released, and even not the latest. However, given the development rate of back-sql (~0), it shouldn't really matter > 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. Well, the solution you propose is not correct, since you are altering schema data, which is supposed to be read-only. In any case, the point is: - if we decide that back-sql should ignore tags, then the solution consists in using the canonical name of the underlying AttributeType when looking up data; - however, this would destroy the possibility to use different storages for differently encoded data; for example, a column for "cn;lang-en" and a column for "cn;lang-jp". I don't know how many users would prefer one solution over another, but in any case either we find a solution that preserves both capabilities or we choose one. I'd vote in favor of ignoring ";binary" since it's obsolete and related to transport only, but in favor of honoring language tags. > 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. This is just fine. > 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). In fact, "userCertificate;binary" is the attribute description. The attribute name is in ad_type->sat_cname. > 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. Fine, but already fixed. > 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). You made an extensive use of C++ style comments, which are non portable. Obviously you didn't read the contribution guidelines. I'm testing (and improving) it. 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#4866) Can we list Null Value Attributes
by hyc＠symas.com 12 Mar '07

12 Mar '07

The ITS is not for general software usage questions. Use the ldap(a)umich.edu mailing list for general LDAP questions. This ITS will be closed. maruthigsr(a)gmail.com wrote: > 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 > > > . > -- -- 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#4869) config creates base64 encoded rootdn
by hyc＠symas.com 12 Mar '07

12 Mar '07

What is the original rootdn? dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.4alpha > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.235.193) > > > When running slapd with -F -f to create a new config database, olcRootDN value > is created base64 encoded > > => ldap_bv2dn(p,0) > ldap_err2string > <= ldap_bv2dn(p)=-4 Decoding error > ldap_err2string > olcRootDN: value #0: <olcRootDN> invalid DN 21 (Invalid syntax) > config error processing olcDatabase={1}hdb,cn=config: <olcRootDN> invalid DN 21 > > (Invalid syntax) > send_ldap_result: conn=-1 op=0 p=0 > send_ldap_result: err=19 matched="" text="" > slapd destroy: freeing system resources. > slapd stopped. > > -Dieter > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 12 Mar '07

12 Mar '07

Full_Name: Dieter Kluenter Version: 2.4.4alpha OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.235.193) When running slapd with -F -f to create a new config database, olcRootDN value is created base64 encoded => ldap_bv2dn(p,0) ldap_err2string <= ldap_bv2dn(p)=-4 Decoding error ldap_err2string olcRootDN: value #0: <olcRootDN> invalid DN 21 (Invalid syntax) config error processing olcDatabase={1}hdb,cn=config: <olcRootDN> invalid DN 21 (Invalid syntax) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=19 matched="" text="" slapd destroy: freeing system resources. slapd stopped. -Dieter

1 0

Re: example: OpenLDAP with SASL/DIGEST-MD5 authentication (ITS#4867)
by ando＠sys-net.it 12 Mar '07

12 Mar '07

Piotr.Golonka(a)cern.ch wrote: > Indeed, 2.2.13 may be historical, It is. It's not an opinion, but a fact. Even 2.2.30, the latest 2.2 release, is historical. > yet this is the version used in large > production systems (e.g. RedHat Enterprise Linux). I believe the problem is not ours. I think we did our best by pushing out 2.2 up to 2.2.30, then 2.3 up to 2.3.34, and now 2.4. If distributions don't catch up I don't think anyone can blame OpenLDAP (and I don't think you are; I'm just trying to make the point). > I'll try to have a look at what's in 2.4. I hope I get my point: every contribution is welcome, but not every contribution may be useful. Writing howtos for code that was released ages ago, and is not maintained may be considered little useful. This is an opinion, of course. 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: example: OpenLDAP with SASL/DIGEST-MD5 authentication (ITS#4867)
by Piotr.Golonka＠cern.ch 12 Mar '07

12 Mar '07

On Monday 12 March 2007 18:04, you wrote: > 2.2.13 is historical. ldap_sasl_bind(3) eventually got documented (only > the prototype in 2.3, more docs in 2.4). Please check current 2.4 > documentation and, in case, adapt your contribution to it. In fact, that > man page does not contain any coding example, as we usually refer to client > tools implementations. Please feel free to submit your contribution, lined > up to active code, as a FAQ entry <http://www.openldap.org/faq/>. The FAQ > is interactive. Hi, thanx for reply. Indeed, 2.2.13 may be historical, yet this is the version used in large production systems (e.g. RedHat Enterprise Linux). I'll try to have a look at what's in 2.4. best regards: Piotr

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs