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
puppet
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
outside
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 you
have a pointer to design?
It has been more 'discussion' without clear outcome then real design:
https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html
https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html
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 world
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
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
