openldap-bugs September 2007

openldap-bugs@openldap.org

33 participants
179 discussions

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

ghenry(a)suretecsystems.com wrote: >> I think the point is not what the code should (or should not) do, or >> whether its current behavior is correct or not; it's rather that the man >> page, as far as I understand it, is not clear about what the code >> currently does. > > Ok, well the text should reflect what the code does. I think I'm missing > the point of your question. If the text doesn't currently match what is > actually happening in the code, then we fix the man page so it does. My point is that from that text I don't understand what the code does. Either it's my English (could well be), or it needs to be reworded. I'm quoting here the original text: snip... dbconfig <Berkeley-DB-setting> Specify a configuration directive to be placed in the DB_CONFIG file of the database directory. The dbconfig directive is just a convenience to allow all necessary configuration to be set in the slapd.conf file. The options set using this directive will only be written to the DB_CONFIG file if no such file existed at server startup time. This allows one to set initial values without overwriting/destroying a DB_CONFIG file that was already customized through other means. snip... So it seems to be quite clear about what's going to happen if no DB_CONFIG exists, but not as clear about what happens if DB_CONFIG already exists, apart from not getting overwritten or otherwise modified. 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#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: >>> The slapd-bdb(5) man page seems to me unclear with respect to the >>> dbconfig >>> directive. In fact, what I gather from the text is that if no >>> DB_CONFIG >>> file >>> exists, any dbconfig directive will be used to generate one; otherwise, >>> an >>> existing DB_CONFIG file will not be altered. What is unclear is what >>> happens if >>> both a DB_CONFIG file and any dbconfig directives exist, and they >>> differ? >>> Who >>> takes the precedence? What if any dbconfig directive is not present in >>> the >>> DB_CONFIG file? >>> >> >> I would say since dbconfig directives only work on a restart of slapd, >> and >> that if a DB_CONFIG is present, the DB_CONFIG should *always* take >> precedence. If dbconfig changes could make a difference via back-config, >> which they can't without a restart, then dbconfig stuff should override >> any DB_CONFIG. > > Gavin, > > I think the point is not what the code should (or should not) do, or > whether its current behavior is correct or not; it's rather that the man > page, as far as I understand it, is not clear about what the code > currently does. Ok, well the text should reflect what the code does. I think I'm missing the point of your question. If the text doesn't currently match what is actually happening in the code, then we fix the man page so it does.

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

ghenry(a)suretecsystems.com wrote: >> The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig >> directive. In fact, what I gather from the text is that if no DB_CONFIG >> file >> exists, any dbconfig directive will be used to generate one; otherwise, an >> existing DB_CONFIG file will not be altered. What is unclear is what >> happens if >> both a DB_CONFIG file and any dbconfig directives exist, and they differ? >> Who >> takes the precedence? What if any dbconfig directive is not present in >> the >> DB_CONFIG file? >> > > I would say since dbconfig directives only work on a restart of slapd, and > that if a DB_CONFIG is present, the DB_CONFIG should *always* take > precedence. If dbconfig changes could make a difference via back-config, > which they can't without a restart, then dbconfig stuff should override > any DB_CONFIG. Gavin, I think the point is not what the code should (or should not) do, or whether its current behavior is correct or not; it's rather that the man page, as far as I understand it, is not clear about what the code currently does. 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#5132) test052 fails: ldapadd failed (21)!
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Fixed in HEAD (HEAD only); please test. 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#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

> > The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig > directive. In fact, what I gather from the text is that if no DB_CONFIG > file > exists, any dbconfig directive will be used to generate one; otherwise, an > existing DB_CONFIG file will not be altered. What is unclear is what > happens if > both a DB_CONFIG file and any dbconfig directives exist, and they differ? > Who > takes the precedence? What if any dbconfig directive is not present in > the > DB_CONFIG file? > I would say since dbconfig directives only work on a restart of slapd, and that if a DB_CONFIG is present, the DB_CONFIG should *always* take precedence. If dbconfig changes could make a difference via back-config, which they can't without a restart, then dbconfig stuff should override any DB_CONFIG. I hope that makes sense? Gavin.

1 0

(ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando The slapd-bdb(5) man page seems to me unclear with respect to the dbconfig directive. In fact, what I gather from the text is that if no DB_CONFIG file exists, any dbconfig directive will be used to generate one; otherwise, an existing DB_CONFIG file will not be altered. What is unclear is what happens if both a DB_CONFIG file and any dbconfig directives exist, and they differ? Who takes the precedence? What if any dbconfig directive is not present in the DB_CONFIG file? p.

1 0

(ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by audrius.valunas＠teo.lt 13 Sep '07

13 Sep '07

Full_Name: Audrius Valunas Version: openldap2-2.3.27-25 OS: SUSE LINUX 10.0 (i586) OSS URL: Submission from: (NULL) (212.59.0.201) There is synchronous replication between mastyer and slave. When network connectivity problems occur master closes tcp connection but slave doesn't notice those problems, it still has tcp connection open, but in real it is not receiving updates any more. I think that can be solved adding some ack from slave because sending on such a socket would fail and force slave to retry connection.

1 0

Re: (ITS#5132) test052 fails: ldapadd failed (21)!
by ando＠sys-net.it 13 Sep '07

13 Sep '07

The test doesn't consider the possibility to build slapo-memberof(5) as module. I'll fix that later. 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#5132) test052 fails: ldapadd failed (21)!
by michael＠stroeder.com 13 Sep '07

13 Sep '07

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.6.221) $ ./run -b bdb test052 Cleaning up test run directory leftover from previous run. Running ./scripts/test052-memberof... running defines.sh Starting slapd on TCP/IP port 9011... Running ldapadd to build slapd config database... ldapadd failed (21)!

1 0

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 13 Sep '07

13 Sep '07

Pierangelo Masarati a écrit : >> I've tested your latest commit, and most of our tests now run great. >> However, I still get a segault with the two rules below. Please note >> that this segfault only happens when *both* rules are present, each one >> by itself does not cause a segfault : >> >>> access to dn.sub="ou=Affectations,dc=linagora,dc=org" >>> attrs=sigleAbrege,labeledURI,mailRoutingAddress,telephoneNumber,facsimileTelephoneNumber,entry >>> by set="([ldap:///] + (([ldap:///] + ((([ldap:///] + this + >>> [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-0) >>> + [??base?])/responsable) + >>> [??base?(|(administrateurResponsable=] + user + >>> [)(administrateur=] + user + [)(membre=] + user + [))])/entryDN" >>> +rscx >>> by * break >>> access to dn.sub="ou=Affectations,dc=linagora,dc=org" >>> attrs=domaineMessagerie,finValidite,identifiantHarpegeStructure,responsable,objectClass,entry >>> by set="[ldap:///] + (((([ldap:///] + this + >>> [??base?(|(objectClass=affectationLiee)(objectClass=affectationSemiLibre))])/entryDN)/-100) >>> & ((([ldap:///] + user + >>> [??base?(objectClass=personnel)])/entryDN)/-100)) + >>> [??sub?entryDN=] + user/entryDN" +rscx >>> by * break >> I'm afraid that we use quite a few specific schemas so you may not be >> able to reproduce this easily. However, I hope these rules will enable >> you to determine the problematic case. If necessary, I could prepare a >> data and schema extract to reproduce the problem. > > That would help, but before you do it, could you please post a backtrace > of the stack when the issue occurs? In case this doesn't suffice, and I > can't figure things out myself, I'll ask you to provide a self-contained > set of data that causes the issue. Of course. Please also see my message a few minutes ago with valgrind output. Stack trace follows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1740719216 (LWP 10412)] 0xb7bcfdec in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7bcfdec in free () from /lib/tls/i686/cmov/libc.so.6 #1 0x0816338e in ber_bvarray_free_x (a=0x82e4058, ctx=0x82bd6b8) at memory.c:731 #2 0x080af40a in slap_set_filter (gatherer=0x8086720 <acl_set_gather>, cp=0x983291e0, fbv=0x983291e8, user=0x82dc094, target=0xb5312bd0, results=0x0) at sets.c:391 #3 0x080864ca in acl_match_set (subj=0x983295b0, op=0x82dbff8, e=0xb5312bc4, default_set_attribute=0x0) at acl.c:2299 #4 0x08089786 in slap_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at acl.c:1621 #5 0x0808b6c4 in fe_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at acl.c:311 #6 0x080c8930 in over_access_allowed (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=ACL_SEARCH, state=0x0, maskp=0x98329c20) at backover.c:314 #7 0x080872c4 in access_allowed_mask (op=0x82dbff8, e=0xb5312bc4, desc=0x8244de8, val=0x97eeb4c0, access=<value optimized out>, state=0x0, maskp=0x0) at acl.c:413 #8 0x08083bcf in test_ava_filter (op=0x82dbff8, e=0xb5312bc4, ava=0x97eeb4bc, type=163) at filterentry.c:545 #9 0x080843e9 in test_filter (op=0x82dbff8, e=0xb5312bc4, f=0x97eeb4e4) at filterentry.c:88 #10 0x080dc90e in bdb_search (op=0x82dbff8, rs=0x983eb154) at search.c:844 #11 0x080679f6 in fe_op_search (op=0x82dbff8, rs=0x983eb154) at search.c:368 #12 0x080c7ca1 in overlay_op_walk (op=0x82dbff8, rs=0x983eb154, which=op_search, oi=0x8264bf8, on=0x8264cf8) at backover.c:652 #13 0x080c820d in over_op_func (op=0x82dbff8, rs=0x983eb154, which=op_search) at backover.c:704 #14 0x0806823e in do_search (op=0x82dbff8, rs=0x983eb154) at search.c:217 #15 0x0806583e in connection_operation (ctx=0x983eb238, arg_v=0x82dbff8) at connection.c:1145 #16 0x08065c71 in connection_read_thread (ctx=0x983eb238, argv=0xe) at connection.c:1271 #17 0x0813cda6 in ldap_int_thread_pool_wrapper (xpool=0x824bfd0) at tpool.c:614 #18 0xb7cab31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #19 0xb7c3457e in clone () from /lib/tls/i686/cmov/libc.so.6 Regards, Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2007