[Freeipa-devel] automount in LDAP

Dmitri Pal dpal at redhat.com
Mon Nov 10 22:30:30 UTC 2008


Rob Crittenden wrote:
> Simo Sorce wrote:
>> On Mon, 2008-11-10 at 10:10 -0500, Rob Crittenden wrote:
>>> And this is what I meant by poor choices now affecting the future :-)
>>>
>>> Right now I'm sort of waving my hand saying 'location will be in the 
>>> DN of the automount entry' but I don't yet say where I'm storing 
>>> location other than in the DN. This will require the UI to fetch all 
>>> the automount entries and sift thru the names to determine the list 
>>> of locations to present to a user.
>>
>> Is it necessary to store it in the DN ?
>> Why can't we add it into the entry instead ?
>
> Because all shares are rooted in the same place, auto_master. So we 
> need a separate auto_master for each location. Our UI would be clever 
> enough to look at another attribute but the autofs code isn't.
>
>>> On the command-line it would be easier as we'd just pass along the 
>>> location requested, though this would be prone to typos.
>>
>> True, but it is not the end of the world if it is just an attribute.
>> If it is part of the DN in a hierarchy of objects it is much more severe
>> as we still do not have subtree renames with FDS.
>
> I don't think that would be a problem. If they want to rename a 
> location we'll just demand that they remove and re-create the maps for 
> now. If we wanted to be super-user-friendly we could probably do this 
> automatically but I think manually would be fine for starters.
>
>>> We could live with this for now and in the future store location in 
>>> some central point. It wouldn't affect the UI, just make the 
>>> processing a bit less intensive.
>>
>> I see the location for now just as a filter, if we put it as an
>> additional attribute for the entry you don't need to show anything else
>> but what is already there (and allow to add arbitrary new location
>> strings)
>
> Granted I'm not an expert at autofs but I don't think the client-side 
> code works that way.
>
>>> I'm thinking of just setting location as a cn in the DN, so a map DN 
>>> would look like:
>>>
>>> dn: automountmapname=auto.direct, cn=Baltimore, cn=automount, 
>>> dc=example, dc=com
>>>
>>> or
>>>
>>> dn: automountmapname=auto.direct, cn=default, cn=automount, 
>>> dc=example, dc=com
>>>
>>> I should probably treat the location cn as case-sensitive since that 
>>> is what the cn attribute defines.
>>
>> IIRC the CN is case-insensitive, anyway I would really prefer not to
>> embed the location in the DN also because, as I said in another mail, we
>> may want to associate an automount map with multiple locations.
>
> I think you'd have to duplicate the map for each location. If you have 
> the same map everywhere then the argument for having separate 
> locations becomes weaker, IMHO.
>
> rob

Is there a requirement to support locations in v2?
If not then we do not need to solve the problem now. We can just have a 
designated default location and have a map for everybody in v2.
In v3 we can solve a problem in different ways - create separate 
containers for separate locations under default place, use  "compat" 
tree and create virtual entries like we do with other things or explore 
more the use of location attribute and so on.

Thanks
Dmitri 




More information about the Freeipa-devel mailing list