<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/29/2014 10:07 PM, Martin Kosek
wrote:<br>
</div>
<blockquote cite="mid:5360068E.80805@redhat.com" type="cite">On
04/29/2014 08:17 PM, Simo Sorce wrote:
<br>
<blockquote type="cite">On Tue, 2014-04-29 at 20:00 +0200, Petr
Viktorin wrote:
<br>
<blockquote type="cite">This adds the "idnsSecInlineSigning"
attribute and related option.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/3801">https://fedorahosted.org/freeipa/ticket/3801</a>
<br>
<br>
Simo, is adding a MAY attribute to an existing objectClass
okay?
<br>
<br>
</blockquote>
<br>
Not unheard of, however in the past we discovered some schema
<br>
replication issues that may have an impact, let's make sure DS
team also
<br>
agrees this is not going to cause issue.
<br>
<br>
<blockquote type="cite">From a purely functional pov a MAY
attribute will not break any stored
<br>
</blockquote>
object, so it is fine.
<br>
<br>
Simo.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<font face="Times New Roman, Times, serif">Hello,<br>
</font><br>
<blockquote><font face="Times New Roman, Times, serif">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 </font><font face="Times New Roman, Times,
serif"><font face="Times New Roman, Times, serif"><a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/47721">https://fedorahosted.org/389/ticket/47721</a>.
So it is fine to add new MAY/MUST attribute or new
attribute/objectclasses.<br>
<br>
</font>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. </font><tt>'</tt><tt>idnsSecInlineSigning'</tt><font
face="Times New Roman, Times, serif"><tt>)</tt> 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.<br>
There is a similar mechanism, when a replica receives a schema
that contains new definitions, it 'learns' them.<br>
<br>
The fix for 47721 is introduced in 389-ds 1.3.2.17 and after.<br>
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. <br>
A limitation is that a legacy instance (not having the fix),
must have a replica agreements to/from an instance with the fix.<br>
<br>
regards<br>
thierry<br>
</font><br>
</blockquote>
</body>
</html>