- openldap-bugs - openldap.org

(ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) When building OpenLDAP 2.3.28, I found that libslapi is full of undefined symbols. Is it not being linked correctly? ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd libslapi.so libc.so.6 => /lib/libc.so.6 (0x00002b58357d6000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd -r -d libslapi-2.3.so.0.2.16 libc.so.6 => /lib/libc.so.6 (0x00002adf05784000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) undefined symbol: slap_schema (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming (./libslapi-2.3.so.0.2.16) undefined symbol: ch_mfuncs (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_extended (./libslapi-2.3.so.0.2.16) undefined symbol: slap_cids (./libslapi-2.3.so.0.2.16) undefined symbol: slap_unknown_bv (./libslapi-2.3.so.0.2.16) undefined symbol: frontendDB (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming_auth (./libslapi-2.3.so.0.2.16) undefined symbol: local_ssf (./libslapi-2.3.so.0.2.16) undefined symbol: slap_debug (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog_level (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_result (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_reference (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str_mutex (./libslapi-2.3.so.0.2.16) undefined symbol: be_isroot (./libslapi-2.3.so.0.2.16) undefined symbol: slapi_plugins_used (./libslapi-2.3.so.0.2.16) undefined symbol: be_slurp_update (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_init (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_broadcast (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: lutil_strcopy (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_check (./libslapi-2.3.so.0.2.16) undefined symbol: value_add_one (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize_one (./libslapi-2.3.so.0.2.16) undefined symbol: rdn_validate (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_pool_context (./libslapi-2.3.so.0.2.16) undefined symbol: ber_dupbv (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_extop (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize (./libslapi-2.3.so.0.2.16) undefined symbol: ch_free (./libslapi-2.3.so.0.2.16) undefined symbol: modify_add_values (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_signal (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_unlock (./libslapi-2.3.so.0.2.16) undefined symbol: be_issuffix (./libslapi-2.3.so.0.2.16) undefined symbol: ch_calloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_sl_free (./libslapi-2.3.so.0.2.16) undefined symbol: anlist2charray_x (./libslapi-2.3.so.0.2.16) undefined symbol: ch_strdup (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: value_match (./libslapi-2.3.so.0.2.16) undefined symbol: slap_str2ad (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_is_inst (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvfree (./libslapi-2.3.so.0.2.16) undefined symbol: is_ad_subtype (./libslapi-2.3.so.0.2.16) undefined symbol: access_allowed_mask (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: dnExtractRdn (./libslapi-2.3.so.0.2.16) undefined symbol: send_ldap_sasl (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_dup (./libslapi-2.3.so.0.2.16) undefined symbol: register_supported_control (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods2entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_wait (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_add (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_get_rw (./libslapi-2.3.so.0.2.16) undefined symbol: dnPrettyNormal (./libslapi-2.3.so.0.2.16) undefined symbol: select_backend (./libslapi-2.3.so.0.2.16) undefined symbol: dnParent (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlerror (./libslapi-2.3.so.0.2.16) undefined symbol: attr_delete (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_release_rw (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2dn (./libslapi-2.3.so.0.2.16) undefined symbol: str2entry (./libslapi-2.3.so.0.2.16) undefined symbol: dnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_initialize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_lock (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_controls (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlclose (./libslapi-2.3.so.0.2.16) undefined symbol: entry_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_parse_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str (./libslapi-2.3.so.0.2.16) undefined symbol: entry_dup (./libslapi-2.3.so.0.2.16) undefined symbol: slap_entry2mods (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_op_walk (./libslapi-2.3.so.0.2.16) undefined symbol: rdnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: str2filter (./libslapi-2.3.so.0.2.16) undefined symbol: filter_free (./libslapi-2.3.so.0.2.16) undefined symbol: attr_find (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdn2bv (./libslapi-2.3.so.0.2.16) undefined symbol: entry_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_dnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_str2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: dnIsSuffix (./libslapi-2.3.so.0.2.16) undefined symbol: rdnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_unbind_ext_s (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_free (./libslapi-2.3.so.0.2.16) undefined symbol: test_filter (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlopen (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_register (./libslapi-2.3.so.0.2.16) undefined symbol: modify_delete_values (./libslapi-2.3.so.0.2.16) undefined symbol: attr_free (./libslapi-2.3.so.0.2.16) undefined symbol: backend_connection_init (./libslapi-2.3.so.0.2.16) undefined symbol: build_new_dn (./libslapi-2.3.so.0.2.16) undefined symbol: entry_schema_check (./libslapi-2.3.so.0.2.16) undefined symbol: ad_inlist (./libslapi-2.3.so.0.2.16) undefined symbol: filter2bv_x (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_init (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: attr_dup (./libslapi-2.3.so.0.2.16) undefined symbol: connection_assign_nextid (./libslapi-2.3.so.0.2.16) undefined symbol: ch_realloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_controls_free (./libslapi-2.3.so.0.2.16) undefined symbol: mods_structural_class (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlsym (./libslapi-2.3.so.0.2.16) undefined symbol: filter_dup (./libslapi-2.3.so.0.2.16) undefined symbol: dnPretty (./libslapi-2.3.so.0.2.16) undefined symbol: slap_bv2ad (./libslapi-2.3.so.0.2.16) undefined symbol: acl_check_modlist (./libslapi-2.3.so.0.2.16) undefined symbol: dnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: ch_malloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlinit (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_config (./libslapi-2.3.so.0.2.16)

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> As far as I remember, that test is intended to prevent mapping when the >> search returns more than one entry. This makes perfectly sense, >> otherwise a SASL identity (or an authorization identity) would be >> arbitrarily mapped to one of the matching entries. So mapping is >> intended to succeed if and only if exactly one identity can be resolved. > > That test is only supposed to prevent mapping when doing an authzRegexp > mapping of a single SASL userID to a DN. When looking up > authzFrom/authzTo it is supposed to allow multiple results. > Interestingly, it looks like slap_sasl_match isn't even used for > authzRegexp mapping any more. Something is definitely broken here. > This behavior was changed in rev 1.126 of saslauthz.c. I believe the relevant portions of that patch need to be reverted. e.g. patch -R: diff -u -r1.125 -r1.126 --- saslauthz.c 26 Apr 2004 19:47:02 -0000 1.125 +++ saslauthz.c 26 Apr 2004 20:47:08 -0000 1.126 @@ -772,14 +802,26 @@ { smatch_info *sm = o->o_callback->sc_private; - if (rs->sr_type != REP_SEARCH) return 0; + if ( rs->sr_type != REP_SEARCH ) { + if ( rs->sr_err != LDAP_SUCCESS ) { + sm->match = -1; + } + return 0; + } + + if ( sm->match == 1 ) { + sm->match = -1; + return 0; + } if (dn_match(sm->dn, &rs->sr_entry->e_nname)) { sm->match = 1; - return -1; /* short-circuit the search */ + + } else { + sm->match = -1; } - return 1; + return 0; } /* @@ -984,7 +1026,7 @@ op.o_bd->be_search( &op, &rs ); - if (sm.match) { + if (sm.match == 1) { rc = LDAP_SUCCESS; } else { rc = LDAP_INAPPROPRIATE_AUTH; -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > sylvain(a)pilotsystems.net wrote: >> Full_Name: Sylvain Viollon >> Version: 2.3 >> OS: FreeBSD 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.204.228.114) >> >> >> >> I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, >> having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) >> having the following attribute : >> >> authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) >> >> He can successfully authenticate, but not become an user listed by the search >> (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the >> last user returned by the search. >> >> In source, I read the file 'servers/slapd/saslauthz.c'. The filter >> 'sasl_sc_smatch' said if the wanted user is in the search result. In this >> function, there is a test : >> >> if ( sm->match == 1 ) { >> sm->match = -1; >> return 0; >> } >> >> I have removed the line : >> >> sm->match = -1; >> >> Which make the match to fail if there is an entry in the search return after the >> good one. Like every DN have to be unique, there is no multiple solution, and >> validation would not be discarded for that. I didn't know if it's a good >> solution, but it's work. >> >> > As far as I remember, that test is intended to prevent mapping when the > search returns more than one entry. This makes perfectly sense, > otherwise a SASL identity (or an authorization identity) would be > arbitrarily mapped to one of the matching entries. So mapping is > intended to succeed if and only if exactly one identity can be resolved. That test is only supposed to prevent mapping when doing an authzRegexp mapping of a single SASL userID to a DN. When looking up authzFrom/authzTo it is supposed to allow multiple results. Interestingly, it looks like slap_sasl_match isn't even used for authzRegexp mapping any more. Something is definitely broken here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by ando＠sys-net.it 11 Nov '06

11 Nov '06

sylvain(a)pilotsystems.net wrote: > Full_Name: Sylvain Viollon > Version: 2.3 > OS: FreeBSD 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.204.228.114) > > > > I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, > having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) > having the following attribute : > > authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) > > He can successfully authenticate, but not become an user listed by the search > (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the > last user returned by the search. > > In source, I read the file 'servers/slapd/saslauthz.c'. The filter > 'sasl_sc_smatch' said if the wanted user is in the search result. In this > function, there is a test : > > if ( sm->match == 1 ) { > sm->match = -1; > return 0; > } > > I have removed the line : > > sm->match = -1; > > Which make the match to fail if there is an entry in the search return after the > good one. Like every DN have to be unique, there is no multiple solution, and > validation would not be discarded for that. I didn't know if it's a good > solution, but it's work. > > As far as I remember, that test is intended to prevent mapping when the search returns more than one entry. This makes perfectly sense, otherwise a SASL identity (or an authorization identity) would be arbitrarily mapped to one of the matching entries. So mapping is intended to succeed if and only if exactly one identity can be resolved. If the behavior you're experiencing is consistent with the above, there is no evidence of a bug in OpenLDAP software. If it's not, please detail. Otherwise, this ITS will be closed. p. Unless 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#4744) Bug in SASL authzTo validation using an ldap:// rule
by sylvain＠pilotsystems.net 11 Nov '06

11 Nov '06

Full_Name: Sylvain Viollon Version: 2.3 OS: FreeBSD 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.204.228.114) I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) having the following attribute : authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) He can successfully authenticate, but not become an user listed by the search (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the last user returned by the search. In source, I read the file 'servers/slapd/saslauthz.c'. The filter 'sasl_sc_smatch' said if the wanted user is in the search result. In this function, there is a test : if ( sm->match == 1 ) { sm->match = -1; return 0; } I have removed the line : sm->match = -1; Which make the match to fail if there is an entry in the search return after the good one. Like every DN have to be unique, there is no multiple solution, and validation would not be discarded for that. I didn't know if it's a good solution, but it's work. Openldap 2.2 and 2.4 seems to have the same problem.

1 0

ITS#3755 strict aliasing rules
by hyc＠symas.com 10 Nov '06

10 Nov '06

Compiling current HEAD with gcc 4.1.1 make AC_CFLAGS="-g -fstrict-aliasing -O3 -Wstrict-aliasing" -j3 CC=gcc turned up a few "will break strict-aliasing rules" warnings: libldap/cyrus.c libldap/getdn.c clients/tools/ldapsearch.c servers/slapd/sasl.c I've silenced all of those. Whether the code was actually unsafe before and is safer now is anybody's guess; I was unable to get any of it to misbehave with various combinations of optimization switches. There are warnings about using the BerElementBuffer "might break strict-aliasing rules" which I've chosen to ignore. Since the memory is only actually referenced through the BerElement pointer, whether or not the contents are defined when accessing the BerElementBuffer is irrelevant. (I.e., we never access it that way, so it's moot.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 10 Nov '06

10 Nov '06

michael(a)stroeder.com wrote: > It seems that slapd stops without configuration error message if unknown > attribute types are set for parameter unique_attributes (slapo-unique). It would > be nice if a descriptive message is displayed (like in other cases). > I think this occurs if debug is set to "config" or "-1". However, it would be more appropriate to log configuration errors that result in failures at "any", so that whatever logging is set they show up. For this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that they show up when caught by tools with default logging (e.g. slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. I'd vote for the latter. 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

(ITS#4743) ldapsearch manpage Project reference
by quanah＠stanford.edu 10 Nov '06

10 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28/2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The ldapsearch(1) man page was sync'd for the 2.3.28 release, and inadverdently included a reference to the "Projects" file, which is a HEAD specific bit.

1 0

(ITS#4742) parameter unique_attributes and unknown attribute types
by michael＠stroeder.com 10 Nov '06

10 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.25.247) HI! It seems that slapd stops without configuration error message if unknown attribute types are set for parameter unique_attributes (slapo-unique). It would be nice if a descriptive message is displayed (like in other cases). Ciao, Michael.

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

Eric Covener wrote: > On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: >> covener(a)gmail.com wrote: >> > FWIW, Another SDK I'm working with exposes a once-per-process SSL >> > initialization method, that would amount to ldap_pvt_tls_init(); >> >> A fix for this is in HEAD, please test. > > Now working for me on HEAD: > ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); > ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); > > ld1 = ldap_init(h,p); > ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); > ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); > ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); > > ld2 = ldap_init(h,p); > > and connections to ld1 and ld2 send the right client cert over the > wire. Hope this is a resonable API usage -- Much appreciated! > Thanks for the confirmation. The is_server flag only needs to be set non-zero if you are going to be accepting incoming TLS sessions with that context. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: > covener(a)gmail.com wrote: > > FWIW, Another SDK I'm working with exposes a once-per-process SSL > > initialization method, that would amount to ldap_pvt_tls_init(); > > A fix for this is in HEAD, please test. Now working for me on HEAD: ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); ld1 = ldap_init(h,p); ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); ld2 = ldap_init(h,p); and connections to ld1 and ld2 send the right client cert over the wire. Hope this is a resonable API usage -- Much appreciated! -- Eric Covener covener(a)gmail.com

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

covener(a)gmail.com wrote: > FWIW, Another SDK I'm working with exposes a once-per-process SSL > initialization method, that would amount to ldap_pvt_tls_init(); A fix for this is in HEAD, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

FWIW, Another SDK I'm working with exposes a once-per-process SSL initialization method, that would amount to ldap_pvt_tls_init();

1 0

(ITS#4739)
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1558012606-1163097706=:73509 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Apologies for the breach of etiqette. Will change the backend.=0A=0A -k= ph=0A=0A=0A=0A=0A=0A=0A =0A________________________________________________= ____________________________________=0ADo you Yahoo!?=0AEveryone is raving = about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.com --0-1558012606-1163097706=:73509 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div>Apologies for the breach of etiqette.  Will change the backe= nd.     -kph </div></div> =0A=0A=0A<hr = size=3D1>Everyone is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D4= 2297/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail= beta.</a></body></html> --0-1558012606-1163097706=:73509--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by hyc＠symas.com 09 Nov '06

09 Nov '06

lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() function, > which is assigned at line 522. The next if-then-else block is checking to > see if the module reported an error, at which point 'ok' would be assigned > LDAP_OTHER regardless of what check_password() returned. A superfluous else > block appears after this check, assigning 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. > > Thanks, A fix has been committed to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

[Fwd: Re: (ITS#4739) Server crashes every time alias is dereferenced]
by hyc＠symas.com 09 Nov '06

09 Nov '06

This is a multi-part message in MIME format. --------------080602030800020000070003 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is the info Kevin sent before. aliases are known to work incorrectly in back-ldbm. back-ldbm has been deprecated since OpenLDAP 2.2 and has been deleted from the source tree for OpenLDAP 2.4. As such, I don't see us taking any action on this bug report. Use back-bdb or back-hdb instead. -------- Original Message -------- Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced Date: Wed, 8 Nov 2006 22:09:51 -0800 (PST) From: Kevin Hardiman <hardimankevin(a)yahoo.com> To: Howard Chu <hyc(a)symas.com> Howard, To answer your initial questions: 1. The aliased entry does exist 2. The backined is ldbm 3. Attached is a sanitized slapd.conf 4. Attached is a sanitized ldif export Here's the output from running slapd (sanitized for sensitive information) without forking (-d 1): > >> dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com> <<< dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com>, <ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => ldbm_back_search dn2entry_r: dn: "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" => dn2id( "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) ====> cache_find_entry_ndn2id("ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com"): 16378 (1 tries) <= dn2id 16378 (in cache) => id2entry_r( 16378 ) ====> cache_find_entry_id( 16378 ) "ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16378 ) 0x82d2068 (cache) search_candidates: base="ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" s=2 d=3 => filter_candidates => list_candidates 0xa0 => filter_candidates => dn2idl( "@ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= filter_candidates 2 => filter_candidates => list_candidates 0xa1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 1 candidates <= equality_candidates 1 <= filter_candidates 1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 idl_free: called with NULL pointer => filter_candidates => list_candidates 0xa0 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 4 candidates <= equality_candidates 4 <= filter_candidates 4 => filter_candidates => equality_candidates => ldbm_cache_open( "uid.dbb", 73, 600 ) <= ldbm_cache_open (cache 4) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 <= list_candidates NULL <= filter_candidates 0 idl_free: called with NULL pointer <= list_candidates 1 <= filter_candidates 1 <= list_candidates 1 <= filter_candidates 1 ====> cache_return_entry_r( 16378 ): returned (0) => id2entry_r( 16400 ) ====> cache_find_entry_id( 16400 ) "uid=test,ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16400 ) 0x82d5580 (cache) dn2entry_r: dn: "ÿÿÐuhH_øP" => dn2id( "ÿÿÐuhH_øP" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= dn2id NOID slapd: dn.c:1148: dnParent: Assertion `( ( ( ( (p[ 0 ]) >= 'a' && (p[ 0 ]) <= 'z' ) || ( (p[ 0 ]) >= 'A' && (p[ 0 ]) <= 'Z' ) ) ) || ( ( (p[ 0 ]) >= '0' && (p[ 0 ]) <= '9' ) ) )' failed. Aborted Let me know if you need anything else. Regards, Kevin Hardiman ----- Original Message ---- From: Howard Chu <hyc(a)symas.com> To: hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, November 8, 2006 9:45:27 PM Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ ------------------------------------------------------------------------ Sponsored Link $200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity - Click now for info <http://www.ratemarketplace.com/forms/form.jsp?ADEL=Os4fVJ19lSwzAOc/zMz/CYLq…> -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --------------080602030800020000070003 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRl CS91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkvdXNy L3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JiYS5zY2hlbWEgCmluY2x1ZGUJL3Vzci9zaGFy ZS9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWEKaW5jbHVkZQkvdXNyL3No YXJlL29wZW5sZGFwL3NjaGVtYS9qYXZhLnNjaGVtYSAKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9rcmI1LWtkYy5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5s ZGFwL3NjaGVtYS9rZXJiZXJvc29iamVjdC5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9taXNjLnNjaGVtYQppbmNsdWRlCS91c3Ivc2hhcmUvb3BlbmxkYXAv c2NoZW1hL25pcy5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9v cGVubGRhcC5zY2hlbWEgCmluY2x1ZGUgL3Vzci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvYXV0 b2ZzLnNjaGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL3NhbWJhLnNj aGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2tvbGFiLnNjaGVtYQpp bmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2V2b2x1dGlvbnBlcnNvbi5zY2hl bWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jYWxlbmRhci5zY2hlbWEK aW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9zdWRvLnNjaGVtYQppbmNsdWRl IC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Ruc3pvbmUuc2NoZW1hCmluY2x1ZGUgL3Vz ci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvZGhjcC5zY2hlbWEKaW5jbHVkZQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9sb2NhbC5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3Nj aGVtYS9tb3ppbGxhQWJQZXJzb25BbHBoYS5zY2hlbWEKaW5jbHVkZSAJL2V0Yy9vcGVubGRh cC9zbGFwZC5hY2Nlc3MuY29uZgoKYWNjZXNzIHRvIGRuLnN1YnRyZWU9ImRjPWV4YW1wbGUs ZGM9Y29tIgogICAgICAgIGJ5IGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4 YW1wbGUsZGM9Y29tIgogICAgICAgIGJ5IHVzZXJzIHJlYWQKICAgICAgICBieSBhbm9ueW1v dXMgcmVhZAoKbGltaXRzIGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4YW1w bGUsZGM9Y29tIgogc2l6ZT11bmxpbWl0ZWQKIHRpbWU9dW5saW1pdGVkCnBpZGZpbGUJCS92 YXIvcnVuL2xkYXAvc2xhcGQucGlkCmFyZ3NmaWxlCS92YXIvcnVuL2xkYXAvc2xhcGQuYXJn cwptb2R1bGVwYXRoCS91c3IvbGliL29wZW5sZGFwClRMU1JhbmRGaWxlICAgICAgICAgICAg L2Rldi9yYW5kb20KVExTQ2lwaGVyU3VpdGUgICAgICAgICBISUdIOk1FRElVTTorU1NMdjIK VExTQ2VydGlmaWNhdGVGaWxlICAgICAgL2V0Yy9zc2wvb3BlbmxkYXAvbGRhcGNlcnQucGVt ClRMU0NlcnRpZmljYXRlS2V5RmlsZSAgIC9ldGMvc3NsL29wZW5sZGFwL2xkYXBrZXkucGVt ClRMU0NBQ2VydGlmaWNhdGVQYXRoICAgL2V0Yy9zc2wvb3BlbmxkYXAvClRMU0NBQ2VydGlm aWNhdGVGaWxlICAgIC9ldGMvc3NsL29wZW5sZGFwL2NhY2VydC5wZW0KVExTVmVyaWZ5Q2xp ZW50IHRyeSAjIChbbmV2ZXJdfGFsbG93fHRyeXxkZW1hbmQpCmxvZ2xldmVsIDI2OAphbGxv dyBiaW5kX3YyCnNhc2wtc2VjcHJvcHMgbm9uZQpkYXRhYmFzZQlsZGJtCnN1ZmZpeAkJImRj PWJsYWRpYW50LGRjPWNvbSIKcm9vdGRuCQkiY249S2V2aW4gSGFyZGltYW4sb3U9UGVvcGxl LGRjPWV4YW1wbGUsZGM9Y29tIgpsYXN0bW9kCQlvbgpkaXJlY3RvcnkJL3Zhci9saWIvbGRh cApjaGVja3BvaW50IDI1NiA1CmluZGV4CW9iamVjdENsYXNzLHVpZCx1aWROdW1iZXIsZ2lk TnVtYmVyLG1lbWJlcnVpZAllcQppbmRleAljbixtYWlsLHN1cm5hbWUsZ2l2ZW5uYW1lCQll cSxzdWJpbml0aWFsCiAK --------------080602030800020000070003 Content-Type: application/octet-stream; name="minimal_export.ldif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minimal_export.ldif" ZG46IG91PVVzZXJzLCBkYz1leGFtcGxlLGRjPWNvbQpvdTogVXNlcnMKb2JqZWN0Q2xhc3M6 IG9yZ2FuaXphdGlvbmFsVW5pdAoKZG46IHVpZD10ZXN0LCBvdT1Vc2VycywgZGM9ZXhhbXBs ZSxkYz1jb20Kc2FtYmFQcmltYXJ5R3JvdXBTSUQ6IFhYWFgKc2FtYmFMTVBhc3N3b3JkOiBY WFhYCmRpc3BsYXlOYW1lOiBLZXZpbiBIYXJkaW1hbgpvYmplY3RDbGFzczogdG9wCm9iamVj dENsYXNzOiBpbmV0T3JnUGVyc29uCm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQKb2JqZWN0 Q2xhc3M6IHNoYWRvd0FjY291bnQKb2JqZWN0Q2xhc3M6IHNhbWJhU2FtQWNjb3VudAp1c2Vy UGFzc3dvcmQ6OiBYWFhYCnNhbWJhTG9nb25UaW1lOiAwCnVpZE51bWJlcjogNTAwCnVpZDog dGVzdApjbjogdGVzdApzYW1iYUxvZ29mZlRpbWU6IDIxNDc0ODM2NDcKc2FtYmFQd2RMYXN0 U2V0OiAxMTYxOTIzMzcwCmxvZ2luU2hlbGw6IC9iaW4vYmFzaApzYW1iYUFjY3RGbGFnczog W1VdCmdpZE51bWJlcjogMTAwCnNhbWJhUHdkTXVzdENoYW5nZTogMTE2NTgxMTM3MApzYW1i YVNJRDogWFhYCnNhbWJhUHdkQ2FuQ2hhbmdlOiAwCnNhbWJhTlRQYXNzd29yZDogWFhYCmdl Y29zOiBLZXZpbiBIYXJkaW1hbgpkZXNjcmlwdGlvbjogS2V2aW4gSGFyZGltYW4KaG9tZURp cmVjdG9yeTogL2hvbWUvdGVzdApzYW1iYUtpY2tvZmZUaW1lOiAyMTQ3NDgzNjQ3CnNuOiBI YXJkaW1hbgoKZG46IG91PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBD b3JlIFNlcnZpY2VzCm9iamVjdENsYXNzOiB0b3AKb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlv bmFsVW5pdAoKZG46IG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhhbXBsZSxkYz1j b20Kb3U6IHNtYgpvYmplY3RDbGFzczogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25h bFVuaXQKCmRuOiBvdT1leGFtcGxlLG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhh bXBsZSxkYz1jb20Kb3U6IGV4YW1wbGUKb2JqZWN0Q2xhc3M6IHRvcApvYmplY3RDbGFzczog b3JnYW5pemF0aW9uYWxVbml0Cgpkbjogb3U9VXNlcnMsb3U9ZXhhbXBsZSxvdT1zbWIsIG91 PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBVc2VycwpvYmplY3RDbGFz czogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKCmRuOiB1aWQ9dGVzdCxv dT1Vc2VycyxvdT1leGFtcGxlLG91PXNtYixvdT1Db3JlIFNlcnZpY2VzLGRjPWV4YW1wbGUs ZGM9Y29tCm9iamVjdENsYXNzOiBhbGlhcwpvYmplY3RjbGFzczogZXh0ZW5zaWJsZU9iamVj dAp1aWQ6IHRlc3QKYWxpYXNlZE9iamVjdE5hbWU6IHVpZD10ZXN0LG91PVVzZXJzLGRjPWV4 YW1wbGUsZGM9Y29tCg== --------------080602030800020000070003--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 2:20 AM +0000 lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() > function, which is assigned at line 522. The next if-then-else block is > checking to see if the module reported an error, at which point 'ok' > would be assigned LDAP_OTHER regardless of what check_password() > returned. A superfluous else block appears after this check, assigning > 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. Howard checked in a fix to HEAD for this last night, please test. --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#4739) Server crashes every time alias is dereferenced
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 5:08 PM +0000 hardimankevin(a)yahoo.com wrote: > --0-1753053770-1163092074=:90949 > Content-Type: text/plain; charset=ascii > Content-Transfer-Encoding: quoted-printable > > Buchan,=0A=0ANot sure what to say - I can reproduce this error with the > Man= driva packages and from source (which leads me to believe it has > nothing to= do with the packaging) with a 100% rate. I had sent Howard > Chu an email l= ast night with much more detail; if you'd like me to > forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message > You should send responses with more detail to the ITS, not to individual people. This allows all developers and other involved to have the full information. --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#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1753053770-1163092074=:90949 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Buchan,=0A=0ANot sure what to say - I can reproduce this error with the Man= driva packages and from source (which leads me to believe it has nothing to= do with the packaging) with a 100% rate. I had sent Howard Chu an email l= ast night with much more detail; if you'd like me to forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message ----=0AFrom: Buchan Milne <bg= milne(a)staff.telkomsa.net>=0ATo: hardimankevin(a)yahoo.com=0ACc: openldap-its@= openldap.org=0ASent: Thursday, November 9, 2006 11:07:10 AM=0ASubject: Re: = (ITS#4739) Server crashes every time alias is dereferenced=0A=0AOn Wednesda= y 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote:=0A> Full_Name: Kev= in Hardiman=0A> Version: 2.3.27=0A> OS: Linux (Mandriva 2007)=0A> URL: ftp:= //ftp.openldap.org/incoming/=0A> Submission from: (NULL) (24.90.130.182)=0A= >=0A>=0A> Using the very simple alias below, OpenLDAP will crash every time= it is=0A> dereferenced:=0A>=0A> dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou= =3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom=0A> objectClass: alias=0A> = objectclass: extensibleObject=0A> uid: test=0A> aliasedObjectName: uid=3Dte= st,ou=3DUsers,dc=3Dexample,dc=3Dcom=0A>=0A> This error has been experience = with OpenLDAP releases 2.3.6 and 2.3.27,=0A> both in the form of provided M= andriva packages. I also have seen a number=0A> of references to this erro= r in previous releases, with no explicit fix. =0A> Please advise.=0A=0A=0AC= an't reproduce:=0A=0A$ ldapsearch -h localhost -LLL -s children -a never -= x -b "ou=3DTest =0AAliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom"=0Adn: uid=3D= bgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass:= alias=0AobjectClass: extensibleObject=0Auid: bgmilne=0AaliasedObjectName: = uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0A=0A$ ldapsea= rch -h localhost -LLL -s children -a always -x -b "ou=3DTest =0AAliases,dc= =3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass=0Adn: uid=3Dbgmilne,ou=3DPeop= le,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass: mailRecipient=0Aobject= Class: person=0AobjectClass: organizationalPerson=0AobjectClass: inetOrgPer= son=0AobjectClass: posixAccount=0AobjectClass: top=0AobjectClass: kerberosS= ecurityObject=0AobjectClass: shadowAccount=0AobjectClass: sambaSamAccount= =0A=0A$ rpm -q openldap-servers=0Aopenldap-servers-2.3.27-1mdv2007.0=0A=0A$= rpm -q openldap-servers --qf "%{PACKAGER}\n"=0ABuchan Milne <bgmilne@mandr= iva.org>=0A=0A=0ARegards,=0ABuchan=0A=0A-- =0ABuchan Milne=0AISP Systems Sp= ecialist - Monitoring/Authentication Team Leader=0AB.Eng,RHCE(8030047890107= 97),LPIC-2(LPI000074592)=0A=0A=0A=0A=0A=0A=0A=0A =0A_______________________= _____________________________________________________________=0ADo you Yaho= o!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.m= ail.yahoo.com --0-1753053770-1163092074=:90949 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt= ;">Buchan, Not sure what to say - I can reproduce this error with th= e Mandriva packages and from source (which leads me to believe it has nothi= ng to do with the packaging) with a 100% rate.  I had sent Howard Chu = an email last night with much more detail; if you'd like me to forward that= I will.     -kph <div style=3D"font-famil= y: times new roman,new york,times,serif; font-size: 12pt;">----- Original M= essage ---- From: Buchan Milne <bgmilne(a)staff.telkomsa.net> To:= hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Thursday= , November 9, 2006 11:07:10 AM Subject: Re: (ITS#4739) Server crashes ev= ery time alias is dereferenced <div>On Wednesday 08 November 2006 21= :18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > V= ersion: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.ope= nldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) >= > > Using the very simple alias below, OpenLDAP will crash eve= ry time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUse= rs,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom > = objectClass: alias > objectclass: extensibleObject > uid: test<= br>> aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom &= gt; > This error has been experience with OpenLDAP releases 2.3.6 and= 2.3.27, > both in the form of provided Mandriva packages. &nbsp= ;I also have seen a number > of references to this error in previous = releases, with no explicit fix. > Please advise. Can't re= produce: $ ldapsearch -h localhost -LLL -s children -a never &n= bsp;-x -b "ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3D= Test Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias ob= jectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgm= ilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom $ ldapsearch -h = localhost -LLL -s children -a always  -x -b "ou=3DTest Aliase= s,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou= =3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient<= br>objectClass: person objectClass: organizationalPerson objectClass:= inetOrgPerson objectClass: posixAccount objectClass: top objectCl= ass: kerberosSecurityObject objectClass: shadowAccount objectClass: s= ambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-= 1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan = Milne <bgmilne(a)mandriva.org> Regards, Buchan -- = Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-= 2(LPI000074592) </div></div> </div></div> =0A=0A<hr size=3D1>Every= one is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D45083/*http://a= dvision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</a></bo= dy></html> --0-1753053770-1163092074=:90949--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by bgmilne＠staff.telkomsa.net 09 Nov '06

09 Nov '06

--nextPart2681002.ZbxIqWnAlZ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3D= example,dc=3Dcom > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, > both in the form of provided Mandriva packages. I also have seen a number > of references to this error in previous releases, with no explicit fix.=20 > Please advise. Can't reproduce: $ ldapsearch -h localhost -LLL -s children -a never -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias objectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc= =3Dcom $ ldapsearch -h localhost -LLL -s children -a always -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: kerberosSecurityObject objectClass: shadowAccount objectClass: sambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan Milne <bgmilne(a)mandriva.org> Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart2681002.ZbxIqWnAlZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFU1IvrJK6UGDSBKcRAhkQAKDCpV5W+plszHrf/GIqkx2yMcTtwQCePs67 JaAwrB9eaYnzEcK7uS41ZEo= =4WpH -----END PGP SIGNATURE----- --nextPart2681002.ZbxIqWnAlZ--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hyc＠symas.com 08 Nov '06

08 Nov '06

hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4741) ppolicy.c improperly discards return value of check_password() function
by lsherida＠nccs.nasa.gov 08 Nov '06

08 Nov '06

Full_Name: Lee Sheridan Version: 2.3.27 OS: Debian GNU/Linux (etch) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.168.13.7) In servers/slapd/overlays/ppolicy.c, check_password_quality function, at line 530, the value of the 'ok' variable is discarded by unconditionally assigning it the value LDAP_SUCCESS. The variable is the return code of the user-defined check_password() function, which is assigned at line 522. The next if-then-else block is checking to see if the module reported an error, at which point 'ok' would be assigned LDAP_OTHER regardless of what check_password() returned. A superfluous else block appears after this check, assigning 'ok' to LDAP_SUCCESS. It works fine for me if I remove the else block. Thanks,

1 0

(ITS#4740) SASL bind assert
by hyc＠OpenLDAP.org 08 Nov '06

08 Nov '06

Full_Name: Howard Chu Version: all < 2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Apparently this bug was discovered by Evgeny Legerov but was not previously reported to anyone on the Project. The bug is now fixed in HEAD and RE23. Performing a SASL Bind with an authcid longer than 255 characters, with a space as the 255th character, will cause the length of the normalized name to be computed incorrectly, failing to take into account the escaping of the space character. (The SASL Bind code truncates all incoming names longer than 255 to exactly 255 characters.) This triggers an assert in libldap because the resulting string length doesn't match what we expected it to be. The fix is in libldap/getdn.c rev 1.134. The MITRE CVE record for this bug is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5779

1 0

(ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 08 Nov '06

08 Nov '06

Full_Name: Kevin Hardiman Version: 2.3.27 OS: Linux (Mandriva 2007) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.90.130.182) Using the very simple alias below, OpenLDAP will crash every time it is dereferenced: dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com objectClass: alias objectclass: extensibleObject uid: test aliasedObjectName: uid=test,ou=Users,dc=example,dc=com This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in the form of provided Mandriva packages. I also have seen a number of references to this error in previous releases, with no explicit fix. Please advise. Kevin Hardiman

1 0

Re: (ITS#4738) hdb livelock
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Please visit > https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for > an updated backtrace. This one almost looks like it has lock contention, > and a writewaiter assert is notably missing... The trace shows several threads backing off because they think some other thread is about to read the entry from the database. At a guess, none of them is actually going to perform the database read. Most likely a lock is missing here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Please visit https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for an updated backtrace. This one almost looks like it has lock contention, and a writewaiter assert is notably missing... I'm going to rm the bad link, it can only hurt people. On Tue, 7 Nov 2006, Aaron Richton wrote: > Sigh. As may be obvious to anybody unfortunate enough to look at the link, I > seem to have gotten my core files confused. I have a bunch of db_stat -CA > done properly, but the backtrace for this may be lost to the bit bucket. I'll > poke around my systems and see what I can find, but I think it might be > nothing. A syslog of "waiting for 1027 threads to terminate" might be the > only other durable evidence. >

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Sigh. As may be obvious to anybody unfortunate enough to look at the link, I seem to have gotten my core files confused. I have a bunch of db_stat -CA done properly, but the backtrace for this may be lost to the bit bucket. I'll poke around my systems and see what I can find, but I think it might be nothing. A syslog of "waiting for 1027 threads to terminate" might be the only other durable evidence.

1 0

(ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28+4720 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock.txt Submission from: (NULL) (128.6.31.137) See also ITS#4720, although this is slightly different. hdb livelock (CPU 100% gunned) on 2.3.28 with patch for ITS #4720 (syncprov.c 1.161 -> 1.162 diff). See URL for backtrace and db_stat -CA of the database on threads t@13 and t@16, which (if I'm reading correctly) are the affected ones. I have the db_stat -CA of the other backends saved if I misread, and the core file available if variables are needed. Aside, I know you're looking for RE23 testing, I was kicking the tires of that and about to put it up when this happened. Soon I'll be there, regardless of how this turns out, due to writewaiter concern.

1 0

Re: (ITS#4737) "overlay not found"
by ando＠sys-net.it 07 Nov '06

07 Nov '06

mmollet(a)westar.com wrote: > Full_Name: Matthieu Mollet > Version: 2.2.13 > OS: Centos 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.45.242.10) > > > Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that > comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd > slapd fails with "overlay smbk5pwd not found" > the syntax "<keyword> = <value>" has never been implemented in OpenLDAP software; the keyword "module" has never been supported as well. I suggest you read at least slapd.conf(5) (but I suspect you need to read more) before considering the possibility of a software bug. 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

Re: (ITS#4737) "overlay not found"
by Kurt＠OpenLDAP.org 07 Nov '06

07 Nov '06

At 09:19 AM 11/7/2006, mmollet(a)westar.com wrote: >Full_Name: Matthieu Mollet >Version: 2.2.13 >OS: Centos 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (208.45.242.10) > > >Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that >comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd >slapd fails with "overlay smbk5pwd not found" While there is no indication that this behavior is due to a bug in OpenLDAP Software and 2.2 is Historic, there seems this report should be closed. If you believe this behavior due to a bug in OpenLDAP Software, I suggest you duplicate it in the latest 2.3 release and then file a new bug report that elaborates on why you believe the behavior is due to a bug in OpenLDAP Software.

1 0

(ITS#4737) "overlay not found"
by mmollet＠westar.com 07 Nov '06

07 Nov '06

Full_Name: Matthieu Mollet Version: 2.2.13 OS: Centos 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.45.242.10) Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd slapd fails with "overlay smbk5pwd not found"

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 06 Nov '06

06 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. I've sync'd the connection manager in RE23 with HEAD. Please test RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 06 Nov '06

06 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. There have been no changes to the connection management since 2.3.27, so it makes sense that the traces look the same. A number of fixes have gone into HEAD along these lines, but they haven't been backported to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4736) writewaiter == 1 in connection_destroy
by richton＠nbcs.rutgers.edu 06 Nov '06

06 Nov '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt Submission from: (NULL) (68.196.250.61) 822 assert( c->c_writewaiter == 0); Unfortunately writewaiter == 1, the assertion catches, byebye... This happened earlier with 2.3.27 (see https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt advised upgrading to 2.3.28, which was running when this caught today. See https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the 2.3.28 trace, not that it looks all too different.

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 06 Nov '06

06 Nov '06

--On Tuesday, November 07, 2006 12:35 AM +0000 quanah(a)stanford.edu wrote: > I've finally figured out how to reproduce this -- The problem is related > to the log purging done by access log. Here is what I did: After applying the commit to HEAD to my source, behavior after log purge was correct. --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#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 06 Nov '06

06 Nov '06

I've finally figured out how to reproduce this -- The problem is related to the log purging done by access log. Here is what I did: Make changes to the database, that were replicated. Everything is happy. Shut down slapd, modify the logpurge parameter so that log purging is done. Restart slapd Verified that log purging was done, and that everything was still happily in sync. Stop slapd, restart slapd Now the access log DB has generated a new CSN that is in the future of the suffix stored CSN. So it appears that somehow the logpurge operation either causes a new contextCSN to be written at the time the server is shut down, or it erases the contextCSN held by the accesslog db. Now, this is when I restarted slapd: Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd However, the contextCSN that was generated is: contextCSN: 20061107002625Z#000000#00#000000 This matches the time at which I started slapd when log purging was run: Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd so I'd say that when log purge is run, it resets the contextCSN in the accesslog DB to the time at which slapd last started... --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#4734) Segmentation fault
by hyc＠symas.com 06 Nov '06

06 Nov '06

Christopher Moore wrote: >> This trace indicates that an attribute in the given entry had NULL for >> its AttributeDescription, which is pretty much a "this-can't-happen" >> situation. It would probably be useful to look at the contents of the >> Entry e in frame 2, and all of its attributes. How was this database >> created, how was the entry created? >> > > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the > database was created by open-xchange. > Here is entry e in frame 2. I hope this is what you are after: > (gdb) frame 2 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > 797 for(a = attrs_find( e->e_attrs, desc ); > (gdb) print *e > $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 > "c=open-xchange,dc=org"}, > e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, > e_ocflags = 0, e_bv = { > bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, > e_private = 0x8265e90} > (gdb) Apparently you are using the OpenLDAP 2.2 database files with OpenLDAP 2.3. This is not supported since the database format changed between 2.2 and 2.3; you have to export with 2.2 slapcat and import with 2.3 slapadd as described in the docs on upgrading. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

RE: (ITS#4734) Segmentation fault
by chris＠linuxepos.com 06 Nov '06

06 Nov '06

> chris(a)linuxepos.com wrote: > > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > > (gdb) where > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) > at > > filterentry.c:797 > > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:853 > > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:355 > > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:217 > > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) > at > > connection.c:1307 > > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at > tpool.c:478 > > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > > (gdb) > > This trace indicates that an attribute in the given entry had NULL for > its AttributeDescription, which is pretty much a "this-can't-happen" > situation. It would probably be useful to look at the contents of the > Entry e in frame 2, and all of its attributes. How was this database > created, how was the entry created? > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the database was created by open-xchange. Here is entry e in frame 2. I hope this is what you are after: (gdb) frame 2 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 797 for(a = attrs_find( e->e_attrs, desc ); (gdb) print *e $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 "c=open-xchange,dc=org"}, e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, e_ocflags = 0, e_bv = { bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, e_private = 0x8265e90} (gdb) _________________________________________________________________________________ Scanned by an Igaware Box - protecting computers from viruses, spam, spyware and other Internet junk. For more information visit http://www.igaware.com/security.html _________________________________________________________________________________

1 0

Re: (ITS#4735) configure choice of ODBC
by ando＠sys-net.it 06 Nov '06

06 Nov '06

rk(a)owen.sj.ca.us wrote: > Full_Name: R.K. Owen > Version: HEAD > OS: linux > URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch > Submission from: (NULL) (66.87.79.68) > > > When using the back-sql with the Oracle XE DB, the Oracle ODBC library > libsqora.so.10.1 was designed to be linked against the unixODBC interface > library instead of the iODBC interface library. This can be demonstrated by > using the unixODBC isql tool which will allow successful interactive querying > of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd > -d 1' the daemon will quit with an error claiming: > Message: [iODBC][Driver Manager] > /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: > undefined symbol: bcuMsgBoxError > > The cause for this is that the configure script will first search for iodbc, > then odbc, and thus cause slapd to be built against the iodbc library. > By adding the -with-odbc option the configure script will allow the > administrator to choose which library to use in a flexible way: > > --with-odbc=iodbc # current default (-liodbc) > --with-odbc=odbc # try -lodbc > --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library > > The changes have been made to the source configure.in file and uploaded as a > patch. > > The patch is not acceptable, since it requires to specify the desired OBDC support, which is counter-intuitive, as most of the RDBMS have drivers or allow to use drivers for both implementations of ODBC. However, your need is clear. I've designed a different fix, which requires to set --with-odbc to the preferred sequence of ODBCs to try (iodbc | unixodbc), while the default (auto) tries the original sequence. It is now committed to HEAD; 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#4735) configure choice of ODBC
by rk＠owen.sj.ca.us 06 Nov '06

06 Nov '06

Full_Name: R.K. Owen Version: HEAD OS: linux URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch Submission from: (NULL) (66.87.79.68) When using the back-sql with the Oracle XE DB, the Oracle ODBC library libsqora.so.10.1 was designed to be linked against the unixODBC interface library instead of the iODBC interface library. This can be demonstrated by using the unixODBC isql tool which will allow successful interactive querying of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd -d 1' the daemon will quit with an error claiming: Message: [iODBC][Driver Manager] /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: undefined symbol: bcuMsgBoxError The cause for this is that the configure script will first search for iodbc, then odbc, and thus cause slapd to be built against the iodbc library. By adding the -with-odbc option the configure script will allow the administrator to choose which library to use in a flexible way: --with-odbc=iodbc # current default (-liodbc) --with-odbc=odbc # try -lodbc --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library The changes have been made to the source configure.in file and uploaded as a patch.

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 06 Nov '06

06 Nov '06

chris(a)linuxepos.com wrote: > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > (gdb) where > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:853 > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:355 > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:217 > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) at > connection.c:1307 > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at tpool.c:478 > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > (gdb) This trace indicates that an attribute in the given entry had NULL for its AttributeDescription, which is pretty much a "this-can't-happen" situation. It would probably be useful to look at the contents of the Entry e in frame 2, and all of its attributes. How was this database created, how was the entry created? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4734) Segmentation fault
by chris＠linuxepos.com 06 Nov '06

06 Nov '06

Full_Name: Christopher Moore Version: 2.3.27 OS: Linux 2.4.31 URL: Submission from: (NULL) (62.49.7.243) Hi, I'm recieving a repeatable Segmentation fault when I try to connect to the ldap server as indicated with this excerpt of gdb trace: Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so Reading symbols from /usr/local/lib/libsasl2.so.2...done. Loaded symbols for /usr/local/lib/libsasl2.so.2 Reading symbols from /usr/local/lib/libssl.so.0.9.7...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.7 Reading symbols from /usr/local/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/local/lib/libcrypto.so.0.9.7 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/local/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/local/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/local/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/local/lib/sasl2/libotp.so.2...done. Loaded symbols for /usr/lib/sasl2/libotp.so.2 Reading symbols from /usr/local/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/local/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/local/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { (gdb) where #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:853 #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:355 #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:217 #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) at connection.c:1307 #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at tpool.c:478 #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 #9 0x4038d4a7 in __clone () from /lib/libc.so.6 (gdb)

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by ghenry＠suretecsystems.com 05 Nov '06

05 Nov '06

<quote who="daveh(a)ci.com.au"> >> Do you mind if I do some clean up on it? >> >> Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and >> assumptions been made with opening files and system commands etc. > > You might also highlight the fact that it seems to require at least 5.8 > (due to the "qw()" lists). Well, according to the method I always use to check that, Perl::MinimumVersion, we get: perlver ldap-stats.pl -------------------------------------------- | file | explicit | syntax | external | | -------------------------------------------- | | ldap-stats.pl | ~ | v5.6.0 | n/a | | -------------------------------------------- | | Minimum explicit version : ~ | | Minimum syntax version : v5.6.0 | | Minimum version of perl : v5.6.0 | -------------------------------------------- > > I also don't like hard-wiring "/usr/bin/perl", as the system Perls are > rarely up to date. My favourite technique is: > > #! /usr/bin/env perl -w > > which finds Perl from $PATH. > > Or just hard-wire "/usr/local/bin/perl" and let the sysadmin sort it > out... Sounds good. env method is best I suppose, but there are others as listed at: http://perldoc.perl.org/perlrun.html#DESCRIPTION Almost finished that cleanup. It's taken a bit longer than expected. Thanks. -- 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

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by daveh＠ci.com.au 05 Nov '06

05 Nov '06

> Do you mind if I do some clean up on it? > > Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and > assumptions been made with opening files and system commands etc. You might also highlight the fact that it seems to require at least 5.8 (due to the "qw()" lists). I also don't like hard-wiring "/usr/bin/perl", as the system Perls are rarely up to date. My favourite technique is: #! /usr/bin/env perl -w which finds Perl from $PATH. Or just hard-wire "/usr/local/bin/perl" and let the sysadmin sort it out... -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

(ITS#4733) back-config should populate defaults
by hyc＠OpenLDAP.org 05 Nov '06

05 Nov '06

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc If a minimal LDIF is slapadd'd to create the slapd configuration, any parameters that are not specified on input will take on their default values. However, these defaults will not be present in the config entries and will not be visible upon subsequent slapcat/ldapsearch. It would be nicer if after each entry is loaded from slapd.d and parsed, the entire entry is regenerated internally, with all defaults populated.

1 0

Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com 05 Nov '06

05 Nov '06

It seems you can close this ITS. I followed Howard's advice and started over with a new CVS working dir. Ciao, Michael.

1 0

Re: (ITS#4731) Build without modules fails
by michael＠stroeder.com 05 Nov '06

05 Nov '06

Howard Chu wrote: > A fresh pull (as of 2 minutes ago) builds fine for me. > > If the problem you're running into is that distclean left something from > your previous build, then you need to tell us what your previous build > invocation was as well. > > I suggest you try building with a separate object directory, so that you > can just rm -rf the object tree when you want a fresh build. Ok, it seems the build worked with a fresh CVS working dir. You can close this ITS. I'll file another one for make distclean though... Ciao, Michael.

1 0

Re: (ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Nov '06

04 Nov '06

Still coring in 2.3.28 + connection code from HEAD. Backtrace: (gdb) info threads 10 process 25180 0x00002ae257d12e2c in pthread_join () from /lib/libpthread.so.0 9 process 25184 0x00002ae257ef2b2c in epoll_wait () from /lib/libc.so.6 8 process 25186 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 25188 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 25189 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 25190 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 25212 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 25213 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 25216 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 25185 0x00002ae257ed27dd in fnmatch () from /lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (process 25185)]#7 0x00000000004457f6 in slap_acl_get (a=Variable "a" is not available. ) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) bt #0 0x00002ae257ed27dd in fnmatch () from /lib/libc.so.6 #1 0x00002ae257eddd22 in re_exec () from /lib/libc.so.6 #2 0x00002ae257edb70b in re_exec () from /lib/libc.so.6 #3 0x00002ae257ed9d83 in re_exec () from /lib/libc.so.6 #4 0x00002ae257ed8526 in re_exec () from /lib/libc.so.6 #5 0x00002ae257ed7e83 in re_exec () from /lib/libc.so.6 #6 0x00002ae257ed74a6 in regexec () from /lib/libc.so.6 #7 0x00000000004457f6 in slap_acl_get (a=Variable "a" is not available. ) at acl.c:874 #8 0x0000000000445eb3 in slap_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:221 #9 0x0000000000447dd1 in fe_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:318 #10 0x0000000000444620 in access_allowed_mask (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x0) at acl.c:429 #11 0x00000000004356f1 in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x40ffeee0) at result.c:894 #12 0x00002ae2596f4894 in hdb_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:878 #13 0x0000000000429502 in fe_op_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:355 #14 0x0000000000429d42 in do_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:217 #15 0x0000000000427a0f in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1109 #16 0x0000000000427dd4 in connection_read_thread (ctx=0x40fff030, argv=Variable "argv" is not available. ) at connection.c:1236 (gdb) frame 7 #7 0x00000000004457f6 in slap_acl_get (a=Variable "a" is not available. ) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) frame 8 #8 0x0000000000445eb3 in slap_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:221 221 while ( ( a = slap_acl_get( a, &count, op, e, desc, val, (gdb) frame 9 #9 0x0000000000447dd1 in fe_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:318 318 rc = slap_access_allowed( op, e, desc, val, access, state, maskp ); (gdb) frame 10 #10 0x0000000000444620 in access_allowed_mask (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x0) at acl.c:429 429 ret = frontendDB->bd_info->bi_access_allowed( op, e, (gdb) frame 11 #11 0x00000000004356f1 in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x40ffeee0) at result.c:894 894 if ( ! access_allowed( op, rs->sr_entry, (gdb) frame 12 #12 0x00002ae2596f4894 in hdb_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:878 878 rs->sr_err = send_search_entry( op, rs ); (gdb) frame 13 #13 0x0000000000429502 in fe_op_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:355 355 (op->o_bd->be_search)( op, rs ); (gdb) frame 14 #14 0x0000000000429d42 in do_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:217 217 rs->sr_err = frontendDB->be_search( op, rs ); (gdb) frame 15 #15 0x0000000000427a0f in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1109 1109 rc = (*(opfun[opidx]))( op, &rs ); (gdb) frame 16 #16 0x0000000000427dd4 in connection_read_thread (ctx=0x40fff030, argv=Variable "argv" is not available. ) at connection.c:1236 1236 rc = (long)connection_operation( ctx, cri.op ); (gdb) frame 17 #17 0x00002ae2572c5724 in ldap_int_thread_pool_wrapper (xpool=0x2ae258ac0080) at tpool.c:478 478 ctx->ltc_start_routine(ltc_key, ctx->ltc_arg); (gdb) frame 8 #8 0x0000000000445eb3 in slap_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:221 221 while ( ( a = slap_acl_get( a, &count, op, e, desc, val, (gdb) print *a $2 = {acl_filter = 0x0, acl_dn_style = ACL_STYLE_CHILDREN, acl_dn_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_dn_pat = { bv_len = 18, bv_val = 0x2ae2586ce858 "dc=stanford,dc=edu"}, acl_attrs = 0x2ae258640080, acl_attrval_mr = 0x0, acl_attrval_style = ACL_STYLE_REGEX, acl_attrval_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_attrval = {bv_len = 0, bv_val = 0x0}, acl_access = 0x2ae258ae9e20, acl_next = 0x2ae258ac55c0} --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#4732) slapd.d man page missing
by hyc＠symas.com 03 Nov '06

03 Nov '06

This is already ITS#3812. This ITS will be closed as a dup. ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Not listed at: > > http://www.openldap.org/software/man.cgi?query=(5)&sektion=&apropos=1&manpa… > > As mentioned at: > > http://www.openldap.org/doc/admin23/slapdconf2.html > > Thanks. > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4732) slapd.d man page missing
by ghenry＠suretecsystems.com 03 Nov '06

03 Nov '06

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Not listed at: http://www.openldap.org/software/man.cgi?query=(5)&sektion=&apropos=1&manpa… As mentioned at: http://www.openldap.org/doc/admin23/slapdconf2.html Thanks.

1 0

Re: (ITS#4731) Build without modules fails
by hyc＠symas.com 03 Nov '06

03 Nov '06

A fresh pull (as of 2 minutes ago) builds fine for me. If the problem you're running into is that distclean left something from your previous build, then you need to tell us what your previous build invocation was as well. I suggest you try building with a separate object directory, so that you can just rm -rf the object tree when you want a fresh build. e.g. mkdir head cd head cvs co ... cd .. mkdir obj cd obj ../head/configure ... make depend; make Personally I have never used "make distclean" ... michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: SuSE Linux 10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.30.198) > > > I tried to build without modules (after make distclean): > > ./configure \ > --prefix=${PREFIX} \ > --enable-dynamic \ > --enable-modules=no \ > --enable-backends=yes \ > --enable-overlays=yes \ > --enable-cleartext \ > --enable-crypt=yes \ > --enable-debug=yes \ > --enable-kpasswd=yes \ > --enable-lmpasswd=yes \ > --enable-rewrite=yes \ > --enable-rlookups=yes \ > --enable-slapi=yes \ > --enable-slp=yes \ > --enable-spasswd=yes \ > --enable-wrappers=no \ > --enable-aci=yes \ > --with-cyrus-sasl=yes \ > --with-kerberos=yes \ > --with-readline=yes \ > --with-threads=yes \ > --with-tls=yes > > > But build fails: > > cc -g -O0 -I../../../include -I../../../include -I.. -I./.. -I./../slapi > -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c version.c > -o version.o > ar ruv libback_monitor.a `echo init.lo search.lo compare.lo modify.lo bind.lo > operational.lo cache.lo entry.lo backend.lo database.lo thread.lo conn.lo rww.lo > log.lo operation.lo sent.lo listener.lo time.lo overlay.lo | sed 's/\.lo/.o/g'` > version.o > ar: creating libback_monitor.a > ar: init.o: No such file or directory > make[3]: *** [libback_monitor.a] Error 1 > make[3]: Leaving directory > `/home/michael/src/openldap-HEAD/ldap/servers/slapd/back-monitor' > make[2]: *** [.backend] Error 1 > make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' > make: *** [all-common] Error 1 > > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4731) Build without modules fails
by michael＠stroeder.com 03 Nov '06

03 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.30.198) I tried to build without modules (after make distclean): ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-modules=no \ --enable-backends=yes \ --enable-overlays=yes \ --enable-cleartext \ --enable-crypt=yes \ --enable-debug=yes \ --enable-kpasswd=yes \ --enable-lmpasswd=yes \ --enable-rewrite=yes \ --enable-rlookups=yes \ --enable-slapi=yes \ --enable-slp=yes \ --enable-spasswd=yes \ --enable-wrappers=no \ --enable-aci=yes \ --with-cyrus-sasl=yes \ --with-kerberos=yes \ --with-readline=yes \ --with-threads=yes \ --with-tls=yes But build fails: cc -g -O0 -I../../../include -I../../../include -I.. -I./.. -I./../slapi -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c version.c -o version.o ar ruv libback_monitor.a `echo init.lo search.lo compare.lo modify.lo bind.lo operational.lo cache.lo entry.lo backend.lo database.lo thread.lo conn.lo rww.lo log.lo operation.lo sent.lo listener.lo time.lo overlay.lo | sed 's/\.lo/.o/g'` version.o ar: creating libback_monitor.a ar: init.o: No such file or directory make[3]: *** [libback_monitor.a] Error 1 make[3]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd/back-monitor' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by peter＠adpm.de 03 Nov '06

03 Nov '06

Hi, On Thursday, 2. November 2006 20:42, Quanah Gibson-Mount wrote: > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Granted ! Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by ando＠sys-net.it 03 Nov '06

03 Nov '06

> This overlay provides simple support for allowedAttributes and > allowedAttributesEffective, a (somewhat broken) AD feature that is > intended to > help GUIs into determining, based on the current objectClass values of an > object, what attributes would comply with the schema (without distinction > between "allowed" and "required"), by listing them in "allowedAttributes", This could be made more useful by providing ";x-allowed" or ";x-required" options to "allowedAttributes", so that GUI developers can easily handle mandatory vs. optional fields. However, I bet this would break existing applications that make use of those attributes. 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#4730) Overlay that generates operational attributes to support GUI interaction
by ando＠sys-net.it 03 Nov '06

03 Nov '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2006-11-03-allowed.c Submission from: (NULL) (81.72.89.40) Submitted by: ando This overlay provides simple support for allowedAttributes and allowedAttributesEffective, a (somewhat broken) AD feature that is intended to help GUIs into determining, based on the current objectClass values of an object, what attributes would comply with the schema (without distinction between "allowed" and "required"), by listing them in "allowedAttributes", and, furthermore, by providing a hint to what of those values could be effectively added by the current connection, by listing them in "allowedAttributesEffective". This is broken since it doesn't consider the possibility of value-dependent ACLs, so it should really be considered just a hint, while the "allowedAttributes" could really be computed starting from the schema definition, which remains the recommended way to solve the problem So this overlay should really be considered only food for thought as a starting base for a tighter integration of OpenLDAP into Samba4. There's minimal support for "allowedChildClasses" and "allowedChildClassesEffective", whose definition is absolutely obscure to me, as I believe the only classes that can be added to an existing object are all the AUXILIARY ones, while considering what are effectively allowed implies getting into value-dependent ACLs. Some discussion can be found here (follow the thread) <http://www.redhat.com/archives/fedora-directory-devel/2006-November/msg0000…> while portions of the schema definition has been taken from here <http://www.redhat.com/archives/fedora-directory-devel/2006-August/msg00007.…> p.

1 0

Re: (ITS#4729) Build fails in dynlist.c
by ando＠sys-net.it 02 Nov '06

02 Nov '06

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE23 > OS: SuSE Linux 10.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.4.222) > > > dynlist.c: In function 'dynlist_initialize': > dynlist.c:1401: error: 'BackendInfo' has no member named 'bi_obsolete_names' > make[3]: *** [dynlist.lo] Error 1 > make[3]: Leaving directory > `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd/overlays' > make[2]: *** [dynamic_overlays] Error 2 > make[2]: Leaving directory > `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory > `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers' > make: *** [all-common] Error 1 > My fault: some -devel stuff slipped in re23; you should remove the lines #elif SLAPD_OVER_DYNGROUP != SLAPD_MOD_STATIC #define TAKEOVER_DYNGROUP at the top of dynlist.c. I'm about to fix re23. 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#3460) Adding LDAP statistics script to contrib directory
by quanah＠stanford.edu 02 Nov '06

02 Nov '06

--On Thursday, November 02, 2006 11:07 PM +0000 ghenry(a)suretecsystems.com wrote: > <quote who="quanah(a)stanford.edu"> >> I'd like to see this script included as well. There were two concern >> listed in the ITS: >> >> # 1) Awaiting new version with proper copyright notice. >> # 2) Need information about incorporated patches to ensure all who have >> # IPR >> in this >> script have made appropriate license grants. >> >> I know #1 has been addressed. >> >> As for #2, I grant such a release for the work I've done on the script. >> >> Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release >> for the work you've done with this script? :) > > Do you mind if I do some clean up on it? > > Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and > assumptions been made with opening files and system commands etc. > > I'll have a patch tomorrow. > > You can take it or leave it ;-) I don't mind at all, just make sure you get the very latest version. ;) --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

(ITS#4729) Build fails in dynlist.c
by michael＠stroeder.com 02 Nov '06

02 Nov '06

Full_Name: Michael Ströder Version: RE23 OS: SuSE Linux 10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.4.222) dynlist.c: In function 'dynlist_initialize': dynlist.c:1401: error: 'BackendInfo' has no member named 'bi_obsolete_names' make[3]: *** [dynlist.lo] Error 1 make[3]: Leaving directory `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd/overlays' make[2]: *** [dynamic_overlays] Error 2 make[2]: Leaving directory `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers' make: *** [all-common] Error 1

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by ghenry＠suretecsystems.com 02 Nov '06

02 Nov '06

<quote who="quanah(a)stanford.edu"> > I'd like to see this script included as well. There were two concern > listed in the ITS: > > #1) Awaiting new version with proper copyright notice. > #2) Need information about incorporated patches to ensure all who have IPR > in this > script have made appropriate license grants. > > I know #1 has been addressed. > > As for #2, I grant such a release for the work I've done on the script. > > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Do you mind if I do some clean up on it? Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and assumptions been made with opening files and system commands etc. I'll have a patch tomorrow. You can take it or leave it ;-) Gavin. http://perlmonks.org/?node_id=386673 http://www.suretecsystems.com/

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by daveh＠ci.com.au 02 Nov '06

02 Nov '06

On Thu, 2 Nov 2006, Quanah Gibson-Mount wrote: > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a > release for the work you've done with this script? :) Sure; fame at last :-) -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by peter.schober＠univie.ac.at 02 Nov '06

02 Nov '06

quanah et al., * Quanah Gibson-Mount <quanah(a)stanford.edu> [2006-11-02 20:42]: > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a > release for the work you've done with this script? :) go ahead. actually I though about rewriting it not just once before (it's rather spaghetti-ish, imho) but too many other things keep popping up. regards, -p.schober -- peter.schober(a)univie.ac.at - vienna university computer center Universitaetsstrasse 7, A-1010 Wien, Austria/Europe Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by tlyons＠ivenue.com 02 Nov '06

02 Nov '06

On Thu, Nov 02, 2006 at 11:42:32AM -0800, Quanah Gibson-Mount wrote: >I'd like to see this script included as well. There were two concern >listed in the ITS: > >#1) Awaiting new version with proper copyright notice. >#2) Need information about incorporated patches to ensure all who have IPR >in this >script have made appropriate license grants. > >I know #1 has been addressed. > >As for #2, I grant such a release for the work I've done on the script. > >Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release >for the work you've done with this script? :) I do, though I don't think my work amounts to much more than one item in a foreach loop. But I do. -- Regards... Todd when you shoot yourself in the foot, just because you are so neurally broken that the signal takes years to register in your brain, it does not mean that your foot does not have a hole in it. --Randy Bush Linux kernel 2.6.17-5mdv 3 users, load average: 0.00, 0.04, 0.13

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by quanah＠stanford.edu 02 Nov '06

02 Nov '06

I'd like to see this script included as well. There were two concern listed in the ITS: #1) Awaiting new version with proper copyright notice. #2) Need information about incorporated patches to ensure all who have IPR in this script have made appropriate license grants. I know #1 has been addressed. As for #2, I grant such a release for the work I've done on the script. Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release for the work you've done with this script? :) --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#4728) accesslog dont write attributes removing
by hyc＠symas.com 02 Nov '06

02 Nov '06

ando(a)sys-net.it wrote: > Sounds odd; can you provide a log at level "packets" of the request with > php? I suspect it's doing something like > > dn: uid=user,ou=people,dc=example > changetype: modify > replace: autoreply > - > This was the problem, it was ignoring Replace when no values were provided. Fixed now in HEAD and RE23. > or > > dn: uid=user,ou=people,dc=example > changetype: modify > delete: autoreply > autoreply: TRUE > - > > which, although semantically equivalent to what you tried, could be handled differently by acesslog(and that would be a bug) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by ando＠sys-net.it 02 Nov '06

02 Nov '06

surnu(a)alkohol.ee wrote: > i made some test and found that if i use ldapmodify > ldapmodify -x -W -ZZ -H 'ldap://example' -D "cn=admin,dc=example" > > dn: uid=user,ou=people,dc=example > changetype: modify > add: autoreply > autoreply: TRUE > modifying entry "uid=user,ou=people,dc=example" > > dn: uid=user,ou=people,dc=example > changetype: modify > delete: autoreply > modifying entry "uid=user,ou=people,dc=example" > > and accesslog shows everything correct > > dn: reqStart=20061102130447.000000Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102130447.000000Z > reqEnd: 20061102130447.000001Z > reqType: modify > reqSession: 153 > reqAuthzID: cn=admin,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: autoReply:+ TRUE > reqMod: entryCSN:= 20061102130447Z#000000#00#000000 > reqMod: modifiersName:= cn=admin,dc=example > reqMod: modifyTimestamp:= 20061102130447Z > entryUUID: 7658ab48-febe-102a-9f6c-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102130447Z > entryCSN: 20061102130447Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102130447Z > > dn: reqStart=20061102130558.000000Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102130558.000000Z > reqEnd: 20061102130558.000001Z > reqType: modify > reqSession: 153 > reqAuthzID: cn=admin,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: autoReply:- > reqMod: entryCSN:= 20061102130558Z#000000#00#000000 > reqMod: modifiersName:= cn=admin,dc=example > reqMod: modifyTimestamp:= 20061102130558Z > entryUUID: a041e758-febe-102a-9f6d-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102130558Z > entryCSN: 20061102130558Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102130558Z > > but if i do same thing with phpldapadmin or any other php application i > get acceslog > > dn: reqStart=20061102131503.000002Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102131503.000002Z > reqEnd: 20061102131503.000003Z > reqType: modify > reqSession: 180 > reqAuthzID: uid=user,ou=people,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: autoReply:+ TRUE > reqMod: entryCSN:= 20061102131503Z#000000#00#000000 > reqMod: modifiersName:= uid=user,ou=people,dc=example > reqMod: modifyTimestamp:= 20061102131503Z > entryUUID: e55e6432-febf-102a-9f70-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102131503Z > entryCSN: 20061102131503Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102131503Z > > dn: reqStart=20061102131511.000002Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102131511.000002Z > reqEnd: 20061102131511.000003Z > reqType: modify > reqSession: 182 > reqAuthzID: uid=user,ou=people,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: entryCSN:= 20061102131511Z#000000#00#000000 > reqMod: modifiersName:= uid=user,ou=people,dc=example > reqMod: modifyTimestamp:= 20061102131511Z > entryUUID: ea4cd596-febf-102a-9f71-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102131511Z > entryCSN: 20061102131511Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102131511Z > > and if using ldap admin (http://ldapadmin.sourceforge.net/) then > accesslog is also correct. > Sounds odd; can you provide a log at level "packets" of the request with php? I suspect it's doing something like dn: uid=user,ou=people,dc=example changetype: modify replace: autoreply - or dn: uid=user,ou=people,dc=example changetype: modify delete: autoreply autoreply: TRUE - which, although semantically equivalent to what you tried, could be handled differently by acesslog(and that would be a 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#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 02 Nov '06

02 Nov '06

i made some test and found that if i use ldapmodify ldapmodify -x -W -ZZ -H 'ldap://example' -D "cn=admin,dc=example" dn: uid=user,ou=people,dc=example changetype: modify add: autoreply autoreply: TRUE modifying entry "uid=user,ou=people,dc=example" dn: uid=user,ou=people,dc=example changetype: modify delete: autoreply modifying entry "uid=user,ou=people,dc=example" and accesslog shows everything correct dn: reqStart=20061102130447.000000Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102130447.000000Z reqEnd: 20061102130447.000001Z reqType: modify reqSession: 153 reqAuthzID: cn=admin,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: autoReply:+ TRUE reqMod: entryCSN:= 20061102130447Z#000000#00#000000 reqMod: modifiersName:= cn=admin,dc=example reqMod: modifyTimestamp:= 20061102130447Z entryUUID: 7658ab48-febe-102a-9f6c-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102130447Z entryCSN: 20061102130447Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102130447Z dn: reqStart=20061102130558.000000Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102130558.000000Z reqEnd: 20061102130558.000001Z reqType: modify reqSession: 153 reqAuthzID: cn=admin,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: autoReply:- reqMod: entryCSN:= 20061102130558Z#000000#00#000000 reqMod: modifiersName:= cn=admin,dc=example reqMod: modifyTimestamp:= 20061102130558Z entryUUID: a041e758-febe-102a-9f6d-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102130558Z entryCSN: 20061102130558Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102130558Z but if i do same thing with phpldapadmin or any other php application i get acceslog dn: reqStart=20061102131503.000002Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102131503.000002Z reqEnd: 20061102131503.000003Z reqType: modify reqSession: 180 reqAuthzID: uid=user,ou=people,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: autoReply:+ TRUE reqMod: entryCSN:= 20061102131503Z#000000#00#000000 reqMod: modifiersName:= uid=user,ou=people,dc=example reqMod: modifyTimestamp:= 20061102131503Z entryUUID: e55e6432-febf-102a-9f70-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102131503Z entryCSN: 20061102131503Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102131503Z dn: reqStart=20061102131511.000002Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102131511.000002Z reqEnd: 20061102131511.000003Z reqType: modify reqSession: 182 reqAuthzID: uid=user,ou=people,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: entryCSN:= 20061102131511Z#000000#00#000000 reqMod: modifiersName:= uid=user,ou=people,dc=example reqMod: modifyTimestamp:= 20061102131511Z entryUUID: ea4cd596-febf-102a-9f71-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102131511Z entryCSN: 20061102131511Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102131511Z and if using ldap admin (http://ldapadmin.sourceforge.net/) then accesslog is also correct.

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 01 Nov '06

01 Nov '06

> It works fine here. Does test043 in the test suite succeed or fail for you? It succeed, i send my configuration. slapd.conf: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba-tng.schema include /etc/openldap/schema/myown.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/openldap/slapd.pid # List of arguments that were passed to the server argsfile /var/run/openldap/slapd.args # Read slapd.conf(5) for possible values loglevel 256 # Allow LDAPv2 for legacy clients allow bind_v2 security update_ssf=128 # Allow nof entries with single search sizelimit -1 timelimit 30 #threads threads 256 # TLS TLSCertificateFile /etc/openldap/ssl/example.crt TLSCertificateKeyFile /etc/openldap/ssl/example.key TLSCACertificateFile /etc/openldap/ssl/ca.crt # REFERRAL referral ldap://example.org # ACL include /etc/openldap/example.acl # Database conf include /etc/openldap/slapd.bdb.log.example include /etc/openldap/slapd.bdb.example slapd.bdb.log.example: database bdb suffix "cn=example_log,dc=logs" directory /var/lib/openldap-data/example/example_log rootdn "cn=example_log,dc=logs" rootpw "secret" cachesize 5000 idlcachesize 1000 checkpoint 128 30 lastmod on overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE # Indexid include /etc/openldap/slapd.log.index slapd.bdb.example: database bdb suffix "dc=example" rootdn "cn=admin,dc=example" rootpw "secret" directory "/var/lib/openldap-data/example/" cachesize 100000 idlcachesize 100000 schemacheck on checkpoint 8 15 lastmod on include /etc/openldap/slapd.index overlay accesslog logdb cn=pop_log,dc=logs logops writes logpurge 7+00:00 1+00:00 limits dn.exact="uid=sync,ou=sync,dc=example" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 1000 modulepath /usr/lib/openldap/openldap/ moduleload back_monitor database monitor rootdn "cn=monitor"

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 31 Oct '06

31 Oct '06

--On Tuesday, October 31, 2006 5:50 PM +0000 quanah(a)stanford.edu wrote: > > > --On Tuesday, October 31, 2006 11:07 AM +0000 Mike Woods > <mike(a)arishi.com> wrote: > >> As promised, my log entries >> >> from my ldap log we have >> >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 ACCEPT from >> IP=127.0.0.1:61497 (IP=0.0.0.0:340) >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 BIND >> dn="uid=replicator,o=menchi" method=128 >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 RESULT tag=97 err=49 >> text= Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=1 UNBIND >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 closed >> >> And from the test modules log we have this. >> >> Oct 31 10:30:58 Menchi Glue: New >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Init >> >> This is all i get, it starts up, runs through new, all the config calls >> and then init, slapd stays up and seems perfectly well but when anything >> attempts to bind to it we get nothing at all! > > I need you to reproduce the behavior involved using the "ldapsearch" > command. I'm going to elaborate on this a little more. Your operation is performing a simple bind. The BIND operation is *only* going to get passed into the PERL backend if it controls the suffix which the binding identity is attempting to bind to. Since you haven't supplied your slapd.conf information for back-perl, this is impossible to determine. However, I will note that unless your slapd.conf has: database perl suffix "o=menchi" I do not expect to see the bind operation in the perl backend. --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#4725) back-perl not calling bind method
by quanah＠stanford.edu 31 Oct '06

31 Oct '06

--On Tuesday, October 31, 2006 11:07 AM +0000 Mike Woods <mike(a)arishi.com> wrote: > As promised, my log entries > > from my ldap log we have > > Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 ACCEPT from > IP=127.0.0.1:61497 (IP=0.0.0.0:340) > Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 BIND > dn="uid=replicator,o=menchi" method=128 > Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 RESULT tag=97 err=49 text= > Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=1 UNBIND > Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 closed > > And from the test modules log we have this. > > Oct 31 10:30:58 Menchi Glue: New > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Init > > This is all i get, it starts up, runs through new, all the config calls > and then init, slapd stays up and seems perfectly well but when anything > attempts to bind to it we get nothing at all! I need you to reproduce the behavior involved using the "ldapsearch" command. --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#4728) accesslog dont write attributes removing
by hyc＠symas.com 31 Oct '06

31 Oct '06

surnu(a)alkohol.ee wrote: > Full_Name: Andres Kahk > Version: 2.3.28 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.80.105.102) > > > if i change attribute, everythings are fine i got: > reqMod: > autoReply:= FALSE > entryCSN:= 20061031104835Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104835Z > > but if i remove attribute from object then i got: > reqMod: > entryCSN:= 20061031104852Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104852Z > > There is no entry to remove. That means the entry is removed in write server, > but it still exists in read server > > If you got any info or patch to fix this and get syncrepl work correctly, please > send it :) It works fine here. Does test043 in the test suite succeed or fail for you? It succeeds here, and it also performs modifications that delete an attribute from an entry. You'll have to provide more information, e.g. your slapd configuration would be a good start. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 31 Oct '06

31 Oct '06

Full_Name: Andres Kahk Version: 2.3.28 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.80.105.102) if i change attribute, everythings are fine i got: reqMod: autoReply:= FALSE entryCSN:= 20061031104835Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104835Z but if i remove attribute from object then i got: reqMod: entryCSN:= 20061031104852Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104852Z There is no entry to remove. That means the entry is removed in write server, but it still exists in read server If you got any info or patch to fix this and get syncrepl work correctly, please send it :)

1 0

Re: (ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 30 Oct '06

30 Oct '06

This can be closed, the problem was tracked down to a broken build of libltdl in Debian Sarge 64-bit. sigh. --Quanah -- Quanah Gibson-Mount QA Engineer <http://www.openldap.org>

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 30 Oct '06

30 Oct '06

--On Monday, October 30, 2006 11:09 AM +0000 mike(a)arishi.com wrote: > Full_Name: Mike Woods > Version: 2.3.28 > OS: FreeBSD 6.1 RELEASE 4 > URL: http://geofront.co.uk/GlueTest.pm > Submission from: (NULL) (207.138.125.56) > > > When using back-perl openldap fails to call the bind methog on > connection, i've tried this with the 2.2 branch and 2.3.28 to the same > effect. > > The failure to call bind essentialy renders back-perl useless. > > I've written and attached a basic "test" module so I can see what > openldap is doing. I am unable to reproduce this issue with 2.3.28. How are you testing this? For me: ldapsearch -LLL -x -h ldap-uat00 -b o=anyorg,c=us -D "uid=quanah,o=anyorg,c=us" -w test tribes:~> And the log clearly shows bind being called: Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 fd=8 ACCEPT from IP=171.64.19.55:41385 (IP=0.0.0.0:389) Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 op=0 BIND dn="uid=quanah,o=anyorg,c=us" method=128 Oct 30 18:38:13 ldap-uat00 Glue: Bind --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

(ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 30 Oct '06

30 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In working to test other bugs, I found that building slapd static allows you to use back-perl, but building slapd with modular back_perl it fails to resolve symbols. Investigation ongoing. This is with perl 5.8.8. --Quanah

1 0

(ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 30 Oct '06

30 Oct '06

Full_Name: Eric Covener Version: 2.4.3 OS: ppc linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.33.49.251) I'm using 2.4.3 and trying to set SSL client certificates on a per-connection basis. A call to ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &newctx) fails in my simple test application because ldap_pvt_tls_init hasn't had a chance to call SSLeay_add_ssl_algorithms() yet. I'm not familiar enough w/ openldap to track down how this path occurs, but it seems like the code in tls.c that handles the SSL_CTX_new() in the event of LDAP_OPT_X_TLS_NEWCTX should make sure the initializer has been run by calling ldap_pvt_tls_init() (My simple test app works when I add SSLeay_add_ssl_algorithms() before ldap_set_option). The failure without the call is TLS: could not allocate default ctx (336236705).

1 0

(ITS#4725) back-perl not calling bind method
by mike＠arishi.com 30 Oct '06

30 Oct '06

Full_Name: Mike Woods Version: 2.3.28 OS: FreeBSD 6.1 RELEASE 4 URL: http://geofront.co.uk/GlueTest.pm Submission from: (NULL) (207.138.125.56) When using back-perl openldap fails to call the bind methog on connection, i've tried this with the 2.2 branch and 2.3.28 to the same effect. The failure to call bind essentialy renders back-perl useless. I've written and attached a basic "test" module so I can see what openldap is doing.

1 0

Re: (ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by hyc＠symas.com 29 Oct '06

29 Oct '06

katuev(a)dvbank.ru wrote: > Full_Name: Konstantin Katuev > Version: 2.3.28 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.137.171.26) > > > When using unicode (russian) strings for DNs & attribute values, all sofwtare > that searches thru LDAP directory returns no results when case of letters does > not match. > If case of letters matches, everything is OK. On ASCII strings search works > fine. > Older versions (2.2.x) work good. > I've upload sample data > (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) > and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) > that can reproduce this behavior. Script will find 1 record when run against > 2.2.x server and nothing on 2.3.x. Thanks for the report. This is now fixed in CVS HEAD libraries/liblunicode/ucdata/ ucgendat.c 1.40 uctable.h 1.6 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by katuev＠dvbank.ru 29 Oct '06

29 Oct '06

Full_Name: Konstantin Katuev Version: 2.3.28 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.137.171.26) When using unicode (russian) strings for DNs & attribute values, all sofwtare that searches thru LDAP directory returns no results when case of letters does not match. If case of letters matches, everything is OK. On ASCII strings search works fine. Older versions (2.2.x) work good. I've upload sample data (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) that can reproduce this behavior. Script will find 1 record when run against 2.2.x server and nothing on 2.3.x.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

> I have no idea what t_delete is but it seems to be dying in your malloc > library. Assuming it's not out of memory, you'll probably need some kind of > malloc debugger (like efence) that can detect heap corruption. Hmm, yeah. Out of memory is unlikely; the core is only a couple hundred MB on a dedicated 2GB box. t_delete is in the depths of the Solaris malloc implementation. I'll ask Sun if they can make anything out of "malloc(35)" causing a SEGV; doesn't exactly sound like documented behavior. You're right that without a memory debugger it's tough to trust any of this. But it's also tough to run a memory debugger in production...they generally slow things down a bit more than I'd like.

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > What a day. I've never had to "_2" dated backtraces ever before... > > Syncprov search, SEGV'd. See "t@13" thread in linked backtrace. I have no idea what t_delete is but it seems to be dying in your malloc library. Assuming it's not out of memory, you'll probably need some kind of malloc debugger (like efence) that can detect heap corruption. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt Submission from: (NULL) (68.196.250.61) What a day. I've never had to "_2" dated backtraces ever before... Syncprov search, SEGV'd. See "t@13" thread in linked backtrace.

1 0

Re: (ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by ando＠sys-net.it 26 Oct '06

26 Oct '06

rk(a)owen.sj.ca.us wrote: > Here is the trivial patch rkowen-061026.patch > Thanks for the fix. It's in HEAD 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

(ITS#4722) crash in daemon.c
by quanah＠stanford.edu 26 Oct '06

26 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) With the latest updates, I hit a assert in daemon.c (from HEAD). It appears there is still a possible race condition. The assert hit was: daemon.c:551 assert( SLAP_SOCK_IS_ACTIVE( s )); in slapd_clr_write called from: connection.c:808 slapd_clr_write( sd, 1 ); in connection_closing It looks like the write needs to be cleared before the mutex is unlocked. --Quanah

1 0

(ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by rk＠owen.sj.ca.us 26 Oct '06

26 Oct '06

Full_Name: R.K. Owen Version: Anon-CVS OS: Ubuntu-6.05 Linux URL: ftp://ftp.openldap.org/incoming/rkowen-061026.patch Submission from: (NULL) (66.87.79.68) After trying to "configure --without-threads ...", the build resulted in the following error message: connection.o: In function `connection_operation':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1044: undefined reference to `ldap_pvt_thread_pool_tid' connection.o: In function `connection_fake_init':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1955: undefined reference to `ldap_pvt_thread_pool_tid' This can be resolved by creating the trivial do-nothing ldap_pvt_thread_pool_tid() function in thr_stub.c Here is the trivial patch rkowen-061026.patch

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. > Backtrace of dead slapd at > > https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > > and db_stat -CA of affected database at > > https://www.nbcs.rutgers.edu/~richton/richton-20061026-dbstatCA.txt > > > I have the core file saved if you need any variables out, but this was > production so I had to restart the service/no opportunity for live debugging. For an immediate workaround, turn off syncprov's contextCSN checkpointing. It will only checkpoint during a clean shutdown, but that shouldn't be a problem. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4720) hdb deadlock
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt Submission from: (NULL) (68.193.253.190) Solaris 9, BDB 4.2.52+4, OL 2.3.28. ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Backtrace of dead slapd at https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt and db_stat -CA of affected database at https://www.nbcs.rutgers.edu/~richton/richton-20061026-dbstatCA.txt I have the core file saved if you need any variables out, but this was production so I had to restart the service/no opportunity for live debugging.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by bgmilne＠staff.telkomsa.net 24 Oct '06

24 Oct '06

--nextPart6645744.gz20WZ6vTg Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 24 October 2006 21:00, quanah(a)stanford.edu wrote: > --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: > >> quanah(a)stanford.edu wrote: > >>> It would be nice if you could pass -u and -g options to run as another > >>> user/group so that on systems where OpenLDAP is running as another us= er > >>> or group, the files created by slapadd & slapindex have the correct > >>> ownerships (rather than root, for example). > >> > >> OK for slapadd; for slapindex and other tools, what about using > >> user/group info from the file(s) itself? > > > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > > is because it changes root after some initialization. > > Because some people are brain dead, and because other people set up > application accounts that don't actually have a shell. And some brain-dead OS's have an su without a -s flag ? > It also makes=20 > things more consistent behavior wise. I personally don't have this issue > because I run openldap as root anyway, but I've seen list traffic about > this on more than one occasion, and am seeing people hit it on the debian > openldap list as well. Debian doesn't have a brain-dead su, so 'su -s /bin/bash -c "slapadd ...."'= =20 etc. is feasible. One of my colleagues has a sticker on his monitor which says: Social Engineering Specialist: because there is no patch for stupidity. I haven't seen the need for this myself (but then I don't use back-config, = and=20 my initscript parses slapd.conf to find all database directories, and check= s=20 ownership on all of them). Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart6645744.gz20WZ6vTg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFPwhOrJK6UGDSBKcRApYPAKCecAu2I8CXqMin3Uz9a1MQv8cUEgCfZFPm TLqaOhPzhqr0KV8Y0W7fNR4= =93Bl -----END PGP SIGNATURE----- --nextPart6645744.gz20WZ6vTg--

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ahasenack＠terra.com.br 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 12:46:30PM -0700, Quanah Gibson-Mount wrote: > >>Because some people are brain dead, and because other people set up > >>application accounts that don't actually have a shell. It also makes > >>things more consistent behavior wise. I personally don't have this > >>issue because I run openldap as root anyway, but I've seen list traffic > >>about this on more than one occasion, and am seeing people hit it on > >>the debian openldap list as well. > > > >The slapd initscript should/could chown the files whenever slapd is > >(re)started. > > And how would the init script know the locations of X number of databases, > particularly if back-config is used? With back-config things get more complicated, but with slapd.conf it's just a bunch of greps. What about storing this info inside the config file itself (i.e., "slapd_user ldap", "slapd_group ldap")? Chicken and egg problem?

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 7:16 PM +0000 ahasenack(a)terra.com.br wrote: > On Tue, Oct 24, 2006 at 07:00:40PM +0000, quanah(a)stanford.edu wrote: >> >> >> --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: >> >> > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> >> quanah(a)stanford.edu wrote: >> >>> It would be nice if you could pass -u and -g options to run as >> >>> another user/group so that on systems where OpenLDAP is running as >> >>> another user or group, the files created by slapadd & slapindex have >> >>> the correct ownerships (rather than root, for example). >> >>> >> >> OK for slapadd; for slapindex and other tools, what about using >> >> user/group info from the file(s) itself? >> > >> > Why not just use su(1)? the only reason slapd(8) has -u/-g options >> > is because it changes root after some initialization. >> >> Because some people are brain dead, and because other people set up >> application accounts that don't actually have a shell. It also makes >> things more consistent behavior wise. I personally don't have this >> issue because I run openldap as root anyway, but I've seen list traffic >> about this on more than one occasion, and am seeing people hit it on >> the debian openldap list as well. > > The slapd initscript should/could chown the files whenever slapd is > (re)started. And how would the init script know the locations of X number of databases, particularly if back-config is used? --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#4719) Support for running slapadd/slapindex as a user
by ahasenack＠terra.com.br 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 07:00:40PM +0000, quanah(a)stanford.edu wrote: > > > --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > > > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: > >> quanah(a)stanford.edu wrote: > >>> It would be nice if you could pass -u and -g options to run as another > >>> user/group so that on systems where OpenLDAP is running as another user > >>> or group, the files created by slapadd & slapindex have the correct > >>> ownerships (rather than root, for example). > >>> > >> OK for slapadd; for slapindex and other tools, what about using > >> user/group info from the file(s) itself? > > > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > > is because it changes root after some initialization. > > Because some people are brain dead, and because other people set up > application accounts that don't actually have a shell. It also makes > things more consistent behavior wise. I personally don't have this issue > because I run openldap as root anyway, but I've seen list traffic about > this on more than one occasion, and am seeing people hit it on the debian > openldap list as well. The slapd initscript should/could chown the files whenever slapd is (re)started.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by hyc＠symas.com 24 Oct '06

24 Oct '06

Kurt(a)OpenLDAP.org wrote: > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> quanah(a)stanford.edu wrote: >>> It would be nice if you could pass -u and -g options to run as another >>> user/group so that on systems where OpenLDAP is running as another user or >>> group, the files created by slapadd & slapindex have the correct ownerships >>> (rather than root, for example). >>> >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > is because it changes root after some initialization. Agreed. As for using info from the files themselves - that requires per-backend functions to return the user/group info. Seems like unnecessary effort. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> quanah(a)stanford.edu wrote: >>> It would be nice if you could pass -u and -g options to run as another >>> user/group so that on systems where OpenLDAP is running as another user >>> or group, the files created by slapadd & slapindex have the correct >>> ownerships (rather than root, for example). >>> >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > is because it changes root after some initialization. Because some people are brain dead, and because other people set up application accounts that don't actually have a shell. It also makes things more consistent behavior wise. I personally don't have this issue because I run openldap as root anyway, but I've seen list traffic about this on more than one occasion, and am seeing people hit it on the debian openldap list as well. --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#4719) Support for running slapadd/slapindex as a user
by ando＠sys-net.it 24 Oct '06

24 Oct '06

quanah(a)stanford.edu wrote: >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? >> > > What file(s)? Assuming this is a new (and only) index? I guess the __db.* > files? or the id2entry file? Just trying to see specifically where you are > going on this. :) > I mean: if slapadding a brand new db, -u/-g (but -g is already in use by glue stuff) is fine. If slapadding/slapindexing an existing db, get the info from the existing file, if any, or from id2entry.bdb. I'd use a specific option, though, and bail out if no definite answer can be gathered (e.g. -H means use ownership from file, -HH use ownership from file, or from id2entry.bdb if file does not exist). Note that it would make sense to have the -HH behavior as the default... 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#4719) Support for running slapadd/slapindex as a user
by Kurt＠OpenLDAP.org 24 Oct '06

24 Oct '06

At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >quanah(a)stanford.edu wrote: >> It would be nice if you could pass -u and -g options to run as another >> user/group so that on systems where OpenLDAP is running as another user or >> group, the files created by slapadd & slapindex have the correct ownerships >> (rather than root, for example). >> >OK for slapadd; for slapindex and other tools, what about using >user/group info from the file(s) itself? Why not just use su(1)? the only reason slapd(8) has -u/-g options is because it changes root after some initialization.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 8:49 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: >> It would be nice if you could pass -u and -g options to run as another >> user/group so that on systems where OpenLDAP is running as another user >> or group, the files created by slapadd & slapindex have the correct >> ownerships (rather than root, for example). >> > OK for slapadd; for slapindex and other tools, what about using > user/group info from the file(s) itself? What file(s)? Assuming this is a new (and only) index? I guess the __db.* files? or the id2entry file? Just trying to see specifically where you are going on this. :) --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#4719) Support for running slapadd/slapindex as a user
by ando＠sys-net.it 24 Oct '06

24 Oct '06

quanah(a)stanford.edu wrote: > It would be nice if you could pass -u and -g options to run as another > user/group so that on systems where OpenLDAP is running as another user or > group, the files created by slapadd & slapindex have the correct ownerships > (rather than root, for example). > OK for slapadd; for slapindex and other tools, what about using user/group info from the file(s) itself? 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#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) It would be nice if you could pass -u and -g options to run as another user/group so that on systems where OpenLDAP is running as another user or group, the files created by slapadd & slapindex have the correct ownerships (rather than root, for example).

1 0

Re: (ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by ando＠sys-net.it 24 Oct '06

24 Oct '06

damonmo(a)gmail.com wrote: > The option 'network-timeout' used to stablish a socket-level timeout on meta > backend is missing on slapd-meta man pages. > Fixed in HEAD/re23. 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#4718) Option 'network-timeout' missing from slapd-meta man pages
by damonmo＠gmail.com 24 Oct '06

24 Oct '06

Full_Name: Daniel Montero Motilla Version: 2.3.27 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) The option 'network-timeout' used to stablish a socket-level timeout on meta backend is missing on slapd-meta man pages.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs