November 2014 - 389-users - Fedora mailing-lists

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

multi-valued nsAccountLock
by Pierre ROUDIER 10 Jul '15

10 Jul '15

Hi all, RedHat DS's doc states that the nsAccountLock attribute is multi-valued [1]. Some tests with 389ds led me to think it's also true for 389ds. I cannot think of any reason explaining why it would have to be multi-valued. Do you have any idea? Thank you. [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server…

3 2

changelog
by Denise Cosso 16 Apr '15

16 Apr '15

Hi, How to modify the attribute nsslapd-encryptionalgorithm in Centos? Thanks, Denise Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES. dn: cn=changelog5,cn=config [...] nsslapd-encryptionalgorithm: AES --- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu: De: Rich Megginson <rmeggins(a)redhat.com> Assunto: Re: [389-users] changelog Para: "Denise Cosso" <guanaes51(a)yahoo.com.br> Data: Terça-feira, 4 de Junho de 2013, 16:34 On 06/04/2013 01:26 PM, Denise Cosso wrote: Hi, Rich CentOS release 6.3 (Final) 389-ds-base-libs-1.2.10.2-20.el6_3.x86_64 389-ds-1.2.2-1.el6.noarch 389-dsgw-1.1.10-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-1.2.10.2-20.el6_3.x86_64 As far as replication goes - you will need to use a security layer (SSL, TLS, or GSSAPI) to protect the clear text password on the wire As far as encrypting it in the changelog - not sure Denise --- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu: De: Rich Megginson <rmeggins(a)redhat.com> Assunto: Re: [389-users] changelog Para: "General discussion list for the 389 Directory server project." <389-users(a)lists.fedoraproject.org> Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br> Data: Terça-feira, 4 de Junho de 2013, 16:11 On 06/04/2013 12:39 PM, Denise Cosso wrote: Hi, Description of problem: When a userPassword is changed in a server with changelog, the hashed password is logged and also a cleartext pseudo-attribute version. It looks like this: change:: replace: userPassword userPassword: {SHA256}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q== - replace: unhashed#user#password unhashed#user#password: secret12 This unhashed version is used in winsync where the cleartext version of the password must be written to the AD. Now if the DS is involved in replication with another DS, the change will be replayed exactly as it is logged to the other DS replicas, including the cleartext pseudo-attribute password. What platform? What version of 389-ds-base are you using? thanks, Denise -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

2 2

389 GUI/Console
by Gonzalo Fernandez Ordas 03 Mar '15

03 Mar '15

Hi I got 389 running on a remote linux box,and I would like to get use of the Console without the need of exporting the X-Windows whenever I want to make a change as I also would prefer not to keep tweaking the configuration files all the time. is there anyway of doing this through any remote client? Any advise on this matter? Thanks very much

4 11

How to get password expiration working?
by Paul Tobias 15 Dec '14

15 Dec '14

Hi guys, We need to implement password expiration because of some policy. The problem is users are not able to bind to ldap anymore, after I switch on password expiration for our ou=People subtree . The ldap command line tools and 389-console both just hang forever when trying to connect. This happens even when the user changes the password right before switching on the password expiration so the password cannot be expired yet. When I use the wrong password, then I get "ldap_bind: Invalid credentials (49)", but when I use the correct password, then it's just a hang. If I switch off password expiration then everything returns to normal again. I've followed the guide at https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/… I've tried both 389ds 1.2.11.32 on CentOS 6 and 389ds 1.3.2.23 on Fedora 20 with the same results. Is password expiration working in 389ds at all? Thanks in advance, Paul Tobias

2 2

Switching from 389-ds-base 1.2.11 to 1.3.3
by Fong, Trevor 01 Dec '14

01 Dec '14

Hi Everyone, I’m afraid this will be a total newb question. I’m currently running 389 DS 1.2.11.29-1.el6 and have seen the notice that 1.2.11.X will be discontinued soon (as of 24-Oct-2014). [It probably has already been discontinued since the COPR repository is no longer there.] I’d like to switch from 1.2.11 to 1.3.3.5 and have yum downgraded to 1.2.11.15-48.el6_6. However, when I try to "yum upgrade 389-ds-base 389-ds-base-devel 389-ds-base-libs” it tells me "No Packages marked for Update”. Am I doing something wrong? I’ve followed the directions on http://www.port389.org/docs/389ds/download.html and epel-release-6-8.noarch.rpm is already installed. [That doc is still telling me to install the temporary COPR, by-the-way.] Thanks in advance, Trev

2 2

Increase in search time operation in 1.2.11 vs 1.2.5
by Bartek 26 Nov '14

26 Nov '14

Hello I have an use case where particular search operations on the same data in 1.2.5 and 1.2.11 differ significantly. 1.2.5 is on Centos 5.9 and 1.2.11 on Centos 5.11. I'm asking this as i'm in the middle of upgrade process and I come across this performance issue. After feeding both versions with data from the same text dump, particular search operation takes 0.5s in 1.2.5 to complete whereas in 1.2.11 it takes 6s: ldapsearch -D 'uid=root,ou=users,o=xxx' -x -b 'uid=someuser,dc=domain,dc=pl,o=xxx' -s subtree -w pass '(objectClass=someObjectClass)' There is a set of 40 acls at the dc=pl,o=xxx node and 9 more on dc=domain,dc=pl,o=xxx. The acl allowing 'uid=root,ou=users,o=xxx' to access everything is at o=xxx. I did already manage to figure out that the more acis i remove the shorter the search operation is. However even with those aci in place, search on 1.2.5 returns significantly faster. I would like to ask if there are any factors that would make search operations longer while jumping from 1.2.5 to 1.2.11? -- Regards Bartek

3 4

389-console display count number for DS entries
by ghiureai 19 Nov '14

19 Nov '14

Hi Gurus, I need to know how to cfg 389-admin console to be able to display the total number of entries in DS ( the count number) , seems that Appache Studio has a limitation to 2000 entries/counts ( is this correct ?), I increase the browsing options to 100000 for DS Users but will show as ( 2000) beside Users Isabella

2 2

Serious memory issues with 1.2.11.x on RHEL 6.6
by Steve Holden 18 Nov '14

18 Nov '14

Hi, folks We've been really pleased with our 389 servers, which have been successfully running as a multi-master pair in production for 7 weeks, following (elapsed) months of development. Unfortunately, in the last few days their performance has radically degraded to the point where they are becoming unusable due to excessive memory consumption. At first, we suspected a recent update to the package - but are no longer convinced that's the problem. I'd really appreciate any suggestions on how to troubleshoot this further. SYMPTOMS 389 ignores its 4GB userRoot nsslapd-cachememsize and its overall memory usage expands to encompass all of the server's 8GB RAM - and a large proportion of its 10GB swap. The service eventually fails, and hangs the server. DETAILS As per the previous guidance for RHEL 6 installations, we had been using the packages from the COPRS repository (389-ds-base-1.2.11.32-1 aka 1.2.11.32 B2014.247.2316). (As several of our applications require CoS/dynamic attributes, earlier versions of the RHEL packages were unusable for us until this fix was ported: https://fedorahosted.org/389/ticket/47762#comment:8 - which was only recently applied to the RHEL packages). Due to an unfortunate misconfiguration, the production servers received automated updates - and were upgraded to RHEL 6.6, the latest COPRS package (1.2.11.32-1), and a new kernel :-/ The directory contains 236,340 entries, and id2entry.db4 is 3.6GB. STEPS TAKEN We've tried to balance isolating the problem with maintaining a critical service for our users: * An additional 8GB RAM (and additional CPU) was added to the VM to mitigate the immediate problem - but this was soon swallowed up too. * Attempting to reproduce this on our equivalent development servers has not been successful, even when subjecting them to load. * Downgrading to the RHEL packages (1.2.11.15-48 aka 1.2.11.15 B2014.300.2010) as per Noriko's very helpful procedure below (though I stopped the services prior to the downgrade). No obvious difference. * Rebooting into the previous kernel (2.6.32-431.29.2). This slowed the problem, but only to an extent. Not attempted yet: * Turning on debugging on the production servers, as they're in a fragile and sluggish state. * Building the latest 1.3.x build on RHEL 6. Will be attempting this soon... * Installing RHEL 7.0 on a fresh VM, as we don't have experience with 7 yet. * Downgrading to the previous COPRS package, as no longer publicly available(?) Please let me know if more information would help... Kind regards, Steve From: 389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Noriko Hosoi Sent: 25 October 2014 00:05 To: 389-announce(a)lists.fedoraproject.org<mailto:389-announce@lists.fedoraproject.org>; General discussion list for the 389 Directory server project. Subject: [389-users] Please take an action: 389 Directory Server 1.2.11.X Discontinued for EL6 389 Directory Server 1.2.11.X Discontinued for EL6 The 389 Directory Server team announces the binary release of 389-ds-base version 1.2.11 for EL6 will be stopped via temporary COPR repository. We encourage you to switch it to the official version included in the Red Hat Enterprise Linux 6 distribution or its equivalent OS. How to switch to the official version Remove a yum repo file which points to the temporary COPR repository (e.g., nhosoi-389-ds-base-epel6-epel-6.repo) from /etc/yum.repos.d. If the current 389 Directory Server 1.2.11 has the greater build number than 15, for instance, 1.2.11.32, downgrade it once by "yum downgrade" as follows. yum downgrade 389-ds-base 389-ds-base-libs Then, upgrade to make sure you have the latest version. yum upgrade 389-ds-base After upgrade completes, run setup-ds-admin.pl -u to update your directory server/admin server/console information. setup-ds-admin.pl -u See Install_Guide<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade See Source<http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. http://www.port389.org/docs/389ds/releases/end-1-2-11.html ___________________________________________________________ This email has been scanned by MessageLabs' Email Security System on behalf of the University of Brighton. For more information see http://www.brighton.ac.uk/is/spam/ ___________________________________________________________

2 1

389ds v1.3.2.24 error log message: replica_generate_next_csn adjusted
by Ivanov Andrey (M.) 17 Nov '14

17 Nov '14

Hi, we've migrated our production systems to 389ds version 1.3.2.24. Everything seems fine now, the only new messages i see in error logs (several times per day) are [15/Nov/2014:03:58:43 +0100] - replica_generate_next_csn: opcsn=5466c164000000010000 <= basecsn=5466c164000000020000, adjusted opcsn=5466c164000100010000 [15/Nov/2014:10:38:38 +0100] - replica_generate_next_csn: opcsn=54671f1f000000010000 <= basecsn=54671f1f000000030000, adjusted opcsn=54671f1f000100010000 Are these only information messages that can be safely ignored or they may be a manifestation of some potential problem? In source code (./ldap/servers/plugins/replication/repl5_replica.c) it looks like a serious one (SLAPI_LOG_FATAL): slapi_log_error (SLAPI_LOG_FATAL, NULL, "replica_generate_next_csn: " "opcsn=%s <= basecsn=%s, adjusted opcsn=%s\n", opcsnstr, basecsnstr, opcsn2str); Thanks!

2 2

Syntax violations while reinitializing database
by shardulsk 17 Nov '14

17 Nov '14

Hi Folks, We are trying to move our database from the much older 1.1.2 version to 1.2.11 on a Centos 6 platform. When trying to initialize the 1.2.11 database with a ldif file exported from the older database I am getting tons of syntax violations. The schema (99user.ldif + dse.ldif extensions) is the same. Does the newer version have stricter rules? import userRoot: WARNING: skipping entry "cn=23609-17622,ou=other,ou=23609,ou=enterprises,o=x.com" which violates attribute syntax, ending line 7196556 of file "/tmp/qa-db-mod.ldif” thanks, SK.

2 1

replicate_now script help
by ghiureai 13 Nov '14

13 Nov '14

Hi LIst, I'm new to 389-ds admin , I have cfg a multimaster replication system , and read the RHES -DS documentation find the replicate_now script which is suppose to trigger master rep updates < 10 min, the script fails , there is no option for -1 in ldapsearch ...etc Wodner if any of you have an update script , I 'm running 389-ds on CentoS 6.5 . Thank you Isabella

4 17

add user aci problem
by Alberto Viana 13 Nov '14

13 Nov '14

389-Directory/1.3.2.17 B2014.182.124 I'm trying to add an user (whitout using the manager, with a regular user): Without any aci: ldap_add: Insufficient access (50) additional info: Insufficient 'add' privilege to the 'userPassword' attribute My aci: dn: ou=test,dc=my,dc=domain changetype: modify add: aci aci: (targetattr = "*") (target = "ldap:///test,dc=my,dc=domain") (version 3.0;acl "POP-AL write permission";allow (all) (userdn = "ldap:///uid=my_user,ou=app,dc=my,dc=domain");) Also tried without "target" with same result. ldap_add: Constraint violation (19) additional info: invalid password syntax - passwords with storage scheme are not allowed I have an older server 389-Directory/1.3.2.17 B2014.182.124, and this works fine. What am I missing in the newer version? Or is that a bug? Thanks Alberto Viana

4 5

Lots of abandoned connections from sssd
by Orion Poplawski 12 Nov '14

12 Nov '14

Just recently we're seeing some very strange behavior on our system. Periodically we will see a sssd process start to have an ever greater number of connections to our ldap server until the server runs out of file descriptors. This seems to be happening with a particular user, who is having trouble logging in at times, particularly with email (dovecot). We see entries like the following on our sever: [05/Nov/2014:17:14:51 -0700] conn=1786153 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [05/Nov/2014:17:14:51 -0700] conn=1786153 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [05/Nov/2014:17:14:51 -0700] conn=1786153 SSL 128-bit AES [05/Nov/2014:17:14:51 -0700] conn=1786153 op=1 BIND dn="uid=user,ou=People,dc=domain,dc=com" method=128 version=3 [05/Nov/2014:17:14:56 -0700] conn=1786153 op=2 ABANDON targetop=NOTFOUND msgid=2 [05/Nov/2014:17:14:56 -0700] conn=1786153 op=3 UNBIND [05/Nov/2014:17:14:56 -0700] conn=1786153 op=3 fd=1022 closed - U1 I don't yet have debug info from the sssd process. Any ideas from the above? Restarting the sssd process seems to clear things up for a while. - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

4 18

389ds v.1.3.2.24 replication deadlocks/retry count exceeded
by Ivanov Andrey (M.) 12 Nov '14

12 Nov '14

Hi, I've continued testing 389ds v.1.3.2.24 on CentOS 7. I really have an impression that everything works fine (plugins etc) but the replication seems to be a little fragile. Both of the tickets i've already opened concern replication partially or completely (https://fedorahosted.org/389/ticket/47942 and https://fedorahosted.org/389/ticket/47950) Here is another issue with replication : i have two servers with multi-master agreements on each of them (the same configuration as in ticket https://fedorahosted.org/389/ticket/47942) We add/delete a lot of groups (943, to be exact). Each group may contain a large number of referenced entries, up to ~250 (uniqueMember: dn). MemberOf plugin is activated and works fine. Referential integrity plugin is also activated but of course it is of any sense only when deleting groups (or renaming them). It goes on for a long time (20-30 minutes or more). Some time after the beginning of the operations (typically 5-8 minutes) we have replication erros and inconsistency of the replica concerning the entries mentioned in error log. When adding and deleting groups the supplier is ok. Howevere the consumer has several (from one to four or five) groupe deletions/adds that are not replicated. The error on the supplier: [12/Nov/2014:16:46:42 +0100] NSMMReplicationPlugin - agmt="cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr" (ldap-model:636): Consumer failed to replay change (uniqueid fa90219d-6a8211e4-a42c901a-94623bee, CSN 546380d6000000020000): Operations error (1). Will retry later. [12/Nov/2014:16:47:55 +0100] NSMMReplicationPlugin - agmt="cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr" (ldap-model:636): Consumer failed to replay change (uniqueid 1e5367ae-6a8311e4-a42c901a-94623bee, CSN 54638125000000020000): Operations error (1). Will retry later. [12/Nov/2014:16:53:14 +0100] NSMMReplicationPlugin - agmt="cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr" (ldap-model:636): Consumer failed to replay change (uniqueid f4e70b85-6a8311e4-a42c901a-94623bee, CSN 54638260000000020000): Operations error (1). Will retry later. [12/Nov/2014:16:55:12 +0100] NSMMReplicationPlugin - agmt="cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr" (ldap-model:636): Consumer failed to replay change (uniqueid 3c6d978a-6a8411e4-a42c901a-94623bee, CSN 546382d6000400020000): Operations error (1). Will retry later. [12/Nov/2014:16:56:31 +0100] NSMMReplicationPlugin - agmt="cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr" (ldap-model:636): Consumer failed to replay change (uniqueid 6030dd93-6a8411e4-a42c901a-94623bee, CSN 54638325000000020000): Operations error (1). Will retry later. [12/Nov/2014:16:57:22 +0100] NSMMReplicationPlugin - agmt="cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr" (ldap-model:636): Consumer failed to replay change (uniqueid 83f42395-6a8411e4-a42c901a-94623bee, CSN 5463835d000000020000): Operations error (1). Will retry later. The corresponding errors on the consumer seem to hint deadlocks in these cases: [12/Nov/2014:16:46:41 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=546380d6000000020000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [12/Nov/2014:16:46:41 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (546380d6000000020000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [12/Nov/2014:16:46:41 +0100] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for cn=LAN452ESP-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu (uniqid: fa90219d-6a8211e4-a42c901a-94623bee, optype: 16) to changelog csn 546380d6000000020000 [12/Nov/2014:16:47:54 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=54638125000000020000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [12/Nov/2014:16:47:54 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (54638125000000020000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [12/Nov/2014:16:47:54 +0100] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for cn=LAN472EFLE-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu (uniqid: 1e5367ae-6a8311e4-a42c901a-94623bee, optype: 16) to changelog csn 54638125000000020000 [12/Nov/2014:16:53:13 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=54638260000000020000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [12/Nov/2014:16:53:13 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (54638260000000020000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [12/Nov/2014:16:53:13 +0100] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for cn=MAT471-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu (uniqid: f4e70b85-6a8311e4-a42c901a-94623bee, optype: 16) to changelog csn 54638260000000020000 [12/Nov/2014:16:55:11 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=546382d6000400020000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [12/Nov/2014:16:55:11 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (546382d6000400020000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [12/Nov/2014:16:55:11 +0100] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for cn=MEC592-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu (uniqid: 3c6d978a-6a8411e4-a42c901a-94623bee, optype: 16) to changelog csn 546382d6000400020000 [12/Nov/2014:16:56:29 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=54638325000000020000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [12/Nov/2014:16:56:29 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (54638325000000020000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [12/Nov/2014:16:56:29 +0100] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for cn=PHY566-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu (uniqid: 6030dd93-6a8411e4-a42c901a-94623bee, optype: 16) to changelog csn 54638325000000020000 [12/Nov/2014:16:57:20 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=5463835d000000020000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [12/Nov/2014:16:57:20 +0100] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (5463835d000000020000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [12/Nov/2014:16:57:20 +0100] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for cn=PHY651K-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu (uniqid: 83f42395-6a8411e4-a42c901a-94623bee, optype: 16) to changelog csn 5463835d000000020000 Each time the failed group entries are different. The replication agreements look liek this : 0 cn=Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr,cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping tree,cn=config objectClass: top objectClass: nsDS5ReplicationAgreement cn: Replication from ldap-edev.polytechnique.fr to ldap-model.polytechnique.fr description: Replication agreement from server ldap-edev.polytechnique.fr to server ldap-model.polytechnique.fr nsDS5ReplicaHost: ldap-model.polytechnique.fr nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu nsDS5ReplicaPort: 636 nsDS5ReplicaTransportInfo: SSL nsDS5ReplicaBindDN: cn=RepliX,cn=config nsDS5ReplicaBindMethod: simple nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName internalModifyTimestamp internalCreatorsname nsds5replicaBusyWaitTime: 3 nsds5replicaTimeout: 30 nsDS5ReplicaCredentials: {DES}... nsds5ReplicaEnabled: on nsds50ruv: {replicageneration} 54636df3000000020000 nsds50ruv: {replica 1 ldap://ldap-model.polytechnique.fr:389} 54637b3c000000010000 54637dce000000010000 nsds50ruv: {replica 2 ldap://ldap-edev.polytechnique.fr:389} 54636ffe000000020000 54637d2d000000020000 nsruvReplicaLastModified: {replica 1 ldap://ldap-model.polytechnique.fr:389} 00000000 nsruvReplicaLastModified: {replica 2 ldap://ldap-edev.polytechnique.fr:389} 00000000 nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20141112173922Z nsds5replicaLastUpdateEnd: 20141112173922Z nsds5replicaChangesSentSinceStartup: 2:1899/21484 nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update succeeded nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 The DNA plug-in is disabled (excluding https://fedorahosted.org/389/ticket/47410) I've made a ticket concerning this problem (https://fedorahosted.org/389/ticket/47410) Another problem when doing these tests, with replication agreements suspended is the following message in the error log: 12/Nov/2014:16:15:35 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:38 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:40 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:43 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:45 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:47 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:50 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:52 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:55 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:57 +0100] - Retry count exceeded in modify [12/Nov/2014:16:15:59 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:02 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:04 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:06 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:09 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:11 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:14 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:17 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:19 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:22 +0100] - Retry count exceeded in modify [12/Nov/2014:16:16:24 +0100] - Retry count exceeded in modify ... (it goes on for approx 5 minutes) [12/Nov/2014:16:20:31 +0100] - Retry count exceeded in modify [12/Nov/2014:16:20:33 +0100] - Retry count exceeded in modify [12/Nov/2014:16:20:36 +0100] - Retry count exceeded in modify [12/Nov/2014:16:20:42 +0100] - Retry count exceeded in modify During these error messages the server doe snot consume CPU but it is does not allow any changes to continue. Do i need to open another ticket for this second problem? Thank you! Regards, Andrey

2 3

Sync problem between AD and 389ds (freeIPA) : no posix attributes sync
by Edouard Guigné 12 Nov '14

12 Nov '14

Dear 389-users, I am trying to make working a sync between my AD win 2008 R2 and FreeIPA (fedora 20) server. My goal is to retrieve all my AD users in freeIPA database. This is my 389 ds version : *# rpm -q 389-ds-base** **389-ds-base-1.3.2.23-1.fc20.x86_64* With "ipa-replica-manage connect --winsync ...", I succeeded to copy users from AD to FreeIPA (via the sync agreement). I tried then to sync posix attributes (from my AD which has "Subsystem for UNIX-based Applications") into the freeIPA server with activating the posix winsync plugin I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain For this, I turn on the posix winsync plugin according to the documentation : http://www.port389.org/docs/389ds/design/winsync-posix.html 1. I enable the plugin this way : ldapmodify -D "cn=directory manager" -w xxxxx dn: cn=Posix Winsync API,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on 2. And I also added a nisDomain attribut like this : ldapmodify -x -D "cn=directory manager" -w xxxxx dn: dc=lmsipa,dc=polytechnique,dc=fr changetype: modify replace: nisDomain nisDomain: lmsadtest The nisDomain is the same than the msSFU30NisDomain (lmsadtest) in my AD. 3. I restarted the ipa server (ipa-ctl restart). However, I do not succeed in syncing the posix attributes... 4. I turned on the replication logging level and this is the log for sync of 1 user account : ... 05/Nov/2014:10:37:28 +0100] NSMMReplicationPlugin - windows sync - agmt="cn=meTolmscad1test.lmsadtest.polytechnique.fr" (lmscad1test:389): map_entry_dn_outbound: looking for AD entry for DS dn="uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr" username="guigne" [05/Nov/2014:10:37:28 +0100] - Calling windows entry search request plugin [05/Nov/2014:10:37:28 +0100] - windows_search_entry: received 2 messages, 1 entries, 0 references [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - agmt="cn=meTolmscad1test.lmsadtest.polytechnique.fr" (lmscad1test:389): map_entry_dn_outbound: found AD entry dn="CN=Edouard Guigné,OU=lms,DC=lmsadtest,DC=polytechnique,DC=fr" [05/Nov/2014:10:37:29 +0100] - Calling windows entry search request plugin [05/Nov/2014:10:37:29 +0100] - windows_search_entry: received 2 messages, 1 entries, 0 references [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, sn : values are equal [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, description : values are equal [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, givenName : values are equal [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, codePage : values not present on peer entry [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, scriptPath : values not present on peer entry [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, accountExpires : values not present on peer entry [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, sAMAccountName : values not present on peer entry [05/Nov/2014:10:37:29 +0100] NSMMReplicationPlugin - windows sync - windows_generate_update_mods: uid=guigne,cn=users,cn=accounts,dc=lmsipa,dc=polytechnique,dc=fr, mail : values are equal *[05/Nov/2014:10:37:29 +0100] posix-winsync - getNisDomainName: no nisdomainname found in DC=fr, LDAP Err-1* [05/Nov/2014:10:37:29 +0100] - smod - windows sync [05/Nov/2014:10:37:29 +0100] - smod 0 - add: codePage [05/Nov/2014:10:37:29 +0100] - smod 0 - value: codePage: 0 [05/Nov/2014:10:37:29 +0100] - smod 1 - add: scriptPath [05/Nov/2014:10:37:29 +0100] - smod 1 - value: scriptPath: Logon_guigne.bat [05/Nov/2014:10:37:29 +0100] - smod 2 - add: accountExpires [05/Nov/2014:10:37:29 +0100] - smod 2 - value: accountExpires: 9223372036854775807 [05/Nov/2014:10:37:29 +0100] - smod 3 - add: sAMAccountName [05/Nov/2014:10:37:29 +0100] - smod 3 - value: sAMAccountName: guigne [05/Nov/2014:10:37:29 +0100] - smod 4 - add: msSFU30uidnumber [05/Nov/2014:10:37:29 +0100] - smod 4 - value: msSFU30uidnumber: 12069 [05/Nov/2014:10:37:29 +0100] - smod 5 - add: msSFU30gidnumber [05/Nov/2014:10:37:29 +0100] - smod 5 - value: msSFU30gidnumber: 4400 [05/Nov/2014:10:37:30 +0100] - smod 6 - add: msSFU30loginshell [05/Nov/2014:10:37:30 +0100] - smod 6 - value: msSFU30loginshell: /bin/bash [05/Nov/2014:10:37:30 +0100] NSMMReplicationPlugin - windows sync - windows_update_remote_entry: modifying entry CN=Edouard Guigné,OU=lms,DC=lmsadtest,DC=polytechnique,DC=fr [05/Nov/2014:10:37:30 +0100] NSMMReplicationPlugin - windows sync - agmt="cn=meTolmscad1test.lmsadtest.polytechnique.fr" (lmscad1test:389): Received result code 16 (00000057: LdapErr: DSID-0C090B8A, comment: Error in attribute conversion operation, data 0, v1db1) for modify operation ... So the Posix attributes are well found but not sync in 389 database. What does it mean : *posix-winsync - getNisDomainName: no nisdomainname found in DC=fr, LDAP Err-1* May you help me to solve the issue ? Best Regards, Ed

1 0

Groupe modifications and internalModifiersName
by Ivanov Andrey (M.) 11 Nov '14

11 Nov '14

Hi,, i continue with my tests of 389ds v1.3.2.24. I've encountered another bug or strange behavior (by design?). I've activated bind dn tracking ( nsslapd-plugin-binddn-tracking: on ). There is an account that has the write to add the entries and to change some attributes (e.g. description). The corresponding ACI: dn: ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu aci: (targetattr = " objectClass || uniqueMember || owner || cn || description || businessCategory " ) (version 3.0;acl "Droits de rejouter/supprimer/modifier les groupes et leurs att ributs";allow ( add, delete, read,compare,search,write )(userdn="ldap:///uid=sync-cours,ou=Comptes generiques,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu");) Any attempt to modify an authorized attribute from the list above (for ex., description ) results in ldap_modify: Insufficient access (50) additional info: Insufficient 'write' privilege to the 'internalModifiersName' attribute of entry 'cn=mec431-2014,ou=2014,ou=cours,ou=enseignement,ou=groupes,dc=id,dc=polytechnique,dc=edu'. [11/Nov/2014:10:38:49 +0100] conn=4 fd=256 slot=256 connection from 129.104.31.54 to 129.104.69.49 [11/Nov/2014:10:38:49 +0100] conn=4 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [11/Nov/2014:10:38:49 +0100] conn=4 op=0 RESULT err=14 tag=97 nentries=0 etime=0.008000, SASL bind in progress [11/Nov/2014:10:38:49 +0100] conn=4 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [11/Nov/2014:10:38:49 +0100] conn=4 op=1 RESULT err=14 tag=97 nentries=0 etime=0.002000, SASL bind in progress [11/Nov/2014:10:38:49 +0100] conn=4 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [11/Nov/2014:10:38:49 +0100] conn=4 op=2 RESULT err=0 tag=97 nentries=0 etime=0.001000 dn="uid=sync-cours,ou=comptes generiques,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" [11/Nov/2014:10:38:49 +0100] conn=4 op=3 SRCH base="dc=id,dc=polytechnique,dc=edu" scope=2 filter="(cn=MEC431-2014)" attrs=ALL [11/Nov/2014:10:38:49 +0100] conn=4 op=3 RESULT err=0 tag=101 nentries=1 etime=0.003000 [11/Nov/2014:10:39:00 +0100] conn=4 op=4 MOD dn="cn=MEC431-2014,ou=2014,ou=Cours,ou=Enseignement,ou=Groupes,dc=id,dc=polytechnique,dc=edu" [11/Nov/2014:10:39:00 +0100] conn=4 op=4 RESULT err=50 tag=103 nentries=0 etime=0.002000 is it an expected behavior and i need to add to all the ACIs that allow modifications the right to modify internalModifiersName attribute (if i add it, everything is fine and the attribute internalModifiersName becomes " cn=ldbm database,cn=plugins,cn=config "). Or is it a bug? Thank you! Regards,

2 2

Account auto unlock
by harry.devine＠faa.gov 10 Nov '14

10 Nov '14

We are using 389-ds 1.2.2-1 on a RHEL 6.5 64-bit server. We have users who occasionally lock themselves out due to too many unsuccessful log in attempts. What we can't seem to find is a setting where that lock out could auto unlock after X minutes (like 30 or so). I thought that it used to work that way when we first started with 389-ds a few years ago, but I can't be 100% certain. Any thoughts or guidance on what we can look at or set to make this happen? Thanks, Harry Harry Devine DOT/FAA/AJM-245 Common ARTS Software Development harry.devine(a)faa.gov (609)485-4218

1 0

need info for replicate_now script
by ghiureai 10 Nov '14

10 Nov '14

Hi List, I'm new to 389-ds, learning and cfg multimaster replication cfg for ds, reading the RH doc about having a script to trigger the updates to from one master to other one in < 10 min , the original script on RH will not work, is using ldapsearch -1 options seems does not exists in my current 389-ds on CentOS 6.5. Would anyone be willing to share a working script for this task? Thank you Isabella

2 1

Combine entities from several replicated databases to one database
by Andrey Cherepanov 10 Nov '14

10 Nov '14

There are a dozen branches in which add and modify users in LDAP. There is central office in which will plan make joint addressbook with branch data. I know that replication works only with database. I can replicate all branch database to central office. But I don't find way to join entities to one database by ridht way. Anybody do it? -- Andrey Cherepanov ALT Linux cas(a)altlinux.ru

1 0

Replication agreement issues
by Ted Strother 09 Nov '14

09 Nov '14

I'm attempting to set up an agreement with the wizard for userRoot on a single master (the hope was that once this was working a second master would be established), and every time I get the following error: LDAP server is unwilling to perform The error logs are equally useful: NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement (nameofagreementappearshere) I have had no issues with any of the other agreements, and it isn't specific to just one slave. Has anyone else seen this happen? Any tips? Thanks! -- Ted Strother Systems Administrator Senior Information Technology Services University of Michigan-Dearborn 19000 Hubbard Drive, 238 FCN Dearborn, MI 48126

1 0

Having issues installing on fc20
by Cawley, Chris 08 Nov '14

08 Nov '14

There is a problem with the install and ipv6/setup-ds-admin.pl . It keeps trying to bind to ipv6, etc. The work around have not been successful. Any suggestions are appreciated . Thanks - Chris Christopher J Cawley Senior Systems Engineer cawley(a)wrlc.org 301 390 2049

1 0

Please take an action: 389 Directory Server 1.2.11.X Discontinued for EL6
by Noriko Hosoi 06 Nov '14

06 Nov '14

389 Directory Server 1.2.11.X Discontinued for EL6 The 389 Directory Server team announces the binary release of 389-ds-base version 1.2.11 for EL6 will be stopped via temporary COPR repository. We encourage you to switch it to the official version included in the Red Hat Enterprise Linux 6 distribution or its equivalent OS. How to switch to the official version Remove a yum repo file which points to the temporary COPR repository (e.g., nhosoi-389-ds-base-epel6-epel-6.repo) from /etc/yum.repos.d. If the current 389 Directory Server 1.2.11 has the greater build number than 15, for instance, 1.2.11.32, downgrade it once by “yum downgrade” as follows. |yum downgrade 389-ds-base 389-ds-base-libs| Then, upgrade to make sure you have the latest version. |yum upgrade 389-ds-base| After upgrade completes, run *setup-ds-admin.pl -u* to update your directory server/admin server/console information. |setup-ds-admin.pl -u| See Install_Guide <http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade See Source <http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. http://www.port389.org/docs/389ds/releases/end-1-2-11.html

2 1

Re: [389-users] 389-Directory/1.3.1.6 cannot setup replica
by Ivanov Andrey (M.) 06 Nov '14

06 Nov '14

Hello Noriko, ----- Mail original ----- De: "Noriko Hosoi" <nhosoi(a)redhat.com> À: "General discussion list for the 389 Directory server project." <389-users(a)lists.fedoraproject.org> Envoyé: Mercredi 5 Novembre 2014 21:26:47 Objet: Re: [389-users] 389-Directory/1.3.1.6 cannot setup replica Hello Andrey, On 11/05/2014 11:53 AM, Ivanov Andrey (M.) wrote: <blockquote> Hi, i'm having the same problem. I'm in the process of migration from our 389DS v1.2.10.25/CentOS5 to 389DS on CentOS 7. Everything is working fine on standalone servers but the replication (especially online initialization). It stucks _each time_ during the online initialization with SSL/TLS (and sometimes without SSL/TLS). And exactly with the same error messages as you describe. The network problems in my case are excluded - i used both virtual machines on the same ESXi in the same network and/or physical servers, the results are the same. I've tried compiling all the branches latest available (tags 1.3.2.24, 1.3.1.22, 1.3.3.5). In all the cases the result was the same. The server pushing the updates just gets stuck at some random number of entries sent to consumer (we have ~30000 entries, it gets stuck at random somewhere from 1200 to 25000 entries, the entries stuck have nothing particular in size, it's completely random). When you tried the versions "(tags 1.3.2.24, 1.3.1.22, 1.3.3.5)", it does not report any extra errors in the error log? E.g., <blockquote> Incoming BER Element was @@@ bytes, max allowable is ### bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. </blockquote> </blockquote> No - as i said, it was clearly not a problem of nsslapd-maxbersize or nsslapd-maxsasliosize or nsslapd-sasl-max-buffer-size, i'v checked it. Anyway, as i said, the on-line initialization has more chances to go to the end (sometimes it goes to the end with the same set of data) if i disable SSL, increase the number of CPUs in VM and increase the nsslapd-db-checkpoint-interval, each time it's stuck in a different place, so it's not entry-related... <blockquote> <blockquote> </blockquote> Next time it happens, could it be possible to get the stacktraces from the hung server? <blockquote> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs </blockquote> </blockquote> Ok, i'll do that tomorrow (for 1.3.2.24 since i'm testing mainly this one). It happens each time during a full on-line initialization, so it won't be difficult difficult to reproduce :) It does not really hang, only the online initialization hangs in fact (with the logs similar to the original mail)... <blockquote> <blockquote> </blockquote> <blockquote> 1.2.10.24 compiled with compat-db-4.7 on CentOS 7 has the least of these problems (and the initial replication is 10 times faster - it takes 8 seconds instead of 80 for 1.3.x!). I've been using 1.2.10.24 on CentOS5 compiled with mozilla ldap labraries and 1.2.10.23 obn CentOS 7 compiled with opendlap librarires. The first one had no problems at all to push the initial replication, the second one had intermittent problems, but much less than v1.3.x I've noticed that this problem is getting worse (or simply appears) if : * the replica is be of type 3 (multi-master), with replication agreements in both directions * our schema has several additional attribuites, it may be also important </blockquote> We improved the schema replication at some time, which should be in 1.3.2.24 and 1.3.3.5. https://fedorahosted.org/389/ticket/47721 </blockquote> The schema ldif is small and it is deployed before the initial on-line init, it is not replicated, so i don't think it's a problem. <blockquote> <blockquote> * if the virtual machine has only one CPU. Adding a second CPU increases the number of transferred entries before the initialization gets stuck. So it may me some thread/transaction contention or deadlock. * if the replication agreement uses SSL(port 636) or TLS(port389). Using port 389 with LDAP protocol instead of TLS/SSL increases the number of transferred entries before the initialization gets stuck. Sometimes the initialization even ends successfully in this case. * decreasing nsslapd-db-checkpoint-interval (say, to 5 seconds) also gets the problem worse </blockquote> This indicates the issue is in the BDB? </blockquote> Don't know. My hypotheses are : * using plugin transactions compared to 1.2.10.x * bdb version? but even with compat-db-47 and 1.2.10 the problem still happens on CentOS7, though much less frequently. It never happens with 1.2.10 with rpm bdb on CentOS5. * change from mozilla ldap libraries to openldap libraries? seems to be some sort of thread or transaction contention that is reduced when i add CPUs/increase checkpoint interval. It really looks like the master server just does not send entries any more at some moment... SSL/TLS slows the things down so less entries are sent before everything gets stuck... I'll get back with more information (stacktraces) tomorrrow. Thanks! <blockquote> Thanks, --noriko <blockquote> When the on-line intialization is finished (if it finishes), there are no problems. I think it is related to the volume of data transferred, so small incremental updates do not generate any problem.... If necessary, i will make any debugs/tests - it is a critical element of our infrastructure, so i'd like this problem to be resolved... Regards, Andrey IVANOV ----- Mail original ----- <blockquote> De: "陳含林" <laneovcc(a)gmail.com> À: 389-users(a)lists.fedoraproject.org Envoyé: Mercredi 5 Novembre 2014 18:01:37 Objet: [389-users] 389-Directory/1.3.1.6 cannot setup replica hello all, I have setup a IDM/freeipa master using CentOS7 , and import about 5000 hosts. then i try to setup a IDM/freeipa replication server by using ipa-replica-install. It seems the total update on replication server hangs after about 1000+ entries imported. I try to trigger a total update by setting nsds5beginreplicarefresh, but the result was the same. Any one help me ? Thanks! idm1 is the master, idm2 is the replication server. master server logs: [06/Nov/2014:00:21:48 +0800] - 389-Directory/ 1.3.1.6 B2014.219.1825 starting up [06/Nov/2014:00:21:48 +0800] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=idc [06/Nov/2014:00:21:51 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idc--no CoS Templates found, which should be added before the CoS Definition. [06/Nov/2014:00:21:51 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idc--no CoS Templates found, which should be added before the CoS Definition. [06/Nov/2014:00:21:51 +0800] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Nov/2014:00:21:51 +0800] - Listening on All Interfaces port 636 for LDAPS requests [06/Nov/2014:00:21:51 +0800] - Listening on /var/run/slapd-IDC.socket for LDAPI requests [06/Nov/2014:00:21:51 +0800] - Entry "uid=admin,ou=people,o=ipaca" -- attribute "krbExtraData" not allowed [06/Nov/2014:00:40:26 +0800] NSMMReplicationPlugin - agmt="cn=meToidm2.ra.cn.idc" (idm2:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [06/Nov/2014:00:40:26 +0800] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meToidm2.ra.cn.idc" (idm2:389)". replication server logs: [06/Nov/2014:00:40:18 +0800] - 389-Directory/ 1.3.1.6 B2014.219.1825 starting up [06/Nov/2014:00:40:18 +0800] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Nov/2014:00:40:18 +0800] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Nov/2014:00:40:18 +0800] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Nov/2014:00:40:18 +0800] - Listening on All Interfaces port 636 for LDAPS requests [06/Nov/2014:00:40:18 +0800] - Listening on /var/run/slapd-IDC.socket for LDAPI requests [06/Nov/2014:00:40:19 +0800] NSMMReplicationPlugin - agmt="cn=meToidm1.ra.cn.idc" (idm1:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [06/Nov/2014:00:40:20 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=idc is going offline; disabling replication [06/Nov/2014:00:40:20 +0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Nov/2014:00:40:40 +0800] - import userRoot: Processed 1581 entries -- average rate 79.0/sec, recent rate 79.0/sec, hit ratio 0% [06/Nov/2014:00:41:00 +0800] - import userRoot: Processed 1581 entries -- average rate 39.5/sec, recent rate 39.5/sec, hit ratio 0% [06/Nov/2014:00:41:20 +0800] - import userRoot: Processed 1581 entries -- average rate 26.4/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:41:41 +0800] - import userRoot: Processed 1581 entries -- average rate 19.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:42:01 +0800] - import userRoot: Processed 1581 entries -- average rate 15.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:42:21 +0800] - import userRoot: Processed 1581 entries -- average rate 13.2/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:42:41 +0800] - import userRoot: Processed 1581 entries -- average rate 11.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:43:01 +0800] - import userRoot: Processed 1581 entries -- average rate 9.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:43:21 +0800] - import userRoot: Processed 1581 entries -- average rate 8.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:43:41 +0800] - import userRoot: Processed 1581 entries -- average rate 7.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:44:01 +0800] - import userRoot: Processed 1581 entries -- average rate 7.2/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:44:21 +0800] - import userRoot: Processed 1581 entries -- average rate 6.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:44:41 +0800] - import userRoot: Processed 1581 entries -- average rate 6.1/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:45:01 +0800] - import userRoot: Processed 1581 entries -- average rate 5.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:45:21 +0800] - import userRoot: Processed 1581 entries -- average rate 5.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:45:21 +0800] - import userRoot: Decided to end this pass because the progress rate has dropped below the 50% threshold. [06/Nov/2014:00:45:21 +0800] - import userRoot: Ending pass number 1 ... [06/Nov/2014:00:45:22 +0800] - import userRoot: Foreman is done; waiting for workers to finish... [06/Nov/2014:00:45:22 +0800] - import userRoot: Workers finished; cleaning up... [06/Nov/2014:00:45:22 +0800] - import userRoot: Workers cleaned up. [06/Nov/2014:00:45:22 +0800] - import userRoot: Sweeping files for merging later... [06/Nov/2014:00:45:22 +0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Nov/2014:00:45:22 +0800] - import userRoot: Sweep done. [06/Nov/2014:00:45:22 +0800] - import userRoot: Beginning pass number 2 [06/Nov/2014:00:45:42 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 214748285.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:46:02 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 107374142.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:46:22 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 71582761.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:46:42 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 53687071.4/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:47:02 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 42949657.1/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:47:22 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 35791381.0/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:47:43 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 30678326.5/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:48:03 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 26843535.7/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:48:23 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 23860920.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:48:43 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 21474828.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:49:03 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 19522571.4/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:49:23 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 17895690.5/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:49:43 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 16519098.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:50:03 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 15339163.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:50:23 +0800] - import userRoot: Processed 1722 entries (pass 2) -- average rate 0.5/sec, recent rate 43.0/sec, hit ratio 0% [06/Nov/2014:00:50:26 +0800] - import userRoot: Workers finished; cleaning up... [06/Nov/2014:00:50:26 +0800] - import userRoot: Workers cleaned up. [06/Nov/2014:00:50:26 +0800] - import userRoot: Sweeping files for merging later... [06/Nov/2014:00:50:26 +0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Nov/2014:00:50:26 +0800] - import userRoot: Sweep done. [06/Nov/2014:00:50:26 +0800] - import userRoot: Beginning 2-way merge of up to 44 files... [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "aci". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "automountkey". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "carLicense". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "cn". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "displayname". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "entryusn". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "fqdn". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "gidnumber". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "givenName". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipakrbprincipalalias". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipasudorunas". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipasudorunasgroup". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipauniqueid". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "krbPrincipalName". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "macAddress". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "mail". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "mailAlternateAddress". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "mailHost". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "managedby". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "manager". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "member". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "memberallowcmd". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "memberdenycmd". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "memberHost". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "memberOf". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "memberservice". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "memberUser". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "nscpEntryDN". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "nsds5ReplConflict". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "nsuniqueid". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "ntUniqueId". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "ntUserDomainId". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "objectclass". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "ou". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "owner". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "secretary". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "seeAlso". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "sn". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "sourcehost". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "telephoneNumber". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "title". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "uid". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "uidnumber". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "uniquemember". [06/Nov/2014:00:50:27 +0800] - import userRoot: Merging completed in 0 seconds. [06/Nov/2014:00:50:27 +0800] - import userRoot: Indexing complete. Post-processing... [06/Nov/2014:00:50:27 +0800] - import userRoot: Generating numSubordinates complete. [06/Nov/2014:00:50:27 +0800] - import userRoot: Flushing caches... [06/Nov/2014:00:50:27 +0800] - import userRoot: Closing files... [06/Nov/2014:00:50:27 +0800] - import userRoot: Import complete. Processed 1722 entries in 607 seconds. (2.84 entries/sec) [06/Nov/2014:00:50:27 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=idc is coming online; enabling replication [06/Nov/2014:00:50:27 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idc--no CoS Templates found, which should be added before the CoS Definition. mapping tree # extended LDIF # # LDAPv3 # base <cn=mapping tree,cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # mapping tree, config dn: cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject cn: mapping tree # dc\3Didc, mapping tree, config dn: cn=dc\3Didc,cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: dc=idc cn: "dc=idc" nsslapd-state: backend nsslapd-backend: userRoot nsslapd-referral: ldap://idm1.ra.cn.idc:389/dc%3Didc # replica, dc\3Didc, mapping tree, config dn: cn=replica,cn=dc\3Didc,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 objectClass: top objectClass: nsds5replica objectClass: extensibleobject nsDS5ReplicaType: 3 nsDS5ReplicaRoot: dc=idc nsds5ReplicaLegacyConsumer: off nsDS5ReplicaId: 3 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsState:: AwAAAAAAAADzUlpUAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA== nsDS5ReplicaName: 6cf48589-650a11e4-90ecc46a-d11f6771 nsds5ReplicaChangeCount: 0 nsds5replicareapactive: 0 # meToidm1.ra.cn.idc, replica, dc\3Didc, mapping tree, config dn: cn=meToidm1.ra.cn.idc,cn=replica,cn=dc\3Didc,cn=mapping tree,cn=config cn: meToidm1.ra.cn.idc objectClass: nsds5replicationagreement objectClass: top nsDS5ReplicaTransportInfo: TLS description: me to idm1.ra.cn.idc nsDS5ReplicaRoot: dc=idc nsDS5ReplicaHost: idm1.ra.cn.idc nsds5replicaTimeout: 600 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaPort: 389 nsDS5ReplicaBindMethod: simple nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in ternalModifyTimestamp nsDS5ReplicaCredentials: {DES} nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 0 nsds5replicaLastUpdateEnd: 0 nsds5replicaChangesSentSinceStartup: nsds5replicaLastUpdateStatus: 402 Replication error acquiring replica: unknown error - Replica has different database generation ID, remote replica may nee d to be initialized nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users </blockquote> -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users </blockquote> -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users </blockquote>

3 5

389-Directory/1.3.1.6 cannot setup replica
by 陳含林 05 Nov '14

05 Nov '14

hello all, I have setup a IDM/freeipa master using CentOS7 , and import about 5000 hosts. then i try to setup a IDM/freeipa replication server by using ipa-replica-install. It seems the total update on replication server hangs after about 1000+ entries imported. I try to trigger a total update by setting nsds5beginreplicarefresh, but the result was the same. Any one help me ? Thanks! idm1 is the master, idm2 is the replication server. master server logs: [06/Nov/2014:00:21:48 +0800] - 389-Directory/1.3.1.6 B2014.219.1825 starting up [06/Nov/2014:00:21:48 +0800] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=idc [06/Nov/2014:00:21:51 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idc--no CoS Templates found, which should be added before the CoS Definition. [06/Nov/2014:00:21:51 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idc--no CoS Templates found, which should be added before the CoS Definition. [06/Nov/2014:00:21:51 +0800] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Nov/2014:00:21:51 +0800] - Listening on All Interfaces port 636 for LDAPS requests [06/Nov/2014:00:21:51 +0800] - Listening on /var/run/slapd-IDC.socket for LDAPI requests [06/Nov/2014:00:21:51 +0800] - Entry "uid=admin,ou=people,o=ipaca" -- attribute "krbExtraData" not allowed [06/Nov/2014:00:40:26 +0800] NSMMReplicationPlugin - agmt="cn=meToidm2.ra.cn.idc" (idm2:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [06/Nov/2014:00:40:26 +0800] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meToidm2.ra.cn.idc" (idm2:389)". replication server logs: [06/Nov/2014:00:40:18 +0800] - 389-Directory/1.3.1.6 B2014.219.1825 starting up [06/Nov/2014:00:40:18 +0800] ipalockout_get_global_config - [file ipa_lockout.c, line 185]: Failed to get default realm (-1765328160) [06/Nov/2014:00:40:18 +0800] ipaenrollment_start - [file ipa_enrollment.c, line 393]: Failed to get default realm?! [06/Nov/2014:00:40:18 +0800] - slapd started. Listening on All Interfaces port 389 for LDAP requests [06/Nov/2014:00:40:18 +0800] - Listening on All Interfaces port 636 for LDAPS requests [06/Nov/2014:00:40:18 +0800] - Listening on /var/run/slapd-IDC.socket for LDAPI requests [06/Nov/2014:00:40:19 +0800] NSMMReplicationPlugin - agmt="cn=meToidm1.ra.cn.idc" (idm1:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [06/Nov/2014:00:40:20 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=idc is going offline; disabling replication [06/Nov/2014:00:40:20 +0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Nov/2014:00:40:40 +0800] - import userRoot: Processed 1581 entries -- average rate 79.0/sec, recent rate 79.0/sec, hit ratio 0% [06/Nov/2014:00:41:00 +0800] - import userRoot: Processed 1581 entries -- average rate 39.5/sec, recent rate 39.5/sec, hit ratio 0% [06/Nov/2014:00:41:20 +0800] - import userRoot: Processed 1581 entries -- average rate 26.4/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:41:41 +0800] - import userRoot: Processed 1581 entries -- average rate 19.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:42:01 +0800] - import userRoot: Processed 1581 entries -- average rate 15.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:42:21 +0800] - import userRoot: Processed 1581 entries -- average rate 13.2/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:42:41 +0800] - import userRoot: Processed 1581 entries -- average rate 11.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:43:01 +0800] - import userRoot: Processed 1581 entries -- average rate 9.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:43:21 +0800] - import userRoot: Processed 1581 entries -- average rate 8.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:43:41 +0800] - import userRoot: Processed 1581 entries -- average rate 7.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:44:01 +0800] - import userRoot: Processed 1581 entries -- average rate 7.2/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:44:21 +0800] - import userRoot: Processed 1581 entries -- average rate 6.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:44:41 +0800] - import userRoot: Processed 1581 entries -- average rate 6.1/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:45:01 +0800] - import userRoot: Processed 1581 entries -- average rate 5.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:45:21 +0800] - import userRoot: Processed 1581 entries -- average rate 5.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:45:21 +0800] - import userRoot: Decided to end this pass because the progress rate has dropped below the 50% threshold. [06/Nov/2014:00:45:21 +0800] - import userRoot: Ending pass number 1 ... [06/Nov/2014:00:45:22 +0800] - import userRoot: Foreman is done; waiting for workers to finish... [06/Nov/2014:00:45:22 +0800] - import userRoot: Workers finished; cleaning up... [06/Nov/2014:00:45:22 +0800] - import userRoot: Workers cleaned up. [06/Nov/2014:00:45:22 +0800] - import userRoot: Sweeping files for merging later... [06/Nov/2014:00:45:22 +0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Nov/2014:00:45:22 +0800] - import userRoot: Sweep done. [06/Nov/2014:00:45:22 +0800] - import userRoot: Beginning pass number 2 [06/Nov/2014:00:45:42 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 214748285.8/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:46:02 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 107374142.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:46:22 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 71582761.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:46:42 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 53687071.4/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:47:02 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 42949657.1/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:47:22 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 35791381.0/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:47:43 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 30678326.5/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:48:03 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 26843535.7/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:48:23 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 23860920.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:48:43 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 21474828.6/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:49:03 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 19522571.4/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:49:23 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 17895690.5/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:49:43 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 16519098.9/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:50:03 +0800] - import userRoot: Processed 1581 entries (pass 2) -- average rate 15339163.3/sec, recent rate 0.0/sec, hit ratio 0% [06/Nov/2014:00:50:23 +0800] - import userRoot: Processed 1722 entries (pass 2) -- average rate 0.5/sec, recent rate 43.0/sec, hit ratio 0% [06/Nov/2014:00:50:26 +0800] - import userRoot: Workers finished; cleaning up... [06/Nov/2014:00:50:26 +0800] - import userRoot: Workers cleaned up. [06/Nov/2014:00:50:26 +0800] - import userRoot: Sweeping files for merging later... [06/Nov/2014:00:50:26 +0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [06/Nov/2014:00:50:26 +0800] - import userRoot: Sweep done. [06/Nov/2014:00:50:26 +0800] - import userRoot: Beginning 2-way merge of up to 44 files... [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "aci". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "automountkey". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "carLicense". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "cn". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "displayname". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "entryusn". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "fqdn". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "gidnumber". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "givenName". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipakrbprincipalalias". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipasudorunas". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipasudorunasgroup". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "ipauniqueid". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "krbPrincipalName". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "macAddress". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "mail". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "mailAlternateAddress". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "mailHost". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "managedby". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "manager". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "member". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "memberallowcmd". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "memberdenycmd". [06/Nov/2014:00:50:26 +0800] - import userRoot: No files to merge for "memberHost". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "memberOf". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "memberservice". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "memberUser". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "nscpEntryDN". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "nsds5ReplConflict". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "nsuniqueid". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "ntUniqueId". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "ntUserDomainId". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "objectclass". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "ou". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "owner". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "secretary". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "seeAlso". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "sn". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "sourcehost". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "telephoneNumber". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "title". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "uid". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "uidnumber". [06/Nov/2014:00:50:27 +0800] - import userRoot: No files to merge for "uniquemember". [06/Nov/2014:00:50:27 +0800] - import userRoot: Merging completed in 0 seconds. [06/Nov/2014:00:50:27 +0800] - import userRoot: Indexing complete. Post-processing... [06/Nov/2014:00:50:27 +0800] - import userRoot: Generating numSubordinates complete. [06/Nov/2014:00:50:27 +0800] - import userRoot: Flushing caches... [06/Nov/2014:00:50:27 +0800] - import userRoot: Closing files... [06/Nov/2014:00:50:27 +0800] - import userRoot: Import complete. Processed 1722 entries in 607 seconds. (2.84 entries/sec) [06/Nov/2014:00:50:27 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=idc is coming online; enabling replication [06/Nov/2014:00:50:27 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idc--no CoS Templates found, which should be added before the CoS Definition. mapping tree # extended LDIF # # LDAPv3 # base <cn=mapping tree,cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # mapping tree, config dn: cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject cn: mapping tree # dc\3Didc, mapping tree, config dn: cn=dc\3Didc,cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: dc=idc cn: "dc=idc" nsslapd-state: backend nsslapd-backend: userRoot nsslapd-referral: ldap://idm1.ra.cn.idc:389/dc%3Didc # replica, dc\3Didc, mapping tree, config dn: cn=replica,cn=dc\3Didc,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 objectClass: top objectClass: nsds5replica objectClass: extensibleobject nsDS5ReplicaType: 3 nsDS5ReplicaRoot: dc=idc nsds5ReplicaLegacyConsumer: off nsDS5ReplicaId: 3 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsState:: AwAAAAAAAADzUlpUAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA== nsDS5ReplicaName: 6cf48589-650a11e4-90ecc46a-d11f6771 nsds5ReplicaChangeCount: 0 nsds5replicareapactive: 0 # meToidm1.ra.cn.idc, replica, dc\3Didc, mapping tree, config dn: cn=meToidm1.ra.cn.idc,cn=replica,cn=dc\3Didc,cn=mapping tree,cn=config cn: meToidm1.ra.cn.idc objectClass: nsds5replicationagreement objectClass: top nsDS5ReplicaTransportInfo: TLS description: me to idm1.ra.cn.idc nsDS5ReplicaRoot: dc=idc nsDS5ReplicaHost: idm1.ra.cn.idc nsds5replicaTimeout: 600 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaPort: 389 nsDS5ReplicaBindMethod: simple nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in ternalModifyTimestamp nsDS5ReplicaCredentials: {DES} nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 0 nsds5replicaLastUpdateEnd: 0 nsds5replicaChangesSentSinceStartup: nsds5replicaLastUpdateStatus: 402 Replication error acquiring replica: unknown error - Replica has different database generation ID, remote replica may nee d to be initialized nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4

3 4

389-admin console
by ghiureai 04 Nov '14

04 Nov '14

I'm having a issues when running 389-console from a local host will not display the correct ds/ local ds instead is pointing to another remote host ds, and I'm not able to see the local ds ? What has been messed up? Thank you Isabella

2 1

Re: [389-users] Dse.ldif file modification issues
by Ghiurea, Isabella 04 Nov '14

04 Nov '14

_____________________________________________ From: Ghiurea, Isabella Sent: November-03-14 12:55 PM To: 389-users-request(a)lists.fedoraproject.org Subject: Dse.ldif file modification issues Hi List, I restore a ds from on server to second host , an copy the dse.ldif file , trying to update the entry for nsslap-localhost on second server is still pointing to first one /initial ds , how can we update this entry , why is still can't take the host name in dse.ldif Thank you Isabella

2 1

Solaris 5.2 DS replicate to 389 DS
by Gary Algier 02 Nov '14

02 Nov '14

Hello, I am looking for help with creating a replication agreement between a Solaris DS and a 389 DS. I says in the FAQ: ------------------------------------------------------------------------ Sun DS 5.2 changed the replication protocol, so you cannot do Sun DS 5.2 style replication with 389. However, Sun DS 5.2 has a legacy replication mode with which they are able to replicate to their 5.1 and 5.0 servers. This replication mode works with 389. ------------------------------------------------------------------------ My Solaris DS is 5.2.4, my 389 DS is 389-ds-base-1.3.2.23-1.fc20. I have setup a legacy consumer on 389 DS and a replication agreement on Solaris DS. No matter what I do it does not seem to want to replicate. I even tried setting the Solaris 4.x replication mode (which does not help). I don't see anyplace to say I want 5.0/5.1-style replication. Is there anyone who has successfully made this replication work that might be willing to help? -- Gary Algier, WB2FWZ gaa(a)ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033

2 2

cannot modify db-home-directory at runtime
by Alan Willis 02 Nov '14

02 Nov '14

I'm trying to setup a server which uses /dev/shm as the db home dir in much the same way described in this ticket: https://fedorahosted.org/389/ticket/469 >From the description in the ticket, it appears that the entry can be modified at runtime. However when I attempt this, I get an error stating that this value cannot be modified at runtime. The only way I have gotten this to work is by modifying the dse.ldif directly and adding the attribute. Can this be made to require a reboot to take effect? -alan -- [image: fist]Alan Willis Systems Administrator | Riot Games Email: alwillis at riotgames.com For, to speak out once for all, man only plays when in the full meaning of the word he is a man, and *he is only completely a man when he plays*. - J.C. Friedrich von Schiller - Letters upon the Æsthetic Education of Man

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2014