openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6034) Assert failure - connection_state_closing / send_ldap_ber / slap_send_search_entry / syncprov_sendresp
by idangerer＠gmail.com 28 Apr '09

28 Apr '09

Hi there, Already posted this a while ago to openldap-bugs, but havn't got a response yet. As the problem still persist in my environment, I'll give it another try here. We upgraded to openldap 2.4.16 a while ago. Since then we are experiencing relatively frequent core dumps (average uptime is around 2-3 days). Investigating the root cause we came across ITS#6034 which reminded us much of problem we are facing, but should be fixed in 2.4.16. Setup: Solaris 10 Openldap 2.4.16 (64bit) Berkeley DB 4.7 1 Master 5 Replicas with deltasyncrepl Cores only happened to the master so far, replicas are running stable so far. I couldn't find a reference to this ITS in the 2.4.16 changelog (probably listed as other ITS or fixed earlier). Also if the fix made it's way into 2.4.16, I am wondering why we still observe this cores. If you need further information or have any suggestions please let me know. Please find some debugging information below. Kind regards, David (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x1004dd428 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x1004dd670 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in __lwp_kill() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() > t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in slap_access_allowed() t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x1004dd1e0 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in __lock_getlocker_int() (dbx) lwp l@10 Current function is connection_state_closing 686 assert( c->c_struct_state == SLAP_C_USED ); t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7decea10 (dbx) where [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), line 148 in "result.c" [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = 0xffffffff733ff2d0), line 1247 in "result.c" [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = 3), line 848 in "syncprov.c" [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line 913 in "syncprov.c" [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), line 971 in "syncprov.c" [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in "tpool.c" (dbx) list 680,690 680 int connection_state_closing( Connection *c ) 681 { 682 /* c_mutex must be locked by caller */ 683 684 int state; 685 assert( c != NULL ); 686 assert( c->c_struct_state == SLAP_C_USED ); 687 688 state = c->c_conn_state; 689 690 assert( state != SLAP_C_INVALID ); (dbx) print c c = 0x1004dce30 (dbx) print *c *c = { c_struct_state = 1 c_conn_state = 0 c_conn_idx = 26 c_sd = -1 c_close_reason = 0x100271eb0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x118772d90 c_starttime = 0 c_activitytime = 0 c_connid = 18446744073709551615U c_peer_domain = { bv_len = 0 bv_val = (nil) } c_peer_name = { bv_len = 0 bv_val = (nil) } c_listener = (nil) c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x1004dcf38 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x1004dcf48 } c_write1_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190080U } __pthread_mutex_owner64 = 4278190080U } __pthread_mutex_data = 18446744071451976704U } c_write1_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_write2_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write2_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_writers = 0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = (nil) c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 3 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 3 c_n_get = 4 c_n_read = 3 c_n_write = 1 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x10006b900 = &slap_send_ldap_result(Operation *op, SlapReply *rs) c_send_search_entry = 0x10006cda0 = &slap_send_search_entry(Operation *op, SlapReply *rs) c_send_search_reference = 0x10006fa80 = &slap_send_search_reference(Operation *op, SlapReply *rs) c_send_ldap_extended = 0x10006c5f8 = &slap_send_ldap_extended(Operation *op, SlapReply *rs) c_send_ldap_intermediate = 0x10006ca28 = &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) }

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 28 Apr '09

28 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

3 3

(ITS#6079) TLS error strings need to be printf() safe
by richton＠nbcs.rutgers.edu 27 Apr '09

27 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Personally I focus on OpenSSL, where ERR_error_string is permitted to return NULL, so we can't Debug() them arbitrarily. This is handled in _connect: 390 Debug( LDAP_DEBUG_ANY,"TLS: can't connect: %s.\n", 391 ld->ld_error ? ld->ld_error : "" ,0,0); but not in _accept: 440 Debug( LDAP_DEBUG_ANY,"TLS: can't accept: %s.\n", 441 tls_imp->ti_session_errmsg( err, buf, sizeof(buf) ),0,0 ); and at least some rc's don't have error strings, so it's all too easy to: t@14 (l@14) signal SEGV (no mapping at the fault address) in strlen at 0xffffffff7ee3d50c 0xffffffff7ee3d50c: strlen+0x007c: ld [%o1], %o2 Current function is ldap_log_printf current thread: t@14 [1] strlen(0x0, 0x0, 0xffffffff46bff1d0, 0x7efefeff, 0x81010100, 0x107a59610), at 0xffffffff7ee3d50c [2] _doprnt(0xffffffff7ea78960, 0xffffffff46bff1d0, 0xffffffff46bff1d0, 0x0, 0x73, 0x0), at 0xffffffff7ee90f50 [3] vsnprintf(0xffffffff46bff31c, 0x3ff, 0xffffffff7ea78960, 0xffffffff46bff7d8, 0x0, 0xffffffff79a23e48), at 0xffffffff7ee9310c =>[4] ldap_log_printf(ld = (nil), loglvl = -1, fmt = 0xffffffff7ea78960 "TLS: can't accept: %s.\n", ... = (nil), ...), line 56 in "print.c" [5] ldap_pvt_tls_accept(sb = 0x11d459e90, ctx_arg = 0x100a6c610), line 441 in "tls2.c" [6] connection_read(s = 215, cri = 0xffffffff46bffaf8), line 1317 in "connection.c" [7] connection_read_thread(ctx = 0xffffffff46bffc20, argv = 0xd7), line 1216 in "connection.c" [8] ldap_int_thread_pool_wrapper(xpool = 0x10064f6a0), line 663 in "tpool.c" I don't know if you want to do a similar tls_imp->() ? tls_imp->() : "" (it'd work but it looks ugly) or make this the job of *_session_errmsg so I didn't write a patch for this...sorry. Actually, come to think of it, there is: 407 return NULL; in tlso_session_errmsg, that would be dangerous too. NULL might also be returned in tls_m. I don't know is gnutls_strerror is safe or not...

1 0

(ITS#6078) Slapd.exe crashes when writing entries while reading many entries.
by Frank.Offermanns＠caseris.de 27 Apr '09

27 Apr '09

Full_Name: Frank Offermanns Version: 2.4.16 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) Hello, i am using OpenLDAP 2.4.16 with Windows XP, compiled with msys/mingw with Windows XP and the berkeley DB 4.7.25 NC The database runs without any replication (though with replication it also crashes) I use the "hdb" Backend. I started the datatbase with "slapd -F slapd.d". Now i add about 21000 Entries under the DN: o=test6,ou=Users,o=caesar. When this is finished i start adding another 21000 Entries under the DN: o=test7,ou=Users,o=caesar. While adding these seconds entries i use the LDAPAdmin 1.1.0.0 to view the subtree at "o=test6,ou=Users,o=caesar". LDAPAdmin starts to read the Users and fails at about the 4000 Entry. At this time my slapd.exe crashed. I also did the test with "slapd -d 1 -F slapd.d" and found the following entries in the logfile: ber_flush2: 77 bytes to sd 2268 ber_get_next: tag 0x30 len 93 contents: <= send_search_entry: conn 0 exit. ber_get_next conn=2 op=4017 do_modify entry_decode: "" ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: <= entry_decode() >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12034,o=test6,ou=Users,o=caesar" => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") ber_flush2: 77 bytes to sd 2268 <= hdb_dn2id: got id=0x53da <= send_search_entry: conn 0 exit. entry_decode: "" entry_decode: "" <= entry_decode() <= entry_decode() bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12035,o=test6,ou=Users,o=caesar" ber_flush2: 77 bytes to sd 2268 entry_decode: "" <= entry_decode() <= send_search_entry: conn 0 exit. bdb_modify_internal: 0x000053da: c²0250 entry_decode: "" <= entry_decode() entry failed schema check: unrecongized attribute type(s) in RDN hdb_modify: modify failed (34) send_ldap_result: conn=2 op=4017 p=3 send_ldap_response: msgid=1026718 tag=103 err=34 => send_search_entry: conn 0 dn="cn=12036,o=test6,ou=Users,o=caesar" ber_flush2: 53 bytes to sd 2336 ber_flush2: 77 bytes to sd 2268 <= send_search_entry: conn 0 exit. entry_decode: "" <= entry_decode() connection_get(4): got connid=2 connection_read(4): checking for input on id=2 ber_get_next ber_get_next: tag 0x30 len 87 contents: ber_get_next conn=2 op=4018 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") <= hdb_dn2id: got id=0x53da entry_decode: "" <= entry_decode() The pointer at "bdb_modify_internal" seems to be dangling. When i didn't read the entries while writing, there seems to be no problem. The Version 2.4.13 also does not seem to have this problem. (I couldn't get the 2.4.13 Version crashing and the 2.4.16 crashes every time after a short time) Additional Info: I am not sure, if this could be a reason for this error, so i am writing this problem also. Starting at Version 2.4.14 the configure command creates makefiles which are not linkable at mingw/msys at windows. I manually added "-lws2_32" in the makefiles at the lines: AC_LIBS = -lregex -lws2_32 I apologize me for my bad english and hope you can understand me. Regards, Frank Offermanns

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 26 Apr '09

26 Apr '09

This is a multi-part message in MIME format. --------------080405020304060402030808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Fixing this for unique_add seams easy enough (see preliminary attached patch) - fixing it for modrdn/modify seems to be another difficulty level as in order to properly apply the filter I think the full modifications have to be applied... If wanted I can produce a patch for this as well, but I would like to know if that is appreciated and if my plan for fixing looks sensible: - Pull the "modification simulation" code out of constraint.c (line 959:1040 and some more in 2.4.16) into constraints.c - Add a overlay-int.h - Make constraint.c and unique.c use that As I dont really know the openldap codebase my analysis could be completely wrong - I would appreciate some feedback. Andres --------------080405020304060402030808 Content-Type: text/x-diff; name="slapd-unique-overlay-spurious-failure-fix-add.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-unique-overlay-spurious-failure-fix-add.patch" --- openldap-2.4.16.saved/servers/slapd/overlays/unique.c 2009-04-23 23:51:37.925387747 +0200 +++ openldap-2.4.16/servers/slapd/overlays/unique.c 2009-04-26 01:58:54.566927667 +0200 @@ -1071,6 +1071,24 @@ && !dnIsSuffix( &op->o_req_ndn, &uri->ndn )) continue; + if (uri->filter.bv_val && uri->filter.bv_len){ + Filter *f = str2filter_x(op, + uri->filter.bv_val); + if(f == NULL) { + op->o_bd->bd_info = (BackendInfo *) on->on_info; + send_ldap_error(op, rs, LDAP_OTHER, + "unique_search invalid filter"); + return(rs->sr_err); + } + + if(test_filter(NULL, op->ora_e, f) == LDAP_COMPARE_FALSE){ + Debug(LDAP_DEBUG_TRACE, "==> unique_add_skip<%s>\n", + op->o_req_dn.bv_val, 0, 0); + continue; + } + filter_free_x(op, f, 1); + } + if(!(a = op->ora_e->e_attrs)) { op->o_bd->bd_info = (BackendInfo *) on->on_info; send_ldap_error(op, rs, LDAP_INVALID_SYNTAX, --------------080405020304060402030808--

1 0

Re: (ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 25 Apr '09

25 Apr '09

Hallvard B Furuseth schrieb: > Yes, the on-th-fly sorting combined with the delete-single-value > code seems broken. I'm not sure if delete-single-value could ever > be invoked Of course could it be "invoked" before: just use slapd 2.4.16 together with slapo-collect and your favorit ldapmodify client. Right after the "invocation" you'll get an error message complaining about a missing equality rule. Thus there's no hint within collect's source that the single-value delete is faulty I inserted an equality rule and began to wonder... > before you inserted an EQUALITY matching rule though. Do you mean the single-value-delete functionality has been silently "disabled" by removing the EQUALITY matching rule leaving slapo-collect's by design defective single-value-delete code block knowingly unchanged/uncommented? This seems very strange to me even more because slapo-collect is advertises as demonstration overlay (ok, a "quick hacked" one but nevertheless questionable). > I too don't know cn=config all that well:-( <speculation> Instead of correcting handling this issue only in collect.c there perhabs exists a more general possibility to pimp the cn=config internal add mechanisms regarding the handling of ordered config values? In my opinion a very important feature concerning "overlapping"... Á la: cfg_value_add(.., .., SLAPD_CFG_VALSORT_ALPHA|SLAPD_CFG_VALSORT_DN|..) only problem seems to be how to sort a configuration value like: '"ou=test,dc=foo,dc=bar" l,st' by DN's depth </speculation>

1 0

(ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 25 Apr '09

25 Apr '09

--000e0cd1e8fc2040e9046856eee5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review http://dmarkey.com/~dmarkey/smbk5pwd.patch to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review <a href="http://dmarkey.com/~dmarkey/smbk5pwd.patch">http://dmarkey.com/~dmarkey/smbk5pwd.patch</a> to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5--

1 0

(ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 25 Apr '09

25 Apr '09

Full_Name: Andres Freund Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (85.178.193.10) If I read the code correctly the unique overlay does not check if the current operation matches the filter of a domain before doing a uniqeness check. This leads to wrongly reported errors. I noticed this after adding a uniqueness constraint on gidNumber on all posixGroup objects (i.e. ldap:///?gidNumber?sub?(objectClass=posixGroup)) - it was not possible anymore to add posixAccounts with that gidNumber. Thanks, Andres Here a modification of the testscript to reproduce the issue: --- openldap-2.4.16.saved/tests/scripts/test024-unique 2009-04-23 23:51:37.942051631 +0200 +++ openldap-2.4.16/tests/scripts/test024-unique 2009-04-25 02:50:40.975257488 +0200 @@ -425,6 +425,7 @@ changetype: modify add: olcUniqueURI olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) - delete: olcUniqueURI olcUniqueURI: ldap:///?description?one @@ -445,6 +446,7 @@ olcOverlay: {0}unique olcUniqueURI: ldap:///?employeeNumber,displayName?sub olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) EOF diff $TESTDIR/third-config.ldif $TESTDIR/third-reference.ldif > /dev/null 2>&1 @@ -473,6 +475,27 @@ exit -1 fi + +echo "Adding a record unique in all domains because of filter conditions " + +$LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \ + $TESTOUT 2>&1 << EOF +dn: uid=empty,ou=users,o=unique +objectClass: inetOrgPerson +uid: edgar +cn: empty +sn: empty +EOF + +RC=$? +if test $RC != 0 ; then + echo "spurious unique error ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit -1 +fi + + + echo "Adding a record unique in one domain, non-unique in the filtered domain..." $LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \

1 0

24 Apr '09

Yes, the on-th-fly sorting combined with the delete-single-value code seems broken. I'm not sure if delete-single-value could ever be invoked before you inserted an EQUALITY matching rule though. I too don't know cn=config all that well:-( -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

oops, lost a few words: I wrote: > I'll fix that and a few other comments and close this ITS, > since you've clarified issue here in ITS#6076. Since you've clarified _the other_ issue here in ITS#6076. -- Hallvard

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs