I'm working on this ticket 48848. Fixing the ticket itself is easy
(please see the proposed patch).
Ticket #48848 <https://fedorahosted.org/389/ticket/48848> - modrdn
deleteoldrdn can fail to find old attribute value, perhaps due to case
But I'm afraid it might have revealed another tricky issue...
If a DN contains CES type RDN, is it ok to return the entry if a given
basedn does not match the case?
Please note that labeledURI is caseExactMatch type.
$ ldapsearch [...] -b
Our dn normalization code does not care the type of rdn but just lower
the case to normalize a dn.
I'm trying to check it with the openldap server, but somehow it is not
happy on my Fedoras... :( Although I continue trying to make it work,
but if someone has the openldap server handy, could you please add the
attached entry, run the command line and check if it returns the entry
$ ldapsearch [...] -b "labeleduri=testuri,ou=People,dc=example,dc=com" dn
Reading our docs, I see something ambiguous:
22.214.171.124. nsslapd-changelogmaxage (Max Changelog Age)
In the scenario where we have a replica that is offline, how does the changelog handle this?
A) Trim the changelog, and expect the offline master to be re-initialised
B) Do we keep the event in the changelog even though it's expired maxage.
I think it would be good to clarify this behaviour in our documentation, but I wanted to know how it behaves first.
Red Hat, Brisbane
There are 2 proposals. I'd like to have your thoughts which one would
git patch file (master) -- second proposal -- this patch allows the
password policy values and shadow account values in sync.
If we choose this option, DS Console Password Policy panel needs to be
modified to support the larger value than INT_MAX.
git patch file (master) -- first proposal -- shadow account values won't
be touched if they already exist in an entry.
1. If objectclass: shadowaccount is set and there is no shadow account
values in an entry, the shadowmax, min, and warning are filled by
calculating them from the password policy values. The maximum value of
calculated shadowMax is 24855 (== 2^31-1 / (24 * 60 * 60)).
2. Even if the values of the password policy are updated, shadow account
values are not effected.