[Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone

[Petr Viktorin]

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.
>>>>>>>
>>>>>>> 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
>>>>
>>>
>>> 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!
>
> Martin
>

Thanks, pushed to master: 8b7daf675e77d7a5e2de6eadb26ca3b682c0d67f

-- 
Petr³