Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.9
• Ruby: 2.3.1
• Distribution: Ubuntu 16.04.6 LTS
• Module version: 3.0.1

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

Using puppetserver 3.0.1

What are you seeing

The MIT keyserver is no longer working. The update is in master but has not been tagged yet, requiring users to fork or pin to master.

https://github.com/voxpupuli/puppet-puppetserver/blob/master/manifests/repository.pp#L32

What behaviour did you expect instead

The validation to work.

Output log

==> agent-xenial: --keyserver
==> agent-xenial: pgp.mit.edu
==> agent-xenial: --recv-keys
==> agent-xenial: 47B320EB4C7C375AA9DAE1A01054B7A24BD6EC30
==> agent-xenial: gpg: requesting key 4BD6EC30 from hkp server pgp.mit.edu
==> agent-xenial: gpgkeys: key 47B320EB4C7C375AA9DAE1A01054B7A24BD6EC30 can't be retrieved
==> agent-xenial: gpg: no valid OpenPGP data found.
==> agent-xenial: gpg: Total number processed: 0
==> agent-xenial: gpg: keyserver communications error: keyserver helper general error
==> agent-xenial: gpg: keyserver communications error: unknown pubkey algorithm
==> agent-xenial: gpg: keyserver receive failed: unknown pubkey algorithm```

## Any additional information you'd like to impart

this module once listed debian 7 in the metadata.json. We removed it because it's EOL. We need to check if recent debian versions work and add them back.

I would be nice to use this module with version 2.0 of puppet server.

Getting the flowing error:

Warning: Augeas[Set puppetserver config webserver.conf/webserver/port](provider=augeas): Loading failed for one or more files, see debug for /augeas//error output
Error: /Stage[main]/Puppetserver::Config/Puppetserver::Config::Helper[webserver/port]/Puppetserver::Config::Puppetserver[webserver.conf/webserver/port]/Augeas[Set puppetserver config webserver.conf/webserver/port]: Could not evaluate: Saving failed, see debug
Notice: /Stage[main]/Puppetserver::Service/Service[puppetserver]: Dependency Augeas[Set puppetserver config webserver.conf/webserver/port] has failures: true
Warning: /Stage[main]/Puppetserver::Service/Service[puppetserver]: Skipping because of failed dependencies
Notice: /Stage[main]/Puppetserver/Anchor[puppetserver::end]: Dependency Augeas[Set puppetserver config webserver.conf/webserver/port] has failures: true
Warning: /Stage[main]/Puppetserver/Anchor[puppetserver::end]: Skipping because of failed dependencies

Probability PR #8 will fix this?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5
• Ruby: 2.3
• Distribution:
• Module version: 3.0.0

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

Try to use repository class on 18.04

What are you seeing

Failing to run apt-get update as "main" is no longer in the puppet repo.

What behaviour did you expect instead

Package repo setup and working

Output log

Error: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install puppetdb-terminus' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package puppetdb-terminus
Error: /Stage[main]/Puppetdb::Master::Config/Package[puppetdb-terminus]/ensure: change from purged to present failed: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install puppetdb-terminus' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package puppetdb-terminus

Any additional information you'd like to impart

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: puppet-agent-5.3.4-1.el7.x86_64 & puppetserver-5.1.5-1.el7.noarch
• Ruby: 2.0.0
• Distribution: CentOS Linux release 7.4.1708 (Core)
• Module version: 3.0.0

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

use puppetserver 5.1.5

What are you seeing

$targetfile in puppetserver::config::bootstrap is set to '/etc/puppetlabs/puppetserver/bootstrap.cfg' in dependency of the puppet agent version.

What behaviour did you expect instead

puppetserver 5.1.5 is using '/etc/puppetlabs/puppetserver/services.d/ca.cfg' instead.
$targetfile should be choosen by dependency of the installed puppetserver version not the agent version.

Output log

no output, functionality is silently ignored when the file isn't existing

Any additional information you'd like to impart

workaround: create a symlink pointing to the new location.

The puppet agent version number is not conclusive to set puppetserver details.
If we don't have a fact for puppetserver version, $targetfile should become a parameter with the current default values. This way you could override the (now) outdated defaults.

Using the latest puppetserver, the auth.conf file can't be read or modified by the trapperkeeper lens. My knowledge of writing lens isn't great but I'm going to guess that this is due to the nested hashes inside the array rules.

Could not evaluate: Augeas didn't load /etc/puppetlabs/puppetserver/conf.d/auth.conf with Trapperkeeper.lns: Syntax error (line:3, character:10)

This is just using an unmodified auth.conf from the package.

rspec tests in spec/unit/puppet/provider/puppetserver_config/augeas_spec.rb are OK on my computer with Fedora 25 but fail with travis.

example:

1) Puppet::Type::Puppetserver_config::ProviderAugeas with empty file should create simple new entry
     Failure/Error: @logs.select { |log| loglevels.include? log.level and log.message !~ /'modulepath' as a setting/ }.should == []

       expected: []
            got: [Could not evaluate: Augeas didn't load /tmp/target20170118-2680-1txepk4 with Trapperkeeper.lns: ] (using ==)
       Diff:
       @@ -1,2 +1,2 @@
       -[]
       +[Could not evaluate: Augeas didn't load /tmp/target20170118-2680-1txepk4 with Trapperkeeper.lns: ]

     # ./spec/fixtures/modules/augeasproviders_core/spec/lib/augeas_spec/fixtures.rb:32:in `apply!'
     # ./spec/unit/puppet/provider/puppetserver_config/augeas_spec.rb:20:in `block (3 levels) in <top (required)>'

full output in travis: https://travis-ci.org/voxpupuli/puppet-puppetserver/jobs/193161617

maybe someone has an idea whats wrong and what to fix.

The tarball uploaded to the puppet forge is actually just a text file that says "HTTP/1.1 500 Internal Server Error". The release tarball on github is fine, though. But 'puppet module install ...' doesn't work, obviously.

The standard content of /etc/puppetserver/conf.d/web-routes.conf includes complex keys that are not currently supported by the lens. After some troubleshooting, I've narrowed down some use cases to the special case of using keys with "/" which needs to be double quoted.

Even though I don't change web-routes.conf, this results a warning for every configuration entry I make using this module.

test: {
  "x" : z
  "x/y" : z
}```

It would likely be better to just depend on https://forge.puppet.com/puppetlabs/puppetserver_gem instead of vendoring it or shipping our own version of it.

Although it would be hard to tell from the docs, the puppetserver class's provisions for managing puppetserver config files are very limited. Class parameter $puppetserver::config is the public gateway to what little it does provide, and contrary to initial appearances, that is limited to four Java arguments, two webserver.conf settings, and one puppetserver.conf setting.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: all
• Ruby: all
• Distribution: all
• Module version: 3.0.0

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

N/A

What are you seeing

The one parameter of class puppetserver, $puppetserver::config, lacks support for most puppetserver settings.

What behaviour did you expect instead

Every configuration setting recognized by puppetserver, in each of its configuration files, should be manageable by binding data to class puppetserver.

Output log

N/A

Any additional information you'd like to impart

The module provides defined type puppetserver::config::puppetserver by which it appears that any configuration setting can be managed, whether actually recognized by the puppetserver software or not. This provides for a workaround for the issue.

Overall, I don't care much for the approach implemented for $puppetserver::config, which basically sets up its own local vocabulary of structured setting names to be used with the module. This would be unnecessarily difficult to use even if the details were well documented, and they are not. It would be better for the data bound to class puppetserver for the purpose of managing configuration settings to map more directly onto the state to be managed: (relative) file name, section, setting, value. I'm sure the idea behind the current implementation was to make it easier to specify settings, but it is not easier for users to have to remember or look up two separate spaces of configuration names and the relationships between them than it would be to rely on just one.

See below for steps necessary to reproduce. The ruby-load-path should be formatted like """ruby-load-path: [/opt/puppetlabs/puppet/lib/ruby/vendor_ruby, /tmp]"""

[root@foo ~]# augtool -I /opt/puppetlabs/puppet/share/augeas/lenses/  -n set /files/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf/jruby-puppet/ruby-load-path/2 "/tmp"
Saved 1 file(s)
[root@foo ~]#
[root@foo ~]#
[root@foo ~]# diff -u /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf.augnew 
--- /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf   2015-06-15 11:20:46.737873717 -0400
+++ /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf.augnew    2015-06-15 14:41:29.743240989 -0400
@@ -2,7 +2,11 @@
 jruby-puppet: {
     # Where the puppet-agent dependency places puppet, facter, etc...
     # Puppet server expects to load Puppet from this location
-    ruby-load-path: [/opt/puppetlabs/puppet/lib/ruby/vendor_ruby]
+ruby-load-path:
+{
+1:/opt/puppetlabs/puppet/lib/ruby/vendor_ruby
+2:/tmp
+}

     # This setting determines where JRuby will look for gems.  It is also
     # used by the `puppetserver gem` command line tool.
@@ -47,6 +51,8 @@

 # Settings related to the puppet-admin HTTP API
 puppet-admin: {
-    client-whitelist: []
+client-whitelist:
+{
+}
 }

[root@foo ~]# 

What are you seeing

Currently, it's not possible to use the module to configure the JRUBY_JAR setting to use the newer 9k JRuby, meaning if you have a gem that requires Ruby > 2.1, you see errors like undefined method 'keep_alive_timeout=' for #<Net::HTTP..." (such as petems/petems-hiera_vault#5)

Affected Puppet, Ruby, OS and module versions/distributions

• Module version: Latest Commit (356e078)

Any additional information you'd like to impart

Current workaround is this quick ini_setting code, but to keep with the rest of the module we could use augeas:

ini_setting { "Change jruby to 9k":
    ensure  => present,
    setting => 'JRUBY_JAR',
    path    => "/etc/sysconfig/puppetserver",
    key_val_separator => '=',
    section => '',
    value   => '"/opt/puppetlabs/server/apps/puppetserver/jruby-9k.jar"',
    show_diff => true,
    notify  => Class['puppetserver::service']
  }

this module doesn't seem to be made to set any values in /etc/puppet/puppet.conf
@camptocamp's puppet-puppet doesn't seem to be made to work with this module :(

just managing the config with Ini_settings seems a bit off…

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.x
• Ruby: all
• Distribution: all
• Module version: 3.x

Description

The module metadata deny compatibility with Puppet 6. It's presently unclear to me what changes may be needed in practice, other than a metadata update, for the module to support that version, but if this module is to remain relevant (and not leave current users hanging) then they need to be performed.

Related: Issue #69

Hello,

Actually, only the "main" repository is configured, so we can't install a puppetserver 2.x

Is this addition to the "puppetserver::repository" class something we could include for debian ?

  if versioncmp($::puppetversion, '4.0.0') >= 0 {
    $targetrepo = 'PC1'
  } else {
    $targetrepo = 'main'
  }

(same thing for products for rhel)

Or maybe you got another idea that isn't just pushed yet ?
I can do a PR, but I wanted to know if it is the "good way" :)

Regards

Olivier

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.4.2
• Puppetserver: 6.8.0
• Ruby: 2.5.3p105
• Distribution: RHEL 7.7
• Module version: 3.0.1

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

class nc_puppetserver::puppetserver (
  String $version = '6.8.0',
  String $java_xms = '3g',
  String $java_xmx = '3g',
) {
  ensure_resource('file', '/usr/share/augeas/lenses/dist', {'ensure' => 'directory'})

  file { 'trapperkeeper_lens_link':
    ensure  => link,
    path    => '/usr/share/augeas/lenses/dist/trapperkeeper.aug',
    target  => '/opt/puppetlabs/puppet/share/augeas/lenses/trapperkeeper.aug',
    before  => Class['puppetserver'],
    require => File['/usr/share/augeas/lenses/dist'],
  }

  class { '::puppetserver':
    version       => $version,
    config        => deep_merge(
      'java_args' => {
        'xms' => $java_xms,
        'xmx' => $java_xmx,
      },
      'webserver' => {
        'ssl-port' => '8140',
      }
    )
  }

What are you seeing

Error: /Stage[main]/Puppetserver::Config/Puppetserver::Config::Helper[webserver/ssl-port]/Puppetserver::Config::Puppetserver[webserver.conf/webserver/ssl-port]/Puppetserver_config[/etc/puppetlabs/puppetserver/conf.d/webserver.conf/webserver/ssl-port]: Could not evaluate: Augeas didn't load /etc/puppetlabs/puppetserver/conf.d/webserver.conf with Trapperkeeper.lns from /opt/puppetlabs/puppet/cache/lib/augeas/lenses: Syntax error (line:7, character:18)

What behaviour did you expect instead

It should apply the catalog without any issues. The catalog worked up to Puppetserver 6.4.0 without any issues.

Output log

Error: /Stage[main]/Puppetserver::Config/Puppetserver::Config::Helper[webserver/ssl-port]/Puppetserver::Config::Puppetserver[webserver.conf/webserver/ssl-port]/Puppetserver_config[/etc/puppetlabs/puppetserver/conf.d/webserver.conf/webserver/ssl-port]: Could not evaluate: Augeas didn't load /etc/puppetlabs/puppetserver/conf.d/webserver.conf with Trapperkeeper.lns from /opt/puppetlabs/puppet/cache/lib/augeas/lenses: Syntax error (line:7, character:18)

Any additional information you'd like to impart

With the upgrade of the Puppetserver to 6.8.0 the configuration file /etc/puppetlabs/puppetserver/conf.d/webserver.conf has changed. With version 6.8.0 there are cipher-suites configured, while in 6.4.0 there were no cipher-suites configured. If I remove them the Puppet run applies without issues. I guess that the Trapperkeeper.lns has an issue with the format how the cipher-suites are written.

webserver: {
    access-log-config: /etc/puppetlabs/puppetserver/request-logging.xml
    client-auth: want
    ssl-host: 0.0.0.0
    ssl-port: 8140

    cipher-suites: [
        "SSL_CK_DES_192_EDE3_CBC_WITH_SHA"
        "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256"
        [...]
    ]
}

Removing the configuration option cipher-suites with all it's content, helps with this issue.

4a9d55a introduced a new tree for the lens, which types every setting.

The manifests were fixed accordingly, but non-existing entries can not be created anymore.

For example, when passing:

puppetserver::config::helper { 'webserver/port':
      setting => 'webserver.conf/@hash[.="webserver"]/@simple[.="port"]',
      type    => 'puppetserver',
}

it will fail if there is no entry for port yet.

The solution is to create each level with Augeas, e.g. in this case:

$changes = [
  'set webserver.conf/@hash[.="webserver"] "webserver"',
  'set webserver.conf/@hash[.="webserver"]/@simple[.="port"] "port"',
  "set webserver.conf/@hash[.="webserver"]/@simple[.="port"]/@value '#{value}'",
]

And if we're going to do that, we might as well revert to the old interface, and add a type parameter.

to reflect 3.0.0 release wich is Puppet 4 only

https://voxpupuli.org/blog/2017/01/11/migrating-to-puppet4/

It seems that the module is only compatible with puppet4 since #42 has been merged. (As https://forge.puppet.com/puppetlabs/puppetserver_gem is puppet 4 only). So it would be time for a 3.0 release ?

Also metadata dependencies have to be updated.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.5.2
• Ruby:
• Distribution: CentOS Linux release 7.5.1804 (Core)
• Module version: v0.4.0

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

pwd

/etc/puppetlabs/code/environments/temp

cat manifests/site.pp

node 'localhost.localdomain' {
# include some classes
notify { "This is from the temp environment" : }
class { 'puppetserver::repository': } ->
class { 'puppetserver': }
}

puppet module install camptocamp-puppetserver --modulepath=$(pwd)/modules
puppet module install puppetlabs-puppetdb --modulepath=$(pwd)/modules
puppet agent -t --environment=temp`

What are you seeing

Info: Using configured environment 'temp'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Resource type not found: Debian (file: /etc/puppetlabs/code/environments/temp/modules/puppetserver/manifests/repository.pp, line: 3, column: 5) on node localhost.localdomain
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

What behaviour did you expect instead

Without errors.

Output log

Info: Using configured environment 'temp'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Resource type not found: Debian (file: /etc/puppetlabs/code/environments/temp/modules/puppetserver/manifests/repository.pp, line: 3, column: 5) on node localhost.localdomain
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Any additional information you'd like to impart

Release last 2.2.0 in puppet3 branch according https://voxpupuli.org/blog/2017/01/11/migrating-to-puppet4/.

needs to be based upon the commit before the puppetserver_gem change which does not support Puppet 3.8.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: any?
• Ruby: any?
• Distribution: any?
• Module version: 2.2.0

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

ensure('vault', {provider=>'puppetserver_gem'})

What are you seeing

Error: /Stage[main]/Profile::Puppetmaster/Package[vault]: Provider puppetserver_gem is not functional on this host

What behaviour did you expect instead

vault to be installed

Output log

Any additional information you'd like to impart

Looking at lib/puppet/provider/package/puppetserver_gem.rb I see that it does a which('puppetserver'), hence the requirement that it be in the path. But this is the only thing I've ever run in to that required puppetserver to be in the path when I run "puppet agent -t". The puppetlabs/puppetserver_gem module doesn't do a which, it hard codes it to the path -- maybe this should do the same?

# puppet generate types --environment master
Notice: Generating Puppet resource types.
Error: /etc/puppetlabs/code/environments/master/modules/puppetserver/lib/puppet/type/puppetserver_config.rb: title patterns that use procs are not supported.
# echo $?
1

I've seen this error for years. Now with puppetserver 7.6.0 the exit code is 1 and my pipelines are broken.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: all
• Ruby: all
• Distribution: all
• Module version: 3.0.0

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

Attempt to determine from module docs how to manage the value of a puppetserver configuration setting, such as master-var-dir.

What are you seeing

An example of using the puppetserver::config parameter is presented in the README, but it is unclear how to generalize it. There is no other documentation of that parameter, neither in the README nor in the manifests.

There are also three defined types that seem to address different facets of Puppetserver configuration, but these also are documented only via examples in the README, one each.

What behaviour did you expect instead

All parameters of all public classes should be fully documented, at least in the README, but preferably also in the manifests. In particular, the puppetserver::config parameter should be documented with the expected structure of its value hashes, and how those map onto Puppetserver config files and specific settings within.

All public defined types addressing puppetserver configuration should be fully documented, with all their parameters. Inasmuch as these seem to attribute significance to the structure of their titles, details of the expected title structure should be included.

What are you seeing

There is a param named 'value' that does not seem to be used.

What behaviour did you expect instead

The variable is used in the define or in a template called by the define or should not exist.

Next Steps

Ensure that param is not being called elsewhere, then remove it.

After installing and configuring my nodes to use this module, I received errors because it couldn't load the augeas class referred to in puppetserver::config::puppetserver.

Ideally this module should use stahnma/puppetlabs_yum and ploperations/puppetlabs_apt

Hi!,

I would like to deprecate this module in favour of https://github.com/theforeman/puppet-puppet
The foreman team puts so much effort into their modules. Their amount of unit and acceptance tests is so high. Also upgrades between versions are tested and supported. @voxpupuli/collaborators let me know what you all think about it.

travis tries to run bundle exec rake $CHECK($CHECK not substituted) which lists just all the tasks and exits 0

did try to run them on my machine. at least the docker nodesets need an update because ss is not in the install list and is required.

spec/spec_helper_acceptance.rb also requires an update.