389-users December 2015

389-users@lists.fedoraproject.org

14 participants
16 discussions

Error enabling SSL
by Phil Daws 15 Dec '15

15 Dec '15

Hello, Am trying to enable SSL on my 389 lab instance but having real issues. I imported the CA certificate chain, created a CSR, signed and installed the certificate. Then went into Directory Server -> Configuration and enabled SSL. Restarted the directory server but now get this error in the log: [12/Dec/2015:11:51:02 +0000] - SSL alert: Security Initialization: Unable to authenticate (Netscape Portable Runtime error -8177 - The security password entered is incorrect.) [12/Dec/2015:11:51:02 +0000] - ERROR: SSL Initialization Failed. Disabling SSL. When I issue systemctl restart dirsrv@lab389 it does not prompt for a password, and if I create a pin.txt that does not work. Yet if I use certutil that all looks good: [root@ads01 slapd-lab389]# certutil -d /etc/dirsrv/slapd-lab389/ -K certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa 725d885b5d0a1ce92babc48d230108e46dd44866 server-cert Version: [root@lab389 slapd-lab389]# rpm -qa | grep 389 389-ds-base-1.3.3.1-23.el7_1.x86_64 389-admin-1.1.38-1.el7.x86_64 389-ds-base-libs-1.3.3.1-23.el7_1.x86_64 389-adminutil-1.1.21-2.el7.x86_64 Any ideas please ? Thanks. Phil

3 7

upgrade replication Q
by ghiureai 07 Dec '15

07 Dec '15

Hi List, Since this our first time running a 389-DS upgrade in a replication master/slave env, and there are no special references in documentation, from your past experience, should we consider upgrading first the slave or master DS? ( upgrade 389-DS 1.2.2 to 1.3.4 ) Thank you for your continue support Isabella

1 0

Delivery reports about your e-mail
by Rich Megginson 07 Dec '15

07 Dec '15

Your message was not delivered due to the following reason: Your message was not delivered because the destination server was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 7 days: Host 23.15.238.86 is not responding. The following recipients could not receive this message: <389-users(a)lists.fedoraproject.org> Please reply to postmaster(a)redhat.com if you feel this message to be in error.

1 0

upgrade to 389-ds-base-1.3.4 Q
by ghiureai 04 Dec '15

04 Dec '15

Hi List, we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed and update the server , when restarting the DS geting the following in DS errorlog, there is no such "entryallowWeakCipher" in cfg file , what should we dissable see entries for this cn SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed nsSSL2: off nsSSL3: off ----->>> This was on but turn to "off" creatorsName: cn=server,cn=plugins,cn=config modifiersName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo t createTimestamp: xxxxxxxxxxxxxxxx modifyTimestamp:xxxxxxxxxxxxxxxxxxxx nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+r sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha ,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_ 56_sha,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha xxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx Thank you for your time Isabella

2 10

Slow search results until cache populated
by Petteri Jekunen 03 Dec '15

03 Dec '15

Hi, Is it just ordinary behavior with 389 DS that search results may take a very loong time just after starting the server when there are no entries in the cache yet? And when the cache is fully saturated (enough cache configured for all the entries) results become dramatically down - for instance from 4 minutes to 4 seconds. If this this is so, is there anything that could be done to fill in the cache automatically after startup? We have some 60 000 entries, RHEL 7.1, 389-Directory/1.3.3.1 B2015.267.1737 on VMWare. We have quite a heavy use of roles, and this seems to be a significant issue especially with them - or at least with them. We have used the Sun DSEE previously and are quite new to 389 DS. The technology seems very similar although. Thanks a lot in advance! Regards, Petteri Jekunen, Tampere University of Applied Sciences

4 7

ldapsearch Max Return Result
by Joel Levin 30 Nov '15

30 Nov '15

Hi: I searched --- probably not effectively --- where is setting for max results returned by ldapsearch? Thanks.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users December 2015