openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 21 Jun '08

21 Jun '08

On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > > Program received signal SIGABRT, Aborted. > > [Switching to Thread -1963996240 (LWP 22635)] > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > This trace resembles ITS#5401, which was only fixed in RE24. You can look > at the patch to syncprov.c there. There's no plan to make another 2.3 > release at the moment. I don't mind patching for this locally, since slapd is crashing every few days. I looked at the patch for ITS 5401 in RE24. I don't know enough about slapd internals to easily backport it to RE23 since a fair bit of the surrounding code differs between RE23 and RE24; would you be willing to do so? john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5568) Multiple Suffix not working in 2.3.39 Release.
by h.b.furuseth＠usit.uio.no 20 Jun '08

20 Jun '08

Howard Chu: > Indeed, the idea of "multiple suffixes" is that you're using suffixes > with no subordinate relation. However in that case, there is no > logical reason to keep them all within the same database either. They > represent totally independent namespaces then, and keeping them in a > single database offers no advantages. Well, it offers some advantages. Some features don't work between multiple databases, like subtree rename and (yuck) aliases. Also it can be simpler and less work to administer and tune one database than several. Though instead it can be more work for slapd, e.g. index data both suffixes get joined together, indexing can give more false positives which will have to be eliminated by checking the filter. -- Hallvard

1 0

Re: (ITS#5572) Append global ACL to new backends
by hyc＠symas.com 20 Jun '08

20 Jun '08

Rein Tollevik wrote: > Howard Chu wrote: >> rein(a)OpenLDAP.org wrote: >>> The global ACLs are not added to newly created backends, i.e a server >>> restart >>> must be done before they are included. The patch at the end should >>> fix this. OK >>> to commit Howard? >> My preference here would be to rip out everything that appends the >> global ACLs and instead change the access_allowed checker to reference >> the global ACLs directly when needed. > > Agreed, that would also fix the problem that dynamic updates to the > global ACLs requires a restart to be effective. I can look into this > next week. To be sure I have the semantics correct, it should be to > evalutate ALCs local to the backend first, then the global, until a > matching entry has been found? Right. Thanks for investigating this. -- -- Howard Chu CTO, 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#5565) slapd crashes due to SIGPIPE
by hyc＠symas.com 20 Jun '08

20 Jun '08

John Morrissey wrote: > On Tue, Jun 17, 2008 at 03:44:39PM -0700, Howard Chu wrote: >>> We had been running 2.3.41 plus the fix for ITS 5469, but upgraded to >>> RE23 as of about a week ago to make sure a fix wasn't already present. >>> Below is a representative backtrace. >> This trace is not indicative of a crash. You have to tell gdb not to stop >> when SIGPIPE is received in order to get an accurate view of the program >> behavior: "handle SIGPIPE nostop" > > Ach, I didn't consider that gdb would be stopping on these signals on its > own. New backtrace is below. > > BTW, how does one retitle a Jitterbug bug? I didn't see a way to > authenticate to the web interface; does Jitterbug accept e-mail commands to > manipulate bugs? Only OpenLDAP engineering team members can authenticate. We don't re-title bug reports. > Program received signal SIGABRT, Aborted. > [Switching to Thread -1963996240 (LWP 22635)] > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 This trace resembles ITS#5401, which was only fixed in RE24. You can look at the patch to syncprov.c there. There's no plan to make another 2.3 release at the moment. > Thread 12 (Thread -1963996240 (LWP 22635)): > #0 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0xb7bb30c9 in abort () from /lib/tls/libc.so.6 > No symbol table info available. > #2 0xb7bab05f in __assert_fail () from /lib/tls/libc.so.6 > No symbol table info available. > #3 0x0806bba2 in connection_state_closing (c=0x90342f48) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:765 > state =<value optimized out> > __PRETTY_FUNCTION__ = "connection_state_closing" > #4 0x0807bc34 in send_ldap_ber (conn=0x90342f48, ber=0x8aefbdac) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:162 > err = 6 > sd = 135491153 > bytes =<value optimized out> > #5 0x0807dd19 in slap_send_search_entry (op=0x8aefbf20, rs=0x8aefc1cc) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:1137 > a_flags = 0x1<Address 0x1 out of bounds> > berbuf = {buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000$Ñ\237\212\232Ñ\237\212Rá\237\212\000\000\000\000\000\000\000\000\210À\"\b\000\000\000\000\210À\"\b\000\000\000\000Ì\rò·\030\000\000\000Ì\rò·\000\000\000\000xÂï\212\030Ÿï\212ÜÀñ·\r\000\000\000\210À\"\b\000\000\000\000ÔÉñ·\f\000\000\000xÂï\2128Ÿï\212ðÅñ·\fÀ\237\212hŸï\212\f\000\000\000tŸï\212\001\000\000\000 ¿ï\212ÈŸï\212\231t\f\bhŸï\212\f\000\000\000\001\000\000\000xÂï\212\210À\"\blŸï\212hŸï\212\206µñ·\001\000\000\000\000\000\000\000csn=,rid=001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002<Address 0x10002 out of bounds>} > ber = (BerElement *) 0x8aefbdac > a = (Attribute *) 0x6 > i = 1 > j =<value optimized out> > rc =<value optimized out> > edn = 0x94abb97 "reqStart=20080604231418.000048Z,cn=log" > userattrs = 1 > acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0}<repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} > attrsonly = 0 > ad_entry = (AttributeDescription *) 0x814ad90 > e_flags = (char **) 0x0 > #6 0xb79c3eaa in syncprov_qtask (ctx=0x8aefc2c8, arg=0x856d058) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/overlays/syncprov.c:798 > so = (syncops *) 0x856d088 > on = (slap_overinst *) 0x819da60 > opbuf = {buffer = "ð¿ï\212c\000\000\000i¥YH\000\000\000\000ÌÀï\212\006\000\000\000\201D\207\006\000\000\000\210D\207\002\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿ\\Ø\031\b\000\000\000\000\204C\207ž\201¬\207.\000\000\000\217D\207", '\0'<repeats 12 times>, "\001", '\0'<repeats 39 times>, "LÀï\212\200", '\0'<repeats 11 times>, "\025\000\000\000kD\207\025\000\000\000kD\207", '\0'<repeats 48 times>, "\001\000\000\000&\000\000\000H/4\220\002\000\000\000\003\000\000\000\000\000\000\000ÈÂï\212\210À\"\bP»\023\bconn=38 op=1", '\0'<repeats 171 times>, ialign = -1963999248, lalign = -1963999248, falign = -2.30870617e-32, dalign = 2.1122923453963239e-312, palign = 0x8aefbff0 "\001"} > op = (Operation *) 0x8aefbf20 > be = {bd_info = 0x819d960, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0'<repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8217320, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79f5660, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} > rc =<value optimized out> > #7 0xb7f2deff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 > ctx = (ldap_int_thread_ctx_t *) 0x8d66c548 > ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822c088, ltk_free = 0x80b6f10<slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xbb, ltk_free = 0xb79ee2e0<bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x861fd008, ltk_free = 0xb79e18d0<search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x3a, ltk_free = 0xb79ee2e0<bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}<repeats 28 times>} > tid = 2330971056 > i = 756 > hash =<value optimized out> > #8 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 > No symbol table info available. > #9 0xb7c5501e in clone () from /lib/tls/libc.so.6 > No symbol table info available. -- -- Howard Chu CTO, 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#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> The global ACLs are not added to newly created backends, i.e a server >> restart >> must be done before they are included. The patch at the end should >> fix this. OK >> to commit Howard? > > My preference here would be to rip out everything that appends the > global ACLs and instead change the access_allowed checker to reference > the global ACLs directly when needed. Agreed, that would also fix the problem that dynamic updates to the global ACLs requires a restart to be effective. I can look into this next week. To be sure I have the semantics correct, it should be to evalutate ALCs local to the backend first, then the global, until a matching entry has been found? Rein

1 0

Re: (ITS#5568) Multiple Suffix not working in 2.3.39 Release.
by hyc＠symas.com 20 Jun '08

20 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> Multiple suffixes are indeed supported, but your configuration is >> completely invalid. > > Why so? Looks to me like a doc bug at best - the doc should say > that _some_ backends support multiple suffixes, and for others one > can use multiple databases instead. > > Though the latter may indeed be what the poster needed. > > BDB does support multiple suffixes #if defined(BDB_MULTIPLE_SUFFIXES), > but it's undocumented except for a FAQ entry which doesn't look right: > http://www.openldap.org/faq/data/cache/342.html > I don't see how subordinates can be a substitute for multiple suffixes > in a single database, since such suffixes should presumably not be > subordinates of each other. Indeed, the idea of "multiple suffixes" is that you're using suffixes with no subordinate relation. However in that case, there is no logical reason to keep them all within the same database either. They represent totally independent namespaces then, and keeping them in a single database offers no advantages. -- -- Howard Chu CTO, 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#5570) Error while using MirrorMode Replication
by hyc＠symas.com 20 Jun '08

20 Jun '08

shravan.rathore(a)polaris.co.in wrote: > Full_Name: Shravan R > Version: 2.3.39 > OS: Linux 2.4.9 > URL: > Submission from: (NULL) (202.168.89.5) > > > Hi, > > I am trying the MirrorMode Replication using syncrepl on 2 Linux machines. > I followed the below configuration, but found an error. MirrorMode was not released in OpenLDAP 2.3. This ITS will be closed. -- -- Howard Chu CTO, 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#5572) Append global ACL to new backends
by hyc＠symas.com 20 Jun '08

20 Jun '08

rein(a)OpenLDAP.org wrote: > The global ACLs are not added to newly created backends, i.e a server restart > must be done before they are included. The patch at the end should fix this. OK > to commit Howard? My preference here would be to rip out everything that appends the global ACLs and instead change the access_allowed checker to reference the global ACLs directly when needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein The global ACLs are not added to newly created backends, i.e a server restart must be done before they are included. The patch at the end should fix this. OK to commit Howard? Rein Tollevik Basefarm AS diff -u -r1.335 bconfig.c --- servers/slapd/bconfig.c 16 Jun 2008 12:45:30 -0000 1.335 +++ servers/slapd/bconfig.c 20 Jun 2008 16:51:03 -0000 @@ -4351,6 +4355,9 @@ /* Newly added databases and overlays need to be started up */ if ( CONFIG_ONLINE_ADD( ca )) { if ( colst[0]->co_type == Cft_Database ) { + /* append global access controls */ + acl_append( &ca->be->be_acl, frontendDB->be_acl, -1 ); + rc = backend_startup_one( ca->be, &ca->reply ); } else if ( colst[0]->co_type == Cft_Overlay ) {

1 0

(ITS#5571) Don't renumber the config database
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Dynamically adding databases that requires renumbering of the existing olcDatabase values could also renumber the config database. But the code expects that to always be index 0, and slapd fails to start again. The "prod" server from test053-syncprov-glue shows a case where this would happen. The patch at the end prevents config_renumber_one() from renumbering the config database. Howard, is this OK? Rein Tollevik Basefarm AS diff -u -r1.335 bconfig.c --- servers/slapd/bconfig.c 16 Jun 2008 12:45:30 -0000 1.335 +++ servers/slapd/bconfig.c 20 Jun 2008 14:39:41 -0000 @@ -3762,6 +3762,10 @@ char ibuf[32], *ptr1, *ptr2 = NULL; int rc = 0; + if ( !strncmp( e->e_nname.bv_val, "olcDatabase={0}config,", + STRLENOF("olcDatabase={0}config,") )) + return 0; + rc = config_rename_attr( rs, e, &rdn, &a ); if ( rc ) return rc;

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