389-users January 2020

389-users@lists.fedoraproject.org

13 participants
23 discussions

Restore from Backup Fails
by Elena Rico 09 Jan '20

09 Jan '20

Hello, We have noticed some inconsistent results while restoring from a backup. We are running the below script which takes backups nightly and then we use the 'bak2db' to restore. Version: 389-Directory/1.3.8.4 B2018.332.2046 We have noticed 2 issues: 1) Segmentation fault The first time we execute 'bak2db' or 'bak2db.pl' both generate the below error: [root(a)iris-ldap-01b.lab1 bak]# bak2db /var/lib/dirsrv/slapd-iris-ldap-01b/bak//iris-ldap-01b-2020_01_08_06_00_02 -n userRoot -Z $(hostname -s) [09/Jan/2020:16:59:58.470938641 +0000] - ERR - config_set - The attribute nsslapd-accesslog-list is read only; ignoring new value /var/log/dirsrv/slapd-iris-ldap-01b/access.20190630-191314.test [09/Jan/2020:16:59:58.474013017 +0000] - ERR - config_set - The attribute nsslapd-accesslog-list is read only; ignoring new value /var/log/test [09/Jan/2020:16:59:58.666392572 +0000] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [09/Jan/2020:16:59:58.694699743 +0000] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [09/Jan/2020:16:59:58.727591335 +0000] - ERR - dblayer_file_check - Previous import or restore failed, file: /var/lib/dirsrv/slapd-iris-ldap-01b/db/../.restore is empty [09/Jan/2020:16:59:58.759491776 +0000] - INFO - dblayer_pre_close - All database threads now stopped [09/Jan/2020:16:59:58.763162191 +0000] - NOTICE - dblayer_delete_database_ex - Skipping instance NetscapeRoot /sbin/bak2db: line 87: 17865 Segmentation fault /usr/sbin/ns-slapd archive2db -D /etc/dirsrv/slapd-iris-ldap-01b -a /var/lib/dirsrv/slapd-iris-ldap-01b/bak/iris-ldap-01b-2020_01_08_06_00_02 -n "userRoot" We have noticed that stopping the server and using 'bak2db' a second time does restore, but it has to be executed 2 times. * Do you know why we are getting this error? 2) In some instances the restore is not successful. And this is inconsistent, sometimes it works and others it does not. Below are the errors: [09/Jan/2020:16:46:10.349362830 +0000] - ERR - libdb - BDB2506 file /var/lib/dirsrv/slapd-iris-ldap-01b/changelogdb/17a67641-223b11e8-966b9f6a-c9bf4dc9_585bee1f000000020000.db has LSN 241/3829568, past end of log at 241/2373072 [09/Jan/2020:16:46:10.351404473 +0000] - ERR - libdb - BDB2507 Commonly caused by moving a database from one database environment [09/Jan/2020:16:46:10.352951735 +0000] - ERR - libdb - BDB2508 to another without clearing the database LSNs, or by removing all of [09/Jan/2020:16:46:10.356241586 +0000] - ERR - libdb - BDB2509 the log files from a database environment [09/Jan/2020:16:46:10.358146068 +0000] - ERR - libdb - BDB1521 Recovery function for LSN 241 1284 failed [09/Jan/2020:16:46:10.360388060 +0000] - ERR - libdb - BDB0061 PANIC: Invalid argument [09/Jan/2020:16:46:10.362683721 +0000] - ERR - libdb - BDB1544 process-private: unable to find environment [09/Jan/2020:16:46:10.365319736 +0000] - ERR - dblayer_make_private_recovery_env - Open error -30973: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery [09/Jan/2020:16:46:10.366912512 +0000] - ERR - dblayer_fri_restore - Recovery failed! [09/Jan/2020:16:46:10.368700472 +0000] - ERR - ldbm_back_archive2ldbm - Failed to read backup file set. Either the directory specified doesn't exist, or it exists but doesn't contain a valid backup set, or file permissions prevent the server reading the backup set. error=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) * Is there anything we need to change to make sure we have correct backups? For backup we are running this script based on a response from the mailing list: #!/bin/bash # # Creates a backup of 389-ds online # Based on https://mjanja.ch/2013/09/backing-up-389-ldap/ # # Read credentials from file timestamp=`date +%Y_%m_%d_%H_%M_%S` source /usr/local/etc/ldap-backup.cfg # Backup each instance for dirsrv in /etc/dirsrv/slapd-* do name=${dirsrv/*slapd-/} if [ "${name}" == "localhost" ]; then continue fi vardir=/var/lib/dirsrv/slapd-${name} [ -d /var/lib/dirsrv/scripts-${name} ] && scriptdir=/var/lib/dirsrv/scripts-${name} [ -d /usr/lib64/dirsrv/slapd-${name} ] && scriptdir=/usr/lib64/dirsrv/slapd-${name} [ -d /usr/lib/dirsrv/slapd-${name} ] && scriptdir=/usr/lib/dirsrv/slapd-${name} ${scriptdir}/db2bak.pl -D "cn=${ldap_user}" -w "${ldap_password}" -a ${vardir}/bak/${name}-${timestamp} -P LDAPI dbdir=${vardir}/db for dbentry in ${dbdir}/* do if [ -d ${dbentry} ] #check if directory exists then dbname=$(basename ${dbentry}) ${scriptdir}/db2ldif -n ${dbname} -a ${vardir}/ldif/${dbname}-${timestamp}.ldif fi done # Cleanup old entries /usr/sbin/tmpwatch -mM ${retention_hours} ${vardir}/bak /usr/sbin/tmpwatch -mM ${retention_hours} ${vardir}/ldif done

2 3

Need Migration assist, please
by Jeffrey Westgate 07 Jan '20

07 Jan '20

we are running "389-Directory/1.2.11.15 B2017.101.1347" on a Scientific Linux 6.9 VM. We have a 2 server cluster running, and have for several years, with very little intervention required. we are wanting to move to RHEL8, and the latest (stable) 389DS We have questions (as the existing system was set up by a late employee of immense knowledge of things computerized): - is the latest 389DS (stable version) compatible with RHEL8 - how do we migrate the user database Been looking through the documents, but I'm not finding much to help. -- Jeff UNIX/Linux admin

3 3

Connections Opened but No BIND Received
by Trevor Fong 06 Jan '20

06 Jan '20

Hi Everyone, We're running a cluster of VM's running 389-Directory/1.3.9.1 B2019.164.1418 on RHEL7.7. Some are providers, which replicate to a bunch of hubs (which provide authentication services), which replicate in turn to a bunch of consumers (which provide support for longer running queries). Of late, we've a few clients have noted timed out connections. When we look in our logs we see things like: [23/Dec/2019:00:21:50.760643645 -0800] conn=7827580 fd=469 slot=469 SSL connection from <their IP> to <our IP> [23/Dec/2019:00:21:50.764149645 -0800] conn=7827580 TLS1.2 256-bit AES-GCM <no other transactions on conn=7827580, until the client times out the connection> [23/Dec/2019:00:22:05.763868515 -0800] conn=7827580 op=-1 fd=469 closed - Encountered end of file. Others connections are made and operate just fine between the opening and closing of the timed-out connection. Would anyone know what this could be/what we could check? Thanks, Trev

5 11

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2020