389-users July 2024

389-users@lists.fedoraproject.org

4 participants
4 discussions

Enable SSHA hashing scheme
by Ralf Spenneberg 02 Jul '24

02 Jul '24

Hi there, I am trying to update a ldap tree from 389ds 1.3.11 (centos7) to 2.4.5 (almalinux9). After migrating the tree all passwords stop working including the Directory Manager. The old tree used SSHA. Setting the rootpwstoragescheme does not help for the Directory Manager. Only manually resetting the passwords using pwdhash in the dse.ldif file and using a PBKDF2-SHA512 password works. Is there a way to enable the old SSHA scheme? Kind regards, Ralf

2 1

Replication weirdness with 3.0.1 mdb instance
by tdarby＠arizona.edu 02 Jul '24

02 Jul '24

I have several 389ds instances using MMR, but only one at the moment that uses 3.0.1 and the new mdb. It's an instance I'm building from scratch and I script it with config files that are similar to the 2.5 instances. When I initiate replication, what I see is that it finishes without errors but only sends approx. 1000 entries to the consumer (there are over 1M entries). I've looked at all the config attributes that I'm aware of and I'm stumped. Can you think of anything that would prevent a replication account from sending over more than 1000 entries? Here's a typical snippet from the logs for this: [02/Jul/2024:17:22:05.137366809 +0000] - NOTICE - NSMMReplicationPlugin - multisupplier_be_state_change - Replica ou=netid,ou=ccit,o=university of arizona,c=us is going offline; disabling replication [02/Jul/2024:17:22:07.913831452 +0000] - INFO - dbmdb_import_monitor_threads - import dsroot: Import writer thread usage: run: 9.31% read: 69.38% write: 19.17% pause: 0.99% txnbegin: 0.00% txncommit: 1.15% [02/Jul/2024:17:22:07.978516129 +0000] - INFO - dbmdb_import_monitor_threads - import dsroot: Workers finished; cleaning up... [02/Jul/2024:17:22:07.981201324 +0000] - INFO - dbmdb_import_monitor_threads - import dsroot: Workers cleaned up. [02/Jul/2024:17:22:07.983442852 +0000] - INFO - dbmdb_public_dbmdb_import_main - import dsroot: Indexing complete. Post-processing... [02/Jul/2024:17:22:07.985709898 +0000] - INFO - dbmdb_public_dbmdb_import_main - import dsroot: Generating numsubordinates (this may take several minutes to complete)... [02/Jul/2024:17:22:07.991134437 +0000] - INFO - dbmdb_public_dbmdb_import_main - import dsroot: Generating numSubordinates complete. [02/Jul/2024:17:22:07.993601582 +0000] - INFO - dbmdb_public_dbmdb_import_main - import dsroot: Flushing caches... [02/Jul/2024:17:22:07.995667599 +0000] - INFO - dbmdb_public_dbmdb_import_main - import dsroot: Closing files... [02/Jul/2024:17:22:07.997941832 +0000] - INFO - dbmdb_public_dbmdb_import_main - import dsroot: Import complete. Processed 1097 entries in 3 seconds. (365.67 entries/sec)

1 0

Replication weirdness with 3.0.1 mdb instance
by tdarby＠arizona.edu 02 Jul '24

02 Jul '24

1 0

MDB db questions/concerns
by tdarby＠arizona.edu 01 Jul '24

01 Jul '24

The mdb change came as a worrying surprise when the container pulled down 3.0.1 without me realizing it. I've read as much as I can find (which is not much), but I don't understand all the changes. Questions: 1. Is there a way to continue to pull the 2.5 version of the container? 2. If I update an existing 2.5 container instance to 3.0.1, will it continue to use bdb? 3. The nsslapd-mdb-max-size attribute: - Does this only set the size of the db on disk? What if it exceeds that limit? - I was going to set it to "use all available space" until I saw these comments, but not sure what to make of them and I don't feel any closer to understanding what I should do with this attribute: - the file will tend to grow up to its maximum - if real memory is smaller than the file then pages will be swappped - My first experience about configuring oversized database was interresting: at first I did not capped the value to 1Gb and the basic import scenario was spending hours before failing because disk was full (with a real db size around 10Gb on the test VM) while once capped to 1 GB the import was successful in less than 10 minutes ==> *Correct sizing matters*"

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2024