openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5419) test048 fails...
by hyc＠symas.com 13 Mar '08

13 Mar '08

luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > consistently > > Running ./scripts/test048-syncrepl-multiproxy... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entry in the master... > Starting P1 slave slapd on TCP/IP port 9012... > Using ldapsearch to check that P1 slave slapd is running... > Starting R1 slave slapd on TCP/IP port 9013... > Using ldapsearch to check that R1 slave slapd is running... > 1> Using ldapadd to populate the master directory... > Waiting 15 seconds for syncrepl to receive changes... > ldapsearch failed at P1 slave (32)! > > modifications to the master are not propagated to the slaves Yes, I see this as well. syncrepl is trying to use backend_attribute() to retrieve the underlying DB's contextCSN, but backend_attribute is discarding the current op->o_bd and using select_backend() to pick which backend to query. This is definitely the wrong behavior; op->o_bd is essentially supposed to be a constant once it is set on an operation. Operations within a backend are generally not allowed to access other backends so it should not be overriding the backend that was given to it. -- -- 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#5391) hdb deadlock
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> How about making #bytes-based checkpoints signal or (pthread_kill?) the >> timed checkpoints thread, so that thread can handle all checkpoints? > > It's an interesting idea. But that means we have to count bytes ourselves, > rather than letting BerkeleyDB do it. Whoops, good point. > Personally I don't think byte counts are very useful here. They're made > somewhat superfluous because the data volume will tend to cause the > transaction log buffers to fill up and be flushed regardless. I don't think Berkeley DB writes a checkpoint record then, at least I don't see that in the docs. If not, #bytes do help keep recovery and checkpoint times down. Anyway, unless you are proposing to ignore the #bytes parameter: If this is a Berkeley DB bug we could hear what they say, and in the meantime put a mutex_trylock around checpoints. Unless db has some feature which defeats that, like if txn_checkpoint() merely schedules a checkpoint. #define CHECKPOINT_WORKAROUND /* hopefully an ITS#5391 workaround */ struct bdb_info { ... #ifdef CHECKPOINT_WORKAROUND # ldap_pvt_thread_mutex_t bi_checkpoint_mutex; #define CHECKPOINT_LOCK(op, bdb) op(&(bdb)->bi_checkpoint_mutex) #else #define CHECKPOINT_LOCK(op, bdb) 0 #endif ... }; #define TXN_CHECKPOINT(bdb, k, m, f) do { \ if ( CHECKPOINT_LOCK( ldap_pvt_thread_mutex_trylock, bdb ) == 0 ) { \ (bdb)->bi_dbenv->txn_checkpoint( (bdb)->bi_dbenv, k, m, f ); \ (void) CHECKPOINT_LOCK( ldap_pvt_thread_mutex_unlock, bdb ); \ } \ } while (0) -- Hallvard

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by jclarke＠linagora.com 13 Mar '08

13 Mar '08

Hi, michael(a)stroeder.com a écrit : > I'd be interested to add support for something like this to my LDAP client. > > BTW: I'd vote against ";x-allowed" or ";x-required" since a schema-aware > client can already determine this in a non-proprietary way from the subschema. > > The overlay's source is quite old. Does it still build with recent HEAD? I'm also interested in an overlay of this type. I started hacking into it recently, and don't remember any problems getting it to build on HEAD (a couple of months ago). This was related to an implementation of Get Effective Rights [1], which returns rights the current user has on each attribute in an object. I had a premilinary working version, but it did not work as a control, just returned extra attributes. Similarly, this would be useful to LDAP GUI clients. If you're interested, I could dig out the code. [1] http://directory.fedoraproject.org/wiki/Get_Effective_Rights_Design and http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-ldapext-acl-model-08.t… Regards, Jonathan -- 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

(ITS#5419) test048 fails...
by luca＠OpenLDAP.org 13 Mar '08

13 Mar '08

Full_Name: Luca Scamoni Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) consistently Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting P1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that P1 slave slapd is running... Starting R1 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R1 slave slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... ldapsearch failed at P1 slave (32)! modifications to the master are not propagated to the slaves

1 0

Re: (ITS#5391) hdb deadlock
by hyc＠symas.com 13 Mar '08

13 Mar '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> One thing that I've started doing recently in my configs is to skip >> the #bytes option (leave it zero), so that only time-based checkpoints >> occur. Since they're done in a dedicated task, only one thread at a >> time can trigger a checkpoint. > > How about making #bytes-based checkpoints signal or (pthread_kill?) the > timed checkpoints thread, so that thread can handle all checkpoints? It's an interesting idea. But that means we have to count bytes ourselves, rather than letting BerkeleyDB do it. And that's rather difficult, since we don't know the actual volume of writes resulting from a given operation. Personally I don't think byte counts are very useful here. They're made somewhat superfluous because the data volume will tend to cause the transaction log buffers to fill up and be flushed regardless. -- -- 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#5401) slapd crashes in mirrormode
by hyc＠symas.com 13 Mar '08

13 Mar '08

A patch for this is now in CVS HEAD. Please test. I was unable to reproduce the reported crash, so your feedback is important here. ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.8 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > Hi, > I am testing OpenLdap 2.4.8 in mirrormode. > I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with > a retry interval of 10 seconds : retry="10 +". > An injector writes data to A. The data is replicated in B. But this server > UNBINDs then reBINDs to A every 10 seconds ! > This continues until slapd on A crashes with a SIGIOT. More investigation in the > slapd log shows that the crash is caused by the losing of the client syncrepl > connection coming from B ! -- -- 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#5411) rename the leave label to allow building on OSF
by ando＠sys-net.it 12 Mar '08

12 Mar '08

pogma(a)thewrittenword.com wrote: Fixed in HEAD, please test. Thanks, 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#5418) Syncrepl filters are evaluated using the wrong DN
by ando＠sys-net.it 12 Mar '08

12 Mar '08

roessner(a)capcom.de wrote: Fixed in HEAD. Thanks, 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#5418) Syncrepl filters are evaluated using the wrong DN
by roessner＠capcom.de 12 Mar '08

12 Mar '08

Full_Name: Ralph Rößner Version: 2.4.8 OS: Debian Linux URL: ftp://ftp.capcom.de/pub/CPS/openldap-ITS-20080312/ Submission from: (NULL) (146.140.221.89) When syncreplication is run in refreshAndPersist mode and it is limited to certain objects by a "filter=..." expression and one of these objects is modified then the attributes needed to check the filter expression are accessed using the rights of the DN that the modifying connection is bound to, not those of the DN that the replication connection is bound to. This can result in modifications not being propagated to the consumer server. This was encountered in the wild when a user successfully changed some service password but found that the change was not reflected by the consumer slapd that he was subsequently trying to authenticate to. The same change requested by a maintenance tool (under a different bind dn) was replicated. Turning on ACL tracing showed up the behaviour described above. I have created a demonstration configuration and data set, available at the provided ftp URL and summarized in the "index" file there. The demonstration features a replication that is restricted to object that have the "replicate" attribute set to "yes", a user object "uid=user,ou=subtree,o=test" that is allowed to change its password but not allowed to read the "replicate" attribute, a maintenance object "uid=maintainer,o=test" that is allowed to create or modify user entries, including their "replicate" attribute, and a replication object "uid=replicator,o=test" that is used as bind dn for the replication and is allowed to read everything that has the "replicate" attribute set to "yes". I have then changed the userPassword attribute of the user object, using the ldappasswd tool, and traced the provider slapd. The logs show that after the modification is done, the "replicate" attribute is accessed, and the ACLs are checked using the dn that the modifying connection is bound to (which is the user dn in the case of the first log and the maintenance dn in the second). Only the modification made by the maintainer is propagated, the one made by the user is not, as shown by the logs and by the ldapsearch results provided with the files. Allowing access to the "replicate" attribute for everyone (as in the "slapd-workaround.conf") works around the problem. The third slapd log file shows that now even a modification made by the user dn is being propagated. Pierangelo Masarati has already suggested a patch for this behaviour on the openldap-software list (included with the files). After applying this patch the behaviour changes as shown in the last provided slapd log file, i.e. the access checks to the "replicate" attribute are made with respect to the replication dn, and do not any more depend on the dn that requested the modification. This fixes the problem for me in the demonstration setup. Sincerely, Ralph Rößner

1 0

Re: (ITS#5417) ldap memory utilization extremely high
by quanah＠zimbra.com 12 Mar '08

12 Mar '08

--On Wednesday, March 12, 2008 4:50 PM +0000 james(a)broadsoft.com wrote: > Full_Name: J B > Version: openldap-2.3.27 (a) I advise upgrading to a newer release (b) There's no indication of a bug being present here isn't fixed in a later release (c) You may simply need to better tune your slapd. If after upgrading to the current 2.3 release (2.3.41) you continue to see issues, I would recommend you email the software list if you have questions about how to properly tune OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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