[Freeipa-devel] automount in LDAP

[Dmitri Pal]

Simo Sorce wrote:
> 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.
>
>   
I would say they are two independent things: which server to connect and 
which policies to get.