389-users November 2014

389-users@lists.fedoraproject.org

24 participants
29 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2014