I have a module that relies on mapfile_manage because the actual mapfile is link to a binary file.
https://github.com/treydock/puppet-osg/blob/master/manifests/cvmfs/config.pp#L13-L18

# file /etc/auto.cvmfs 
/etc/auto.cvmfs: symbolic link to `/usr/libexec/cvmfs/auto.cvmfs'
# file /usr/libexec/cvmfs/auto.cvmfs 
/usr/libexec/cvmfs/auto.cvmfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=032b54252652ba5c4fd2202e500a8ce44985249a, not stripped

I use autofs::mount to ensure that /etc/auto.master gets the necessary line in addition to my other autofs managed mounts for things like home directories.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet:
• Ruby:
• Distribution:
• Module version:

How to reproduce (e.g Puppet code you use)

What are you seeing

Hello, what I am asking is not an issue. I am testing how to add NIS/LDAP maps:
To add the following two lines in /etc/auto.master:
/nethome ldap:nisMapName=auto.nethome,dc=mydom,dc=com
/net yp:auto.net

I use :
include autofs
autofs::mount { 'add_nis_map':
ensure => 'present',
mount => '/net',
mapfile => 'yp:auto.net',
}
autofs::mount { 'ldap_map':
ensure => 'present',
mount => '/nethome',
mapfile => 'ldap:nisMapName=auto.nethome,dc=mydom,dc=com',
}

It is working well.

But if I want to add just one line '+auto.master' in /etc/auto.master is not possible. Do you plan to add this possibility in the future or not?

Thanks

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

There's an inconsistancy with

autofs::mount using the plural parameter mapcontents and autofs::map using the singular mapcontent
for the same array of lines in the map file.

Changing the new autofs::map parameter probably makse sense.

Am happy about the changes overnight and happy to do this but after the other two MR are processed.

The one thing this module doesn't have the capability of doing is managing the main autofs configuration file (/etc/sysconfig/autofs on RedHat-based systems, /etc/default/autofs on Debian-based systems).

This will be an optional feature initially and then will later be updated to manage those default values provided by the OS packages.

Testing for all supported OSes will be necessary.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4.0
• Ruby: 2.1
• Distribution: RedHat 7.4
• Module version: 4.3.0

How to reproduce (e.g Puppet code you use)

Pursuant to the current examples and defined-type detail documentation in README.md, I declared

autofs::map { 'test':
  map => '/etc/test.auto',
  mapcontents => ['test defaults test.my.com:/test']
}

What are you seeing

Catalog compilation fails with two errors:

Evaluation Error: Error while evaluating a Resource Statement, Autofs::Map[test]:
  has no parameter named 'map'
  parameter 'mapfile' expects a Stdlib::Absolutepath = Variant[Stdlib::Windowspath = Pattern[/^(([a-zA-Z]:[\\\/])|([\\\/][\\\/][^\\\/]+[\\\/][^\\\/]+)|([\\\/][\\\/]\?[\\\/][^\\\/]+))/], Stdlib::Unixpath = Pattern[/^\/([^\/\0]+\/*)*$/]] value, got String

What behaviour did you expect instead

Catalog compilation should succeed, and the resulting catalog should manage an indirect automount map in file /etc/test.auto.

Output log

The failure can be made to occur in RSpec tests, producing this output:

failed: rspec: ./spec/classes/test_spec.rb:8: error during compilation: Evaluation Error: Error while evaluating a Resource Statement, Autofs::Map[test]:
  has no parameter named 'map'
  parameter 'mapfile' expects a Stdlib::Absolutepath = Variant[Stdlib::Windowspath = Pattern[/^(([a-zA-Z]:[\\\/])|([\\\/][\\\/][^\\\/]+[\\\/][^\\\/]+)|([\\\/][\\\/]\?[\\\/][^\\\/]+))/], Stdlib::Unixpath = Pattern[/^\/([^\/\0]+\/*)*$/]] value, got String (file: /home/whitegrp/jbolling/puppet-clone/code/environments/production/modules/sb/spec/fixtures/modules/sb/manifests/test.pp, line: 10) on node svlpsbpuppet01.stjude.org
  sb::test on redhat-7-x86_64 should compile into a catalogue without dependency cycles
  Failure/Error:
        let(:facts) { os_facts }
  
        it { is_expected.to compile }
      end
    end

Any additional information you'd like to impart

Notwithstanding the module documentation to the contrary (defined type detail documentation and multiple examples), the actual name of the autofs::map parameter in question is 'mapfile', not 'map'. Changing the parameter name accordingly resolves the catalog compilation error.

I was wondering if you could also give the "Multiple mappings in the same file" example shown via Heira data? Im sure its something I am doing incorrectly, but I keep running into an error of key "" not found in map source(s) as soon as I try to put the data into multiple files.

Thanks

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4.0
• Ruby: 2.1
• Distribution: RedHat Enterprise Linux 7.4
• Module version: 4.3.0, 4.3.1-rc0

How to reproduce (e.g Puppet code you use)

include '::autofs'
autofs::map { 'test':
  mapfile     => '/tmp/test',
  mapcontents => 'example -ro example.com:/export/test'
}

The same problem can be triggered by specifying map contents on an autofs::mount, too.

What are you seeing

Catalog compilation fails.

What behaviour did you expect instead

Catalog compilation should succeed, treating the map contents string the same as an array with that string as its only element.

Output log

Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Failed to parse template autofs/auto.map.erb:
Filepath: /home/jbolling/.puppetlabs/etc/code/modules/autofs/templates/auto.map.erb
Line: 17
Detail: undefined method `each' for "test -ro example.com:/export/test":String
(file: /home/jbolling/.puppetlabs/etc/code/modules/autofs/manifests/map.pp, line: 66, column: 18) (file: /home/jbolling/tmp/str_err.pp, line: 3) on node random.stjude.org

Any additional information you'd like to impart

The module documentation and the data type declarations in autofs::map and autofs::mount both permit the map contents to be expressed as a bare string, but the template for map contents assumes it will be an array.

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

$key in autofs/manifests/mapping.pp and autofs/types/fs_mapping.pp should allow a space character.
Current pattern Pattern[/\A\S+\z/] does not allow offeset directories or directories with a space in the name. Proposed new pattern: Pattern[/\A\S+.*\z/]

From autofs docs:
centos autofs docs

mount-point options location
where:
mount-point is the autofs mount point. This can be a single directory name for an indirect mount or the full path of the mount point for direct mounts. Each direct and indirect map entry key (mount-point above) may be followed by a space separated list of offset directories (sub directory names each beginning with a "/") making them what is known as a mutli-mount entry.

Sample code:

autofs::mapfile {
    '/mnt/example':
        path     => '/etc/auto.example',
        mappings => [
            { 'key' => "example /Company\\ Home", 'options' => 'rw,soft,intr', 'fs' => 'server.example.com:/shares' }
        ]
}

Add a fact that tracts the installed version of autofs.

On a new install of CentOS 7.3.1611 I get the below error using your example for just a simple home setup. It works on Ubuntu but not RedHat/CentOS. I think the module is good cause it gives flexibility with using a define type and adding additional mounts.

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Invalid relationship: Concat[/etc/auto.master] { notify => Service[autofs] }, because Service[autofs] doesn't seem to be in the catalog.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet:
• Ruby:
• Distribution:
• Module version:

How to reproduce (e.g Puppet code you use)

autofs::mount { 'home':
mount => '/home',
mapfile => '/etc/auto.home',
mapcontents => ['* -fstype=nfs nfs_server:/path/to/home/shares'],
options => '--timeout=120',
order => 01
}

What are you seeing

autofs does not install no files get configured.

What behaviour did you expect instead

Should work just like Ubuntu.

Output log

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Invalid relationship: Concat[/etc/auto.master] { notify => Service[autofs] }, because Service[autofs] doesn't seem to be in the catalog.

Any additional information you'd like to impart

Remove deprecated and unused autofs::mounts class

It'd be nice to have the /etc/auto. file auto-named based on the name of the defined type, "mount."

autofs::mount { 'home':
mount => '/home',
mapfile => '/etc/auto.home',
mapcontents => ['* netapp.example.com//home/&'],
}

Since the name of the defined type in this instance is 'home' and the mapfile is '/etc/auto.home', it makes sense that leaving out $mapfile should imply that the $name of the defined type is also the name of the /etc/auto. file.

Leaving out $mapfile when instantiating the defined type just leaves out the file in /etc/auto.master.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4.0
• Ruby: 2.1
• Distribution: RedHat Enterprise Linux 7.4
• Module version: 4.3.0, 4.3.1rc0

How to reproduce (e.g Puppet code you use)

This is a generalization of issue #104. The underlying problem is that the module relies on autofs::map to declare an appropriate Concat resource for its map file, which it does indirectly by means of ensure_resource() in an attempt to avoid duplicate resource declarations when multiple autofs::map resources target the same map file. But this strategy is only partially effective: it works only as long as all autofs::map resources contributing to the same map file pass identical parameter lists to ensure_resource().

The example in issue #104 demonstrates this problem, and so does this:

autofs::map { 'foo':
  mapfile => '/etc/auto.test',
  replace => false,
}

autofs::map { 'bar':
  mapfile => '/etc/auto.test',
  mapcontents => ['bar -rw example.com:/export/bar'],
}

(That can also be rewritten to avoid the using the undocumented $autofs::map::replace parameter directly by using an autofs::mount resource with $replace => false in place of Autofs::Map[foo].)

What are you seeing

Catalog compilation fails with a duplicate resource declaration error.

What behaviour did you expect instead

Either catalog compilation should succeed, somehow merging map file properties from multiple autofs::map declarations, or it should fail with a user-actionable error message (i.e. one describing a problem with the resources declared explicitly, not those declared internally by the module).

But really, the module design ought not to allow the problem to arise in the first place. Or at bare minimum, the module documentation should present the relevant usage constraints.

Output log

Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Duplicate declaration: Concat[/etc/auto.test] is already declared at (file: /home/jbolling/.puppetlabs/etc/code/modules/autofs/manifests/map.pp, line: 54); cannot redeclare (file: /home/jbolling/.puppetlabs/etc/code/modules/autofs/manifests/map.pp, line: 54) (file: /home/jbolling/.puppetlabs/etc/code/modules/autofs/manifests/map.pp, line: 54, column: 3) (file: /home/jbolling/tmp/map_err.pp, line: 7) on node xxx.yyy.org

Any additional information you'd like to impart

I account the issue to a design flaw: defined type autofs::map is trying to do too many things. It represents a chunk of contents of a map file, and with the possibility of multiple resources of that type contributing to the same map file, it is too much for autofs::map to have overall responsibility for the map file itself. That ought to be the job of autofs::mount.

Making autofs::mount responsible for the overall map file (via that file's master Concat resource) would mean that one could not use autofs::map without autofs::mount (or equivalent data), but that's already halfway the case. Without an autofs::mount to manage an appropriate entry in the master map (leaving aside the map file for a moment) the use cases for managing map files are relatively few. And these could be addressed by giving autofs::mount the capability of managing only the specified map file, leaving the master map alone.

On the other hand, Autofs does not require every mount point to have a distinct map file, though it's unclear how useful it is for different mount points to share, or how common it is for them to do so. This module can accommodate mapfile sharing as-is, but it would make for a cleaner separation of concerns to add a separate resource to manage map files.

Point the Forge Project URL at the yardoc-based Module Documentation site hosted in Vox Pupuli's Github pages space.

This Documentation will contain the README contents, as well as, more detailed documentation on the classes, parameters, and defined types in the module.

Dear developers,

today I just wanted to remove an existing autofs::mount, but, there is no ensure => absent option available. The only workaround I found was to set mapcontents => [], but this doesn't remove the entry in auto.master and also the mapfile is not removed.

Would be possible to extend the module having in mind also the removal for already defined autofs::mount entries ?

Thank you
Dan

Autofs master maps support the following format for map references:

[maptype[,format]:]map

Autofs requires the map component to start with a / only for certain map types, and for other types it generally should not start with a /.

Puppet-autofs supports only a subset of that pattern: it does not accept map specifications that include the optional format component, or for which the map component does not begin with a /, except for the -hosts map as a special case.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4.0
• Ruby: 2.1.9
• Distribution: RedHat Enterprise 7.4
• Module version: 4.3.0, 4.3.1-rc0

How to reproduce (e.g Puppet code you use)

include '::autofs'

autofs::mount { '/data':
  mapfile => 'file,sun:/etc/auto.data',
  mapfile_manage => false,  # required by the module when a map type is given
}

# this one comes directly from the Linux auto.master(5) manual page
autofs::mount { '/mnt':
  mapfile => 'yp:mnt.map',
  mapfile_manage => false,
}

What are you seeing

Catalog compilation fails on each example with a data type mismatch error.

What behaviour did you expect instead

Catalog compilation should succeed, and the master map should be managed to contain the entries described by the autofs::map resources presented.

Output log

Each example yields the following error from the catalog builder:

Evaluation Error: Error while evaluating a Resource Statement, Autofs::Mount[/mnt]: parameter 'mapfile' expects a value of type Undef, Stdlib::Absolutepath = Variant[Stdlib::Windowspath = Pattern[/^(([a-zA-Z]:[\/])|([\/][\/][^\\\/]+[\/][^\\\/]+)|([\/][\/]?[\/][^\\\/]+))/], Stdlib::Unixpath = Pattern[/^/([^\/\0]+/)$/]], or Autofs::Mapentry = Pattern[/^[a-z]+(,[a-z]+)?:/([^\/\0]+(/)?)+$|^-hosts$/], got String (line: 3) on node random.stjude.org

Any additional information you'd like to impart

A pull request resolving this issue will be forthcoming shortly.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.9.4
• Ruby: 2.3.1
• Distribution: ubuntu
• Module version: 3.0.1

How to reproduce (e.g Puppet code you use)

    ::autofs::mount { "share":
        mount => "/share",
        mapcontents => ["files -fstype=nfs4,ro,hard,intr,nosuid,exec hostname:/share/files"],
        options => "--timeout=600",
        order => 50
      }

What are you seeing

I'm seeing one of these puppet warning for every puppet resource I have, which is making the puppet apply logs unreadable.

Warning: This method is deprecated, please use match expressions with Stdlib::Compat::Bool instead. They are described at https://docs.puppet.com/puppet/latest/reference/lang_data_type.html#match-expressions. at ["/tmp/puppet-deploy/manifests/.modules-contrib/concat/manifests/init.pp", 82]:
(at /tmp/puppet-deploy/manifests/.modules-contrib/stdlib/lib/puppet/functions/deprecation.rb:25:in `deprecation')

What behaviour did you expect instead

No warnings. As much flexibility as possible for puppetlabs/concat dependency version.

Output log

Any additional information you'd like to impart

puppet/autofs declares a dependency on puppetlabs/concat 2.x:

...which means I am using puppetlabs/concat 2.2.1 - the latest 2.x release. It looks like the above warnings from puppetlabs/concat might be fixed by puppetlabs/concat 3.x or 4.x. Is is possible for puppet-autofs to allow use a wider range of puppetlabs/concat versions?

The Puppet version range limits maximum puppet compatibility to Puppet 4.x and lower. Metadata.json needs to be updated to make the module Puppet 5 compatible (from a puppet module tool standpoint)

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.9.3
• Ruby: ruby 2.1.9p490 (2016-03-30 revision 54437) [x86_64-linux]
• Distribution: Oracle Linux 7.2
• Module version: 2.1.0

How to reproduce (e.g Puppet code you use)

Add the following to your manifest (per the README):

class { 'autofs':
  service_enable => false,
  service_ensure => 'stopped'
}

What are you seeing

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while eva
luating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Class[Autofs]:
  has no parameter named 'service_enable'
  has no parameter named 'service_ensure' at /etc/puppetlabs/code/environments/dsee/dist/profile/manifests/orabase.pp:147:
3 on node build.example.com

What behaviour did you expect instead

I expected it to disable the service and ensure it is not running

Output log

Any additional information you'd like to impart

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4.0
• Ruby: 2.1
• Distribution: RedHat Enterprise Linux 7.4
• Module version: Current HEAD of the git master branch (commit 4dac54d)

How to reproduce (e.g Puppet code you use)

class { 'autofs': }
autofs::mount { 'data':
  mount   => '/mnt/data',
  mapfile => '/etc/auto.data',
  execute => true,  # this is the key attribute
}
autofs::map { 'datamapA':
  mapfile     => '/etc/auto.data',
  mapcontents => [ 'dataA -o rw /mnt/dataA', 'dataB -o rw /mnt/dataB' ],
}

What are you seeing

Catalog building fails with a duplicate resource error.

What behaviour did you expect instead

The catalog should be successfully built and applied.

Output log

Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Duplicate declaration: Concat[/etc/auto.data] is already declared in file /opt/puppetlabs/puppet/modules/autofs/manifests/map.pp:54; cannot redeclare at /opt/puppetlabs/puppet/modules/autofs/manifests/map.pp:54 at /opt/puppetlabs/puppet/modules/autofs/manifests/map.pp:54:3 at /opt/puppetlabs/puppet/modules/autofs/manifests/mount.pp:161 on node centos-7-x64.xxx.yyy

Any additional information you'd like to impart

If the execute => true attribute is not declared on Autofs::Mount[data] then the catalog compiles successfully and is applied with the expected result (I have a Beaker acceptance test demonstrating both the success case and the failure case).

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4
• Ruby: 2.1
• Distribution: RedHat 7.4
• Module version: 4.3.0

How to reproduce (e.g Puppet code you use)

The issue revolves around defining the contents of a single map file via multiple autofs::map resources. This is a useful thing to do, because it allows the mapfile definition to be distributed among different classes, and it already works. But the current module implementation emits a warning banner into the target map file for each contributing autofs::map resource, instead of just one banner at the top of the file.

You don't even need to weigh the merits of distributed map file definitions, because the issue can be reproduced by applying a catalog built from as little as this:

include '::autofs'

autofs::mount { 'test':
  ensure  => 'present',
  mount   => '/mnt/test',
  mapfile => '/etc/test.auto'
}

autofs::map { 'test1':
  mapfile     => '/etc/test.auto',
  mapcontents => ['test1 -rw test.example.com:/export/test1']
}

(There is a workaround for that particular case, however.)

What are you seeing

In the example manifest above, the autofs::mount declares an autofs::map with the (default; empty) mapcontents that is declared directly on the autofs::mount, so there are two autofs::map resources contributing to /etc/test.auto. Result:

###############################################################
#                                                             #
# THIS FILE IS MANAGED BY PUPPET. ANY CHANGES MADE TO THIS    #
#   FILE WILL BE REVERTED BACK ON THE NEXT PUPPET RUN.        #
#                                                             #
###############################################################

###############################################################
#                                                             #
# THIS FILE IS MANAGED BY PUPPET. ANY CHANGES MADE TO THIS    #
#   FILE WILL BE REVERTED BACK ON THE NEXT PUPPET RUN.        #
#                                                             #
###############################################################

test1 -rw test.example.com:/export/test1

If there were more contributing autofs::map resources, there would be an additional banner for each.

The extra banners do not invalidate the map file, of course, but they do make it needlessly hard for a human to read. It gets worse when there are more autofs::map resources, so that the actual mappings are sandwiched between banners.

What behaviour did you expect instead

The banner ought to be presented only once, at the top of the map file, no matter how many autofs::map resources contribute to it:

###############################################################
#                                                             #
# THIS FILE IS MANAGED BY PUPPET. ANY CHANGES MADE TO THIS    #
#   FILE WILL BE REVERTED BACK ON THE NEXT PUPPET RUN.        #
#                                                             #
###############################################################

test1 -rw test.example.com:/export/test1

Output log

(irrelevant)

Any additional information you'd like to impart

It looks like this should be easy to fix. The concat resource type has a warn parameter that serves exactly the purpose of presenting a warning banner, and it can be used to present a customized banner. This (autofs) module does not use that, but it probably should. Instead, it puts the banner -- a selection between two alternatives, in fact -- in the per-autofs::map templates. Even if it were for some reason undesirable to use $autofs::warn for this purpose, the problem could also be solved by putting the banner in its own concat::fragment, and ensuring that that fragment comes first.

Support for Darwin is quite simple to add IMHO.

What am I doing wrong here?

#autofs
autofs::mounts:
'home':
mountpoint: '/mnt/nov'
remote: '10.x.x.x:/nov'
options: '-rw,intr,timeo=20'

This is configured in a node yaml file for that particular node. The puppet run recognizes the change but it does not implement it. Previously configured node has similar settings except the mount point and the remote server ip is different. If I run 'mount' command directly on the server, it works.
Puppet 2016.4.3

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.4.0
• Ruby: 2.1
• Distribution: RedHat Enterprise Linux 7.4
• Module version: 4.3.0, 4.3.1-rc0

How to reproduce (e.g Puppet code you use)

include '::autofs'
autofs::mount { 'test':
  mount   => '/mnt/tmp',
  mapfile => '/etc/auto.tmp',
  execute => true,
  use_dir => true,
}

What are you seeing

The module creates an executable file (mode 0755) in the map directory.

What behaviour did you expect instead

The module should create a non-executable file (mode 0644) in the map directory.

Output log

Any additional information you'd like to impart

The files dropped in the map directory (e.g. /etc/auto.master.d) are always interpreted as containing extra content for the master map. They are never executed, and therefore do not need to be executable, notwithstanding whether any map file for which they contain a mapping is executable.

It currently doesn't work but isn't listed as being supported either. Please add support for RHEL 8.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.5.3
• Ruby: 2.4.4
• Distribution: EL7
• Module version: 5.0.0

How to reproduce (e.g Puppet code you use)

autofs::mount { 'title':
  attribute => value,
}

What are you seeing

failed: rspec: ./spec/classes/init_spec.rb:8: error during compilation: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Unknown variable: 'autofs::auto_master_map'. (file: /spec/fixtures/modules/autofs/manifests/mount.pp, line: 66, column: 45)

What behaviour did you expect instead

clean

Output log

n/a

Any additional information you'd like to impart

This is with PDK 1.7.0 and I am assuming because of https://github.com/voxpupuli/puppet-autofs/blob/master/manifests/mount.pp#L70 and https://github.com/voxpupuli/puppet-autofs/blob/master/manifests/init.pp#L92 that this is a bug with something within PDK, because this error should really not be occurring. I need confirmation that this is not really an issue with this module though. Then I can move forward with this being a bug with PDK and/or its required software.

Change data type from String to Stdlib::Absolutepath:

• master
• map_dir
• mapfile
• mount

Mark any Optional parameters as such with the Optional data type.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet:
• Ruby:
• Distribution:
• Module version:

How to reproduce (e.g Puppet code you use)

What are you seeing

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.3.4
• Ruby: AIO
• Distribution: AIX
• Module version: 4.2.0

I would like to add AIX support. As part of this, we will add module level hieradata.

In attempt to make the code more readable and simplify user interaction with the module, the autofs::package and autofs::service classes will be made private classes.

Controlling settings within those classes will be done via parameters set in the init class.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.4.2
• Ruby: 2.3.1
• Distribution: ubuntu
• Module version: 3.0.1

How to reproduce (e.g Puppet code you use)

      ::autofs::mount { "share":
        mount => "/share",
        mapcontents => ["files -fstype=nfs4,ro,hard,intr,nosuid,exec hostname:/share/files"],
        options => "--timeout=600",
        order => 50
      }

What are you seeing

Error: Evaluation Error: Error while evaluating a Resource Statement, Autofs::Mount[share]:
  parameter 'map_dir' expects a Resource value, got String
  parameter 'master' expects a Resource value, got String
  parameter 'mount' expects a Resource value, got String

What behaviour did you expect instead

No errors.

Output log

Any additional information you'd like to impart

It looks like this is caused by puppet/stdlib module's version. Was using puppet/stdlib version 4.9.0. The problem went away when I upgraded it to version 4.16.0. If don't want to change the module to avoid this, looks like the dependency's version_requirement in

Tracking progress for migration to VoxPupuli

• Ask one of the Administrators to add you to the modules/admin team.
• At that point you can transfer your own repository
• If migrating a module from puppetlabs, re-enable github issues.
• Verify that all webhooks except travis are disabled.
• Update the README.md with a description of the deprecation and a link to the new module location.
• Release a 999.999.999 version of the original module to the forge, so users and tools knows to stop using it.
• Release a copy of your module to the ‘puppet’ forge account.
• Add the module to our modulesync setup
• Add the module to our plumbing repository(handles travis secrets)
• Ask one of the Admins to add the module to the collaborators Team on github.
• Resubmit to Puppet JIRA for review and move "Approved" badge to new namespace

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10.4
• Ruby: 2.3.3
• Distribution: Debian 9
• Module version: 5.0.0

How to reproduce (e.g Puppet code you use)

hiera yaml example

autofs::mounts:
gmail:
mount: '/srv'
mapfile: '/etc/auto.master.d/auto.gmail'

autofs::mapfiles:
gmail:
path: '/etc/auto.master.d/auto.gmail'
mappings:
key: 'gmail'
options: 'rw,soft,intr,tcp,nfsvers=4,noacl'
fs: 'ld-sys-smb:/srv/gmail'

What are you seeing

puppet agent -t
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Autofs::Mapfile[gmail]: parameter 'mappings' expects an Array value, got Struct at /srv/puppet/env/production/modules/autofs/manifests/init.pp:111

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

The autofs::map defined type will completely replace the contents of the target concat file if the order parameter is not set. This is because the concat::fragment set within both autofs::mount and autofs::map default to 1, which will cause concat to replace the content in that location (in the case of autofs::map it will replace the entire array that was laid down in autofs::mount).

My suggestion to @traylenator is that autofs::map should be a wholly separate defined type that does not interact with anything laid down by autofs::mount, otherwise we end up with redundant code and functionality.

If the concern is adding additional lines to an existing file, updating the array in the code or, better yet, in the hieradata is the appropriate place to do so.

If the concern is the ability to manage a mapfile outside of the autofs::mount block, then let's make the autofs::map file a completely separate define type meant to be called standalone.

Additionally, we could completely remove mapfile concat code in autofs::mount and instead have autofs::mount call autofs::map

Adding promised capabilities to be able to manage package ensure and service ensure/enable/hasstatus/hasrestart from the main init class.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.8.1
• Ruby: ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
• Distribution: El Capitan
• Module version: 3.0.1, 3.0.2 and presumably 3.0.0

How to reproduce (e.g Puppet code you use)

Run puppet apply with any puppet manifests. Don't need to be using autofs resources, just need to have puppet/autofs in your Puppetfile (and have done a pluginsync).

What are you seeing

 DEBUG [71b964ab] 	Debug: Facter: searching for custom facts in /opt/puppetlabs/puppet/cache/lib/facter.
 DEBUG [71b964ab] 	Debug: Facter: fact "agent_specified_environment" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "apt_has_updates" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "apt_package_updates" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "apt_reboot_required" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "apt_security_updates" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "apt_update_last_success" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "apt_updates" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: fact "archive_windir" resolved to null and will not be added.
 DEBUG [71b964ab] 	Debug: Facter: executing command: /bin/sh -c /usr/sbin/automount -V 2>&1
 DEBUG [71b964ab] 	Debug: Facter: /usr/sbin/automount: illegal option -- V
 DEBUG [71b964ab] 	Debug: Facter: process exited with status code 1.
 DEBUG [71b964ab] 	Debug: Facter: process exited with status code 1.
 DEBUG [71b964ab] 	Error: Facter: error while resolving custom fact "autofs_version": undefined method `[]' for nil:NilClass

What behaviour did you expect instead

No crash, and autofs_version fact returning something like nil or empty string.

Output log

Any additional information you'd like to impart

This new autofs_version fact was added in this PR:

#33

Would be handy to cut a new release that includes the updates to metadata.json so that modules depending on autofs can also depend on newer stdlib and concat.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.23.0
• Ruby: 2.5.9
• Distribution: RHEL
• Module version: 6.0.0

puppet-autofs depends on puppetlabs-concat < 6.0.0. But all versions of puppetlabs-concat below 7.0.1 depend on puppetlabs-translate which has been deprecated and is not available on the forge anymore.

I want to use the special -hosts map in autofs. Something like

/net -hosts

in auto.master. The puppet code to get this would be

  autofs::mount{'auto.NET':
    mount          => '/net',
    mapfile_manage => false,
    mapfile        => '-hosts',
  }

Currently the type Autofs::Mapentry doesn't allow -hosts, a simple addition to the regexp could fix this:

# type Autofs::Mapentry = Pattern[/^[a-z]+:\/([^\/\0]+(\/)?)+$/]
type Autofs::Mapentry = Pattern[/^[a-z]+:\/([^\/\0]+(\/)?)+$|^-hosts$/]

-hosts is the only such special map, hence just adding the full string and no pattern to the regexp seems o.k..

Does this fit into the module and is the way to implement it o.k.? I'm not sure whether I can do all that's required to submit a pull request, I'm no developer, but I can do a start.

cheers,
Heiner Billich

$mount = hiera_hash('autofs::mounts', [])

$mount is passed to create_resources which takes a hash as its second argument, not an array.
I think the correct change isn't

$mount = hiera_hash('autofs::mounts', {})

but perhaps

$mount = hiera_hash('autofs::mounts', $::autofs::mounts)

In this way, the module would work for users who have passed a mounts hash to the base class explicitly as well as those using hiera.

There's also every chance I've just misread the code and this isn't a bug/issue at all! :)