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?

--
Martin Basti

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

Reply via email to