On Tue, Dec 16, 2025 at 5:02 PM Bob Green <[email protected]> wrote: > > > that class to these user objects if necessary. Or perhaps there is a > > way to add one of my already defined objectclasses to the fixup > > process? > > answering my question was as simple as looking at what options fixup > allows, and sure enough there is a -f / --filter option: > > -f FILTER, --filter FILTER > Filter for entries to fix up. If omitted, all entries > with objectclass inetuser/inetadmin/nsmemberof under > the specified base will have their memberOf attribute > regenerated. > > I'm running this now and will report back on my success. Thanks again > for your pointers.
Turns out the issue I was facing was not with the memberOf plugin, but rather with the excessively large groups I was attempting to import on an untuned 389ds instance. To insure groups would be properly imported I had to increase the value of nsslapd-maxbersize and nsslapd-db-locks. Thankfully 389ds logging is clear when errors with these undersized parameters are encountered, one merely need to pay attention to what's being recorded in the errors log. Concerning 389ds performance tuning, are the Red Hat documents[1] considered authoritative? Or are there other resources I should be looking at as well? Thanks again, Bob [1]: https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/tuning_the_performance_of_red_hat_directory_server/index -- _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
