[Freeipa-devel] automount in LDAP

[Simo Sorce]

On Fri, 2008-11-07 at 15:18 -0500, Dmitri Pal wrote:
> Simo Sorce wrote:
> > On Fri, 2008-11-07 at 12:07 -0500, Dmitri Pal wrote:
> >   
> >>> If we add some sort of location identifier for automount what 
> >>> implications does this have for other features? Do we want to have 
> >>> per-location settings for anything else?
> >>>
> >>> My plan is to embed the location into the DN of the automount map and 
> >>> key names using cn.
> >>>
> >>> For the UI we'll need some method of selecting/managing this list of 
> >>> locations (drop-down box comes to mind). I'm not sure if storing this 
> >>> separately is a good idea or not.
> >>>
> >>> I just want to avoid any short-term choices I make don't have 
> >>> long-term consequences.
> >>>
> >>>       
> >> Yes I agree . We need to have a more generic approach to that.
> >>
> >> I am struggling with understanding how client would determine which 
> >> location he is in.
> >> I do not think that it should be based on the server the client is 
> >> connected to.
> >> This approach would require servers to serve out data different from 
> >> data being served by other replica. But what if the client fails over? 
> >> Does not seem like a good approach  imo.
> >> So may be using IP address range  would be a better indication?
> >> May be we have a part of client policy that would say :
> >>
> >> Location A: range1, ragne2, range 3
> >> Location B: range4, ragne5, range 6
> >>  
> >> This approach works if you can determine the right IP to check. From my 
> >> past experience answering the question "which of my IPs is the IP that 
> >> server sees" is not a trivial answer.
> >> But let us say we dealt with that. Then as soon as client gets online it 
> >> would know its IP so it will know its location so it will be able to 
> >> construct a search filter and add it to the search string.
> >>     
> >
> > It is not a simple task, that said I have been working on a document on
> > DNS based location discovery for some time, I will try to publish it as
> > soon as I have some time.
> >
> >   
> >> I really like the idea of having location as an attribute. Then for any 
> >> object that client needs to fetch and it can be location specific it 
> >> would just add to the search filter:
> >> ( | (location=<determined location>) (!(location))) This will pull down 
> >> all entries that are specific to the location or entries that are not 
> >> location specific.
> >>
> >> This logic can be then reused across different entities not only mounts.
> >>     
> >
> > It is fundamental for SSSD to be able to discover the closest IPA
> > service and fallback to the next closest in case of problems and so on.
> > It's a fundamental feature we have been discussing for some time months
> > ago, I will publish some docs as soon as possible.
> >
> > Simo.
> >
> >   
> Simo I remember and do not discard that.
> But I was talking about the fact that affinity and closest server do not 
> mean that the location of the client is the determined correctly.
> 
> What if the APAC replica is down and all clients now to use one in 
> Europe. But they are still in APAC so they need to use APAC mount shares.
> For the visiting salesman with laptop from Europe his mounts should be 
> APAC is he visits APAC right though he is affiliated naturally with 
> European server?
> 
> These are the scenarios I was talking about . I think determining 
> location of the client is  different from the affinity and failover logic.

Determining the location of the client is indeed only a precondition to
determine which services to use. Depending on the service you want to
use, policies on which server is appropriate to contact may vary.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York