On 10/21/2013 10:57 PM, Simo Sorce wrote: > Comments inline. > > On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: >> On 1.10.2013 17:11, Petr Spacek wrote: > > [trim] > >> Proposal - variant A ("classical" views) >> ==================== >> - keep it simple :-) >> - single level inheritance, all views inherit from 'base' (Base is our >> current >> cn=dns subtree, so old and new plugins can co-exist. The base can be empty.) >> - the data in views can be modified via DNS updates, a change done to >> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' >> is >> shared between View1 and View2. Value change in View1 doesn't affect View2. >> - particular record from the 'base' can be overriden (deleted/replaced) in >> any >> view >> - changes done to the base are propagated to all views >> >> LDAP schema >> ----------- >> My goal is to maintain 1:1 mapping between "name+view" pair and LDAP DN. >> This >> is crucial for DNS updates. The other option is to maintain some >> 'record->LDAP >> DN database' or do a LDAP search before each DNS update - I would like to >> avoid that. >> >> Each view is stored as separate object under cn=dns. >> DN: idnsView=view1, cn=dns >> - this object stores settings specific to particular view (allowed clients, >> recursion ...) >> >> Zone in particular view is stored inside view container: >> DN: idnsName=zone1, idnsView=view1, dn=dns >> - this object can be empty container >> - attributes without explicit configuration are inherited from the base >> - a zone doesn't appear in the DNS view if the container is not present >> (i.e. >> it is possible to hide the zone from particular view) >> 'Override' records for particular name in zone and view are stored as: >> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > Doesn't this scheme means you always have to do 2 searches ? One to find > if the object is in the view and one to the base ? > > We could use multivalued RDNs to achieve something similar but that will > require you only one search (assuming it matters). > >> - values added on top of inherited set are represented as normal DNS >> attributes: e.g. aRecord: 192.0.2.1 >> - values deleted from inherited set - *are open question*: It would be great >> if we could store it under the same object as additions, it would make >> implementation a bit simpler. >> - Would it be acceptable to store override 'delete TXT record "hello"' as >> attribute 'tXTRecord;x-deleted: test'? > > I think this would be acceptable, however what happens if then someone > deletes the base object and later on again recreates it ? > > Will the view still 'mask' it ? > Is this the actual desired outcome maybe ? > > Should we allow Dynamic Updates in Views at all ? > >> - The other option is to store deleted attributes in separate object: >> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns > > This sound cumbersome and require a 3rd search for every query, nack :) > > > I like variant A, I think it is the most sensible and the only one > really needed. People have an internal view and want to 'filter' it some > for the external world or similar. > > >> Proposal - variant B (shared record groups) >> ==================== >> - not so simple to implement, especially update-performance could be an issue >> - multiple zones can share the same record group >> - each view can contain arbitrary zones anf those zones can inherit >> arbitrary >> record groups - inheritance is fully configurable >> - the data in views can be modified via DNS updates, a change done to >> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' >> is >> shared between View1 and View2. Value change in View1 doesn't affect View2. >> - particular record from any shared record group can be overriden >> (deleted/replaced) in any zone in any view >> - changes done to the shared record group are propagated to all views (this >> is >> the hard part!) > > Sound very complex not only to build, but to explain to admins as well, > is anyone actually going to need this level of complexity, what scenario > would really benefit from this that can't be done with A ? > > >> LDAP schema >> ----------- >> Group of shared records - container: >> DN: idnsRecordGroup=group1, cn=dns >> >> One shared name: >> DN: idnsName=record1, idnsRecordGroup=group1, cn=dns >> - contains DNS records for that name as usual >> >> Each view is stored as separate object under cn=dns. >> DN: idnsView=view1, cn=dns >> >> Zone in particular view is stored inside view container: >> DN: idnsName=zone1, idnsView=view1, dn=dns >> - zone has a attribute with DNs of inherited record groups >> >> 'Override' records for particular name in zone and view are stored as: >> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns >> >> >> After each change to any data we have to compute new resulting value. It >> means >> to combine the data for particular name from all record groups and then >> apply >> overrides for particular instance. >> >> It means a lot of bookkeeping after each change ... >> >> >> Proposal - variant 0 >> ==================== >> Do not implement it in bind-dyndb-ldap and wait if Martin Basti succeeds >> with >> his thesis. He is trying to design and implement some generic/pluggable >> LDAP<->DNS synchronization mechanism. >> >> Personally, I think that variant "0" is the best one! :-D One of side >> effects >> is that our depedency on BIND 9 will be lowered and most of the work will be >> deferred to the real DNS server. > > > Synchronization is always very, very hard, especially when you throw in > the word 'generic'. Especially problematic are races. I would proceed > with A unless there is solid evidence this can work with all corner > cases and in a short period of time. > > Simo.
I read all the proposals, I would personally stick with variant A as this is something that is doable in near future. Variant 0 seems a bit utopic to me, especially when speaking about synchronization corner cases. Martin's thesis may prove me wrong, we will see. Martin _______________________________________________ Freeipa-users mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users