openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7114) Password synchronization is not working
by venkata.udumula＠yahoo.co.in 20 Dec '11

20 Dec '11

Full_Name: venkata reddy Version: 2.4.26 OS: Windows server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.252.70.4) Hi, I am setting up a Forefront Identity Manager (FIM) infrastructure. I installed the FIM software. Our Active Directory is already exists. And I have to use another LDAP system for testing the my FIM setup. I chose OpenLDAP for Windows, as i am comfortable with only windows applications. I am assuming that your Tech support team would have some idea of what FIM does. I have setup the management agents on the FIM synchronize server to FIM, AD and OpenLDAP. For FIM and AD management agents are available by default in the FIM synchronization server. But for OpenLDAP i used OpenLDAP XMA management agent provided by sourceforge. With the management agents I am able to move the user and group objects between all the systems successfully. When a new user is created the password is moved to the OpenLDAP system successfully. But when I change the password in the FIM portal, it should automatically update it in all the systems. It is updating in the FIM and AD. But not in OpenLDAP. I am not aware of any configuration settings I have to change to make it work in OpenLDAP. Could you please help me resolving this issue? At the time of installation instead of using the default port numbers I used 50000 for LDAP and 50001 for LDAPS. Is it a problem? Thanks,

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 19 Dec '11

19 Dec '11

On 12/15/11 11:14 PM, Howard Chu wrote: > > A fix for this is in git master, please test. > Built and deployed, I've allowed to run for 72h and problem has yet to show. I believe this particular bug has been squashed.

1 0

(ITS#7113) broken read-only replica results in assertion failure and crash on master slapd process
by kacarstensen＠csupomona.edu 19 Dec '11

19 Dec '11

Full_Name: Kevan Carstensen Version: 2.4.28 OS: gentoo linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.71.248.23) During a heavy update load, replication from our master to one of our read-only ldap replicas started failing due to locking errors on the replica. Dec 14 04:01:08 pip-dev slapd[12645]: bdb(dc=csupomona,dc=edu): Lock table is out of available lock entries Dec 14 04:01:08 pip-dev slapd[12645]: => bdb_idl_delete_key: c_get failed: Cannot allocate memory (12) Dec 14 04:01:08 pip-dev slapd[12645]: conn=-1 op=0: attribute "memberUid" index delete failure Dec 14 04:01:08 pip-dev slapd[12645]: null_callback : error code 0x50 Dec 14 04:01:08 pip-dev slapd[12645]: syncrepl_entry: rid=001 be_modify failed (80) Dec 14 04:01:08 pip-dev slapd[12645]: do_syncrepl: rid=001 rc 80 retrying (these are due to an incorrect DB_CONFIG on the replica and are not related to this issue; I include them in case their impact on how/when the replica connects to the master are important) After about ten minutes of the replica trying and failing to start its syncrepl again, the master slapd crashed. Nothing in the master slapd logs specifically references the crash or indicates why it happened. Shortly after the replica broke, some unusual messages started showing up in the logs on the master: Dec 14 03:50:11 fosse slapd[22596]: connection_read(65): no connection! Dec 14 03:50:22 fosse slapd[22596]: send_search_entry: conn 7535053 ber write failed. Dec 14 03:50:32 fosse slapd[22596]: send_search_entry: conn 7535061 ber write failed. Dec 14 03:50:42 fosse slapd[22596]: send_search_entry: conn 7535065 ber write failed. Dec 14 03:50:56 fosse slapd[22596]: send_search_entry: conn 7535068 ber write failed. Dec 14 03:51:06 fosse slapd[22596]: connection_read(65): no connection! Dec 14 03:51:06 fosse slapd[22596]: connection_read(65): no connection! These continued until the crash, persisted after the master slapd was successfully restarted, and went away when I turned the broken replica off. I found similar behavior in a development setup similar to our production setup. There is one master, and there are two read-only replicas configured to replicate from the master with the following syncrepl stanza: syncrepl rid=1 provider=ldaps://master-2.ldap.csupomona.edu/ type=refreshAndPersist retry="10 10 60 +" searchbase="dc=csupomona,dc=edu" bindmethod=simple binddn=cn=slapd-syncrepl,ou=user,ou=service,dc=csupomona,dc=edu credentials=__PASSWORD__ (there are two replicas because I couldn't reliably produce a crash with one replica) The replicas have a DB_CONFIG that causes their replication attempts to fail with the same error as we saw in our production setup. The master database is initialized so that the replicas have a lot of changes to catch up on, as was the case when our production setup failed. Even with loglevel -1, there's nothing specifically referencing the crash in the master slapd's logs. There's an assertion failure in the backtrace: slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffea863700 (LWP 27623)] 0x00007ffff6a95175 in raise () from /lib64/libc.so.6 (gdb) bt full #0 0x00007ffff6a95175 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff6a96590 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007ffff6a8e201 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x000000000042ec9b in slapd_clr_write (s=<value optimized out>, wake=0) at daemon.c:942 id = 0 __PRETTY_FUNCTION__ = "slapd_clr_write" #4 0x000000000043419b in connection_write (s=17) at connection.c:1896 c = <value optimized out> op = <value optimized out> __PRETTY_FUNCTION__ = "connection_write" #5 0x000000000043006a in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2782 rc = 1 fd = 17 w = 6 ns = 1 at = 0 revents = <value optimized out> tvp = <value optimized out> cat = {tv_sec = 1324320980, tv_usec = 0} i = 0 now = <value optimized out> tv = {tv_sec = 1135, tv_usec = 0} rtask = <value optimized out> l = <value optimized out> last_idle_check = 1324317380 ebadf = 0 tid = <value optimized out> #6 0x00007ffff71ed914 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #7 0x00007ffff6b347dd in clone () from /lib64/libc.so.6 No symbol table info available. The master and replicas in my development setup all run 2.4.28. The production master runs 2.4.26. I successfully reproduced the issue on both 2.4.26 and 2.4.28, but only have a backtrace for 2.4.28. If you want a backtrace for 2.4.26, I can get one. Thanks.

1 0

Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by mkrz＠free.fr 16 Dec '11

16 Dec '11

----- Mail Original ----- De: "Howard Chu" <hyc(a)symas.com> À: mkrz(a)free.fr Cc: openldap-its(a)openldap.org Envoyé: Jeudi 8 Décembre 2011 22h37:21 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations >> I noticed an issue with "refreshOnly" syncrepl when a large number of records is >> added, updated and deleted. At the end of synchronization the contextCSN is >> equal on all servers, but the data is out of synchronization for some deleted >> records that remains undeleted on consumer/slave servers. >> >> Restarting the consumer or forcing a synchronization with "slapd ... -c >> 'rid=1,csn=0' " does not help. > >This appears to caused by the sessionlog overflowing due to incoming modifies >that occur after the refresh operation has begun. I would call this a >misconfigured server, since the sessionlog can only ever be useful if you size >it large enough to accomodate all of your update traffic. > >I don't have any plans to fix this issue; fix the server configuration. Thank you for your answer. I withdrew the "syncprov-sessionlog" parameter and this fixed the data loss issue.

1 0

Re: (ITS#7112) Slapd Daemon leaking file descriptor
by quanah＠zimbra.com 15 Dec '11

15 Dec '11

--On Friday, December 16, 2011 5:45 AM +0000 aditya1606(a)gmail.com wrote: > Full_Name: Aditya Bajaj > Version: 2.2.30 > OS: RHEL 5.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.100.112.203) 2.2 is not a supported release series. 2.3 is not a supported release series. Upgrade to a supported release series. This ticket will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7112) Slapd Daemon leaking file descriptor
by aditya1606＠gmail.com 15 Dec '11

15 Dec '11

Full_Name: Aditya Bajaj Version: 2.2.30 OS: RHEL 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.100.112.203) Hello, losf of slapd is showing like this slapd 10127 root 585u sock 0,5 3532897126 can't identify protocol we have read openldap previous queries , were it as being mentioned that its already fixed in 2.3.32 or after. My question is what was the ticket number that fixed this issue. we would like to now more about that ticket. Regards Aditya

1 0

(ITS#7111) Forward bug-fix commits to ITS
by hyc＠OpenLDAP.org 15 Dec '11

15 Dec '11

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc Testing...

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hyc＠symas.com 15 Dec '11

15 Dec '11

hume-ol(a)bofh.ca wrote: > I have reproduced the problem on 2.4.27. The mentioned ldapsearch query > seems to have a high probability of success if run immediately after > server start, which also seems true on 2.4.28. > > I threw in an extra Debug() line and op->op_protocol == 2 at the check. > > I'm rebuilding with as many debugging symbols enabled as possible to try > to figure out what's going on. A fix for this is in git master, please test. -- -- 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#7110) cn=config mixes values
by raphael.ouazana＠linagora.com 15 Dec '11

15 Dec '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, I try to modify valuse of eg. olcAccess with a certain order, I get different values if numbered values are in the correct order or not. Case 1 (normal): dn: olcDatabase={3}bdb,cn=config changetype: modify replace: olcAccess olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write Result: olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write Case 2 (inversed values): dn: olcDatabase={3}bdb,cn=config changetype: modify replace: olcAccess olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write Result: olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write The two last values are incorrectly mixed. Regards, Raphaël Ouazana.

1 0

Re: (ITS#7109) Slapd Freezing
by h.b.furuseth＠usit.uio.no 14 Dec '11

14 Dec '11

I wrote: >> And what information should we provide to solve this problem? (strace, gdb >> log, db_stat or something else?) > > Server log from slapd, and gdb 'thread apply all backtrace'. Eh, I forgot the obvious one: slapd's configuration, minus any passwords. -- Hallvard

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