389-ds-base

#48862 At startup DES to AES password conversion causes timeout in start script
Closed: wontfix Opened by mreynolds.

Closed: wontfix
Reopen Issue

When the server is started, and the DES plugin is enabled, it searches all the backends for DES passwords to convert to AES. This search is typically unindexed, and on large databases/backends this takes a long time and the start script time's out.

We need to come up with a better way to handle this. Perhaps only run it on cn=config when starting the server? And/or add a new task to convert DES passwords to AES for specific backends(filter/scope)?

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1342609

Note: Ticket #48777 - "DES to AES password conversion fails if a backend is empty" is in 1.3.4.

Setting target milestone to 1.3.4.

169d0ab..11f55f3 master -> master
commit 11f55f3dd2a2c44ddf7b5be54273401add13b1bc
Author: Mark Reynolds ​mreynolds@redhat.com
Date: Tue Jun 7 10:02:42 2016 -0400

ca50d1c..c0ad918 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit c0ad918939c40779e463b71c41ab106e7ee890e2

0b98840..fd96d1b 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit fd96d1bcfc854047e8796c07e44b134d560c495d

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.3.14

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1922

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
Metadata
None
None
None
Normal
ack
QE
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.