- openldap-bugs - openldap.org

(ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no 12 Feb '08

12 Feb '08

Full_Name: Hallvard B Furuseth Version: RE23 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard /configure \ --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \ --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \ --enable-backends --disable-sql --enable-overlays \ CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' ./run -b hdb test043-delta-syncrepl server 1 crashes at accesslog.c line 918, which unlocks &li->li_op_mutex when it is owned by another thread. (Can also check it by setting li_unlock = (int) ldap_pvt_thread_self() instead of 1 after lock, and assert()ing the same before unlock.) accesslog_op_mod() has a comment /* FIXME: this needs to be a recursive mutex to allow * overlays like refint to keep working. */ ldap_pvt_thread_mutex_lock( &li->li_op_mutex ); but this problem is not recursive use of the mutex. (gdb) thread apply all backtrace Thread 4 (process 10963): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00a64297 in pthread_join () from /lib/tls/libpthread.so.0 #2 0x081f0f62 in ldap_int_thread_join (thread=20061088, thread_return=0x0) at thr_posix.c:193 #3 0x081c3de4 in ldap_pvt_thread_join (thread=20061088, thread_return=0x0) at thr_debug.c:612 #4 0x0807bb54 in slapd_daemon () at daemon.c:2579 #5 0x08066554 in main (argc=8, argv=0xbfffefd4) at main.c:859 Thread 3 (process 10965): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008cb82e in epoll_wait () from /lib/tls/libc.so.6 #2 0x0807ae29 in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #3 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x008cb1ae in clone () from /lib/tls/libc.so.6 Thread 2 (process 10967): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008bc29b in __write_nocancel () from /lib/tls/libc.so.6 #2 0x0086064f in _IO_new_file_write () from /lib/tls/libc.so.6 #3 0x0086089c in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #4 0x00855af1 in fputs () from /lib/tls/libc.so.6 #5 0x081f6160 in lutil_debug (debug=261, level=1, fmt=0x8237950 "<= key_change %d\n") at debug.c:89 #6 0x0814f485 in hdb_key_change (be=0x3061d24, db=0x838d518, txn=0x839bfe0, k=0xb7bba47c, id=16, op=1) at key.c:101 #7 0x0814e7ca in indexer (op=0x83799c0, txn=0x839bfe0, ad=0x830c6e8, atname=0x830d21c, vals=0x839aaa0, id=16, opid=1, mask=1814) at index.c:244 #8 0x0814e9a3 in index_at_values (op=0x83799c0, txn=0x839bfe0, ad=0x830c6e8, type=0x830d1e0, tags=0x830c6f8, vals=0x839aaa0, id=16, opid=1) at index.c:324 #9 0x0814eb05 in hdb_index_values (op=0x83799c0, txn=0x839bfe0, desc=0x830c6e8, vals=0x839aaa0, id=16, opid=1) at index.c:373 #10 0x0814eec1 in hdb_index_entry (op=0x83799c0, txn=0x839bfe0, opid=1, e=0x83946e8) at index.c:544 #11 0x0813ce65 in hdb_add (op=0x83799c0, rs=0x306218c) at add.c:304 #12 0x080e8903 in overlay_op_walk (op=0x83799c0, rs=0x306218c, which=op_add, oi=0x830c800, on=0x0) at backover.c:650 #13 0x080e8ab8 in over_op_func (op=0x83799c0, rs=0x306218c, which=op_add) at backover.c:702 #14 0x080e8bc4 in over_op_add (op=0x83799c0, rs=0x306218c) at backover.c:748 #15 0x080869e1 in fe_op_add (op=0x83799c0, rs=0x306218c) at add.c:342 #16 0x08086457 in do_add (op=0x83799c0, rs=0x306218c) at add.c:182 #17 0x0807e428 in connection_operation (ctx=0x3062218, arg_v=0x83799c0) at connection.c:1133 #18 0x081c1d40 in ldap_int_thread_pool_wrapper (xpool=0x82c86c8) at tpool.c:478 #19 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 #20 0x008cb1ae in clone () from /lib/tls/libc.so.6 Thread 1 (process 10976): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00829815 in raise () from /lib/tls/libc.so.6 #2 0x0082b279 in abort () from /lib/tls/libc.so.6 #3 0x081c2b9e in error (file=0x82749bd "thr_debug.c", line=784, msg=0x82750a0 "ldap_pvt_thread_mutex_unlock", var=0x8274d72 "rc", val=1) at thr_debug.c:155 #4 0x081c44ec in ldap_pvt_thread_mutex_unlock (mutex=0x830cd04) at thr_debug.c:784 #5 0x08183fdf in accesslog_response (op=0x8386bc8, rs=0x220318c) at accesslog.c:918 #6 0x08184f14 in accesslog_mod_cleanup (op=0x8386bc8, rs=0x220318c) at accesslog.c:1241 #7 0x0808fcca in send_ldap_response (op=0x8386bc8, rs=0x220318c) at result.c:458 #8 0x080903f1 in slap_send_ldap_result (op=0x8386bc8, rs=0x220318c) at result.c:574 #9 0x0813d474 in hdb_add (op=0x8386bc8, rs=0x220318c) at add.c:409 #10 0x080e8903 in overlay_op_walk (op=0x8386bc8, rs=0x220318c, which=op_add, oi=0x830c800, on=0x0) at backover.c:650 #11 0x080e8ab8 in over_op_func (op=0x8386bc8, rs=0x220318c, which=op_add) at backover.c:702 #12 0x080e8bc4 in over_op_add (op=0x8386bc8, rs=0x220318c) at backover.c:748 #13 0x080869e1 in fe_op_add (op=0x8386bc8, rs=0x220318c) at add.c:342 #14 0x08086457 in do_add (op=0x8386bc8, rs=0x220318c) at add.c:182 #15 0x0807e428 in connection_operation (ctx=0x2203218, arg_v=0x8386bc8) at connection.c:1133 #16 0x081c1d40 in ldap_int_thread_pool_wrapper (xpool=0x82c86c8) at tpool.c:478 #17 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 #18 0x008cb1ae in clone () from /lib/tls/libc.so.6

1 0

(ITS#5373) ppolicy issues when deleting the password attribute, even if no password checking is enforced
by Guillaume.Rousse＠inria.fr 12 Feb '08

12 Feb '08

Full_Name: Guillaume Rousse Version: 2.3.40 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) Here are my ppolicy settings: password policy overlay ppolicy ppolicy_use_lockout ppolicy_default cn=default,ou=policies,dc=futurs,dc=inria,dc=fr Here is my default entry: dn: cn=default,ou=policies,dc=futurs,dc=inria,dc=fr cn: default objectClass: pwdPolicy objectClass: organizationalRole pwdAttribute: userPassword pwdMaxAge: 0 pwdInHistory: 0 pwdCheckQuality: 0 According to documentation, no user password quality checking should take places, however, trying to delete userPassword attribute for an user triggers at least a server error with this LDIF fragment: dn: userdn changetype: modify delete: userPassword ldapmodify: Internal (implementation specific) error (80) additional info: Internal Error Error message in logs: "cannot locate modification supplying new password" Or worst, a server crash with this one: dn: userdn changetype: modify replace: userPassword No error message from ldapmodify, and no error message in the logs in this case.

1 0

Re: (ITS#5344) Wrong check for bad Modify DN
by h.b.furuseth＠usit.uio.no 11 Feb '08

11 Feb '08

Pierangelo Masarati writes: > You should apply your initial patch (to HEAD, 2.4), Done. > then modify HEAD to pass dest_dn/dest_ndn Later. -- Hallvard

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 11 Feb '08

11 Feb '08

Some fixed in HEAD. Remaining bugs: > Looking at the code, some overlays also send results when used as > be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. Hmm - back-ldap does send_ldap_extended() too. I don't know any of that code well though. Might have a look later, if nobody else does. > * be->be_fetch() (bi->bi_entry_get_rw()): > The LDAP result code matters (...) It can return just a boolean > in (...) back-relay. I haven't looked at what it should return when not forwarding to the backend. relay_back_has_subordinates() is also broken. It should return an LDAP result code, and if returning LDAP_SUCCESS it must also set *hasSubs to LDAP_COMPARE_FALSE or LDAP_COMPARE_TRUE. See bdb_hasSubordinates() for an example. However: slapd's be_has_subordinates() API seems broken: It has no way to return "don't know" or normal errors which slapd will pay attention to. If it returns non-success, test_ava_filter(,,,LDAP_FILTER_EQUALITY) returns LDAP_OTHER. Looks abit excessive. OTOH test_presence_filter() assumes that if the backend function exists then attr hasSubordinates does too. > back-ldap:ldap_back_entry_get() can return LDAP_NO_MEMORY. > Maybe that's OK and instead send_ldap_response() should change > negative negative result codes to LDAP_OTHER? Awaiting opinions - will do the smallest change and patch back-ldap if nobody says anything. -- Hallvard

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 11 Feb '08

11 Feb '08

--UugvWAfsgieZRqgk Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kurt, On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote: > On Feb 11, 2008, at 1:09 AM, mimir(a)samba.org wrote: > >> Full_Name: Rafal Szczesniak >> Version: HEAD >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-head.diff > > The submitted patch file does not contain (at the top of the file, not = =20 > as part of the diffs) the required notices. I'm sorry about that. I was submitting it late yesterday and must have miss= ed that. I'll update the diff and let you know soon. > Please review=20 > http://www.openldap.org/devel/contributing.html and insert appropriate=20 > notices. Also, please don't include in the diffs derived files (e.g.,=20 > configure). Of course. My mistake. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --UugvWAfsgieZRqgk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHsK9nHvdfyv3qiKkRAiusAKChoX739lSkfFFRSqXxZG9ht5l3oQCghVrP mWR71B2o2KIifs5uaiMzH58= =SPnD -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--

1 0

Re: (ITS#5370) race condition in slap_op_time()
by hyc＠symas.com 11 Feb '08

11 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd/operation.c:slap_op_time() can decrease last_time: > > thread 1: *t = slap_get_time(); > <clock: increment time()> > thread 2: *t = slap_get_time(); > thread 2: with mutex lock: increment last_time, set last_incr = 0; > thread 1: with mutex lock: decrement last_time, set last_incr = 0; > > The simplest fix is to move the slap_get_time() call inside the > (global) slap_op_mutex lock. > > However as far as I can tell, only the accesslog overlay uses > op->o_tincr, the value which needs the mutex. And accesslog > calls slap_op_time() itself when it needs that value. > So maybe we should remove the op->o_tincr field. Other calls > to slap_op_time() can be replaced with slap_get_time(). Sounds like a good idea. It was somewhat redundant with the CSN counter (except that this was for all operations, and CSN was only for write operations) and it never became generally useful. (Shifted to microsecond timestamps in 2.4, because tincr isn't useful across multiple servers.) I guess it makes more sense to make it specific to accesslog. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5369) GSSAPI support for client library
by kurt＠OpenLDAP.org 11 Feb '08

11 Feb '08

On Feb 11, 2008, at 1:09 AM, mimir(a)samba.org wrote: > Full_Name: Rafal Szczesniak > Version: HEAD > OS: GNU/Linux > URL: http://www.samba.org/~mimir/gssapi-head.diff The submitted patch file does not contain (at the top of the file, not as part of the diffs) the required notices. Please review http://www.openldap.org/devel/contributing.html and insert appropriate notices. Also, please don't include in the diffs derived files (e.g., configure). -- Kurt

1 0

(ITS#5370) race condition in slap_op_time()
by h.b.furuseth＠usit.uio.no 11 Feb '08

11 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd/operation.c:slap_op_time() can decrease last_time: thread 1: *t = slap_get_time(); <clock: increment time()> thread 2: *t = slap_get_time(); thread 2: with mutex lock: increment last_time, set last_incr = 0; thread 1: with mutex lock: decrement last_time, set last_incr = 0; The simplest fix is to move the slap_get_time() call inside the (global) slap_op_mutex lock. However as far as I can tell, only the accesslog overlay uses op->o_tincr, the value which needs the mutex. And accesslog calls slap_op_time() itself when it needs that value. So maybe we should remove the op->o_tincr field. Other calls to slap_op_time() can be replaced with slap_get_time().

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 11 Feb '08

11 Feb '08

h.b.furuseth(a)usit.uio.no writes: > Also, now that I think of it, back-hdb/ldif subtree rename is broken if > there are referral objects with DNs in the subtree. Duh, that's a feature, not a bug. If a referral entry gets renamed, that does not magically rename the entry it refers to. It gets to be a bug if one has cooperating servers where they all rename the entry. Anyway, getting back to back-bdb - once the database has a ref attribute with a DN, I don't see how rewriting it is worse than not rewriting. So I think the fix for now is to to follow the RFCs. -- Hallvard

1 0

(ITS#5369) GSSAPI support for client library
by mimir＠samba.org 11 Feb '08

11 Feb '08

Full_Name: Rafal Szczesniak Version: HEAD OS: GNU/Linux URL: http://www.samba.org/~mimir/gssapi-head.diff Submission from: (NULL) (12.104.75.4) OpenLDAP client libraries do not implement convenient mechanisms for interfacing to MS Active Directory with minimum necessary configuration. Also, SASL implementation is tightly connected with Cyrus SASL libs. Submitted patch modifies the library to provide more generic SASL layer used both by Cyrus SASL and contributed GSSAPI mechanism. The GSSAPI itself is limited to Kerberos 5, at the moment, but the goal is to provide complete SASL layer for easy connecting to MS servers.

1 0

Re: (ITS#5368) s/strncasecmp/ber_bvstrncasecmp/ broke substring check for {CLEARTEXT}
by hyc＠symas.com 11 Feb '08

11 Feb '08

steve.langasek(a)canonical.com wrote: > Full_Name: Steve Langasek > Version: 2.4.7 > OS: Debian > URL: http://people.ubuntu.com/~vorlon/sasl-cleartext-strncasecmp.patch > Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) > > > A regression was introduced in revision 1.239 of servers/slapd/sasl.c. > Previously, sasl_ap_lookup() would check for a leading string of {CLEARTEXT} and > trim it from the userPassword value returned to SASL; but in revision 1.239, the > strncasecmp() was replaced with ber_bvstrcasecmp() which instead looks for an > exact match of the whole string, causing passwords to be handed back to SASL > with the leading "{CLEARTEXT}" attached. > > The referenced patch is verified to correct this regression. Thanks, this is now fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5368) s/strncasecmp/ber_bvstrncasecmp/ broke substring check for {CLEARTEXT}
by steve.langasek＠canonical.com 11 Feb '08

11 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/sasl-cleartext-strncasecmp.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) A regression was introduced in revision 1.239 of servers/slapd/sasl.c. Previously, sasl_ap_lookup() would check for a leading string of {CLEARTEXT} and trim it from the userPassword value returned to SASL; but in revision 1.239, the strncasecmp() was replaced with ber_bvstrcasecmp() which instead looks for an exact match of the whole string, causing passwords to be handed back to SASL with the leading "{CLEARTEXT}" attached. The referenced patch is verified to correct this regression.

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 11 Feb '08

11 Feb '08

On Sun, Feb 10, 2008 at 01:19:49AM -0800, Howard Chu wrote: >> It's true that the /length/ of a string doesn't include the trailing NUL, >> but it does have to be included in the storage /size/ of a C string, and >> it's debatable which is intended here. > Since this is an ASN.1 structure, one would ordinarily not expect any NUL > termination in the first place. And since other GnuTLS library functions > are returning the raw data size, excluding any trailing NUL, the behavior > you're seeing here is pretty suspicious. Well, granted; it is consistent in newer versions of GnuTLS, though, despite being inconsistent with older versions and with the other crt APIs. >> Given that one of the errors >> returned by gnutls_x509_crt_get_subject_alt_name() is >> GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use >> semantics for storage size rather than string length, and the only question >> in my mind is whether the trailing NUL is included as part of the internal >> representation of the string. >> If this is a behavior change as you say, then I guess we need clarification >> from GnuTLS upstream about whether this is intentional. > That sounds like the best step for now. Just to be sure, how was the > certificate created? Using the openssl commandline tool, and specifying a subjectAltName=DNS:hostname entry in the [ v3_ca ] section of /etc/ssl/openssl.cnf. This was created strictly as a test certificate, in response to reports of problems precisely with subjectAltName validation (http://bugs.debian.org/462588#98). > Have you verified that libldap with OpenSSL accepts the certificate > correctly? Yes, I've tested with ldapsearch from OpenLDAP 2.3.30 linked against OpenSSL, which was able to validate the subjectAltName just fine. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

Re: (ITS#5367) test019-syncreplication-cascade fails
by hyc＠symas.com 11 Feb '08

11 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080210.tgz.1 > Submission from: (NULL) (129.240.203.232) > Submitted by: hallvard > > > "./run test019-syncreplication-cascade" fails in HEAD: > master and R2 slave databases differ Sorry about that, was poking at things that didn't need poking. Fixed in HEAD. > diff testrun/server1.out testrun/server3.out says server3 has an extra object > cn=James A Jones 2,ou=Information Technology > Division,ou=People,dc=example,dc=com > > testrun directory in enclosed, including test output in testrun/output. > > (Ignore the ftp'ed filename without ".1" at the end, transfer failed.) > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5367) test019-syncreplication-cascade fails
by h.b.furuseth＠usit.uio.no 10 Feb '08

10 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080210.tgz.1 Submission from: (NULL) (129.240.203.232) Submitted by: hallvard "./run test019-syncreplication-cascade" fails in HEAD: master and R2 slave databases differ diff testrun/server1.out testrun/server3.out says server3 has an extra object cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com testrun directory in enclosed, including test output in testrun/output. (Ignore the ftp'ed filename without ".1" at the end, transfer failed.)

1 0

(ITS#5366) ldap_get_dn man page errors
by rra＠stanford.edu 10 Feb '08

10 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.14) The ldap_get_dn man page has the following prototype for ldap_str2dn: int ldap_str2dn( const char *str, LDAPDN **dn, unsigned flags ) However, ldap.h has: LDAP_F( int ) ldap_str2dn LDAP_P(( LDAP_CONST char *str, LDAPDN *dn, unsigned flags )); Note the difference for the second argument. This is related to, later in the man page: typedef struct ldap_ava { char *la_attr; struct berval *la_value; unsigned la_flags; } LDAPAVA; typedef LDAPAVA** LDAPRDN; typedef LDAPRDN** LDAPDN; but ldap.h says: typedef struct ldap_ava { struct berval la_attr; struct berval la_value; unsigned la_flags; void *la_private; } LDAPAVA; typedef LDAPAVA** LDAPRDN; typedef LDAPRDN* LDAPDN; Note the type difference for LDAPDN (which explains the earlier varience) and for la_attr. Original Debian bug report: http://bugs.debian.org/465024

1 0

(ITS#5365) Library symbol versioning or other help for library transitions
by rra＠stanford.edu 10 Feb '08

10 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.14) One of the challenges of handling core system libraries like OpenLDAP in the context of a packaged distribution is handling library transitions when the SONAME of the library changes (such as between 2.3 and 2.4, and presumably between 2.4 and 2.5). It's rarely possible to rebuild every package at the same time against the newer libraries (particularly since there are dependency chains that often require one package go first before another can be rebuilt), let alone all of the user software that's outside the space managed by the distribution. Because of that, both the old and new library usually have to co-exist for at least a brief period on many systems, with some binaries linked against the old version and some against the new version, until the upgrade is complete. This is, fundamentally, the problem of the distribution and not the problem of the OpenLDAP team. However, one thing that, from a distributor perspective, helps considerably with transitions like this is if the upstream library distributor uses symbol versioning on those platforms that support it (primarily Linux and Solaris, and possibly -- I have no personal experience -- the *BSDs). If symbol versioning is used for the libraries, the 2.3 and 2.4 libraries can be loaded into the same namespace and won't conflict with each other, since the programs and other libraries will bind to the version against which they were compiled. So, basically, this is a feature request: would it be possible to add symbol versioning to the libldap and libber libraries? Very simple symbol versioning (just assigning one version to all public symbols) would be sufficient to make these sorts of transitions much easier. I'm happy to help provide information and Makefile glue to do this if it's desirable; I've done it in a portable way with several other libraries in packages I maintain. Please feel free to tell me I should move this to a post to openldap-technical or somewhere else; I know it's sort of borderline between an ITS and a library usage discussion.

1 0

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by rra＠stanford.edu 10 Feb '08

10 Feb '08

hyc(a)symas.com writes: > You might consider suggesting to PADL that they contribute pam/nss_ldap > to the OpenLDAP Project, if you want us to take an active role in > solving this. Until then, the discussion just doesn't belong here on the > OpenLDAP ITS. I'll note that I've described the solution Symas uses in > our commercial distribution of pam/nss-ldap on the pam/nss-ldap mailing > lists in the past. Our package has none of these issues. > > Hint: since dynamic linker dependencies are causing the conflict, the > solution is not to rely on the dynamic linker. In this particular case, > using the dynamic linker introduces a security vulnerability anyway. Understood. Thank you very much for the help that you've provided. We'll try to find a solution that won't make you hate us. :) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by hyc＠symas.com 10 Feb '08

10 Feb '08

rra(a)stanford.edu wrote: > We'll talk this over and see if there's a way that we can either move from > nss-ldap or try to get it out of the places where it causes problems, > although that's going to be really rough going as you can probably > imagine. libnss-ldap has over 2,800 installations that report popcon > statistics, which means a *lot* of people are using it. > > Thinking out-loud here a bit (because I really want to solve this problem > in the long run in a way that you can support), libnss-ldap and slapd on > the same system are instant death unless everything uses libldap_r. If we > have slapd conflict with libnss-ldap and then have only slapd use > libldap_r (and make people use libnss-ldapd on systems that are also > running slapd), we may solve a fair chunk of the problem. The other place > where libldap is pulled in is via PAM, but slapd itself should never need > to call into PAM (even indirectly). You might consider suggesting to PADL that they contribute pam/nss_ldap to the OpenLDAP Project, if you want us to take an active role in solving this. Until then, the discussion just doesn't belong here on the OpenLDAP ITS. I'll note that I've described the solution Symas uses in our commercial distribution of pam/nss-ldap on the pam/nss-ldap mailing lists in the past. Our package has none of these issues. Hint: since dynamic linker dependencies are causing the conflict, the solution is not to rely on the dynamic linker. In this particular case, using the dynamic linker introduces a security vulnerability anyway. > If any slapd backends load dynamic libraries that in turn load libldap, > the world may also explode, but this should only affect back-perl, which > isn't working right now anyway due to the libtool RTLD_GLOBAL issues. >> The other obvious step in this situation is never to use LDAP for >> hostname resolution. ("Doctor, it hurts when I do this." - "Don't do >> that.") LDAP is a much heavier weight protocol than DNS; as such it's >> simply the wrong tool for the job. (Note - I like using DNS servers >> backed by LDAP, but that's a completely different situation.) > > Okay. I can at least pass that along to the user. Or patch nss_ldap to simply return a failure whenever it's invoked for hostname resolution. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by rra＠stanford.edu 10 Feb '08

10 Feb '08

Howard Chu <hyc(a)symas.com> writes: > libldap_r was written solely for use by slapd and slurpd. Anybody else > who uses it does so at their own risk. Applications are supposed to link > with libldap. This has been stated several times before. Unfortunately, I still need to figure out how best to fix the problem and that by itself doesn't give me a way, but I do understand where you're coming from. > Unfortunately your problems with libnss-ldap are outside our purview, > and any ITS relating to it will just be closed/rejected. The fact that > nss-ldap is essentially broken is not for us to fix. The problems you > encounter from breaking our Makefiles in response to the nss-ldap > problems are also obviously not for us to fix; you did that to yourself. In, I should point out, a testing version as a short-term way of getting 2.4.7 into the archive so that we could throw out 2.1, which I'm sure you'd agree is a great good. :) I was always planning on trying to replace this solution with something that you felt you could support; we were just trying to do one thing at a time. We'll talk this over and see if there's a way that we can either move from nss-ldap or try to get it out of the places where it causes problems, although that's going to be really rough going as you can probably imagine. libnss-ldap has over 2,800 installations that report popcon statistics, which means a *lot* of people are using it. Thinking out-loud here a bit (because I really want to solve this problem in the long run in a way that you can support), libnss-ldap and slapd on the same system are instant death unless everything uses libldap_r. If we have slapd conflict with libnss-ldap and then have only slapd use libldap_r (and make people use libnss-ldapd on systems that are also running slapd), we may solve a fair chunk of the problem. The other place where libldap is pulled in is via PAM, but slapd itself should never need to call into PAM (even indirectly). If any slapd backends load dynamic libraries that in turn load libldap, the world may also explode, but this should only affect back-perl, which isn't working right now anyway due to the libtool RTLD_GLOBAL issues. > The other obvious step in this situation is never to use LDAP for > hostname resolution. ("Doctor, it hurts when I do this." - "Don't do > that.") LDAP is a much heavier weight protocol than DNS; as such it's > simply the wrong tool for the job. (Note - I like using DNS servers > backed by LDAP, but that's a completely different situation.) Okay. I can at least pass that along to the user. Thanks for the response. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(ITS#5364) Thread pool efficiency
by h.b.furuseth＠usit.uio.no 10 Feb '08

10 Feb '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://www.openldap.org/lists/openldap-devel/200802/msg00003.html Submission from: (NULL) (129.240.203.232) Submitted by: hallvard ITS filed for the changes in thread "Thread pool efficiency", openldap-devel, Feb 2008. slapd spends too much time contending for ltp_mutex in the thread pool (libldap_r/tpool.c). Applying some easy fixes first: Move work out of the region where pool_submit() and pool_wrapper hold the mutex locked. Also slapd/result.c checks if the pool is paused every 64 entries and if so returns LDAP_BUSY, it needs no lock for that.

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 10 Feb '08

10 Feb '08

hyc(a)symas.com wrote: > Steve Langasek wrote: >> Given that one of the errors >> returned by gnutls_x509_crt_get_subject_alt_name() is >> GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use >> semantics for storage size rather than string length, and the only question >> in my mind is whether the trailing NUL is included as part of the internal >> representation of the string. >> >> If this is a behavior change as you say, then I guess we need clarification >> from GnuTLS upstream about whether this is intentional. Yes. I've just tested with GnuTLS 2.2.1 and 2.3.0 and see the same result you're seeing. The change is here: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=deaa3ac31c2… and it is clearly a bug, since subjectAltName's are not necessarily strings. (E.g., they can also be IP addresses, which are just 4 or 16 octets.) If you notice in the diff, they set *name_size = len + 1; and then later name[len] = 0; but this occurs *after* the check for SHORT_MEMORY_BUFFER. So in fact they can cause a write past the end of the supplied buffer. This patch should be reverted, it is clearly wrong. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 10 Feb '08

10 Feb '08

Steve Langasek wrote: > On Sat, Feb 09, 2008 at 11:04:18PM -0800, Howard Chu wrote: >> I cannot duplicate this error with GnuTLS 1.7.8 or 1.7.9. The altname >> length that is returned just includes the non-NUL characters. Note that >> all of libldap's TLS functionality was tested and working with GnuTLS >> 1.7. What version are you using? > > Reproduced with GnuTLS 2.0.4 and GnuTLS 2.2.1. > >> It seems to me that if your version of GnuTLS is indeed behaving this way, >> then it's a GnuTLS bug, since in C, the length of a string never includes >> the trailing NUL. > > It's true that the /length/ of a string doesn't include the trailing NUL, > but it does have to be included in the storage /size/ of a C string, and > it's debatable which is intended here. Since this is an ASN.1 structure, one would ordinarily not expect any NUL termination in the first place. And since other GnuTLS library functions are returning the raw data size, excluding any trailing NUL, the behavior you're seeing here is pretty suspicious. > Given that one of the errors > returned by gnutls_x509_crt_get_subject_alt_name() is > GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use > semantics for storage size rather than string length, and the only question > in my mind is whether the trailing NUL is included as part of the internal > representation of the string. > > If this is a behavior change as you say, then I guess we need clarification > from GnuTLS upstream about whether this is intentional. That sounds like the best step for now. Just to be sure, how was the certificate created? Have you verified that libldap with OpenSSL accepts the certificate correctly? So far it sounds just as likely to me that your subjectAltName actually includes a trailing NUL in its data. ASN.1 structures don't use NUL-terminated strings here, the DER form requires definite lengths to be encoded up front. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 10 Feb '08

10 Feb '08

On Sat, Feb 09, 2008 at 11:04:18PM -0800, Howard Chu wrote: > I cannot duplicate this error with GnuTLS 1.7.8 or 1.7.9. The altname > length that is returned just includes the non-NUL characters. Note that > all of libldap's TLS functionality was tested and working with GnuTLS > 1.7. What version are you using? Reproduced with GnuTLS 2.0.4 and GnuTLS 2.2.1. > It seems to me that if your version of GnuTLS is indeed behaving this way, > then it's a GnuTLS bug, since in C, the length of a string never includes > the trailing NUL. It's true that the /length/ of a string doesn't include the trailing NUL, but it does have to be included in the storage /size/ of a C string, and it's debatable which is intended here. Given that one of the errors returned by gnutls_x509_crt_get_subject_alt_name() is GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use semantics for storage size rather than string length, and the only question in my mind is whether the trailing NUL is included as part of the internal representation of the string. If this is a behavior change as you say, then I guess we need clarification from GnuTLS upstream about whether this is intentional.

1 0

Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com 10 Feb '08

10 Feb '08

steve.langasek(a)canonical.com wrote: > Full_Name: Steve Langasek > Version: 2.4.7 > OS: Debian > URL: http://people.ubuntu.com/~vorlon/gnutls-altname-nulterminated.patch > Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) > > > When built with GnuTLS, libldap fails to correctly verify DNS hostnames against > the subjectAltName field of the provided certificate. The reason for this is > that, while the "length" that gnutls returns for the CN is equal to the > strlen(), the length returned by gnutls_x509_crt_get_subject_alt_name() includes > a trailing NUL. > > I have verified that the referenced patch corrects this for the case of > non-wildcard DNS subjectAltName values. I have not tested the code for the > wildcarded case, though it seems likely that the same bug applies there and will > need to be fixed. I cannot duplicate this error with GnuTLS 1.7.8 or 1.7.9. The altname length that is returned just includes the non-NUL characters. Note that all of libldap's TLS functionality was tested and working with GnuTLS 1.7. What version are you using? It seems to me that if your version of GnuTLS is indeed behaving this way, then it's a GnuTLS bug, since in C, the length of a string never includes the trailing NUL. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by hyc＠symas.com 10 Feb '08

10 Feb '08

rra(a)stanford.edu wrote: > rra(a)stanford.edu writes: >> ldapsearch calls getaddrinfo inside a mutex because on many systems it's >> not thread-safe. However, this means that if libnss-ldap is in use and >> pointing to LDAP for host information, we get deadlock. ldapsearch >> calls getaddrinfo(), which calls into libnss-ldap, which tries to open a >> connection, which then hits the same lock inside the LDAP libraries. > Oh, and incidentally, if you're wondering why ldapsearch is using > libldap_r and hence getting this mutex at all, it's because of the issue > that I raised on openldap-technical (which I can also file an ITS about if > it would be appropriate). We can't ship both libldap and libldap_r and > have some applications linked against one and some against the other > because they expose the same symbols and it's caused problems in the past. > Right now, pending advice, we're taking the easiest possible solution and > just linking everything against libldap_r. libldap_r was written solely for use by slapd and slurpd. Anybody else who uses it does so at their own risk. Applications are supposed to link with libldap. This has been stated several times before. Until somebody decides to invest some energy into writing a new C API spec, (simply dusting off the expired C API draft won't cut it) there is not and will never be any official support for threading/re-entrancy in the LDAP API. > But this particular problem probably wouldn't happen without that. So one > solution may be to fix *that* problem, and any advice there is most > definitely welcome. (However, I would expect any slapd backend that > itself did a search to possibly have this same issue, so fixing ldapsearch > may not fix the full problem.) Unfortunately your problems with libnss-ldap are outside our purview, and any ITS relating to it will just be closed/rejected. The fact that nss-ldap is essentially broken is not for us to fix. The problems you encounter from breaking our Makefiles in response to the nss-ldap problems are also obviously not for us to fix; you did that to yourself. Unofficially, I would suggest that you look into nss-ldapd. I haven't used it personally, and have no idea what's missing in the current implementation. But it at least has a fighting chance of working sanely. The other obvious step in this situation is never to use LDAP for hostname resolution. ("Doctor, it hurts when I do this." - "Don't do that.") LDAP is a much heavier weight protocol than DNS; as such it's simply the wrong tool for the job. (Note - I like using DNS servers backed by LDAP, but that's a completely different situation.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by rra＠stanford.edu 10 Feb '08

10 Feb '08

rra(a)stanford.edu writes: > ldapsearch calls getaddrinfo inside a mutex because on many systems it's > not thread-safe. However, this means that if libnss-ldap is in use and > pointing to LDAP for host information, we get deadlock. ldapsearch > calls getaddrinfo(), which calls into libnss-ldap, which tries to open a > connection, which then hits the same lock inside the LDAP libraries. Oh, and incidentally, if you're wondering why ldapsearch is using libldap_r and hence getting this mutex at all, it's because of the issue that I raised on openldap-technical (which I can also file an ITS about if it would be appropriate). We can't ship both libldap and libldap_r and have some applications linked against one and some against the other because they expose the same symbols and it's caused problems in the past. Right now, pending advice, we're taking the easiest possible solution and just linking everything against libldap_r. But this particular problem probably wouldn't happen without that. So one solution may be to fix *that* problem, and any advice there is most definitely welcome. (However, I would expect any slapd backend that itself did a search to possibly have this same issue, so fixing ldapsearch may not fix the full problem.) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5360) wrong default for TLSVerifyClient (with GnuTLS?)
by hyc＠symas.com 10 Feb '08

10 Feb '08

steve.langasek(a)canonical.com wrote: > Full_Name: Steve Langasek > Version: 2.4.7 > OS: Debian > URL: http://people.ubuntu.com/~vorlon/slapd-tlsverifyclient-default.patch > Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) > > > The code in slapd whose purpose is to override the library default value for > LDAP_OPT_X_TLS_REQUIRE_CERT is failing, at least when OpenLDAP is built with > GnuTLS, because the override is done to a set of "global" options which are > never used. > > The patch referenced below has been verified to fix this issue. Thanks for the patch, committed to HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by rra＠stanford.edu 10 Feb '08

10 Feb '08

hyc(a)symas.com writes: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.7 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.23.156.219) >> As reported in the Debian BTS, and Howard has seen this as well: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024 > Also, as usual, a GDB stack trace from a slapd with debug symbols would > be useful. strace is generally useless since it only traces system > calls, not application code. I wish whoever is telling people to provide > strace output would quit that. Just for reference, if you ever need to get real stack traces from people who are using Debian packages, tell them to install slapd-dbg first. That package contains the detached debugging information for slapd, which gdb will pick up automatically if it's installed. (It's still an optimized build, so the resulting backtrace may leave something to be desired, but it's at least not completely useless.) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
by rra＠stanford.edu 10 Feb '08

10 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.64.19.147) ldapsearch calls getaddrinfo inside a mutex because on many systems it's not thread-safe. However, this means that if libnss-ldap is in use and pointing to LDAP for host information, we get deadlock. ldapsearch calls getaddrinfo(), which calls into libnss-ldap, which tries to open a connection, which then hits the same lock inside the LDAP libraries. Not sure the best fix for this. Removing the locks fixes the deadlock and is safe for glibc systems since glibc's getaddrinfo is thread-safe; however, it would not be safe on those other systems that prompted the lock in the first place. See http://bugs.debian.org/340601 for reference including the patch that appears to clear the deadlock on Debian that Steve came up with while tracking the problem down. I'm guessing that you don't want it in its current form, but it may be useful for reference.

1 0

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by hyc＠symas.com 10 Feb '08

10 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.7 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > As reported in the Debian BTS, and Howard has seen this as well: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024 Also, as usual, a GDB stack trace from a slapd with debug symbols would be useful. strace is generally useless since it only traces system calls, not application code. I wish whoever is telling people to provide strace output would quit that. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by hyc＠symas.com 10 Feb '08

10 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.7 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > As reported in the Debian BTS, and Howard has seen this as well: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024 I saw a similar problem while investigating ITS#5332. While ldapadd'ing 1000 entries I saw several instances where a cookie was sent without a CSN. It didn't result in a crash though. After sprinkling some assert's in the code I think I've identified the problem, and the current code in HEAD no longer triggers any of the assert's that I used. But I'm not certain that the behavior I was chasing is the same as in this bug report. Please test and report your results. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by quanah＠OpenLDAP.org 09 Feb '08

09 Feb '08

Full_Name: Quanah Gibson-Mount Version: 2.4.7 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) As reported in the Debian BTS, and Howard has seen this as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024

1 0

Re: (ITS#5344) Wrong check for bad Modify DN
by ando＠sys-net.it 09 Feb '08

09 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >>> The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it >>> requires newSuperior to be in the same backend. That does not catch >>> moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y". >> I don't see how it can miss this. > > It checks if newSuperior is in another backend, but that move doesn't > need a newSuperior. It keeps the same parent: > > database 1: suffix cn=y > database 2: suffix cn=z,cn=y > modify rdn: dn "cn=x,cn=y"; newrdn cn=z; newSuperior (if any) cn=y. > >> Probably should look at adding the dest_dn to the op struct, so each >> backend doesn't have to rebuild it. > > Indeed. And dest_ndn. You should apply your initial patch (to HEAD, 2.4), then modify HEAD to pass dest_dn/dest_ndn p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 09 Feb '08

09 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/gnutls-altname-nulterminated.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) When built with GnuTLS, libldap fails to correctly verify DNS hostnames against the subjectAltName field of the provided certificate. The reason for this is that, while the "length" that gnutls returns for the CN is equal to the strlen(), the length returned by gnutls_x509_crt_get_subject_alt_name() includes a trailing NUL. I have verified that the referenced patch corrects this for the case of non-wildcard DNS subjectAltName values. I have not tested the code for the wildcarded case, though it seems likely that the same bug applies there and will need to be fixed.

1 0

(ITS#5360) wrong default for TLSVerifyClient (with GnuTLS?)
by steve.langasek＠canonical.com 09 Feb '08

09 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/slapd-tlsverifyclient-default.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) The code in slapd whose purpose is to override the library default value for LDAP_OPT_X_TLS_REQUIRE_CERT is failing, at least when OpenLDAP is built with GnuTLS, because the override is done to a set of "global" options which are never used. The patch referenced below has been verified to fix this issue.

1 0

(ITS#5359) Add BDB encryption support
by hyc＠OpenLDAP.org 09 Feb '08

09 Feb '08

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Encryption support was added to HEAD on 2007-12-15. Just filing this here for tracking purposes. Some discussion followed here http://www.openldap.org/lists/openldap-devel/200712/msg00082.html

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 08 Feb '08

08 Feb '08

Howard Chu writes: >Hallvard B Furuseth wrote: >>hyc(a)symas.com writes: >>> Frankly this whole example doesn't make sense, and RFC4511 doesn't say >>> anything specific about it. >> >> Yes it does. Section 4.1.10. Referral: >> - If the<dn> part is present, the client uses this name in its next >> request to progress the operation, and if it is not present the >> client uses the same name as in the original request. > > Yes, I saw that. But the text doesn't give any explanation of the > ramifications of what it's describing. Which is what I'm complaining > about here. Take it up with ldapext:-) And I guess we could make a slapd.conf option which turns on your preferred way. The ramifications are that things can break, I think. In particular DN-valued attributes in the search result or in an Add request. The server can't help with that either, the client would have to handle it. Also, now that I think of it, back-hdb/ldif subtree rename is broken if there are referral objects with DNs in the subtree. So I guess the slapd.conf option should allow to strip DNs that match the entry DN. And maybe allow to be more paranoid about rewriting writes (and Binds?) than searches. However... >> Both RFCs disagree. > > They are wrong. Or at least, under-specified. In X.501 section 17.3 > "Directory Distribution Model" it's quite clear that all of the > components of a distributed directory must belong to a single DIT. Which is not true in the LDAP world, and I don't know about today's X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe the X.500 world has also switched to 'dc' structure, I don't know. Anyway, LDAP is not X.500. Remember, LDAP referrals need not even be LDAP URLs. My guess is that's one reason for the difference from X.500: When you can even return a HTTP URL, why should you _not_ be allowed to return a far smaller change from the original URL? Also LDAP started out a lot sloppier than X.500. Getting some response which hopefully resembled what you wanted was better than none:-) > And again, the service model requires the directory to store the > client's data without any alteration. If the client wants to create > the entry "cn=me,o=we" either that exact entry must be created, or the > operation must fail. Well, the operation does fail in the original server. Then the client may try another operation at another server... I don't know if that's a valid interpretation of the service model or not. In any case, it's a detail compared to the mess -- Hallvard

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Howard Chu wrote: > Oren Laadan wrote: >> Howard Chu wrote: >>> This discussion has wandered off of potential bugs and into regular >>> software usage. You should pick this up again on the -software mailing >>> list. This ITS will be closed. >> >> Well, the fact is that as far as I can tell the meta-URIs are not >> mis-configured, the server works well for some random amount of time >> and then reaches a lockup. True, the configuration isn't the optimal >> in terms of performance. However, in the absence of text in the man >> pages that prohibits doing so, the observed behavior is buggy. >> >> In fact, there is at least one example in the archives of -software >> that discusses a deployment of meta with "uri ldap://localhost/" that >> seems to have gone ok without too much criticism: >> http://www.openldap.org/lists/openldap-software/200301/msg00112.html) > > The URIs in that example clearly do not overlap with the actual meta > database. It's also not stated in the example, but it's most likely that > that example is directing queries to a separate slapd process. In your > config, your URIs clearly *do* overlap with your meta database, which > guarantees an infinite loop. True. The guy is merging three subtrees into a single tree to a common root, while I try to merge two database that into the exact same DN. > >> To that I'll add, that to the best of my knowledge and after reading >> and re-reading the docs and the man-pages, I cannot find another way >> to merge two databases (not distinct subtrees) such that a local db >> adds entries to a remote db, but to use meta. > > You haven't provided any information to explain why you cannot structure > your additional entries as a distinct subtree. You're still just > handwaving when we ask for concrete examples of the entries involved. Clearly I'm new to LDAP. Please indicate what information is missing, I'll be happy to provide, even the local database (my .ldif file) and sample queries from the remote server. Just name it. Taking a step back: we have a departmental LDAP server for user auth, (posix) groups, autofs maps and so on. In my group, we add to the DB groups and autofs maps that do not exist on the remote server, so a user on our machines can belong to additional groups. I am not arguing that I cannot structure it differently. I simply do not know if I can structure it differently. Ideally I could add entries to the remote database, but that is impossible. The remote server gives DN dc=MAIN,dc=EXAMPLE,dc=COM, which is what I made the local server give (via the meta backend) and which is what the clients are using as their base DN. The local database (.ldif file) currently looks like this, in this example adding the group LOCAL_GRP with user USER1 USER2 (there are more entries, also for autofs maps, but I think this explains the idea). # root/base dn: dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM dc: EXAMPLE objectClass: top objectClass: domain # group subtree dn: ou=Group,dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM ou: Group objectClass: top objectClass: organizationalUnit # specific group information dn: cn=LOCAL_GRP,ou=Group,dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM cn: LOCAL_GRP objectClass: posixGroup objectClass: uidObject gidNumber: 1000 memberUid: USER1 memberUid: USER2 uid: root > The best of your knowledge clearly didn't get you very far or you > wouldn't have been asking for help in the first place. For you to > second-guess the folks trying to help you and omit the information > requested really isn't very productive. No need to make it a personal. I'm new to LDAP, but not clueless either. I truly appreciate the time and efforts that you guys are putting into this issue (and ldap in general). I only omit information because I'm not aware of its importance to you. It helps if you indicate what's missing, and I'll provide promptly, as I've been doing so far. > >> So: the config seems fine (see the original ticket), I need to use meta, >> but it exhibits random lockups. Using a suboptimal solution is not a >> bug. Random lockups are a symptom of a bug :( > > No. Lockups due to thread exhaustion are a symptom of a bad configuration. I then suggest that this specific issue be mentioned in the ldap-meta man-page (as it is now, it doesn't read so), for the sake of others. > >> (That said, I will ask on the -software list with regard to alternative >> configurations, as you suggest). (also sent a message to the -software list as you suggested; made it with shorted DN for simplicity) Thanks, Oren.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 08 Feb '08

08 Feb '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Frankly this whole example doesn't make sense, and RFC4511 doesn't say >> anything specific about it. > > Yes it does. Section 4.1.10. Referral: > - If the<dn> part is present, the client uses this name in its next > request to progress the operation, and if it is not present the > client uses the same name as in the original request. Yes, I saw that. But the text doesn't give any explanation of the ramifications of what it's describing. Which is what I'm complaining about here. >> A referral is not an alias. If I try to add an entry "cn=me,o=we" then >> that is the DN that the entry must be created with. If something >> redirects me to create "cn=me,o=they" this should be an error - that >> is not the entry I requested the server to create. > Both RFCs disagree. They are wrong. Or at least, under-specified. In X.501 section 17.3 "Directory Distribution Model" it's quite clear that all of the components of a distributed directory must belong to a single DIT. And again, the service model requires the directory to store the client's data without any alteration. If the client wants to create the entry "cn=me,o=we" either that exact entry must be created, or the operation must fail. > RFC 4511 4.1.10. Referral: > - It is RECOMMENDED that the<dn> part be present to avoid ambiguity. > RFC 3296 section 2.2 (about 'ref'): > The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP > URLs with absent or empty DN parts or with explicit scope specifier > is not defined by this specification. > RFC 3296 Section 5.2: > The DN part MUST be modified such that it refers to the appropriate > target in the referenced server (as detailed below). Even where the > DN to be returned is the same as the target DN, the DN part SHOULD > NOT be trimmed. The X.500 model does not allow for arbitrary DNs to be inserted here. The RFC text implies that arbitrary DNs are allowed, but that's incorrect. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 08 Feb '08

08 Feb '08

hyc(a)symas.com writes: > Frankly this whole example doesn't make sense, and RFC4511 doesn't say > anything specific about it. Yes it does. Section 4.1.10. Referral: - If the <dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request. > A referral is not an alias. If I try to add an entry "cn=me,o=we" then > that is the DN that the entry must be created with. If something > redirects me to create "cn=me,o=they" this should be an error - that > is not the entry I requested the server to create. RFC 3296 (Named Subordinate References in LDAP) disagrees: 4. Named Subordinate References Typically the DN of the referral object and the DN of the object in ^^^^^^^^^ the referenced server are the same. 5.1. Example Configuration dn: OU=People,O=MNN,C=WW ^^^^ ou: People ref: ldap://hostb/OU=People,O=MNN,C=US ref: ldap://hostc/OU=People,O=MNN,C=US ^^^^ objectClass: referral objectClass: extensibleObject > In general, I think it is inappropriate for referral URIs to contain DNs. Both RFCs disagree. RFC 4511 4.1.10. Referral: - It is RECOMMENDED that the <dn> part be present to avoid ambiguity. RFC 3296 section 2.2 (about 'ref'): The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP URLs with absent or empty DN parts or with explicit scope specifier is not defined by this specification. RFC 3296 Section 5.2: The DN part MUST be modified such that it refers to the appropriate target in the referenced server (as detailed below). Even where the DN to be returned is the same as the target DN, the DN part SHOULD NOT be trimmed. -- Hallvard

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by hyc＠symas.com 08 Feb '08

08 Feb '08

Oren Laadan wrote: > Howard Chu wrote: >> This discussion has wandered off of potential bugs and into regular >> software usage. You should pick this up again on the -software mailing >> list. This ITS will be closed. > > Well, the fact is that as far as I can tell the meta-URIs are not > mis-configured, the server works well for some random amount of time > and then reaches a lockup. True, the configuration isn't the optimal > in terms of performance. However, in the absence of text in the man > pages that prohibits doing so, the observed behavior is buggy. > > In fact, there is at least one example in the archives of -software > that discusses a deployment of meta with "uri ldap://localhost/" that > seems to have gone ok without too much criticism: > http://www.openldap.org/lists/openldap-software/200301/msg00112.html) The URIs in that example clearly do not overlap with the actual meta database. It's also not stated in the example, but it's most likely that that example is directing queries to a separate slapd process. In your config, your URIs clearly *do* overlap with your meta database, which guarantees an infinite loop. > To that I'll add, that to the best of my knowledge and after reading > and re-reading the docs and the man-pages, I cannot find another way > to merge two databases (not distinct subtrees) such that a local db > adds entries to a remote db, but to use meta. You haven't provided any information to explain why you cannot structure your additional entries as a distinct subtree. You're still just handwaving when we ask for concrete examples of the entries involved. The best of your knowledge clearly didn't get you very far or you wouldn't have been asking for help in the first place. For you to second-guess the folks trying to help you and omit the information requested really isn't very productive. > So: the config seems fine (see the original ticket), I need to use meta, > but it exhibits random lockups. Using a suboptimal solution is not a > bug. Random lockups are a symptom of a bug :( No. Lockups due to thread exhaustion are a symptom of a bad configuration. > (That said, I will ask on the -software list with regard to alternative > configurations, as you suggest). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Howard Chu wrote: > Oren Laadan wrote: >> >> Pierangelo Masarati wrote: >>> hyc(a)symas.com wrote: >>>> Oren Laadan wrote: >>>>>> It shows enough; back-meta is hanging waiting for responses from >>>>>> some other >>>>>> LDAP server. This is a pretty bad configuration; you should not >>>>>> use back-meta >>>>>> (or back-ldap) to redirect queries back into the same slapd. You >>>>>> should use >>>>>> back-relay instead. >>>>> I'm not quite sure why having the server query itself is such a bad >>>>> idea. >>>>> Can you please explain ? >>>> Any request then occupies a minimum of two slapd threads - one for >>>> back-meta >>>> itself, and one for the extra inbound query. If you misconfigure the >>>> meta URIs >>>> then you get into an infinite loop, which consumes all of the >>>> available slapd >>>> threads. >>> Let me add that, moreover, any request is re-encoded as an LDAP request, >>> sent to itself, re-decoded and re-processed by slapd. Back-relay >>> directly relies the original, decoded request to another database, >>> within the same thread. So it saves at least 3 resource-consuming >>> steps- >>> >> >> Ok, I see the rational. So I guess my question is whether back-relay >> gives >> the same functionality like ldap-meta (that is, merging the two >> databases, >> the remote one and the local one) except better with respect to a local >> database ? and if so, then how would I set it up for this ? >> >> I looked at "subordinate" directive but I'm not sure it helps, since as >> far as I could tell it can join two disjoint subtrees into seemingly one >> big database. However, what I need is to add local (new) entries (not >> only modify attributes) to an existing database. > > This discussion has wandered off of potential bugs and into regular > software usage. You should pick this up again on the -software mailing > list. This ITS will be closed. Well, the fact is that as far as I can tell the meta-URIs are not mis-configured, the server works well for some random amount of time and then reaches a lockup. True, the configuration isn't the optimal in terms of performance. However, in the absence of text in the man pages that prohibits doing so, the observed behavior is buggy. In fact, there is at least one example in the archives of -software that discusses a deployment of meta with "uri ldap://localhost/" that seems to have gone ok without too much criticism: http://www.openldap.org/lists/openldap-software/200301/msg00112.html) To that I'll add, that to the best of my knowledge and after reading and re-reading the docs and the man-pages, I cannot find another way to merge two databases (not distinct subtrees) such that a local db adds entries to a remote db, but to use meta. So: the config seems fine (see the original ticket), I need to use meta, but it exhibits random lockups. Using a suboptimal solution is not a bug. Random lockups are a symptom of a bug :( (That said, I will ask on the -software list with regard to alternative configurations, as you suggest). Oren.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 08 Feb '08

08 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If a referral object's "ref" DN differs from the entry DN, and > you update a subordinate of the referral object, the DN part > of the referral from back-bdb is wrong. > > bash$ cat ref.ldif > dn: o=we > o: we > ref: ldap://elsewhere/o=they > objectClass: referral > objectClass: extensibleObject > > dn: cn=me,o=we > cn: me > objectClass: organizationalRole > > bash$ ldapadd ...< ref.ldif > adding new entry "o=we" > > adding new entry "cn=me,o=we" > ldap_add: Referral (10) > matched DN: o=we > referrals: > ldap://elsewhere/cn=me,o=we Frankly this whole example doesn't make sense, and RFC4511 doesn't say anything specific about it. A referral is not an alias. If I try to add an entry "cn=me,o=we" then that is the DN that the entry must be created with. If something redirects me to create "cn=me,o=they" this should be an error - that is not the entry I requested the server to create. In general, I think it is inappropriate for referral URIs to contain DNs. It is inappropriate for the server to alter the DN that the client supplied. In the case of a search, it is inappropriate for the server to continue the search outside the scope specified by the client. E.g., if the client requests a subtree search with base "o=we" it is incorrect for the client to receive entries based at "o=they". (Aliases are an exception to this behavior, but aliases also are only valid for searches, not for any other operation.) > It works if NULL is changed to&e->e_name at back-bdb/referral.c line 96: > > rs->sr_ref = referral_rewrite( ref, NULL, > &op->o_req_dn, LDAP_SCOPE_DEFAULT ); > > I don't quite understand that function though: > Why does it use default_referral (slapd.conf 'referral')? That is for > use when no local backend database handles the operation, which I would > think means no database's be_chk_referrals() gets be called. And indeed > the function uses it if > !be_issuffix( op->o_bd,&op->o_req_ndn ) > which looks to me like a test for whether this function is _not_ to be > called for this database. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by hyc＠symas.com 08 Feb '08

08 Feb '08

Oren Laadan wrote: > > Pierangelo Masarati wrote: >> hyc(a)symas.com wrote: >>> Oren Laadan wrote: >>>>> It shows enough; back-meta is hanging waiting for responses from some other >>>>> LDAP server. This is a pretty bad configuration; you should not use back-meta >>>>> (or back-ldap) to redirect queries back into the same slapd. You should use >>>>> back-relay instead. >>>> I'm not quite sure why having the server query itself is such a bad idea. >>>> Can you please explain ? >>> Any request then occupies a minimum of two slapd threads - one for back-meta >>> itself, and one for the extra inbound query. If you misconfigure the meta URIs >>> then you get into an infinite loop, which consumes all of the available slapd >>> threads. >> Let me add that, moreover, any request is re-encoded as an LDAP request, >> sent to itself, re-decoded and re-processed by slapd. Back-relay >> directly relies the original, decoded request to another database, >> within the same thread. So it saves at least 3 resource-consuming steps- >> > > Ok, I see the rational. So I guess my question is whether back-relay gives > the same functionality like ldap-meta (that is, merging the two databases, > the remote one and the local one) except better with respect to a local > database ? and if so, then how would I set it up for this ? > > I looked at "subordinate" directive but I'm not sure it helps, since as > far as I could tell it can join two disjoint subtrees into seemingly one > big database. However, what I need is to add local (new) entries (not > only modify attributes) to an existing database. This discussion has wandered off of potential bugs and into regular software usage. You should pick this up again on the -software mailing list. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> Oren Laadan wrote: >>>> It shows enough; back-meta is hanging waiting for responses from some other >>>> LDAP server. This is a pretty bad configuration; you should not use back-meta >>>> (or back-ldap) to redirect queries back into the same slapd. You should use >>>> back-relay instead. >>> I'm not quite sure why having the server query itself is such a bad idea. >>> Can you please explain ? >> Any request then occupies a minimum of two slapd threads - one for back-meta >> itself, and one for the extra inbound query. If you misconfigure the meta URIs >> then you get into an infinite loop, which consumes all of the available slapd >> threads. > > Let me add that, moreover, any request is re-encoded as an LDAP request, > sent to itself, re-decoded and re-processed by slapd. Back-relay > directly relies the original, decoded request to another database, > within the same thread. So it saves at least 3 resource-consuming steps- > Ok, I see the rational. So I guess my question is whether back-relay gives the same functionality like ldap-meta (that is, merging the two databases, the remote one and the local one) except better with respect to a local database ? and if so, then how would I set it up for this ? I looked at "subordinate" directive but I'm not sure it helps, since as far as I could tell it can join two disjoint subtrees into seemingly one big database. However, what I need is to add local (new) entries (not only modify attributes) to an existing database. Thanks, Oren. > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > 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#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

So, I followed your suggestion and set up the following config using overlay translucent: ... modulepath /opt/ldap/lib/ moduleload back_ldap moduleload back_bdb moduleload translucent ... backend bdb ... database bdb suffix "dc=CS,dc=EXAMPLE,dc=COM" readonly on directory "/var/lib/ldap" ... overlay translucent uri "ldaps://ORIG_SERVER_IP/" lastmod off translucent_no_glue ... The good news: it runs. The bad news: it doesn't do what I want :( "ldapsearch -x" dumps the full contents of the original (remote) server. But it doesn't give any of the entries in the local DB. If I take out the translucent directives, then "ldapsearch -x" does dump the contents of the local DB. >>> * I need to build a server that extends the contents of that server, for >>> the same domain; but I don't have access to the DB of that server. >> See slapo-translucent, which was written specifically for this reason. Re-reading the man page - it says: "Entries retrieved from a remote LDAP server may have some or all attributes overridden, or new attributes added, by entries in the local database before being presented to the client." However my local DB _extends_ the original server, that is: it adds _new entries_, as opposed to overriding attributes of existing entries. Again, this is why I selected the ldap-meta is the first place. Either that, or something has gone wrong with the configuration ? >> I would use back-ldap to contact the remote server and subordinate glue >> for the local bdb database. How would I go about the "subordinate glue" ? Oren. orenl(a)cs.columbia.edu wrote: > Hi, > > Howard Chu wrote: >> Oren Laadan wrote: >>>> It shows enough; back-meta is hanging waiting for responses from some >>>> other >>>> LDAP server. This is a pretty bad configuration; you should not use >>>> back-meta >>>> (or back-ldap) to redirect queries back into the same slapd. You >>>> should use >>>> back-relay instead. >>> I'm not quite sure why having the server query itself is such a bad idea. >>> Can you please explain ? >> Any request then occupies a minimum of two slapd threads - one for >> back-meta itself, and one for the extra inbound query. If you >> misconfigure the meta URIs then you get into an infinite loop, which >> consumes all of the available slapd threads. > > The URIs are configured as following (see my original ITS post > for the full config file): > > database meta > lastmod off > suffix "dc=CS,dc=EXAMPLE,dc=COM" > > uri "ldaps://ldap.cs.example.com/dc=CS,dc=EXAMPLE,dc=COM" > uri "ldaps:///dc=CS,dc=EXAMPLE,dc=COM" > suffixmassage "dc=CS,dc=EXAMPLE,dc=COM" "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >>> Let me repeat how my setup works: >>> >>> * there exists an LDAP server "ldap.cs.example.com" for domain >>> CS.EXAMPLE.COM >>> >>> * I need to build a server that extends the contents of that server, for >>> the same domain; but I don't have access to the DB of that server. >> See slapo-translucent, which was written specifically for this reason. > > I see. Am trying to build a new config using this overlay now. > >>> * My clients will use my server, with the domain CS.EXAMPLE.COM >>> (instead of >>> querying the original server) >> Please stop using the "domain" terminology. LDAP uses Distinguished >> Names, not domains. Tell us the distinguished names of the server >> contexts you're dealing with. Tell us the actual DNs of the entries >> you're dealing with. > > Yes are correct. I confuse the two terms because the DNs follow the > convention of the network domains. So -- > > the original server servers "dc=CS,dc=EXAMPLE,dc=COM" > my server serves the same DNs for the clients; however the "extra" > local DB that I created is set for "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >>> * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that >>> serves two >>> databases: >>> >>> (1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very >>> small >>> database (less than 100 entries). >>> >>> (2) a META-backend for domain CS.EXAMPLE.COM that is configured to >>> relay >>> to both the original server (ldap.cs.example.com) and also relay >>> to the >>> local (other) server (ldap.mine.cs.example.com); the second relay >>> is done >>> with "suffixmassage" to convert from CS.EXAMPLE.COM to >>> MINE.CS.EXAMPLE.COM >>> and back. >>> >>> So, yes, my server/2nd-DB effectively relays queries to the my >>> server/1st-DB >>> The questions are: >>> >>> (1) why is this such a bad idea ? >> See above. >> >>> (2) how would I use back-ldap in place ? >> I would use back-ldap to contact the remote server and subordinate glue >> for the local bdb database. >> >>> Note that the reason to originally select the meta-ldap backend was >>> because >>> it was the only one that I could find in the docs that automagically >>> merges >>> two separate databases and presents them as a single database the client. >> I think you should be able to construct your DIT without needing to do >> any suffix massaging. >> > > The reason I needed the suffix massaging in my setup is because I had > two servers coexisting on the same machine: one that is used by the > clients, and one that is used by the server itself through ldap-meta; > > since the one visible to the clients was already "dc=CS,dc=EXAMPLE,dc=COM" > I had to make the other one do a different DN, hence the addition of > the "dc=MINE" at the beginning, and the suffix massaging > > I hope that overlay translucent works, and that it does away with this > ugly trick that I had to put there. > > I'm now re-doing the config to try it out. Many thanks to everybody > for the help so far. > > Oren. > >

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by ando＠sys-net.it 08 Feb '08

08 Feb '08

hyc(a)symas.com wrote: > Oren Laadan wrote: >>> It shows enough; back-meta is hanging waiting for responses from some other >>> LDAP server. This is a pretty bad configuration; you should not use back-meta >>> (or back-ldap) to redirect queries back into the same slapd. You should use >>> back-relay instead. >> I'm not quite sure why having the server query itself is such a bad idea. >> Can you please explain ? > > Any request then occupies a minimum of two slapd threads - one for back-meta > itself, and one for the extra inbound query. If you misconfigure the meta URIs > then you get into an infinite loop, which consumes all of the available slapd > threads. Let me add that, moreover, any request is re-encoded as an LDAP request, sent to itself, re-decoded and re-processed by slapd. Back-relay directly relies the original, decoded request to another database, within the same thread. So it saves at least 3 resource-consuming steps- p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5332) multimaster replication crash
by hyc＠symas.com 08 Feb '08

08 Feb '08

ghenry(a)suretecsystems.com wrote: > <quote who="Marcel Ritter"> >> Gavin Henry schrieb: >>> Marcel.Ritter(a)rrze.uni-erlangen.de wrote: >>>> Full_Name: Marcel Ritter >>>> Version: HEAD >>>> OS: Linux (openSUSE 10.3) >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (131.188.78.179) >>>> When using multimaster replication slapd dies (on x86_64). >>>> >>>> I've used the scripts/test050-syncrepl-multimaster with one simple >>>> modification: I added one ldapadd command at the end of the script, >>>> trying to add some 20000 entries. >>>> >>> Have you tried this on a release, i.e. 2.4.7, not HEAD? >> Yes - I tried with 2.4.7 first. Then I asked Ralf Haferkamp from >> SuSE/Novell >> (he build's openldap 2.4 packages on the openSUSE Build Service) wether >> he had run some tests on this topic, but he declined and suggested to test >> with HEAD version. >> >> I tried this too, but to the same result. >> >> I've run my tests both on SuSE Linux Enterprise Server 10 and openSUSE >> 10.3. >> As far as I tested, this occurs only on x86_64 systems (i386 seems to >> get into >> an endless loop instead - but this may be for a different reason ...) I've seen the same crash while trying to add 10,000 entries. A patch for this is now in HEAD. I should point out that it's probably not getting into an endless loop. Just that this test wasn't designed to handle a large number of entries. None of the indexing that is normally recommended for syncrepl is set up in these configurations, so all of the search operations that syncrepl performs will wind up scanning the entire DB multiple times. Also the cache size remains at its default, so that will cause a lot of churn as you continue to operate on more entries. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Hi, Howard Chu wrote: > Oren Laadan wrote: >>> It shows enough; back-meta is hanging waiting for responses from some >>> other >>> LDAP server. This is a pretty bad configuration; you should not use >>> back-meta >>> (or back-ldap) to redirect queries back into the same slapd. You >>> should use >>> back-relay instead. >> >> I'm not quite sure why having the server query itself is such a bad idea. >> Can you please explain ? > > Any request then occupies a minimum of two slapd threads - one for > back-meta itself, and one for the extra inbound query. If you > misconfigure the meta URIs then you get into an infinite loop, which > consumes all of the available slapd threads. The URIs are configured as following (see my original ITS post for the full config file): database meta lastmod off suffix "dc=CS,dc=EXAMPLE,dc=COM" uri "ldaps://ldap.cs.example.com/dc=CS,dc=EXAMPLE,dc=COM" uri "ldaps:///dc=CS,dc=EXAMPLE,dc=COM" suffixmassage "dc=CS,dc=EXAMPLE,dc=COM" "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >> Let me repeat how my setup works: >> >> * there exists an LDAP server "ldap.cs.example.com" for domain >> CS.EXAMPLE.COM >> >> * I need to build a server that extends the contents of that server, for >> the same domain; but I don't have access to the DB of that server. > > See slapo-translucent, which was written specifically for this reason. I see. Am trying to build a new config using this overlay now. > >> * My clients will use my server, with the domain CS.EXAMPLE.COM >> (instead of >> querying the original server) > > Please stop using the "domain" terminology. LDAP uses Distinguished > Names, not domains. Tell us the distinguished names of the server > contexts you're dealing with. Tell us the actual DNs of the entries > you're dealing with. Yes are correct. I confuse the two terms because the DNs follow the convention of the network domains. So -- the original server servers "dc=CS,dc=EXAMPLE,dc=COM" my server serves the same DNs for the clients; however the "extra" local DB that I created is set for "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >> * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that >> serves two >> databases: >> >> (1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very >> small >> database (less than 100 entries). >> >> (2) a META-backend for domain CS.EXAMPLE.COM that is configured to >> relay >> to both the original server (ldap.cs.example.com) and also relay >> to the >> local (other) server (ldap.mine.cs.example.com); the second relay >> is done >> with "suffixmassage" to convert from CS.EXAMPLE.COM to >> MINE.CS.EXAMPLE.COM >> and back. >> >> So, yes, my server/2nd-DB effectively relays queries to the my >> server/1st-DB >> The questions are: >> >> (1) why is this such a bad idea ? > > See above. > >> (2) how would I use back-ldap in place ? > > I would use back-ldap to contact the remote server and subordinate glue > for the local bdb database. > >> Note that the reason to originally select the meta-ldap backend was >> because >> it was the only one that I could find in the docs that automagically >> merges >> two separate databases and presents them as a single database the client. > > I think you should be able to construct your DIT without needing to do > any suffix massaging. > The reason I needed the suffix massaging in my setup is because I had two servers coexisting on the same machine: one that is used by the clients, and one that is used by the server itself through ldap-meta; since the one visible to the clients was already "dc=CS,dc=EXAMPLE,dc=COM" I had to make the other one do a different DN, hence the addition of the "dc=MINE" at the beginning, and the suffix massaging I hope that overlay translucent works, and that it does away with this ugly trick that I had to put there. I'm now re-doing the config to try it out. Many thanks to everybody for the help so far. Oren.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs