389-users November 2012

389-users@lists.fedoraproject.org

37 participants
33 discussions

Changelog encryption
by Andreas Kekkou 22 Nov '12

22 Nov '12

Hi, Is the changelog encryption option available on CentOS Directory Server 8.2? I have followed the instructions from http://directory.fedoraproject.org/wiki/Changelog_Encryption without any luck. Regards, Andreas

2 1

389-dir + dynamic groups + PAM
by thomas 21 Nov '12

21 Nov '12

Hi, I can't find any how-to-documentation for configuring dynamic groups login on Linux with PAM and 389-dir. Can someone help me finding something about this , please ? Thanks a lot.

3 2

(no subject)
by thomas 21 Nov '12

21 Nov '12

Hi, I can't find any how-to-documentation for configuring dynamic groups login on Linux with PAM and 389-dir. Can someone help me finding something about this , please ? Thanks a lot.

1 0

Tuning dbcache size for large directory
by P R 16 Nov '12

16 Nov '12

Hello, First off, my server is equipped with 12GB of physical memory. From reading tuning guides online, I’ve found that a starting estimate for the ‘dbcachesize’ = SUM(allDB4files). For one of my directory instances, the id2entry.db4 file alone is ~ 11GB. Performance wise, would it be worthwhile to increase the amount of physical memory on the server (perhaps 64-128GB)? Or does 11GB for an id2entry seem like an extremely high value that’s out of the operating capabilities of the directory? Is it unheard of for a production directory server to be equipped with 64GB of physical memory? Thanks, pwr

3 3

MMR issue ...
by Reinhard Nappert 16 Nov '12

16 Nov '12

Hi, I've encountered issues with a MMR setup, which looks like the following: A ------- B \ / \ / \ / C The replication works for approximately 24 hours. There are not many changes to the content anyway. After about 1 day, the attribute value of the type "nsds5replicaLastUpdateStatus" changes to "1 Can't acquire busy replica " of the replication agreement object from type "nsDS5ReplicationAgreement". I see this message on C for the agreement "C-to-B". The start-time of the last update is 01:08:33. When I check the status on B, it looks fine for "B-to-C" and "B-to-A", however, the start-time of the last update is stuck at 01:08:36 for "B-to-C", whereas A gets updated afterwards as well. I don't have the values for A! When, I check errors and access on the boxes, I see the following: Errors on A: [10/Nov/2012:01:19:31 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Warning: unable to receive endReplication extended operation response (Timed out) [10/Nov/2012:01:25:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [10/Nov/2012:01:25:05 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed [10/Nov/2012:02:26:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:02:31:55 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [10/Nov/2012:02:31:59 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed [10/Nov/2012:02:43:36 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:03:03:00 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:03:08:24 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [10/Nov/2012:03:11:35 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:03:11:35 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [10/Nov/2012:03:14:45 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:03:14:52 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed [10/Nov/2012:03:33:29 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:03:33:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [10/Nov/2012:03:43:29 -0300] slapi_ldap_bind - Error: timeout after [0.0] seconds reading bind response for [cn=replication,cn=config] mech [SIMPLE] [10/Nov/2012:03:43:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 85 (Timed out) ((null)) [10/Nov/2012:03:46:39 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:03:46:39 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [10/Nov/2012:03:46:42 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed [10/Nov/2012:05:12:02 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:06:16:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:06:21:27 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [10/Nov/2012:06:21:46 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed [10/Nov/2012:06:39:23 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:07:43:45 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:19:38:22 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [10/Nov/2012:19:43:51 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [10/Nov/2012:19:43:54 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed [10/Nov/2012:20:18:21 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:20:18:21 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [10/Nov/2012:20:23:21 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:20:28:21 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:20:33:20 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:20:38:22 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:20:43:22 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:20:48:20 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:21:00:15 -0300] slapi_ldap_bind - Error: timeout after [0.0] seconds reading bind response for [cn=replication,cn=config] mech [SIMPLE] [10/Nov/2012:21:00:15 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 85 (Timed out) ((null)) [10/Nov/2012:21:03:24 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:21:03:24 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [10/Nov/2012:21:06:36 -0300] slapi_ldap_bind - Error: could not send bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [10/Nov/2012:21:16:39 -0300] slapi_ldap_bind - Error: timeout after [0.0] seconds reading bind response for [cn=replication,cn=config] mech [SIMPLE] [10/Nov/2012:21:16:39 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth failed: LDAP error 85 (Timed out) ((null)) [10/Nov/2012:21:24:14 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): Replication bind with SIMPLE auth resumed Errors on B: [10/Nov/2012:01:27:56 -0300] NSMMReplicationPlugin - agmt="cn=B-to-A" (A:389): Replication bind with SIMPLE auth resumed Errors on C: No entry for the time I also analyzed the access files and see the following: >From access on A: I see replication sessions from B and C, established at 01:00:10 and closed at 01:01:14. Next replication session from C, established at 01:05:12 and closed at 01:06:12. There was NO session from B. B and C establish the next replication session at 01:07:52. During the session, a MOD is performed at 01:08:33. C closes this session at 01:09:35. The session from B stays open, and I see a ABANDOM request from A at 01:17:53. Eventually, the session gets closed (no unbind) at 01:23:25. [10/Nov/2012:01:17:53 -0300] conn=1439 op=3 ABANDON targetop=NOTFOUND msgid=3 Replication sessions from C continue to work fine. There is one more replication session from B, established at 01:27:56 and closed at 01:28:38. After this session, B does not establish any replication session anymore. >From access on B: I see replication sessions from A and C, established at 01:00:09 and closed at 01:01:14. Next replication session from C, established at 01:05:12 and closed at 01:06:12. There was NO session from A. A and C establish the next replication session at 01:07:52. During the session, a MOD is performed at 01:08:33. C closes this session at 01:09:35. The session from A stays open forever!!! Replication sessions from C continue to work fine. >From access on C: I see replication sessions from A and B, established at 01:00:09 and closed at 01:01:14. I don't see any replication session from the 01:05 time-slot A and B establish the next replication session at 01:07:53. During the session, a MOD is performed at 01:08:33. A closes this session at 01:09:33 and B closes session at 01:09:38 >From now on, I only see replication sessions from A! Has anybody seen this kind of behavior? Any feedback is highly appreciated. Thanks, -Reinhard

4 21

Re: [389-users] Tuning dbcache size for large directory
by Howard Chu 16 Nov '12

16 Nov '12

389-users-request(a)lists.fedoraproject.org wrote: > Date: Fri, 16 Nov 2012 09:30:26 -0500 > From: P R <pwrdevman(a)gmail.com> > First off, my server is equipped with 12GB of physical memory. From reading > tuning guides online, I’ve found that a starting estimate for the > ‘dbcachesize’ = SUM(allDB4files). For one of my directory instances, the > id2entry.db4 file alone is ~ 11GB. Wow, still manually tuning cache sizes, how quaint. > Performance wise, would it be worthwhile to increase the amount of physical > memory on the server (perhaps 64-128GB)? Or does 11GB for an id2entry seem > like an extremely high value that’s out of the operating capabilities of > the directory? Is it unheard of for a production directory server to be > equipped with 64GB of physical memory? Dunno about 389DS, but there are production OpenLDAP installations out there running on 64-core machines with over a terabyte of RAM. (The NoSQL/Big Data guys are just noisy children, really...) They serve directories with hundreds of millions to billions of entries. 11GB sounds pretty trivial to me. So no, it's not unheard of. It's not even very extreme, really. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: [389-users] Question about 389-ds and Solaris
by Carsten Grzemba 16 Nov '12

16 Nov '12

Am 14.11.12, schrieb Jean-Francois Saucier <jsaucier(a)gmail.com>: > Hi everyone, > > I just installed 389-ds on Fedora and have a problem with Solaris clients. > > Everything works well on the Linux side (Fedora, CentOS and RHEL clients works fine). > > On the Solaris side, I got everything to work too (pam, ssh, getent passwd, getent group, ldaplist -l paswd, ldaplist -l group, etc). I used the native Solaris ldapclient tool to make everything work. > > > The problem I have is with the Group attribute. In 389-ds, the group are created with the objectClass "groupofuniquenames" and the members are listed with the attribute "uniqueMember". I manually add the objectClass "posixgroup" to allow the group to be visible on the client. > > > With this configuration, everything work fine in Linux. In Solaris, I can see the group with "getent group" but there are no member. What I have found is that Solaris need it's member to be in the "memberUid" attribute and not in the "uniqueMember" attribute. > memberUid is standard for posixGroups and works for Linux clients too. > > > > Also, I found that while uniqueMember require a full qualification (uid=jeff,ou=people,dc=test,dc=com), the memberUid just require the uid (jeff). > > > What should I do to make this work easy on Solaris? Adding the memberUid by hand is not an option because it's sure there will be a difference between the uniqueMember and memberUid list in some point in time. > How you add uniqueMember? If you want to continue to maintain uniqueMember than you have the following options: - try to use winbind of Samba on the Solaris client to resolve the groups - map uniqueMember to memberUid with a script in your preferred scripting language - in an AD - DS replication setup there is contained a logic which maps uniquemember to memberUid automatically. This can also triggered via a task. > > > > > Thank you! > > -- > Jean-Francois Saucier (djf_jeff) > GPG key : 0xA9E6E953 > Regards -- Carsten Grzemba

3 4

Re: [389-users] 389ds + modrdn + NSMMReplicationPlugin - Consumer failed to replay change
by Derek Belcher 15 Nov '12

15 Nov '12

Thank you for all of your help Rich. I have opened a ticket with fedorahosted.org/389 Ticket # 521 --Derek On Wed, Nov 14, 2012 at 10:16 AM, Rich Megginson <rmeggins(a)redhat.com>wrote: > On 11/14/2012 08:56 AM, Derek Belcher wrote: > > This master is bi-directionally syncing with my Active Directory server. > On the AD server, I have created a customer filtered view for the time this > started, 11/12/2014 between 1pm and 2pm, included all possible windows log > sources and I am not seeing any errors. I believe this is due to 389ds, > pulls and pushes updates, and AD is not really aware of 389ds. > > > Correct. > > > > So I am thinking that the modrdn command is not able to make the changes > on the AD side? But if 389ds is pushing changes... > > > It should be, but AD is more restrictive of the types of modrdn and entry > move operations it will allow. > > > > What is also interesting is that you can in AD "move" a users to a > different DN and 389ds will replicate that change to all of its > multi-masters and consumers. Just does not seem to work when you do DN > changes on the 389ds side and it pushes to AD. > > > It should work - does this happen with any modrdn entry move operation? > > > > Is there a way to remove this offending entry in the change log? > > > Not that I know of. What you will have to do is dump your database to > ldif and reload it, then reinitialize all of your replicas and winsync > agreements. > > Please file a ticket at https://fedorahosted.org/389 - this is definitely > a bug. > > > > > On Wed, Nov 14, 2012 at 9:22 AM, Rich Megginson <rmeggins(a)redhat.com>wrote: > >> On 11/14/2012 08:18 AM, Derek Belcher wrote: >> >> Good morning Rich, >> >> # rpm -q 389-ds-base >> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 >> >> >> What does it say in the consumer access and errors log for this change >> replay attempt? >> >> Look in the consumer access log for 50a150a4000000020000, see what the >> timestamp is, then look in the errors log at around that timestamp. >> >> >> >> Thank you >> >> >> On Wed, Nov 14, 2012 at 8:58 AM, Rich Megginson <rmeggins(a)redhat.com>wrote: >> >>> On 11/13/2012 07:21 PM, Derek Belcher wrote: >>> >>> Here is the error message that I am receiving in >>> /var/log/dirsrv/slap-xxxx/errors : >>> >>> [13/Nov/2012:20:13:27 -0600] NSMMReplicationPlugin - agmt="cn=sync001" >>> (AD1.company.net:636): Consumer failed to replay change (uniqueid >>> 754ce981-e4d411e1-b828c127-7d7e145e, CSN 50a150a4000000020000): Server is >>> unwilling to perform. Will retry later. >>> >>> Thanks again for your time. >>> >>> rpm -q 389-ds-base >>> >>> >>> >>> On Tue, Nov 13, 2012 at 5:38 PM, Derek Belcher <jderekbelcher(a)gmail.com>wrote: >>> >>>> Good evening, >>>> >>>> I am requesting some help from the community, I have an issue that I >>>> can not seem to resolve. >>>> >>>> Yesterday I committed a change on a users DN and today I noticed >>>> replication issues in my logs. The logs told me the uniqueid # and CSN # >>>> >>>> So I used cl-dump to dump the changelog into a file. Here are the >>>> results of what I grep'ed out: >>>> >>>> >>>> [root@ds]# grep "50a150a4000000020000" -B2 -A13 /var/tmp/change.dump >>>> changetype: modrdn >>>> replgen: 4ff8a4c0000000010000 >>>> csn: 50a150a4000000020000 >>>> nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e >>>> dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net >>>> newrdn: uid=auser >>>> deleteoldrdn: false >>>> newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net >>>> change:: >>>> replace: modifiersname >>>> modifiersname: cn=directory manager >>>> - >>>> replace: modifytimestamp >>>> modifytimestamp: 20121112194019Z >>>> - >>>> >>>> So now that I know what entry NSMReplicationPlugin is complaining >>>> about, I don't know what to do in order to fix it and get replication back >>>> on track. >>>> >>>> I really appreciate any help on this matter, Thank you >>>> >>> >>> >>> >>> -- >>> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> >>> >> >> > >

2 5

segfault while moving entry to non-existent LDAP container
by Vlad 14 Nov '12

14 Nov '12

Hello, First of all I'd say that most likely this segfault is a result of badly designed application and/or bad coding. The segfault occurs while this application tries to move an entry to non-existing LDAP container. Unfortunately I don't have access to the source code of this app. The segfault is below with backtrace from dgb: ns-slapd[4983]: segfault at 18 ip 00007f2ed4a60759 sp 00007f2e955e13e0 error 4 in libback-ldbm.so[7f2ed4a34000+8f000] #0 0x00007f2ed4a60759 in id2entry_add_ext () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #1 0x00007f2ed4a8a34c in modify_update_all () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #2 0x00007f2ed4a8eb4f in ldbm_back_modrdn () from /usr/lib64/dirsrv/plugins/libback-ldbm.so #3 0x00007f2eddbecdaa in ?? () from /usr/lib64/dirsrv/libslapd.so.0 #4 0x00007f2eddbed66c in do_modrdn () from /usr/lib64/dirsrv/libslapd.so.0 #5 0x0000000000413904 in ?? () #6 0x00007f2edc0369e3 in ?? () from /lib64/libnspr4.so #7 0x00007f2edb9d9851 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f2edb72711d in clone () from /lib64/libc.so.6 I'd appreciate any thoughts regarding what kind of (bad) things this application is doing. Is it possible to have a kind of protection in this case on directory server? Regards, Vlad.

4 10

389ds + modrdn + NSMMReplicationPlugin - Consumer failed to replay change
by Derek Belcher 14 Nov '12

14 Nov '12

Good evening, I am requesting some help from the community, I have an issue that I can not seem to resolve. Yesterday I committed a change on a users DN and today I noticed replication issues in my logs. The logs told me the uniqueid # and CSN # So I used cl-dump to dump the changelog into a file. Here are the results of what I grep'ed out: [root@ds]# grep "50a150a4000000020000" -B2 -A13 /var/tmp/change.dump changetype: modrdn replgen: 4ff8a4c0000000010000 csn: 50a150a4000000020000 nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net newrdn: uid=auser deleteoldrdn: false newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net change:: replace: modifiersname modifiersname: cn=directory manager - replace: modifytimestamp modifytimestamp: 20121112194019Z - So now that I know what entry NSMReplicationPlugin is complaining about, I don't know what to do in order to fix it and get replication back on track. I really appreciate any help on this matter, Thank you

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2012