[Freeipa-devel] Ticket #293

[Adam Young]

On 05/16/2011 04:01 AM, Jakub Hrozek wrote:
> On 05/14/2011 03:27 AM, Adam Young wrote:
>> I'm tripping over the solution to this ticket:
>>
>> https://fedorahosted.org/freeipa/ticket/293
>> I don't understand the statement:
>> "The key for a direct map is /- so only one can be in auto.master"
>> auto.master is the map.  Do you mean that there cannot be more than one
>> direct map in a location?
>>
> auto.master is the default map that is consulted for the list of maps.
>
> The problem was that we were storing the map key (automountkey
> attribute) as RDN, so in effect you could not have duplicate keys. For
> indirect maps, it is usually OK, but the problem is storing something
> like this in LDAP:
>
> /etc/auto.master:
> /-	/etc/auto.direct
> /-	/etc/auto.direct2
>
>
> The patch for #293 worked around the uniqueness constraint by not
> storing the automountkey in the DN but rather storing the (automountkey,
> automountinformation) tuple in the description attribute and using
> description for the RDN. So instead of requiring the key to be unique we
> require the (key,info) tuple to be unique.
>
> Automounter does not care about DNs of keys, so this approach was safe.
>
>> The key for a direct map should be the fully qualified path name down to
>> the mount point.  If it is a direct map, the mount point is specified
>> from /-,  but the key will be unique:
>>
> You are describing the contents of the direct map. The problem is
> linking the direct map into the master map.
>
>> For example
>>
>> /home/ayoung exporter:/altlocation/ayoung
>> /home/* exporter:/home/&
>>
>> That would allow a different location for my home directory (ayoung)
>> than everyone else.
>>
>> I've reverted the patch in my tree and the original behavior seems
>> sensible.  What was the impetus for pushing this patch through, and can
>> we cleanly revert it?  Rob stated that that there will be a data porting
>> issue due to the values we put in to Dir Srv for the dn.
>>
> I fail to see what is the problem with the patch and why do you suggest
> reverting it?

It has to do with managing the keys.  The entire key/info has to be 
unique, as opposed to just the key.  This makes the logic for the UI 
very convoluted, and it makes the SHOW command difficult to use, as you 
bascially need all of the information to show, not just the key.  We 
broke the the normal case for a corner case, and there is a better solution.

 From a uniqueness perspective, the location itself should be uniquye, 
the combination of location and mapname should be the unique key for the 
map, and the tripart key location, mapname, keyname should be the unique 
key for the key.  For default maps , I agree that you should not be 
using the key as the unique identifier, and I can see why that caused 
problems.


>> A related issue that may be moot:  I tested an indirect map, and can't
>> see where the key gets stored.  I haven't tried it without the reverted
>> patch, so it may be something that got fixed later.
>>
>>
> In the automountkey attribute, which is the same as with the reverted
> patch. The patch only changes the DNs, nothing else.
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20110516/92544ded/attachment.htm>