openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#8426) unable to get group names of user
by pradeepagrawal8184＠gmail.com 16 May '16

16 May '16

Full_Name: Pradeep Agrawal Version: 2.4.40-7 OS: centos URL: Submission from: (NULL) (114.143.121.177) is there any way to get groups of users by providing username. i am using java code to fetch list of groups of given users but it seems its not possible as user don't have 'memberof' attribute.

1 0

(ITS#8425) sssvlv active process
by pencilkhan07＠gmail.com 16 May '16

16 May '16

Full_Name: nilom khan Version: 2.4.40 OS: Centors 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.53.173.178) Dear sir , I know this is common problem but i can't able to solve it . Although previously some one suggest to add some code into /etc/ldap/sldap.conf . but my version doesn't contain /etc/openldap/sldap.conf . I google it and found that centors 6.5 version dos not contain this file. Below my version information . [root@mail ~]# slapd -V @(#) $OpenLDAP: slapd 2.4.40 (Nov 10 2015 09:41:16) $ mockbuild@c6b8.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.40 /openldap-2.4.40/build-servers/servers/slapd Could u please suggest me how to enable SSSVLV so that i can browse open ldap address book in outlook . Their have any process for search with group attribute ? its very kind full if you suggest me . Thanks in advance Nilom KHan

1 0

Re: (ITS#8423) Slapd hang when modifying the configuration and an accesslog purge is going on
by hyc＠symas.com 14 May '16

14 May '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.43 > OS: RH7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.169.142.218) > > > When the accessLog is being purged, a change in cn=config will wait until the > purge is done, which may take a while. > > The access_log purge should honor cn=config pause requests. > Fixed now in git master. -- -- 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#8424) mdb_env_cwalk() is broken, leading to crash if MDB_CP_COMPACT is set
by hyc＠symas.com 14 May '16

14 May '16

ddmitrie(a)gmail.com wrote: > Full_Name: Dmitry Dmitrienko > Version: trunk, 0.9.18 > OS: Linux, Windows > URL: > Submission from: (NULL) (100.36.101.84) > Thanks, fixed now in git mdb.master > In short: > Reproduce: create a large database (1GB would be enough), run md_copy with -c > argument. Expected result - compacted new database, Actual result - empty new > database and crash in md_copy. > > In details: > mdb_env_cwalk() defines cursor and does not initialize most of its fields, > including mc_flags field. Then it calls mdb_page_get() procedure, which checks > if (C_ORIG_RDONLY|C_WRITEMAP) flags are set in mc_flags. Since this field is not > initialized, it may have arbitrary value. If these flags are not set, it starts > checking txn's mt_u.dirty_list, as if it was a writing transaction, while in > fact this is a walker, it is a reader, so it initialized mt_u.reader fields. > This field is in the same memory location with dirty_list just because it's > union. So mdb_page_get() actually reads lock file memory (it's where mt_u.reader > points to). If the database is large enough, it leads to access to far beyond > lock file memory mapped region and crashes md_copy. > > Proposed fix: > mdb_env_cwalk(mdb_copy *my, pgno_t *pg, int flags) > ... > + memset(&mc, 0, sizeof(mc)); > mc.mc_snum = 1; > mc.mc_top = 0; > mc.mc_txn = my->mc_txn; > + mc.mc.mc_flags = my->mc_txn->mt_flags & (C_ORIG_RDONLY|C_WRITEMAP); > > > > -- -- 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#8424) mdb_env_cwalk() is broken, leading to crash if MDB_CP_COMPACT is set
by ddmitrie＠gmail.com 14 May '16

14 May '16

Full_Name: Dmitry Dmitrienko Version: trunk, 0.9.18 OS: Linux, Windows URL: Submission from: (NULL) (100.36.101.84) In short: Reproduce: create a large database (1GB would be enough), run md_copy with -c argument. Expected result - compacted new database, Actual result - empty new database and crash in md_copy. In details: mdb_env_cwalk() defines cursor and does not initialize most of its fields, including mc_flags field. Then it calls mdb_page_get() procedure, which checks if (C_ORIG_RDONLY|C_WRITEMAP) flags are set in mc_flags. Since this field is not initialized, it may have arbitrary value. If these flags are not set, it starts checking txn's mt_u.dirty_list, as if it was a writing transaction, while in fact this is a walker, it is a reader, so it initialized mt_u.reader fields. This field is in the same memory location with dirty_list just because it's union. So mdb_page_get() actually reads lock file memory (it's where mt_u.reader points to). If the database is large enough, it leads to access to far beyond lock file memory mapped region and crashes md_copy. Proposed fix: mdb_env_cwalk(mdb_copy *my, pgno_t *pg, int flags) ... + memset(&mc, 0, sizeof(mc)); mc.mc_snum = 1; mc.mc_top = 0; mc.mc_txn = my->mc_txn; + mc.mc.mc_flags = my->mc_txn->mt_flags & (C_ORIG_RDONLY|C_WRITEMAP);

1 0

(ITS#8423) Slapd hang when modifying the configuration and an accesslog purge is going on
by elecharny＠apache.org 13 May '16

13 May '16

Full_Name: Emmanuel Lecharny Version: 2.4.43 OS: RH7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.169.142.218) When the accessLog is being purged, a change in cn=config will wait until the purge is done, which may take a while. A typical trace : ... Thread 7 (Thread 0x7f431bfff700 (LWP 57043)):D0D #0 0000007f4863858fdd in fdatasync () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f48619db98d in mdb_env_sync (env=0xc63d20, force=0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:2474 #2 0x00007f48619de46e in mdb_txn_commit (txn=0xc36ed0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:3572 #3 0x00007f48619c06c6 in mdb_delete (op=0x7f431bffe4c0, rs=0x7f431bffe450) at /home/build/sol_R_2.4.43.1/openldap/servs%s/slapd/back-mdb/delete.c:415 #4 0x00000000004d2b87 in overlay_op_walk (op=0x7f431bffe4c0, rs=0x7f431bffe450, which=op_delete, oi=0xc96a80, on=0x0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:677 #5 0x00000000004d2db4 in over_op_func (op=0x7f431bffe4c0, rs=0x7f431bffe450, which=op_delete) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:730 #6 0x00000000004d2f6e in over_op_delete (op=0x7f431bffe4c0, rs=0x7f431bffe450) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:787 #7 0x00007f486136dfb2 in accesslog_purge (ctx=0x7f431bffebb0, arg=0xc8ee00) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/overlays/accesslog.c:700 #8 0x00007f48656ff7f3 in ldap_int_thread_pool_wrapper (xpool=0xbd5d80) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:956 #9 0x00007f4864e89182 in start_thread (arg=0x7f431bfff700) at pthread_create.c:312 #10 0x00007f486386147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 ... Thread 4 (Thread 0x7f1a7f7fc700 (LWP 57046)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f4865700ed3 in ldap_pvt_thread_cond_wait (cond=0xbd5ce0, mutex=0xbd5c88) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/thr_posix.c:277 #2 0x00007f48656ffcb6 in handle_pause (tpool=0x76b500 <connection_pool>, pause_type=96) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:1106 #3 0x00007f48656ffdb6 in ldap_pvt_thread_pool_pause (tpool=0x76b500 <connection_pool>) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:1152 #4 0x0000000000428c3b in config_back_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/bconfig.c:5943 #5 0x0000000005e5e87e in fe_op_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/modify.c:303 #6 0x000000000045e150 in do_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/modify.c:177 #7 0x000000000043dcff in connection_operation (ctx=0x7f431a7fbbb0, arg_v=0x7f43040008e0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/connection.c:1158 #8 0x000000000043e2a0 in connection_read_thread (ctx=0x7f431a7fbbb0, argv=0x63) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/connection.c:1294 #9 0x00007f48656ff7f3 in ldap_int_thread_pool_wrapper (xpool=0xbd5d80) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:956 #10 0x00007864e4e89182 in start_thread (arg=0x7f431a7fc700) at pthread_create.c:312 #11 0x00007f486386147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 The access_log purge should honor cn=config pause requests.

1 0

Re: (ITS#8422) --enable-ldap library linking failure
by hyc＠symas.com 13 May '16

13 May '16

jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.44 > OS: Ubuntu 12 and 14 > URL: > Submission from: (NULL) (173.173.23.148) > > > The --enable-ldap option, according to the Admin Guide section 12.3.1 is > required to make chaining work. However, enabling this feature as part of the > configuration does not automatically perform the library linking task,r%r > return an error if the linking were to fail for some reason. > > Per Howard Chu, "It worked at some time in the past. It's apparently broken > now..." > > Relevant Minutia: This bug report is inaccurate/incomplete. There is no linking problem when using configure --enable-ldap. Please provide accurate information on the issue you are reporting. -- -- 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#8422) --enable-ldap library linking failure
by jtrupp＠symas.com 11 May '16

11 May '16

Full_Name: Jason Trupp Version: 2.4.44 OS: Ubuntu 12 and 14 URL: Submission from: (NULL) (173.173.23.148) The --enable-ldap option, according to the Admin Guide section 12.3.1 is required to make chaining work. However, enabling this feature as part of the configuration does not automatically perform the library linking task,r%r return an error if the linking were to fail for some reason. Per Howard Chu, "It worked at some time in the past. It's apparently broken now..." Relevant Minutia: But when chaining via TLS, we get this error: 572be686 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:41427 (IP=0.0.0.0:389) 572be686 conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 572be686 conn=1000 op=0 STARTTLS 572be686 conn=1000 op=0 RESULT oid= err=0 text= 572be687 conn=1000 fd=14 TLS established tls_ssf=256 ssf=256 572be687 conn=1000 op=1 BIND dn="" method=163 572be687 conn=1000 op=1 BIND authcid="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" authzid="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" 572be687 conn=1000 op=1 BIND dn="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" mech=EXTERNAL sasl_ssf=0 ssf=256 572be687 conn=1000 op=1 RESULT tag=97 err=0 text= 572be687 conn=1000 op=2 MOD dn="cn=La Valko,ou=Peons,dc=example,dc=com" 572be687 conn=1000 op=2 MOD attr=description /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_modify_ext A checked against the libraries in use returns the following: root@alcoa12:/usr/local/etc/openldap# ldd /usr/local/libexec/openldap/back_ldap-2.4.so.2 linux-vdso.so.1 => (0x00007fff14b39000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc92c915000) /lib64/ld-linux-x86-64.so.2 (0x00007fc92cf17000) root@alcoa12:/usr/local/etc/openldap# ldd /usr/local/libexec/slapd linux-vdso.so.1 => (0x00007fffab493000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f18edf63000) libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f18edbc1000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f18ed9a5000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f18ed748000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f18ed36d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f18ed133000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f18ecf16000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f18ecb56000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f18ec951000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f18ec73a000) /lib64/ld-linux-x86-64.so.2 (0x00007f18ee187000)

1 0

Re: (ITS#8420) lmdb Windows sizeof(off_t) == sizeof(int32_t)
by hyc＠symas.com 10 May '16

10 May '16

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: lmdb master a04aad31c2 > OS: Windows 7 64 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.54.58.5) > > > This is an lmdb bug. I see no bug here. We fixed this back in January in commit 20dec1f69bf4860202c764ce92b1fbbe3d11a065 > > mdb_page_flush fails as database size nears 2 GB on Windows. The reason is off_t > == int32_t on Windows. So the off_t pos variable becomes negative and this > section of code in mdb_page_flush enters the error condition as ov.OffsetHigh is > also negative: > > ov.Offset = pos & 0xffffffff; > ov.OffsetHigh = pos >> 16 >> 16; > if (!WriteFile(env->me_fd, dp, size, NULL, &ov)) { > rc = ErrCode(); > DPRINTF(("WriteFile: %d", rc)); > return rc; > } > > Adding23dedefine off_t int64_t in an #ifdef _WIN32 region solves 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#8421) LMDB broken for files larger than 2^31 bytes under Windows
by lukaswhl＠gmail.com 10 May '16

10 May '16

--94eb2c123f7c8355130532869195 Content-Type: text/plain; charset=UTF-8 Looks like a duplicate indeed. Didn't see ITS#8420, sorry. 2016-05-11 12:56 GMT+12:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Wednesday, May 11, 2016 1:47 AM +0000 lukaswhl(a)gmail.com wrote: > > Full_Name: Lukas W >> Version: mdb.master >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2407:7000:9a07:8600::2) >> > > Isn't this a dupe of ITS#8420? > > --Quanah > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > --94eb2c123f7c8355130532869195 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Looks like a duplicate indeed. Didn't see ITS#8420, so= rry.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">201= 6-05-11 12:56 GMT+12:00 Quanah Gibson-Mount <span dir=3D"ltr"><<a href= =3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah(a)zimbra.com</a>></= span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex">--On Wednesday, May 11, 2016 1:47 = AM +0000 <a href=3D"mailto:lukaswhl@gmail.com" target=3D"_blank">lukaswhl@g= mail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Lukas W<br> Version: mdb.master<br> OS:<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> Submission from: (NULL) (2407:7000:9a07:8600::2)<br> </blockquote> <br> Isn't this a dupe of ITS#8420?<br> <br> --Quanah<br> <br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Platform Architect<br> Zimbra, Inc.<br> --------------------<br> Zimbra ::=C2=A0 the leader in open source messaging and collaboration<br> A division of Synacor, Inc<br> </blockquote></div><br></div> --94eb2c123f7c8355130532869195--

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