389-users February 2019

389-users@lists.fedoraproject.org

15 participants
16 discussions

Replicate 389DS with another LDAP server
by wodel youchi 19 Feb '19

19 Feb '19

Hi, is it possible to create a replication matser/master or master/slave between 389DS and another LDAP server openldap for example? Regards.

2 1

SHA1SUM incorrect on download website for Windows Console MSI files
by Steve Kuervers 19 Feb '19

19 Feb '19

Good morning all, I've been working with 389-ds RPMs from EPEL on CentOS 7.6, looking to replicate in a testing environment the capabilities of RH directory server. First off, thanks for your work on all this great 389 project! I'm also doing some cross-testing with Windows clients for administrative purposes. I noticed that the SHA1SUMS for the Windows Console MSI files on the download page are incorrect. https://directory.fedoraproject.org/docs/389ds/download.htm Specifically, the following downloads do not match the listed SHA1SUM (the text in these two lists was cut and pasted from the actual web page). Windows 2008/2012 32-bit 389-Console-1.1.15-i386.msi 772e4691daea66dcdef97cb220d9ae77ab9fbe78 Windows 2008/2012 64-bit 389-Console-1.1.15-x86_64.msi 35ec5bad0d309c334ba8c5e8ac0ab183f004d7fd I also note that there are 1.1.18 binaries in the following directory, but they do not match the posted SHA1SUMs. I also note the double // in the link - which was copied directly from the link for 389-Console-1.1.15-i386.msi on the Download page. https://fedorapeople.org/groups/389ds//binaries/ My hope is that this is an administrative error - the web page needs to be updated with the confirmed binary SHA1SUMs. Of more concern, there is a possibility that the binaries have been replaced with modified MSI files. If someone could look at this, it would be much appreciated. My guess is the download web page needs to be updated for the 1.1.18 MSI binaries and SHA1SUM entries. Steve Kuervers

2 1

Re: Change of IP on 389-server
by Olivier JUDITH 15 Feb '19

15 Feb '19

Hi , you can make a grep your_old_ip in /etc/dirsrv/admin-serv directory . Then change with the new ip . look these files console.conf: Listen XXX.XXX.XXX.XXX local.conf: configuration.nsserveraddress:

1 0

Change of IP on 389-server
by John.Berger＠us.fujitsu.com 15 Feb '19

15 Feb '19

FYI, Our server team re-IP'd our development 389 directory server and now the Admin server will not start. We looked through all the config files we could find and nothing jumped out what could be causing the problem. Is there a way we can easily get this back up and running without having to reinstall? Thank you in advance. John

1 0

389 fails to start, libdb: BDB1546 unable to join the environment
by Zarko D 09 Feb '19

09 Feb '19

Hi there, this is 389-ds-base-1.3.5.10-11 (part of ipa-server-4.4.0-12.0.1) and suddenly daily backup has started to fail with messages: 2019-01-28T04:10:04Z INFO Backing up ipaca in REALM-COM to LDIF 2019-01-28T04:10:04Z INFO Waiting for LDIF to finish 2019-01-28T04:10:05Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_backup.py", line 300, in run self.db2ldif(instance, 'ipaca', online=options.online) File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_backup.py", line 425, in db2ldif shutil.move(ldiffile, os.path.join(self.dir, ldifname)) File "/usr/lib64/python2.7/shutil.py", line 301, in move copy2(src, real_dst) File "/usr/lib64/python2.7/shutil.py", line 130, in copy2 copyfile(src, dst) File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc: 2019-01-28T04:10:05Z DEBUG The ipa-backup command failed, exception: IOError: [Errno 2] No such file or directory: u'/var/ lib/dirsrv/slapd-REALM-COM/ldif/REALM-COM-ipaca.ldif' 2019-01-28T04:10:05Z ERROR [Errno 2] No such file or directory: u'/var/lib/dirsrv/slapd-REALM-COM/ldif/REALM-COM-ipaca.ldif' 2019-01-28T04:10:05Z ERROR The ipa-backup command failed. See /var/log/ipabackup.log for more information And service start fails with messages: [02/Feb/2019:22:47:37.889779410 -0800] 389-Directory/1.3.5.10 B2016.309.1527 starting up [02/Feb/2019:22:47:37.906422534 -0800] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [02/Feb/2019:22:47:37.921288555 -0800] WARNING: userRoot: entry cache size 10485760 B is less than db size 16932864 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.921943984 -0800] WARNING: ipaca: entry cache size 10485760 B is less than db size 1757741056 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.922701343 -0800] WARNING: changelog: entry cache size 2097152 B is less than db size 82935808 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.925215059 -0800] Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Feb/2019:22:47:37.926177620 -0800] libdb: BDB1546 unable to join the environment thanks in advance for any help, Zarko

2 9

tls encryption and key changes: symmetric key failed to unwrap
by Jan Kowalsky 03 Feb '19

03 Feb '19

Hi all, we have the following situation: An 389ds with tls/ssl configured whith an certificate from letsencrypt. Since letsencrypt is short-dated we have an automated update routine for regenerating the cert8.db. Now we have this sort of errors in changelog. [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_cipher_init: symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_cipher_init: symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [01/Jun/2018:11:46:40 +0200] attrcrypt - All prepared ciphers are not available. Please disable attribute encryption. I never used attribute encryption and we don't need it at the moment. But as far as I understand, it's based on the server private key. This is the one we change every 60 days. The best idea seems to disable attribute encryption (which doesn't make much sense if the private key isn't password protected anyway). Or is there any other way to deal with key changes? Thanks and regards Jan

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users February 2019