On 10/04/2013 04:31 PM, Adam Young wrote:
> On 10/01/2013 04:45 AM, Petr Spacek wrote:
>> On 23.9.2013 19:06, Dmitri Pal wrote:
>>> On 09/23/2013 10:25 AM, Petr Spacek wrote:
>>>> On 20.9.2013 19:29, Dmitri Pal wrote:
>>>>> 5) Met with James (the blogger) and the community guy who created
>>>>> scripts for IPA. He was trying to convince me that we need to support
>>>>> the use case when IPA is the DNS that provides two different sets
>>>>> of the
>>>>> IPA addresses for the IPA clients running inside the subnet and
>>>>> the subnet. I see a clear use case and value. So that get back to the
>>>>> views. Why do we thing views will be a problem in IPA?
>>>> In principle - it is technically possible. Just pretty hard.
>>>> - It requires re-designing of LDAP schema for DNS.
>>>> - It implies that we will have to adapt all parts of FreeIPA and
>>>> bind-dyndb-ldap which touches the LDAP.
>>>> - And also re-design CLI and WebUI, because views adds one level of
>>>> indirection: Your will need some tool to see what is in the particular
>>>> view, move records from one view to another, share records between
>>>> views, do exceptions etc.
>>>> We tried to design schema for views approximately year ago, but there
>>>> wasn't a clear agreement on that.
>>> Hm. OK. That means that we are probably over complicating things. Do
>>> have a pointer to design?
>> It has been more 'discussion' without clear outcome then real design:
>>> Let us table the actual design conversation for now but when we start
>>> 3.5 planning I want to take a closer look.
>> We should move the discussion to freeipa-devel at thins point ...
>> I have spent some time thinking about DNS views and I think that we
>> should design support for DNS views as soon as possible.
> Opening up the discussion. This is FreeIPA general stuff:
> I think that the idea of different internal and external views is not
> specific to DNS. Other things that might be different between
> internal and external:
> Kerberos might only want to let a subset of users get tickets from
> outside the VPN, and only provide service tickets for services in the DMZ
> You might want to run an Kerberos KDC proxy outside of the IPA instance
> LDAP might be limited to read only when accessed from outside, and
> only a subset of users, or a subset of the data from other entities
> would be exposed
> Dogtag might want to only publish CRL and expose OCSP to the outside
> IPA ui might be limited to self service
> Perhaps a better abstraction is an IPA proxy, a server that is an
> incomplete replica of an IPA server. As such it would get:
> 1. A subset of the data from the canonical LDAP server
> 2. Some of that data would be modified, such as the A records marked
> for external use
> 3. It will not push updates to the centralized server. It will be
> configured to not accept updates from the outside world.
>> Resulting design will significantly influence bind-dyndb-ldap
>> internals & also DNSSEC support. At the moment, the code relies on
>> assumption that one LDAP object = one DNS name.
>> We have to find out if DNS views will break this assumption as soon
>> as possible. IMHO views will change things significantly, including
>> this 1:1 mapping - which will require major code re-design.
>> I would like to avoid re-designing for DNSSEC and then immediate
>> re-design for DNS views.
> Freeipa-devel mailing list
This brings us to the read only replicas.
May be it is time to think about those more seriously?
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list