389-users April 2014

389-users@lists.fedoraproject.org

39 participants
45 discussions

Announcing 389 Directory Server version 1.2.11.29
by Noriko Hosoi 04 Apr '14

04 Apr '14

389 Directory Server 1.2.11.29 The 389 Directory Server team is proud to announce 389-ds-base version 1.2.11.29. This release is only available in binary form for EL5 (EPEL5) and EL6 - see http://port389.org/wiki/Download#RHEL6/EPEL6 for more details. The new packages and versions are: * 389-ds-base-1.2.11.29-1 A source tarball is available for download at http://port389.org/sources/389-ds-base-1.2.11.29.tar.bz2 Highlights in 1.2.11.29 * several bug fixes Installation and Upgrade See http://port389.org/wiki/Download for information about setting up your yum repositories. To install, use *yum install 389-ds* yum install 389-ds After install completes, run *setup-ds-admin.pl* to set up your directory server. setup-ds-admin.pl To upgrade, use *yum upgrade* yum upgrade 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://directory.fedoraproject.org/wiki/Install_Guide> for more information about the initial installation, setup, and upgrade See Source <http://directory.fedoraproject.org/wiki/Source> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://admin.fedoraproject.org/mailman/listinfo/389-users If you find a bug, or would like to see a new feature, file it in our Trac instance: https://fedorahosted.org/389 Detailed Changelog since 1.2.11.28 * Ticket 346 - version 4 Slow ldapmodify operation time for large quantities of multi-valued attribute values * Ticket 415 - winsync doesn't sync DN valued attributes if DS DN value doesn't exist * Ticket 417, 458, 47522 - Password Administrator Backport * Ticket 471 - logconv.pl tool removes the access logs contents if "-M" is not correctly used * Ticket 47369 - version2 - provide default syntax plugin * Ticket 47448 - Segfault in 389-ds-base-1.3.1.4-1.fc19 when setting up FreeIPA replication * Ticket 47455 - valgrind - value mem leaks, uninit mem usage * Ticket 47463 - IDL-style can become mismatched during partial restoration * Ticket 47492 - PassSync removes User must change password flag on the Windows side * Ticket 47516 - replication stops with excessive clock skew * Ticket 47538 - RFE: repl-monitor.pl plain text output, cmdline config options * Ticket 47587 - hard coded limit of 64 masters in agreement and changelog code * Ticket 47591 - entries with empty objectclass attribute value can be hidden * Ticket 47596 - attrcrypt fails to find unlocked key * Ticket 47623 - fix memleak caused by 47347 * Ticket 47627 - changelog iteration should ignore cleaned rids when getting the minCSN * Ticket 47627 - Fix replication logging * Ticket 47637 - rsa_null_sha should not be enabled by default * Ticket 47638 - Overflow in nsslapd-disk-monitoring-threshold on 32bit platform * Ticket 47640 - Fix coverity issues - part 3 * Ticket 47641 - 7-bit check plugin not checking MODRDN operation * Ticket 47642 - Windows Sync group issues * Ticket 47677 - Size returned by slapi_entry_size is not accurate * Ticket 47678 - modify-delete userpassword * Ticket 47692 - single valued attribute replicated ADD does not work * Ticket 47693 - Environment variables are not passed when DS is started via service * Ticket 47693 - Environment variables are not passed when DS is started via service * Ticket 47704 - invalid sizelimits in aci group evaluation * Ticket 47722 - rsearch filter error on any search filter * Ticket 47722 - Fixed filter not correctly identified * Ticket 47729 - Directory Server crashes if shutdown during a replication initialization * Ticket 47731 - A tombstone entry is deleted by ldapdelete * Ticket 47734 - Change made in resolving ticket #346 fails on Debian SPARC64 * Ticket 47735 - e_uniqueid fails to set if an entry is a conflict entry * Ticket 47737 - Under heavy stress, failure of turning a tombstone into glue makes the server hung * Ticket 47740 - Coverity Fixes (Mark - part 1) * Ticket 47740 - Coverity issue in 1.3.3 * Ticket 47740 - Crash caused by changes to certmap.c * Ticket 47740 - Fix coverity erorrs - Part 4 * Ticket 47740 - Fix coverity issues - Part 5 * Ticket 47740 - Fix coverity issues: null deferences - Part 6 * Ticket 47740 - Fix coverity issues(part 7) * Ticket 47743 - Memory leak with proxy auth control * Ticket 47748 - Simultaneous adding a user and binding as the user could fail in the password policy check * Ticket 47766 - Tombstone purging can crash the server if the backend is stopped/disabled * fix coverity 11915 - dead code - introduced with fix for ticket 346 Retrieved from "http://directory.fedoraproject.org/wiki/Releases/1.2.11.29"

1 0

Netscape Portable Runtime error -5982
by Paolo Barbato 04 Apr '14

04 Apr '14

After a while I start again to work on 389 ds. 389ds last released from epel, is installed on a rhel 6.5, that host also other services (bind, dhcpd, radius.....). Such server is configured with some virtual nic. I noticed starting 389ds the following error: intranet5...[14/Feb/2014:08:30:20 +0100] createprlistensockets - PR_Bind() on All Interfaces port 636 failed: Netscape Portable Runtime error -5982 (Local Network address is in use.) I've tried to insert in dse.ldif directives like nsslapd-listenhost: 192.168.60.23 nsslapd-securelistenhost: 192.168.60.23 but it comes a more "IP specific" error : intranet5...[14/Feb/2014:10:01:34 +0100] createprlistensockets - PR_Bind() on 192.168.60.23 port 636 failed: Netscape Portable Runtime error -5982 (Local Network address is in use.) finally I noticed: [root@intranet5 dirsrv]# netstat -anp | grep 636 udp 0 0 0.0.0.0:636 0.0.0.0:* 1342/portreserve such service clearly conflict with 389ds ldaps It seems I'm facing bug https://bugzilla.redhat.com/show_bug.cgi?id=848414 since I really have tested also openldap [root@intranet5 dirsrv]# more /etc/portreserve/slapd ldaps from portreserve man I read For each service configuration file, a socket is created and bound to the appropriate port. A service wishing to bind to its port must first run portrelease, which instructs portreserve to release the port associated with the service. It seems so that 389ds be not aware of portreserve . Shoud I simply remove /etc/portreserve/slapd and restart portreserve ? Regards, Paolo. ------------------------------------------------------------------------------------------------ Paolo Barbato Consorzio RFX corso Stati Uniti,4 35127 Padova - Italy Network Administrator phone: +39 049 8295097 fax: +39 049 8700718 ------------------------------------------------------------------------------------------------

1 2

Is it safe to downgrade?
by Orion Poplawski 03 Apr '14

03 Apr '14

We're looking to downgrade 389-ds-base from 1.2.11.28-1.el5 to 1.2.9.9-1.el5. I know that various schema updates and the like happen on upgrades, but I don't know about what happens in the downgrade case. Thanks for any help, Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

2 1

Windows sync agreement - Received result code 34
by Vesa Alho 03 Apr '14

03 Apr '14

Hi, I'm trying to get Windows AD sync working. When trying to start full re-syncronization, I get the errors listed below. I've tried to verify all settings, but haven't figured out what could cause this. It seems to use value (null) with DN, but why? Other information: 389 => 1.2.11.25 (dc=example,dc=com) AD => Windows 2012 R2 (dc=example,dc=login) ==> notice, domain names are different! Windows sync agreement details Windows domain: example.login DS subtree: ou=People,dc=example,dc=com Windows subtree: cn=People,dc=example,dc=login Replicated subtree: dc=example,dc=com My goal is to sync 389 users to one OU/CN under AD and groups to different OU/CN. I'm not sure if this even possible, but was hoping to achieve this by creating separate sync agreements for users and groups. PS. thanks for excellent software and support! -Vesa [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): map_entry_dn_inbound: problem looking for username: -1 [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): windows_process_total_entry: Looking dn="uid=user1,ou=People,dc=example,dc=com" (ours) [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=user1,ou=People,dc=example,dc=com" guid="c647c882ee76ab4aac2239ef81ebebb7" [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=user1,ou=People,dc=example,dc=com" username="user1" [12/Mar/2014:10:23:56 +0200] - Calling windows entry search request plugin [12/Mar/2014:10:23:56 +0200] - windows_search_entry: received 1 messages, 0 entries, 0 references [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): map_entry_dn_outbound: entry not found - rc 0 [12/Mar/2014:10:23:56 +0200] - Windows sync entry: Created new remote entry: dn:: Y249VHVvbWFzIFN5cmrDpG5lbiwobnVsbCk= objectClass: top objectClass: person objectClass: organizationalperson objectClass: user userprincipalname: user1(a)example.login cn:: VHVvbWFzIFN5cmrDpG5lbg== givenName: First mail: First.Last(a)example.com sAMAccountName: user1 accountExpires: 9223372036854775807 sn:: U3lyasOkbmVu telephoneNumber: codePage: 0 [12/Mar/2014:10:23:56 +0200] - Attempting to add entry cn=First Last,(null) to AD for local entry uid=user1,ou=People,dc=example,dc=com [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): Received result code 34 (0000208F: NameErr: DSID-03100225, problem 2006 (BAD_NAME), data 8350, best match of: '(null)' ) for add operation [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): windows_replay_update: Cannot replay add operation. [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): Beginning linger on the connection [12/Mar/2014:10:23:56 +0200] NSMMReplicationPlugin - agmt="cn=adsync" (hki-dc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1

2 6

389-console broken
by warron.french 03 Apr '14

03 Apr '14

Does anyone have instructions on how to troubleshoot logging into the 389-console? I haven't made any changes to 389 Directory Server (version 389-ds-1.2.2-1.el6.noarch) for over a week. The change I made was to enable the directory server to run on port 636, and drop support for port 389. After making those changes I am positive that there was no ill effect because I was able to successfully login to the console and create a test user account using POSIX values. Today is the first time since the 26 March (today is 3 April) that I have attempted to log back into the console. I can no longer perform "ldapsearch -x -Z" while I am logged in as root on the server itself. On the console login box I have the following: cn=Directory Manager <password_for_DM> http://localhost:9830/ However the error I get back is: Cannot logon because of an incorrect User ID, Incorrect password or Directory problem. Http Exception: Response: HTTP/1.1 401 Authentication Required Status: 401 URL: http://localhost:9830/admin-server/authenticate Any ideas of how to troubleshoot this further, more importantly fix the issue I am having with logging in? -------------------------- Warron French 703.967.8936(c) 571.307.5311(W) 703.393.7275(h)

1 0

epel-389-ds-base not updated with 389-ds-base-1.2.11.28
by Orion Poplawski 03 Apr '14

03 Apr '14

The epel-389-ds-base repo has not been updated with 389-ds-base-1.2.11.28, which according to https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0834 is an important security update. Is this repository still being maintained? Thanks, Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

3 3

git repo / tarball issues
by Timo Aaltonen 03 Apr '14

03 Apr '14

Hi It's me again :) 1) 389-ds-console 1.2.7 has no tarball though it was tagged for release in Sep'12 2) 389-adminutil 1.1.20 is not tagged in git 3) 389-ds-base repo seems to be in limbo, since 1.3.2 branch doesn't have the latest release, which itself was just 1.3.2.13+ one patch, so doesn't contain changes from .14 and .15. So which one am I supposed to push to the distro? -- t

2 1

replication password
by Herb Burnswell 02 Apr '14

02 Apr '14

Noriko, Thank you for your response. It looks like there's an issue with directory manager privilege. When I attempt the command: ldapsearch -x -D "cn=Directory Manager" -w <pw> -s base -b "" "objectclass=*" ldap_bind: No such object (32) How can I confirm directory manager user? Thanks again for your help, Herb Hello, This password is base64 encoded and folded at the ~80th column. (So, please do not remove the last '=') userPassword:: e1NTSEF9dGljWTdhcTlFSVRoYmRrZHhYcWxWN2dLZnhSMVpFeEJWd0xOeEE9PQ== If you decode it, it looks like this: {SSHA}ticY7aq9EIThbdkdxXqlV7gKfxR1ZExBVwLNxA== It is SSHA hashed. I think you have a directory manager privilege. If so, you could reset the password by ldapmodify command? ldapmodify ... << EOF dn: cn=replicationManager,cn=config changetype: modify replace: userPassword userPassword: <new_password> EOF Herb Burnswell wrote: >* All, *>>* I am taking over a newly installed 389-ds environment: *>>* 389-admin-1.1.29-1.el6.x86_64 *>* 389-admin-console-1.1.8-1.el6.noarch *>* 389-admin-console-doc-1.1.8-1.el6.noarch *>* 389-adminutil-1.1.15-1.el6.x86_64 *>* 389-console-1.1.7-1.el6.noarch *>* 389-ds-1.2.2-1.el6.noarch *>* 389-ds-base-1.2.11.15-32.el6_5.x86_64 *>* 389-ds-base-libs-1.2.11.15-32.el6_5.x86_64 *>* 389-ds-console-1.2.6-1.el6.noarch *>* 389-ds-console-doc-1.2.6-1.el6.noarch *>* 389-dsgw-1.1.10-1.el6.x86_64 *>>* I have two systems that I will use as Multiple Masters. The problem *>* is when creating a replication agreement on each side, replication *>* fails with: *>>* 49 LDAP error invalid credentials *>>* So, I need to reset the replication manager user password. When I *>* look at the dse.ldif file I see: *>>* dn: cn=replicationManager,cn=config *>* objectClass: inetorgperson *>* objectClass: person *>* objectClass: top *>* objectClass: organizationalPerson *>* cn: replicationManager *>* sn: RM *>* passwordExpirationTime: 20380119031407Z *>* nsIdleTimeout: 0 *>* userPassword:: *>* e1NTSEF9dGljWTdhcTlFSVRoYmRrZHhYcWxWN2dLZnhSMVpFeEJWd0xOeEE9PQ= *>* = *>* creatorsName: cn=administrators *>* modifiersName: cn=administrators *>* createTimestamp: 20131025040123Z *>* modifyTimestamp: 20131025040123Z *>>>* This looks odd to me regarding the userPassword and it having an *>* 'extra line' after it. If I move the '=' sign back to the same above *>* line and bounce dirsrv it goes back to the above. *>>* In any event, how can I reset this password? Any assistance is *>* greatly appreciated. *>>* Thanks in advance, *>>* Herb*

2 5

replication password
by Herb Burnswell 02 Apr '14

02 Apr '14

All, I am taking over a newly installed 389-ds environment: 389-admin-1.1.29-1.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-adminutil-1.1.15-1.el6.x86_64 389-console-1.1.7-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.11.15-32.el6_5.x86_64 389-ds-base-libs-1.2.11.15-32.el6_5.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-dsgw-1.1.10-1.el6.x86_64 I have two systems that I will use as Multiple Masters. The problem is when creating a replication agreement on each side, replication fails with: 49 LDAP error invalid credentials So, I need to reset the replication manager user password. When I look at the dse.ldif file I see: dn: cn=replicationManager,cn=config objectClass: inetorgperson objectClass: person objectClass: top objectClass: organizationalPerson cn: replicationManager sn: RM passwordExpirationTime: 20380119031407Z nsIdleTimeout: 0 userPassword:: e1NTSEF9dGljWTdhcTlFSVRoYmRrZHhYcWxWN2dLZnhSMVpFeEJWd0xOeEE9PQ= = creatorsName: cn=administrators modifiersName: cn=administrators createTimestamp: 20131025040123Z modifyTimestamp: 20131025040123Z This looks odd to me regarding the userPassword and it having an 'extra line' after it. If I move the '=' sign back to the same above line and bounce dirsrv it goes back to the above. In any event, how can I reset this password? Any assistance is greatly appreciated. Thanks in advance, Herb

2 1

Re: [389-users] 389-console problem restore backup
by Carsten Grzemba 02 Apr '14

02 Apr '14

Am 02.04.14 schrieb Rich Megginson <rmeggins(a)redhat.com>: > > > > > > On 04/02/2014 02:50 AM, Carsten Grzemba wrote: > > > > If I try to restore backups I get the error: > > > > error:could not read config file. > > > > In the console log I see: > > > > http://testcsw.contac.lan:2389/[1:0] recv> error: could not read config file. > > http://testcsw.contac.lan:2389/[1:0] recv> system_errno: 13 > > http://testcsw.contac.lan:2389/[1:0] recv> Admin-Server: 389-Administrator/1.1.3 1 > > > > > > Which config file causes this error? > > > > > > > > I don't know. > > > > > > Can anybody help? > > > > > > Is this on RHEL/Fedora? If so, could it be related to selinux? > > > > no, on Solaris10 Sparc. > > > > > > > > > > > > > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > > > >

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users April 2014