openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

(ITS#5417) ldap memory utilization extremely high
by james＠broadsoft.com 12 Mar '08

12 Mar '08

Full_Name: J B Version: openldap-2.3.27 OS: FreeBSD 4.7-RELEASE-p28 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.88.7.2) The ldap process periodically shows high CPU utilization. It will gradually climb from an extremely low number to up to 95%, then gradually return to an extremely low number again. The server is running ldap to authenticate for a Plone/zope for which the user needs to log in. In this instance the process is extremely low. However at times it can reach 85%. During these times, the login process can take up to 30 seconds. It seems when the utilization is low, the login process is only 1 second. PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 34154 zope2 2 0 1173M 1165M poll 1 21.2H 14.06% 14.06% python2 370 ldap 2 0 149M 12564K poll 0 469.1H 2.34% 2.34% slapd another top output shows that slpad actually reached 0% PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 62976 root 28 0 2068K 1064K CPU1 1 0:01 16.10% 3.56% top4 370 ldap 2 0 149M 12564K poll 0 469.1H 0.00% 0.00% slapd

1 0

Re: (ITS#5414) About nis.schema
by h.b.furuseth＠usit.uio.no 12 Mar '08

12 Mar '08

I wrote: > Rename your hacked nis.schema and put it somewhere an upgrade will not > touch. ..and include that instead of nis.schema from slapd.conf, if that wasn't clear. -- Hallvard

1 0

Re: (ITS#5414) About nis.schema
by h.b.furuseth＠usit.uio.no 12 Mar '08

12 Mar '08

jtwang(a)cs.nctu.edu.tw writes: > When we upgrade the openldap server, the modifed "nis.schema" would be > replaced with a unmodified "nis.schema". > > Our servers will be down, because there are some strings in database which > conflicts to "nis.schema". Rename your hacked nis.schema and put it somewhere an upgrade will not touch. > May you change the default schema of the "gecos" field and make it to > be able to carry dual-byte string? Unfortunately, no. The schema is defined in RFC2307, which specifies IA5 String (ASCII) gecos. OpenLDAP follows that, and a change would cause interoperability problems with servers which still follow the RFC. You could write the RFC author and ask if there are plans to update to use Directory String. So, not an OpenLDAP bug. This ITS will be closed. -- Hallvard

1 0

(ITS#5416) slapd core dump
by rui.yan＠gmail.com 12 Mar '08

12 Mar '08

Full_Name: yanr Version: 2.4.8 OS: Linux 2.6.22 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.221.197.21) Verion: 2.4.8 Desc: client runs some codes like ldap_modify_ext, sometimes slapd core dump. The same codes works on 2.3.38. [root@test1 /]# uname -r 2.6.22.9-2.smp.gcc3.4.x86_64 (gdb) bt #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 67 int res = INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #1 0x00002b018fa6ef1e in *__GI_abort () at ../sysdeps/generic/abort.c:88 #2 0x00002b018fa67720 in *__GI___assert_fail (assertion=0x56ad43 "i > 0", file=0x56acf8 "schema_init.c", line=366, function=0x56ad30 "octetStringIndexer") at assert.c:83 #3 0x00000000004664b3 in octetStringIndexer (use=163, flags=4, syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x2aaaaacad6b0, keysp=0x42001598, ctx=0x83d970) at schema_init.c:366 #4 0x000000000046ffde in objectSubClassIndexer (use=163, mask=4, syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x87b7e0, keysp=0x42001598, ctx=0x83d970) at schema_prep.c:305 #5 0x00000000004e898b in indexer (op=0x839cc0, txn=0x87c680, ad=0x7789b0, atname=0x77ec48, vals=0x87b7e0, id=86, opid=2, mask=4) at index.c:205 #6 0x00000000004e8e2d in index_at_values (op=0x839cc0, txn=0x87c680, ad=0x7789b0, type=0x77ebe0, tags=0x7789d0, vals=0x87b7e0, id=86, opid=2) at index.c:337 #7 0x00000000004e8fa6 in bdb_index_values (op=0x839cc0, txn=0x87c680, desc=0x7789b0, vals=0x87b7e0, id=86, opid=2) at index.c:386 #8 0x00000000004ae4d6 in bdb_modify_internal (op=0x839cc0, tid=0x87c680, modlist=0x87b700, e=0x420018f0, text=0x42002e30, textbuf=0x42001980 "��\213\216\001+", textlen=256) at modify.c:287 #9 0x00000000004af29c in bdb_modify (op=0x839cc0, rs=0x42002e10) at modify.c:577 #10 0x0000000000443710 in fe_op_modify (op=0x839cc0, rs=0x42002e10) at modify.c:300 #11 0x0000000000443172 in do_modify (op=0x839cc0, rs=0x42002e10) at modify.c:175 #12 0x000000000042629d in connection_operation (ctx=0x42002f60, arg_v=0x839cc0) at connection.c:1084 #13 0x00000000004267d9 in connection_read_thread (ctx=0x42002f60, argv=0xc) at connection.c:1211 #14 0x000000000052409d in ldap_int_thread_pool_wrapper (xpool=0x78ab30) at tpool.c:625 #15 0x00002b018e8bc35a in start_thread () from /lib64/tls/libpthread.so.0 #16 0x00002b018faf6473 in clone () from /lib64/tls/libc.so.6 #17 0x0000000000000000 in ?? ()

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