[Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone
Petr Viktorin
pviktori at redhat.com
Mon May 26 10:48:51 UTC 2014
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.
--
Petr³
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0543.3-dns-Add-idnsSecInlineSigning-attribute-add-dnssec-op.patch
Type: text/x-patch
Size: 9711 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140526/1bc80b88/attachment.bin>
More information about the Freeipa-devel
mailing list