On Sun, May 26, 2013 at 09:40:03PM +0200, Sigbjorn Lie wrote:
> I did some testing on this. I added an entry to "cn=Schema
> Compatibility, cn=plugins, cn=config", and defined the various
> settings for the compat plugin. It worked as a charm, the requested
> automountmaps we're mirrored. However, one glitch when I attempt to
> actually use it. Setting "schema-compat-container-group" to
> cn=default hides all the existing keys in automount location
> default. Setting it to a level below the cn=default, and the
> automounter does not see the entries with the error below. It seem
> like the automounter can only handle a single level of a tree, and
> does not search subtrees.
> "get_query_dn: lookup(ldap): failed to find query dn under search base dns"
Were there any messages preceding that one? I'm looking at the sources
and there are a couple of code paths that would get to the point where
that message is logged, and I only ever see the plugin searching using
scope "subtree", so I can't be sure what's causing it to not find the
> I don't think the flatten trees does any harm, it's already flat, as
> long as the container-group could be set to cn=default,cn=automount.
> However it would require logic within the IPA framework to follow
> any "automountinformation=-fstype=autofs auto_anothermapname" and
> also create setup for the additional "auto_anothermapname" in the
> compat plugin. And again the idea seem flawed when the additional
> maps cannot sit under the same schema-compat-container-group.
> Is there any way to have several entries in the schema compatibility
> plugin to share the same level of schema-compat-container-group?
Not without at least some changes to its internals, I'm afraid. It's
basically reusing the same internal representation that's used for NIS
maps and NIS domains, and the one-configuration-entry-per-map
relationship is what triggers the module's housekeeping when a config
entry is added or removed. But I think it could be done.
Freeipa-users mailing list