On 05/28/2014 02:45 PM, Martin Kosek wrote:
On 05/26/2014 12:48 PM, Petr Viktorin wrote:
On 05/14/2014 12:50 PM, Petr Viktorin wrote:
On 04/30/2014 10:00 AM, thierry bordaz wrote:
On 04/29/2014 10:07 PM, Martin Kosek wrote:
On 04/29/2014 08:17 PM, Simo Sorce wrote:
On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote:
This adds the "idnsSecInlineSigning" attribute and related option.
Simo, is adding a MAY attribute to an existing objectClass okay?
Not unheard of, however in the past we discovered some schema
replication issues that may have an impact, let's make sure DS team
agrees this is not going to cause issue.
From a purely functional pov a MAY attribute will not break any stored
object, so it is fine.
Adding Thierry to the CC list to evaluate the risks, he was already
involved in fixing related issue in the DS for a similar Dogtag schema
When an instance in the topology contains schema extensions like new
MAY attribute, this extension would be propagated to all instances
by replication (no need to copy/merge schema files). This was the
purpose of https://fedorahosted.org/389/ticket/47721. So it is fine
to add new MAY/MUST attribute or new attribute/objectclasses.
During a replication session, a master will check what schema
definitions (objectclasses/attributes) of the replica extends its
own schema. If such definitions exist the supplier add/replace them
in its schema and its user99.ldif file. In your case if a replica
contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but
not the supplier then the supplier 'learns it' (during a replication
session it initiated) and so an entry containing that new attribute
can be updated on the supplier as well.
There is a similar mechanism, when a replica receives a schema that
contains new definitions, it 'learns' them.
The fix for 47721 is introduced in 389-ds 18.104.22.168 and after.
It was tested with mixing 22.214.171.124 instance with legacy versions
(1.3.1, 1,3.0..), and the schema on both side converged to a common
one. This, whatever if the extensions are present on both side.
A limitation is that a legacy instance (not having the fix), must
have a replica agreements to/from an instance with the fix.
Thanks. This means the patch is good for review.
I've just rebased it slightly.
Another rebase in VERSION was necessary.
Still looking for a review.
This is pretty obvious change, worked fine for me. ACK!
Thanks, pushed to master: 8b7daf675e77d7a5e2de6eadb26ca3b682c0d67f
Freeipa-devel mailing list