Default auto.master

[benkevan]

The default /etc/auto.master differs between several supported OSs. Therefore the users experience is different without an option to make the config alike across all.

By default it'd be nice to have the following:
/misc /etc/auto.misc
/net -hosts
+dir:/etc/auto.master.d
+auto.master

Maybe the capability is already there. I haven't looked at the code yet, just reviewed README

[dhollinger]

The default auto.master files are not included. this is primarily because mist use cases I've seen require a wholesale replacement of the default auto.master.

We could include a parameter that will use a different template that contains the default settings if necessary.

[benkevan]

That's be best because by default on some systems /etc/master.d isn't sourced either (Suse for example). Control of just the 3 optional parameters which are within default auto.master would provide great control of what the module should achieve across all systems and ensure the behavior is alike across all systems.

…

On Sat, Mar 4, 2017 at 7:21 AM David Hollinger III ***@***.***> wrote: The default auto.master files are not included. this is primarily because mist use cases I've seen require a wholesale replacement of the default auto.master. We could include a parameter that will use a different template that contains the default settings if necessary. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUr8eu0UjQ5f5A1Sdf3VJ8ubwOCUXm_ks5riYFdgaJpZM4MS_2d> .

[dhollinger]

Are you saying that the version of autofs on Suse doesn't allow for sourcing of a master.d directory or that it's simply not the default? (NOTE: This module does not source any /etc/auto.master.d by default, that has to be set).

I'm trying to make sure I understand before going through a lot of work to add some defaults. The goal with this module is to make configuring autofs as simple and universal across OSes as possible. Currently, anything applied by this module will replace all defaults.

If autofs functionality isn't changed between OSes, then the current module defaults won't matter as autofs will know what to do.

As for those default settings, I would like more information as to why those need to be persisted before putting what could potentially be a lot of work for minimal gains. Why not just add those to your profile/hieradata if you need them to persist?

Any other thoughts?

[benkevan]

In SLES the directive to include auto.master.d isn't enabled by default within auto.master.. neither are the directives for /net or /misc. Therefor anything created within auto.master.d won't be externally sourced. Nor would someone the behaviors across systems be the same. I found this by trying to do a net install from /net which failed on SUSE because the default /net rule wasn't in place.

…

On Mon, Mar 6, 2017 at 7:26 AM David Hollinger III ***@***.***> wrote: Are you saying that the version of autofs on Suse doesn't allow for sourcing of a master.d directory or that it's simply not the default? (NOTE: This module does not source any /etc/auto.master.d by default, that has to be set). I'm trying to make sure I understand before going through a lot of work to add some defaults. The goal with this module is to make configuring autofs as simple and universal across OSes as possible. Currently, anything applied by this module will replace all defaults. If autofs functionality isn't changed between OSes, then the current module defaults won't matter as autofs will know what to do. As for those default settings, I would like more information as to why those need to be persisted before putting what could potentially be a lot of work for minimal gains. Why not just add those to your profile/hieradata if you need them to persist? Any other thoughts? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUr8WNStnRFDxvEPxeHUzPsqpFDJJ_Yks5rjCWogaJpZM4MS_2d> .

[dhollinger]

Ok, in that case, as long as you don't specify use_dir => true or use_dir: true in the code or hieradata respectively, it won't even try to source the auto.master.d directory. Unless I'm missing something.

We could add some logic to the defined type to force use_dir to false when SLES or SUSE are being used, but even that may be a little overboard.

[dhollinger]

@benkevan Did my last comment make sense or does it not solve the issue?

[benkevan]

I'll give it a whirl. That does make some sense, but overall the default behavior is much different because /net, /misc and the master.d aren't sourced. It'd be nice to have the same auto.master across all systems. So behavior is always alike.

…

On Sun, Mar 26, 2017 at 1:57 PM David Hollinger III < ***@***.***> wrote: @benkevan <https://github.com/benkevan> Did my last comment make sense or does it not solve the issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUr8eCHu8Pym35wpoFsuy0nHiB3QIDiks5rpsL_gaJpZM4MS_2d> .

[mterzo]

I'm trying to do something similar:

I'm using this hiera content:

classes:
  - autofs

autofs::mounts:
  net:
    mount: /net
    order: 1
    mapfile: /etc/auto.net
    options: -hosts
    use_dir: false

I tried leaving out the mapfile, but now that type has an issue when it's left blank.

parameter 'mapfile' expects a match for Variant[Stdlib::Windowspath = Pattern[/^(([a-zA-Z]:[\\\/])|([\\\/][\\\/][^\\\/]+[\\\/][^\\\/]+)|([\\\/][\\\/]\?[\\\/][^\\\/]+))/], Stdlib::Unixpath = Pattern[/^\/([^\/\0]+\/*)+$/]], got '' at /etc/puppetlabs/code/environments/production/modules/autofs/manifests/init.pp:81

You put code to handle that originally:

  if $mapfile != '' {
    $contents = "${mount} ${mapfile} ${options}\n"
  } else {
    $contents = "${mount} ${options}\n"
  }

But this code will never get executed.

[clevelas]

I am needing the ability to add +auto.master to my auto_master. The use case if we get most of our automounts from LDAP. But for some machines, we have a need to specify additional custom mounts.

[dhollinger]

@clevelas With the way the code is setup, you can use node definitions or hieradata to dynamically set those per-machine configurations.

[dhollinger]

Closing due to age and I believe this was addressed