Similar to ticket #3314, user had huge value in directory. Setting up replication was failing.
User had to directly modify the 389-ds dse.ldif templates to increase the values.
If possible would be good to have some mechanism to pass custom values prior to starting replication or doing any real work.
In this case we had to increase nssslapd-maxbersize, nsslapd-cachememsize, nsslapd-import_cachesize and nsslapd-dbcachesize.
nssslapd-maxbersize
nsslapd-cachememsize
nsslapd-import_cachesize
nsslapd-dbcachesize
May be back port.
Related Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1029905
Make the value big during install and then set it back at the end of the install.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1029905 (Red Hat Enterprise Linux 7)
Moving to Backlog, not a release blocker.
Moving to next release - no time for the RFE in 4.0.
No time left for this ticket in 4.1 -> moving out.
The FreeIPA 4.2 was already shaped (see [[milestone:FreeIPA 4.2]] milestone), this does not fit. Pushing out.
If anyone is willing to help and contribute to this one, please let us know!
Very related: #4949.
My patch for #4949 is almost done and resolves this ticket as well.
I'm taking ownership of this ticket.
master:
How to use:
# cat update.ldif dn: cn=config changetype: modify replace: nssslapd-maxbersize nssslapd-maxbersize: 209715201 dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 10485761 dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-import_cachesize nsslapd-import_cachesize: 20000001 - replace: nsslapd-dbcachesize nsslapd-dbcachesize: 10000001 # ipa-{server,replica}-install --dirsrv-config-file=update.ldif
Metadata Update from @rcritten: - Issue assigned to mbasti - Issue set to the milestone: FreeIPA 4.3
Login to comment on this ticket.