automount keys have a dn constructed with the description attribute which is a combination of key name and automountinformation. This guarantees a unique dn but makes the show command impossible because you need the exact string for automountinformation.
This level of uniqueness doesn't seem to be required in any case. keys just need to be unique within a given map, which is unique within a given location.
It is likely going to be more work migrating existing entries to the new dn format than changing the way the dn is handled.
This is easiest to see by adding a map, a key, then try to show the key.
The reason we used description is to support multiple direct maps. We may just need to tweak this a bit.
The underlying problem is that there are two kinds of keys:
One type of key is an actual mount point where automountinformation contains, for example, the NFS server information.
The second kind of key connects a map to a parent, say auto.share to auto.master. In this case the automountinformation contains the name of the map (auto.share) and the automountmapname is auto.share. Direct maps have a key of /- and indirect maps have a key of the mount point (e.g. /share).
This second problem is the one we tried to solve with description. Since the key is /- if we have it in the dn we can support only a single direct map within a given location.
Within the framework we know what a dn is supposed to look like and for the show commands we construct it and fetch it directly, avoiding a search.
It does raise an interesting point though, assume we do find a way around this. The key is still /- in this case, so does a _show return multiple records if we have multiple maps? That would break lots of assumptions.
I've almost come to the conclusion that we can't really support multiple direct maps.
Replying to [comment:2 rcritten]:
I don't strictly disagree, because we're really shoehorning the automount map files structure into LDAP in a weird way.
Do we have any estimate if multiple direct maps are commonly used in production, though? This feature was added into autofs in version 5, maybe the maintainer would know..
Replying to [comment:3 jhrozek]:
Replying to [comment:2 rcritten]: I've almost come to the conclusion that we can't really support multiple direct maps. I don't strictly disagree, because we're really shoehorning the automount map files structure into LDAP in a weird way. Do we have any estimate if multiple direct maps are commonly used in production, though? This feature was added into autofs in version 5, maybe the maintainer would know..
Sorry, replying to self..
Actually the more interesting question would be - if someone uses multiple direct maps, then why?
The only reason I can think about right now would be having one direct map managed centrally by the means of puppet of cfengine and the second being specific to the machine. I think this usecase is moot in LDAP environment where the local override would still be a flat file and automount would fetch info from both files and LDAP.
Yes, that is my thinking as well. I wanted to support separate direct maps to make importing easier, so you could verify that things imported as you expected. What we can do on the import side is just add all direct maps, regardless of name, to auto.direct.
Replying to [comment:5 rcritten]:
Sounds like a plan to me -- that way we wouldn't lose any of the maps. Export wouldn't be 1:1 but I think it is good enough.
Any ideas how we are going to deal with migration of the existing direct maps?
Replying to [comment:7 dpal]:
I think we could merge them into auto.direct (or whatever the name of the new default direct map would be).
attachment freeipa-rcrit-788-automount.patch
Adam please review and test UI to see if it is not broken.
master: bee4e6a
Metadata Update from @rcritten: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.1 - 2011/06
Login to comment on this ticket.