On 12/18/25 7:14 AM, Ondřej Kuzník wrote:
On Wed, Dec 17, 2025 at 11:44:03AM -0500, Brendan Kearney wrote:
I don't have any explicit size limits on identities. DB size limits are
"unlimited" for cn=config, 25 GB on DIT.
It's not about DB size (although yes, worth monitoring olmMDBPagesUsed
etc.) but about search size limits which AFAIK tend to default to 500
for non-root users unless changed by olcLimits.
The root DN is currently used as the bind DN for replication, so search
size would/should not affect replication. otherwise, I don't have
olcLimits set.
Reusing serverids is a misconfiguration, each provider **has** to have a
unique non-zero serverID. The replication logic relies on it to decide
where changes are coming from and where (not) to route them. This is why
the serverID option has a second form of "serverID <id> <listen URL from
slapd -h ...>" so that you can replicate cn=config but have every server
maintain its own identity.
Everyone else apart from providers can keep their serverid at default
(="0") but they can also have one assigned if you want to be able to
promote them to providers easily, your choice.
so, the olcServerID and rid used in the replication configs should both be
incremented when rolling over / upgrading a box?
Upgrading in-place is fine, because there's never two servers with the
same sid. But when adding a new provider, add another olcServerID: value
to cn=config with a unique serverID and its URI.
I am seeking a bit of clarification here. I am upgrading in place, and
no servers have overlapping SID, but I cannot reuse a SID. The rebuild
will reuse IPs as well. The newly built server will retain just about
every configuration that was set in the previously installed OS. So,
should I increment the below:
olcServerID: 1 ldap://ldap1.bpk2.com
olcServerID: 2 ldap://ldap2.bpk2.com
olcServerID: 3 ldap://ldap3.bpk2.com
to be:
olcServerID: 1 ldap://ldap1.bpk2.com
olcServerID: 2 ldap://ldap2.bpk2.com
olcServerID: 4 ldap://ldap3.bpk2.com
when I rebuild the host known as ldap3?
Thanks for the insight,
Brendan Kearney
Regards,
