[Freeipa-devel] automount in LDAP

Dmitri Pal dpal at redhat.com
Fri Nov 7 20:18:07 UTC 2008


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.

Thanks
Dmitri




More information about the Freeipa-devel mailing list