[Freeipa-devel] DNS forward zone upgrade problem: post-mortem

Martin Basti mbasti at redhat.com
Tue Jan 6 07:54:19 UTC 2015


On 05/01/15 19:01, Simo Sorce wrote:
> On Mon, 05 Jan 2015 17:35:49 +0100
> Martin Basti <mbasti at redhat.com> wrote:
>
>> On 05/01/15 17:18, Petr Spacek wrote:
>>> Hello,
>>>
>>> as you may now, me and Martin^2 Basti screwed upgrades from RHEL
>>> 6.x to RHEL 7.1+.
>>>
>>> Cause
>>> =====
>>> RHEL 7.1/bind-dyndb-ldap 6.x supports new object class
>>> idnsForwardZone and has modified idnsZone object class semantics .
>>> This new semantics match what is called "master zones" in BIND
>>> terminology.
>>>
>>> Motivation
>>> ==========
>>> We have two main reasons for the change:
>>> 1) Clearly define (and un-obscure) idnsZone semantics to make
>>> implementation of master root zones & global forwarding possible at
>>> the same time.
>>>
>>> 2) Match BIND semantics for master and forward zones, i.e. make all
>>> the BIND docs and how-tos applicable to FreeIPA. We had many
>>> user-reported problems with forward zone configuration in the past
>>> just because the semantics was obscure and ill-defined.
>>>
>>> Upgrade
>>> =======
>>> To make upgrade possible we decided to add support for new
>>> idnsForwardZone object class to RHEL 7.0/bind-dyndb-ldap 3.5. This
>>> version serves as 'transitional' element between old and new
>>> semantics because it supports new object class idnsForwardZone but
>>> still expects old semantics on the old object class idnsZone.
>>>
>>> RHEL 7.1/bind-dyndb-ldap 6.x/FreeIPA 4.x supports new object class
>>> and at the same time expects new semantics of the idnsZone object
>>> class. FreeIPA upgrade automatically transforms existing data to
>>> the new format which is understood by RHEL 7.0.
>>>
>>> After upgrade, the new idnsZone semantics will stay be unused until
>>> user decides to use it so this is covered by "new features will not
>>> be available on old servers" clause in our release notes.
>>>
>>> For some reason nobody realized that RHEL 6.x replicas will never
>>> have bind-dyndb-ldap 3.5, i.e. the hybrid version/'transitional'
>>> element which helps with upgrade.
>>>
>>> Solution (for now)
>>> ========
>>> I have patched bind-dyndb-ldap 2.x in RHEL 6.x to add support for
>>> new idnsForwardZone object class to it:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1175318
>>>
>>> Upgrade will work as expected if users install this patched version
>>> before introducing RHEL 7.1 to their topology.
>>>
>>>
>>> All the gory details are in the design document:
>>> http://www.freeipa.org/page/V4/Forward_zones
>>>
>>> (Clearly, domain levels would help ...)
>>>
>> Also this ticket causes troubles
>> https://fedorahosted.org/freeipa/ticket/4818
>>
>> Current solution doesn't work because new schema was added, before
>> upgrade was executed on replica.
>> For now we need to store flag in LDAP, when forward zones was already
>> migrated.
>>
>> Simo, where is the right place to store this information, DNS
>> container? Or should we use something from domain levels?
> A ipaConfigString option is probably fine for this.
>
> Simo.
>
Thanks.

-- 
Martin Basti




More information about the Freeipa-devel mailing list