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.

https://fedorahosted.org/freeipa/ticket/3801

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 also
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.

Simo.

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 extension.
Hello,

   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 1.3.2.17 and after.
   It was tested with mixing 1.3.2.17 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.

   regards
   thierry

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to