Thanks Jakub, I'll submit a patch.

On Tue, May 21, 2013 at 2:24 AM, Jakub Hrozek <> wrote:
On Mon, May 20, 2013 at 09:12:37PM -0700, C. S. wrote:
> Hi folks,
> We have two auto.master maps: auto_master_a and auto_master_b. The reason
> for this is that it allows us to maintain the same paths at different
> campuses and redirect them to local filers vs. traversing a WAN link.
> In sssd I don't see an option to change the auto.master map name however,
> the cache expiring code seems to be hard coded to the string "auto.master".
> Looking at the code briefly I'm also not quite sure what the best way to
> add an ldap_autofs_master_map_name option would be, since it doesn't look
> like the configuration contexts are available in the provider and be code.
> Any suggestions appreciated.
> Thanks!
> cs


I'm afraid the auto.master name is currently hardcoded. When we were
designing the automounter integration with the autofs maintainer, we
decided that it's not really worth it because there seemed to be nobody
using that option (then). Even now I think it falls into a
"nice-to-have-patches-welcome" bucket.

If you wanted to take a look into that one, below is a summary of what
would need to be done, feel free to ping us on #sssd or ask again here
or the devel list.

If it was enough for you to have the alias on the ldap side and let the
automounter deamon still request auto.master (which I think would be
nice to keep all the other map sources working), then adding the option
amounts to all the places the options are tracked at, in this case
primarily to struct rfc2307_autofs_mobject_map and struct
rfc2307bis_autofs_entry_map in src/providers/ldap/ldap_opts.h. The
upstream commit fae99bfe4bfc8b4a12e9c2a0ad01b3684c22f934 is a nice and
easy one that adds a new option, maybe that could get you started.

Then the check for map invalidation would have to be moved from
be_autofs_handler() to sdap_autofs_handler() and use the value of the
new option instead of the hardcoded one using dp_opt_get_string. Any new
provider would have to use its own similar option in the future (which
is not a big deal I think, currently all existing identity providers are
sssd-users mailing list