Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

OS Name/Version: Windows

When I set serviceautostart: true without setting either serviceautostartprovidername or serviceautostartprovidertype within an iis_site resource, I expected that the website would automatically start on the next reboot, using the default mechanism.

Desired Behavior:

As it turns out, if serviceautostart is true, then serviceautostartprovidername and serviceautostartprovidertype must both be non-blank, although it is still unclear to me what constitutes a valid value for each setting. To be fair, the official Microsoft documentation, part of which is repeated by the iis module, is equally inadequate.

At a minimum, setting serviceautostart to true without supplying non-blank values for both serviceautostartprovidername and serviceautostartprovidertype should have resulted in a compile-time error.

Actual Behavior:

The setting had no effect, and subsequent puppet runs re-applied the setting as a corrective change.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

As the title says, minrate is not supported creating a yumrepo definition.

minrate

This sets the low speed threshold in bytes per second. If the server is sending data slower than this for at least `timeout' seconds, Yum aborts the connection. The default is `1000'.

http://man7.org/linux/man-pages/man5/yum.conf.5.html

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

When managing a file, if you specify a location that requires an intermediate directory that is missing, and not managed by puppet, the error message is misleading. It implies that the issue is with the temp file created, rather than the missing directory itself. For example, when managing /etc/eyaml/config.yaml, /etc/eyaml does not exist:

Catalog:

  file {'/etc/eyaml/config.yaml':

    ensure => file,

    content => template('eyaml/config.yaml.erb'),

  }

Error:

Error: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

Error: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

Wrapped exception:

No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock

Error: /Stage[main]/Eyaml/File[/etc/eyaml/config.yaml]/ensure: change from absent to file failed: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

The preference would be to generate an error that indicates that /etc/eyaml does not exist, or even a generic "Parent directories for $file do not exist"

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 2.1.0
Puppet Version: 4.10.9
OS Name/Version: CentOS 7.4

Describe your issue in as much detail as possible...

I have multiple tomcat instances, so I tried to declare the realm resources a bit like this (to avoid duplicate resource issues).

tomcat::config::server::realm { "LockOutRealm for ${catalina_base}":

    catalina_base => $catalina_base,

    class_name    => 'org.apache.catalina.realm.LockOutRealm',

}

Desired Behavior:
Module produces valid Realm configuration.

Actual Behavior:
The augeas goes wrong and produces this.

<Realm puppetName="LockOutRealm"></Realm>

<Realm className="org.apache.catalina.realm.LockOutRealm">

</Realm>

puppetName is supposed to be an attribute of the actual Realm (and is supposed to equal to the resource title, not just the title up until the first space).

In my code I've worked around the issue by replacing the spaces with underscores. Dunno if the module should sanitise the resource title itself, or whether it just needs some extra quotes or escape characters somewhere.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

The systemd service provider doesn't use double dashes for ending options, meaning that it will fail on any service with a name beginning with a - (dash):

13:52:54 runejuhl@tolu:~

$ /opt/puppetlabs/bin/puppet --version

4.9.2

13:53:00 runejuhl@tolu:~ 

$ /opt/puppetlabs/bin/puppet apply -e "service { '-h-asd': enable=>true}" | head

Notice: Compiled catalog for tolu.petardo.dk in environment production in 0.27 seconds

systemctl [OPTIONS...] {COMMAND} ...

Query or send control commands to the systemd manager.

  -h --help           Show this help

     --version        Show package version

     --system         Connect to system manager

     --user           Connect to user service manager

  -H --host=[USER@]HOST

Error: Failed to apply catalog: Broken pipe @ io_write - <STDOUT>

Units starting with - are fairly common in systemd, e.g. the -.mount unit.

For a quick fix, it looks like changing https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb#L47 like this would work (albeit only when enabling/disabling):

- output = systemctl(action, @resource[:name])

+ output = systemctl(action, '--', @resource[:name])

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.0.0
Puppet Version: 6.7.2
OS Name/Version: Windows 10 1903

Desired Behavior: When I uninstall a package manually that was installed via puppet-chocolatey, I'd expect that puppet-chocolatey picks up on this and reinstalls it on the next run.

Actual Behavior:

When I uninstall a package manually that was installed via puppet-chocolatey and I re-run puppet, puppet says everything is fine - even though the package is no longer installed.

I'm seeing this issue with the following puppet code:

include chocolatey

package { 'vscode':

    ensure   => installed,

    provider => 'chocolatey',

}

Now, when I (accidentally) uninstall Visual Studio Code through Windows' Settings -> Apps and re-run puppet, puppet won't reinstall VSCode.

I'm guessing this is because when manually uninstalling VSCode, it remains "registered" in Chocolatey (i.e. choco list --local-only).

While I understand that you shouldn't manually uninstall packages that were installed via Chocolatey, I still think the current behavior breaks the promise (expected behavior) of package in Puppet - in that one would expect that package re-installs uninstalled packages.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.0.0
Puppet Version: 6.7.2
OS Name/Version: Windows 10 1903

Desired Behavior: When I uninstall a package manually that was installed via puppet-chocolatey, I'd expect that puppet-chocolatey picks up on this and reinstalls it on the next run.

Actual Behavior:

When I uninstall a package manually that was installed via puppet-chocolatey and I re-run puppet, puppet says everything is fine - even though the package is no longer installed.

I'm seeing this issue with the following puppet code:

include chocolatey

package { 'vscode':

    ensure   => installed,

    provider => 'chocolatey',

}

Now, when I (accidentally) uninstall Visual Studio Code through Windows' Settings -> Apps and re-run puppet, puppet won't reinstall VSCode.

I'm guessing this is because when manually uninstalling VSCode, it remains "registered" in Chocolatey (i.e. choco list --local-only).

While I understand that you shouldn't manually uninstall packages that were installed via Chocolatey, I still think the current behavior breaks the promise (expected behavior) of package in Puppet - in that one would expect that package re-installs uninstalled packages.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

OS Name/Version: Windows

When I set serviceautostart: true without setting either serviceautostartprovidername or serviceautostartprovidertype within an iis_site resource, I expected that the website would automatically start on the next reboot, using the default mechanism.

Desired Behavior:

As it turns out, if serviceautostart is true, then serviceautostartprovidername and serviceautostartprovidertype must both be non-blank, although it is still unclear to me what constitutes a valid value for each setting. To be fair, the official Microsoft documentation, part of which is repeated by the iis module, is equally inadequate.

At a minimum, setting serviceautostart to true without supplying non-blank values for both serviceautostartprovidername and serviceautostartprovidertype should have resulted in a compile-time error.

Actual Behavior:

The setting had no effect, and subsequent puppet runs re-applied the setting as a corrective change.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Currently, after each class, type, function, task, or plan name in the table of contents, Strings writes either the text from the @summary tag or the first 140 characters of the "overview" text. This ticket is to display the @summary tag or nothing at all, as a clipped overview may be nothing more than clutter in the table of contents.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

This ticket sprung from a comment on MODULES-1155 . We now have a schema type for schema creation but a nice-to-have would be a way to grant permissions on a schema. This can wrap `postgresql::server::grant` like `database_grant` and `table_grant`

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PUP-5687
Created | Mon, 11 Jan 2016 12:42:32 -0800
Updated | Wed, 19 Jun 2019 14:17:04 -0700
Component | Types and Providers
Labels | beginner, help_wanted

Hi

We have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a

resources { 'user':

    purge => true

}

or the like

Well, that ends up, for each resource type, calling Puppet::Type::Resources#generate, which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:

  # Generate any new resources we need to manage.  This is pretty hackish

  # right now, because it only supports purging.

  def generate

    return [] unless self.purge?

    resource_type.instances.

      reject { |r| catalog.resource_refs.include? r.ref }.

      select { |r| check(r) }.

      select { |r| r.class.validproperty?(:ensure) }.

      select { |r| able_to_ensure_absent?(r) }.

      each { |resource|

        @parameters.each do |name, param|

          resource[name] = param.value if param.metaparam?

        end

        # Mark that we're purging, so transactions can handle relationships

        # correctly

        resource.purging

      }

  end

In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces the function runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:

  def generate                                                                  

    return [] unless self.purge?                                                

    refs = Hash[*catalog.resource_refs.zip([]).flatten]                         

    resource_type.instances.                                                    

      reject { |r| refs.include? r.ref }.                                       

)

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/MODULES-6060
Created | Fri, 17 Nov 2017 07:03:40 -0800
Updated | Mon, 12 Mar 2018 04:23:27 -0700
Component | Modules
Labels | beginner, intermediate

Basic Info
Module Version: 2.1.0
Puppet Version: 4.10.9
OS Name/Version: CentOS 7.4

Describe your issue in as much detail as possible...

I have multiple tomcat instances, so I tried to declare the realm resources a bit like this (to avoid duplicate resource issues).

tomcat::config::server::realm { "LockOutRealm for ${catalina_base}":

    catalina_base => $catalina_base,

    class_name    => 'org.apache.catalina.realm.LockOutRealm',

}

Desired Behavior:
Module produces valid Realm configuration.

Actual Behavior:
The augeas goes wrong and produces this.

<Realm puppetName="LockOutRealm"></Realm>

<Realm className="org.apache.catalina.realm.LockOutRealm">

</Realm>

puppetName is supposed to be an attribute of the actual Realm (and is supposed to equal to the resource title, not just the title up until the first space).

In my code I've worked around the issue by replacing the spaces with underscores. Dunno if the module should sanitise the resource title itself, or whether it just needs some extra quotes or escape characters somewhere.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.9.0
Puppet Version: 4.10 (puppet-agent 1.10)
OS Name/Version: CentOS/RedHat Enterprise Linux 7

I've tried to install PuppetDB with PostgreSQL 9.5 from SoftwareCollections. This worked out mostly fine after i've figured out all postgresql::globals params.
Example puppet manifest: https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-puppetdb-postgresql-9-5-example-pp

The only missing failing class was postgresql::service with the Postgresql::Validate_db_connection['validate_service_is_running'] resource. It was missing the LD_LIBRARY_PATH environment variable.

I've edited manifests/server/service.pp so it passes postgresql::server::default_connect_settings as connect_settings param to this resource.

Proposed patch: https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-postgresql-service-validate_db_connection-patch

Desired Behavior:
Connection validation works

Actual Behavior:
Connection validation fails

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Puppet Version: 5.5.16
Puppet Server Version: PE 2018.1.9
OS Name/Version: RHEL 7.6

Desired Behavior:

puppet agent can manage the contents of a file resource that uses a Binary type for its contents, with behavior consistent with puppet apply running the same manifest.

Actual Behavior:

Attempting to write binary file content represented in hex as c7 d1 fc 84, converted to base64 and passed as Binary('x9H8hA=='), editing /etc/puppetlabs/code/environments/production/manifests/site.pp:

[root@pe-201819-master manifests]# cat site.pp

## site.pp ##

# This file (/etc/puppetlabs/puppet/manifests/site.pp) is the main entry point

...

node default {

  # This is where you can declare classes for all nodes.

  # Example:

  #   class { 'my_class': }

  file { '/tmp/test':

    ensure  => present,

    content => Binary('x9H8hA=='),

  }

}

[root@pe-201819-master manifests]# puppet apply site.pp

Notice: Compiled catalog for pe-201819-master.puppetdebug.vlan in environment production in 0.02 seconds

Notice: /Stage[main]/Main/Node[default]/File[/tmp/test]/ensure: defined content as '{md5}387d16f3cb61048e6fb16cfd81367ce8'

Notice: Applied catalog in 0.20 seconds

[root@pe-201819-master manifests]# od -t x1 /tmp/test

0000000 c7 d1 fc 84

0000004

This is the expected result of applying the manifest. puppet apply works as expected.

Running as puppet agent fails:

[root@pe-201819-master manifests]# puppet agent --test

Info: Using configured environment 'production'

Info: Retrieving pluginfacts

Info: Retrieving plugin

Info: Retrieving locales

Info: Loading facts

Info: Caching catalog for pe-201819-master.puppetdebug.vlan

Info: Applying configuration version '1570644420'

Notice: /Stage[main]/Main/Node[default]/File[/tmp/test]/content: Received a Log attribute with invalid encoding:"\n--- /tmp/test\t2019-10-09 18:06:34.850138853 +0000\n+++ /tmp/puppet-file20191009-20057-12z3c2w\t2019-10-09 18:07:15.397076080 +0000\n@@ -1 +1 @@\n-\xC7\xD1\xFC\x84\n\\ No newline at end of file\n+x9H8hA==\n\\ No newline at end of file\n"\nBacktrace:

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:190:in `newmessage'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:313:in `initialize'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `new'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `create'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:11:in `send_log'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:20:in `block (2 levels) in <module:Logging>'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:45:in `block in checksum_insync?'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:19:in `write_temporarily'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:44:in `checksum_insync?'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/content.rb:104:in `insync?'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:278:in `safe_insync?'

Notice: /Stage[main]/Main/Node[default]/File[/tmp/test]/content: content changed '{md5}387d16f3cb61048e6fb16cfd81367ce8' to '{md5}1567c6c4f10f34202b0f7578d8d44e43'

Notice: Applied catalog in 21.24 seconds

Excerpted with debug logging:

...

2019-10-09 18:25:28 +0000 Puppet (debug): Executing: 'diff -u /tmp/test /tmp/puppet-file20191009-29036-thyi2b'

2019-10-09 18:25:28 +0000 /Stage[main]/Main/Node[default]/File[/tmp/test]/content (notice): Received a Log attribute with invalid encoding:"\n--- /tmp/test\t2019-10-09 18:25:21.809153889 +0000\n+++ /tmp/puppet-file20191009-29036-thyi2b\t2019-10-09 18:25:28.063298027 +0000\n@@ -1 +1 @@\n-\xC7\xD1\xFC\x84\n\\ No newline at end of file\n+x9H8hA==\n\\ No newline at end of file\n"\nBacktrace:

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:190:in `newmessage'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:313:in `initialize'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `new'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `create'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:11:in `send_log'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:20:in `block (2 levels) in <module:Logging>'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:45:in `block in checksum_insync?'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:19:in `write_temporarily'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:44:in `checksum_insync?'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/file/content.rb:104:in `insync?'

/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:278:in `safe_insync?'

2019-10-09 18:25:28 +0000 Puppet (debug): Executing: 'diff -u /tmp/test /tmp/puppet-file20191009-29036-2dqm05'

2019-10-09 18:25:28 +0000 /Stage[main]/Main/Node[default]/File[/tmp/test]/content (notice):

2019-10-09 18:25:28 +0000 /Stage[main]/Main/Node[default]/File[/tmp/test]/content (notice): content changed '{md5}387d16f3cb61048e6fb16cfd81367ce8' to '{md5}1567c6c4f10f34202b0f7578d8d44e43' (corrective)

2019-10-09 18:25:28 +0000 /Stage[main]/Main/Node[default]/File[/tmp/test] (debug): The container Node[default] will propagate my refresh event

...

The file is created, but with the base64 content written as a string:

[root@pe-201819-master manifests]# od -t x1 /tmp/test

0000000 78 39 48 38 68 41 3d 3d

0000010

[root@pe-201819-master manifests]# cat /tmp/test

x9H8hA==

md5 of the incorrect content ends in 4e43. md5 of the correct content ends in 7ce8.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PUP-7218
Created | Tue, 14 Feb 2017 04:55:59 -0800
Updated | Mon, 21 May 2018 12:27:51 -0700
Component | Types and Providers
Labels | beginner, linux, provider, service, systemd, type_and_provider

The systemd service provider doesn't use double dashes for ending options, meaning that it will fail on any service with a name beginning with a - (dash):

13:52:54 runejuhl@tolu:~

$ /opt/puppetlabs/bin/puppet --version

4.9.2

13:53:00 runejuhl@tolu:~ 

$ /opt/puppetlabs/bin/puppet apply -e "service { '-h-asd': enable=>true}" | head

Notice: Compiled catalog for tolu.petardo.dk in environment production in 0.27 seconds

systemctl [OPTIONS...] {COMMAND} ...

Query or send control commands to the systemd manager.

  -h --help           Show this help

     --version        Show package version

     --system         Connect to system manager

     --user           Connect to user service manager

  -H --host=[USER@]HOST

Error: Failed to apply catalog: Broken pipe @ io_write - <STDOUT>

Units starting with - are fairly common in systemd, e.g. the -.mount unit.

For a quick fix, it looks like changing https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb#L47 like this would work (albeit only when enabling/disabling):

- output = systemctl(action, @resource[:name])

+ output = systemctl(action, '--', @resource[:name])

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

When attempting to disable a service that doesn't exist on a machine, Puppet throws an error:

Error: /Stage[main]/module::Disable_cups/Service[cups]: Could not evaluate: Could not find init script or upstart conf file for 'cups'

service {'cups':

  enable => false,

}

It seems to me that there should be a way to suppress this error, as there are cases in which disabled is the goal, but completely missing is also fine. This to me would be more in-line with the Package module behavior, where you can say ensure => absent and it won't throw an error if the package already didn't exist.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

1. Overview #
   The classes.txt file is only written when running Puppet in the agent run mode.

It would be useful for integration with MCollective filtering if this
file were also written when running Puppet the stand alone apply run
mode.

# The file in which puppet agent stores a list of the classes

# associated with the retrieved configuration.  Can be loaded in

# the separate `puppet` executable using the `--loadclasses`

# option.

# The default value is '$statedir/classes.txt'.

classfile = /var/lib/puppet/state/classes.txt

This would be useful with MCollective's configuration setting of:

classesfile = /var/lib/puppet/state/classes.txt

1. Impact Data #

At least one community member has requested this feature. (See comments below).

This ticket is important for mcollective integration with "puppet apply."

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PUP-7040
Created | Wed, 21 Dec 2016 10:48:00 -0800
Updated | Mon, 21 May 2018 12:28:14 -0700
Component | Modules
Labels | beginner, help_wanted, service, type_and_provider

When attempting to disable a service that doesn't exist on a machine, Puppet throws an error:

Error: /Stage[main]/module::Disable_cups/Service[cups]: Could not evaluate: Could not find init script or upstart conf file for 'cups'

service {'cups':

  enable => false,

}

It seems to me that there should be a way to suppress this error, as there are cases in which disabled is the goal, but completely missing is also fine. This to me would be more in-line with the Package module behavior, where you can say ensure => absent and it won't throw an error if the package already didn't exist.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

As of 5.4.0 the puppetlabs-apache mod's README page has a number of dead links. Several of the links to other parts of the docs reference old material that no longer exists.

For example, in the "Installing arbitrary modules" section, the final sentence:

"There are several optional parameters you can specify when defining Apache modules this way. See the defined type's reference for details."

That link does not exist, and thus no examples can be found. This is important for users who need to know how to add custom and arbitrary modules.

There are a few others as well, clicking them just takes you to the top of the page.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Hi

We have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a

resources { 'user':

    purge => true

}

or the like

Well, that ends up, for each resource type, calling Puppet::Type::Resources#generate, which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:

  # Generate any new resources we need to manage.  This is pretty hackish

  # right now, because it only supports purging.

  def generate

    return [] unless self.purge?

    resource_type.instances.

      reject { |r| catalog.resource_refs.include? r.ref }.

      select { |r| check(r) }.

      select { |r| r.class.validproperty?(:ensure) }.

      select { |r| able_to_ensure_absent?(r) }.

      each { |resource|

        @parameters.each do |name, param|

          resource[name] = param.value if param.metaparam?

        end

        # Mark that we're purging, so transactions can handle relationships

        # correctly

        resource.purging

      }

  end

In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces the function runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:

  def generate                                                                  

    return [] unless self.purge?                                                

    refs = Hash[*catalog.resource_refs.zip([]).flatten]                         

    resource_type.instances.                                                    

      reject { |r| refs.include? r.ref }.                                       

)

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

When managing a file, if you specify a location that requires an intermediate directory that is missing, and not managed by puppet, the error message is misleading. It implies that the issue is with the temp file created, rather than the missing directory itself. For example, when managing /etc/eyaml/config.yaml, /etc/eyaml does not exist:

Catalog:

  file {'/etc/eyaml/config.yaml':

    ensure => file,

    content => template('eyaml/config.yaml.erb'),

  }

Error:

Error: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

Error: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

Wrapped exception:

No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock

Error: /Stage[main]/Eyaml/File[/etc/eyaml/config.yaml]/ensure: change from absent to file failed: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

The preference would be to generate an error that indicates that /etc/eyaml does not exist, or even a generic "Parent directories for $file do not exist"

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

This ticket sprung from a comment on MODULES-1155 . We now have a schema type for schema creation but a nice-to-have would be a way to grant permissions on a schema. This can wrap `postgresql::server::grant` like `database_grant` and `table_grant`

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

HTTP 408 says the server should close the connection and the client should make a new connection and retry on that. But I don't see any mention of an `Retry-After` header. https://tools.ietf.org/html/rfc7231#section-6.5.7

Similarly HTTP 504 doesn't mention that header. https://tools.ietf.org/html/rfc7231#section-6.6.5

It also looks like `Retry-After` can be included in any 3xx response: https://tools.ietf.org/html/rfc7231#section-7.1.3 but our http code assumes they are exclusive.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

This ticket sprung from a comment on MODULES-1155 . We now have a schema type for schema creation but a nice-to-have would be a way to grant permissions on a schema. This can wrap `postgresql::server::grant` like `database_grant` and `table_grant`

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.9.0
Puppet Version: 4.10 (puppet-agent 1.10)
OS Name/Version: CentOS/RedHat Enterprise Linux 7

I've tried to install PuppetDB with PostgreSQL 9.5 from SoftwareCollections. This worked out mostly fine after i've figured out all postgresql::globals params.
Example puppet manifest: https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-puppetdb-postgresql-9-5-example-pp

The only missing failing class was postgresql::service with the Postgresql::Validate_db_connection['validate_service_is_running'] resource. It was missing the LD_LIBRARY_PATH environment variable.

I've edited manifests/server/service.pp so it passes postgresql::server::default_connect_settings as connect_settings param to this resource.

Proposed patch: https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-postgresql-service-validate_db_connection-patch

Desired Behavior:
Connection validation works

Actual Behavior:
Connection validation fails

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Hi

We have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a

resources { 'user':

    purge => true

}

or the like

Well, that ends up, for each resource type, calling Puppet::Type::Resources#generate, which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:

  # Generate any new resources we need to manage.  This is pretty hackish

  # right now, because it only supports purging.

  def generate

    return [] unless self.purge?

    resource_type.instances.

      reject { |r| catalog.resource_refs.include? r.ref }.

      select { |r| check(r) }.

      select { |r| r.class.validproperty?(:ensure) }.

      select { |r| able_to_ensure_absent?(r) }.

      each { |resource|

        @parameters.each do |name, param|

          resource[name] = param.value if param.metaparam?

        end

        # Mark that we're purging, so transactions can handle relationships

        # correctly

        resource.purging

      }

  end

In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces the function runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:

  def generate                                                                  

    return [] unless self.purge?                                                

    refs = Hash[*catalog.resource_refs.zip([]).flatten]                         

    resource_type.instances.                                                    

      reject { |r| refs.include? r.ref }.                                       

)

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PUP-4085
Created | Thu, 5 Mar 2015 04:14:36 -0800
Updated | Thu, 4 Apr 2019 22:31:33 -0700
Component | Windows
Labels | beginner, windows

We had some puppet agents run unexpectedly. I was tasked with trying to figure out if the system clock had changed, thus kicking them off, or if someone had manually ran them. However, we discovered that puppet does not report to event viewer the name of the user under which puppet is running.

It would be beneficial if puppet reported the user (SYSTEM/Local) that puppet is running under.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

From PUP-8586:

If a type's property/parameter depends on a provider feature, and that provider feature isn't available, we repeat the same set of messages for every instance of that resource type. I think we should only emit the message once per resource type (and possibly once if the feature becomes true later in the run if the command, feature, etc becomes available):

Debug: /Firewall[a]: Provider iptables does not support features hop_limiting; not managing attribute hop_limit

Debug: /Firewall[a]: Provider iptables does not support features ishasmorefrags; not managing attribute ishasmorefrags

Debug: /Firewall[a]: Provider iptables does not support features islastfrag; not managing attribute islastfrag

Debug: /Firewall[a]: Provider iptables does not support features isfirstfrag; not managing attribute isfirstfrag

...

Debug: /Firewall[b]: Provider iptables does not support features hop_limiting; not managing attribute hop_limit

Debug: /Firewall[b]: Provider iptables does not support features ishasmorefrags; not managing attribute ishasmorefrags

Debug: /Firewall[b]: Provider iptables does not support features islastfrag; not managing attribute islastfrag

Debug: /Firewall[b]: Provider iptables does not support features isfirstfrag; not managing attribute isfirstfrag

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.0.0
Puppet Version: 6.7.2
OS Name/Version: Windows 10 1903

Desired Behavior: When I uninstall a package manually that was installed via puppet-chocolatey, I'd expect that puppet-chocolatey picks up on this and reinstalls it on the next run.

Actual Behavior:

When I uninstall a package manually that was installed via puppet-chocolatey and I re-run puppet, puppet says everything is fine - even though the package is no longer installed.

I'm seeing this issue with the following puppet code:

include chocolatey

package { 'vscode':

    ensure   => installed,

    provider => 'chocolatey',

}

Now, when I (accidentally) uninstall Visual Studio Code through Windows' Settings -> Apps and re-run puppet, puppet won't reinstall VSCode.

I'm guessing this is because when manually uninstalling VSCode, it remains "registered" in Chocolatey (i.e. choco list --local-only).

While I understand that you shouldn't manually uninstall packages that were installed via Chocolatey, I still think the current behavior breaks the promise (expected behavior) of package in Puppet - in that one would expect that package re-installs uninstalled packages.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

This ticket sprung from a comment on MODULES-1155 . We now have a schema type for schema creation but a nice-to-have would be a way to grant permissions on a schema. This can wrap `postgresql::server::grant` like `database_grant` and `table_grant`

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PUP-1042
Created | Mon, 16 Dec 2013 03:01:33 -0800
Updated | Wed, 19 Jun 2019 14:18:05 -0700
Component |
Labels | beginner, help_wanted, redmine

1. Overview #
   The classes.txt file is only written when running Puppet in the agent run mode.

It would be useful for integration with MCollective filtering if this
file were also written when running Puppet the stand alone apply run
mode.

# The file in which puppet agent stores a list of the classes

# associated with the retrieved configuration.  Can be loaded in

# the separate `puppet` executable using the `--loadclasses`

# option.

# The default value is '$statedir/classes.txt'.

classfile = /var/lib/puppet/state/classes.txt

This would be useful with MCollective's configuration setting of:

classesfile = /var/lib/puppet/state/classes.txt

1. Impact Data #

At least one community member has requested this feature. (See comments below).

This ticket is important for mcollective integration with "puppet apply."

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PUP-4442
Created | Mon, 20 Apr 2015 15:20:23 -0700
Updated | Fri, 8 Jun 2018 13:44:49 -0700
Component | Types and Providers
Labels | beginner

When managing a file, if you specify a location that requires an intermediate directory that is missing, and not managed by puppet, the error message is misleading. It implies that the issue is with the temp file created, rather than the missing directory itself. For example, when managing /etc/eyaml/config.yaml, /etc/eyaml does not exist:

Catalog:

  file {'/etc/eyaml/config.yaml':

    ensure => file,

    content => template('eyaml/config.yaml.erb'),

  }

Error:

Error: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

Error: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

Wrapped exception:

No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock

Error: /Stage[main]/Eyaml/File[/etc/eyaml/config.yaml]/ensure: change from absent to file failed: Could not set 'file' on ensure: No such file or directory - /etc/eyaml/config.yaml20150420-14321-me6waj.lock at 66:/etc/puppetlabs/puppet/environments/eyaml/dist/eyaml/manifests/init.pp

The preference would be to generate an error that indicates that /etc/eyaml does not exist, or even a generic "Parent directories for $file do not exist"

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

We had some puppet agents run unexpectedly. I was tasked with trying to figure out if the system clock had changed, thus kicking them off, or if someone had manually ran them. However, we discovered that puppet does not report to event viewer the name of the user under which puppet is running.

It would be beneficial if puppet reported the user (SYSTEM/Local) that puppet is running under.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/MODULES-4682
Created | Mon, 10 Apr 2017 04:49:57 -0700
Updated | Mon, 22 May 2017 09:04:41 -0700
Component | Modules
Labels | beginner, puppethack

Basic Info
Module Version: 4.9.0
Puppet Version: 4.10 (puppet-agent 1.10)
OS Name/Version: CentOS/RedHat Enterprise Linux 7

I've tried to install PuppetDB with PostgreSQL 9.5 from SoftwareCollections. This worked out mostly fine after i've figured out all postgresql::globals params.
Example puppet manifest: https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-puppetdb-postgresql-9-5-example-pp

The only missing failing class was postgresql::service with the Postgresql::Validate_db_connection['validate_service_is_running'] resource. It was missing the LD_LIBRARY_PATH environment variable.

I've edited manifests/server/service.pp so it passes postgresql::server::default_connect_settings as connect_settings param to this resource.

Proposed patch: https://gist.github.com/vinzent/448fa47032a6f050fb4c501cc741ccad#file-postgresql-service-validate_db_connection-patch

Desired Behavior:
Connection validation works

Actual Behavior:
Connection validation fails

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.5.1
Puppet Version: 2018.1.8
OS Name/Version: Windows server 2012 r2 & Windows server 16

When trying to set "restart_memory_limit" it will not allow you to set the value to '0' saying "restart_memory_limit should be greater than 0"

To add more. It looks like you guys are using the value from lib/puppet_x/puppetlabs/iis/property/positive_integer.rb to not allow 0. This is correct for some of the settings it is applied to but not all of them.

if you search the source code for PositiveInteger a few of these items should also allow a 0 input.

iis_application_pool.rb Items that should allow 0

"cpu limit" 
"max_processess" 
"restart_memory_limit" 
"restart_private_memory_limit" 
"restart_requests_limit"

Desired Behavior:

Allow 0 as an accepted value. 

Actual Behavior:

does not allow 0 as an accepted value.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Both new and experienced users alike will accidentally type "puppet apply -t" when they mean to do a puppet run (puppet agent -t)

puppet apply -t is a valid use case, and should not be changed as it could affect those using masterless puppet. If the client were to detect that puppet apply -t was run, no file argument was given, no input has been fed on standard in and that it was waiting for input, it could print an informational message, such as:

"Info: Puppet apply ready for input on stdin"

Then it would prevent confusion as people wait 2.. 5... 10... seconds (or going for coffee) before thinking that puppet has hung, hitting CTRL-C to break, running "puppet agent -t" like they meant to and kicking themselves for making this mistake AGAIN...

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

The problem

There is no current way—at least that I could find—for an agent to be able to view its trusted fact values using a puppet command.

Someone that is troubleshooting a Puppet-built node would need to do one of:

• Have root access on the Puppet master to run puppet cert print <node-name>
• Have API access to do a PuppetDB query
• Run openssl x509 -text -noout -in $(puppet config print hostcert) to view certificate extensions but not have the OID mapping for trusted facts.

The values of a trusted fact are not considered secret and are only trusted in that they've been signed by the CA. Also, they are plainly visible in the x509 certificate. An admin/Puppet user shouldn't need to know the intricacies of the openssl command to view that data. It seems silly that there is not a way to view this data from a puppet command.

The improvement

There should be some command, puppet <something>, that shows the values of local trusted facts and their OID mappings if using one of the named OID values.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

We had a problem with our artifactory server, where it would return a 404 for the Puppet repository it was providing. This caused an error message to appear, about 404 errors. I tried to install the module manually (or search for it) and also got a 404 error:

[root@puppetmaster ~]# puppet module --debug search saz-sudo

Debug: Runtime environment: puppet_version=5.3.5, ruby_version=2.4.3, run_mode=user, default_encoding=UTF-8

Notice: Searching https://artifactory.domain.com/artifactory/api/puppet/puppet ...

Debug: HTTP GET https://artifactory.domain.com/artifactory/api/puppet/puppet/artifactory/api/puppet/puppet/v3/modules?query=saz-sudo&module_groups=base%20pe_only

Error: Request to Puppet Forge failed.

  The server being queried was https://artifactory.domain.com/v3/modules?query=saz-sudo&module_groups=base%20pe_only

  The HTTP response we received was '404 '

Error: Try 'puppet help module search' for usage 

Before adding the debug flag, I thought that the puppet module tool was loosing the "path" part of the "module_repository" configuration when it read it from the puppet.conf, vs when it was specified on the command line. This was not the case, but it led to a lot of pointless troubleshooting. The error message should have the correct URL that failed.

NOTICE the difference between:

Debug: HTTP GET https://artifactory.domain.com/artifactory/api/puppet/puppet/artifactory/api/puppet/puppet/v3/modules?query=saz-sudo&module_groups=base%20pe_only 

... and:

The server being queried was https://artifactory.domain.com/v3/modules?query=saz-sudo&module_groups=base%20pe_only 

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

1. Overview #
   The classes.txt file is only written when running Puppet in the agent run mode.

It would be useful for integration with MCollective filtering if this
file were also written when running Puppet the stand alone apply run
mode.

# The file in which puppet agent stores a list of the classes

# associated with the retrieved configuration.  Can be loaded in

# the separate `puppet` executable using the `--loadclasses`

# option.

# The default value is '$statedir/classes.txt'.

classfile = /var/lib/puppet/state/classes.txt

This would be useful with MCollective's configuration setting of:

classesfile = /var/lib/puppet/state/classes.txt

1. Impact Data #

At least one community member has requested this feature. (See comments below).

This ticket is important for mcollective integration with "puppet apply."

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

As of 5.4.0 the puppetlabs-apache mod's README page has a number of dead links. Several of the links to other parts of the docs reference old material that no longer exists.

For example, in the "Installing arbitrary modules" section, the final sentence:

"There are several optional parameters you can specify when defining Apache modules this way. See the defined type's reference for details."

That link does not exist, and thus no examples can be found. This is important for users who need to know how to add custom and arbitrary modules.

There are a few others as well, clicking them just takes you to the top of the page.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Feedback received on the docs site, January 2020, requested a way to "elegantly handle lookups where the key exists in Hiera but with an undef value." 

Per Henrik: "it would be possible to modify hiera and add a lookup_option that would control if a looked up `undef` results in an `undef` value or `not found` - this would be per key  (as we don't want this to be controlled by a global setting)." 
 
 

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Puppet Version: 5.5.16
Puppet Server Version: 5.5.16
OS Name/Version: FreeBSD-12-RELEASE

puppet agent --help

...
'--tags' allows you to specify what portions of a configuration you want
to apply. Puppet elements are tagged with all of the class or definition
names that contain them, and you can use the 'tags' flag to specify one
of these names, causing only configuration elements contained within
that class or definition to be applied. This is very useful when you are
testing new configurations – for instance, if you are just starting to
manage 'ntpd', you would put all of the new elements into an 'ntpd'
class, and call puppet with '--tags ntpd', which would only apply that
small portion of the configuration during your testing, rather than
applying the whole thing.

...

Desired Behavior:

Add a section describing --skip_tags option.

Actual Behavior:

See above

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Jira link | https://tickets.puppetlabs.com/browse/PDOC-242
Created | Mon, 23 Apr 2018 01:32:47 -0700
Updated | Tue, 6 Aug 2019 16:50:17 -0700
Component |
Labels | beginner

Currently, after each class, type, function, task, or plan name in the table of contents, Strings writes either the text from the @summary tag or the first 140 characters of the "overview" text. This ticket is to display the @summary tag or nothing at all, as a clipped overview may be nothing more than clutter in the table of contents.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Basic Info
Module Version: 4.5.1
Puppet Version: 2018.1.8
OS Name/Version: Windows server 2012 r2 & Windows server 16

When trying to set "restart_memory_limit" it will not allow you to set the value to '0' saying "restart_memory_limit should be greater than 0"

To add more. It looks like you guys are using the value from lib/puppet_x/puppetlabs/iis/property/positive_integer.rb to not allow 0. This is correct for some of the settings it is applied to but not all of them.

if you search the source code for PositiveInteger a few of these items should also allow a 0 input.

iis_application_pool.rb Items that should allow 0

"cpu limit" 
"max_processess" 
"restart_memory_limit" 
"restart_private_memory_limit" 
"restart_requests_limit"

Desired Behavior:

Allow 0 as an accepted value. 

Actual Behavior:

does not allow 0 as an accepted value.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Puppet Version: 6.12
Puppet Server Version: 6.7.2
OS Name/Version: CentOS 7

find_file function returns path even if absolute path does not exit

Desired Behavior:

The function should return undef/false if none of the given paths were found

Actual Behavior:

The function returns the path if file does not exist

e.g. : find_file('/etc/testfile')

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Puppet Version: 5.5.17-1.el7
Puppet Server Version:5.3.10-1.el7
OS Name/Version: Centos 7

This is a copy of an old redmine ticket that was never resolved:

https://projects.puppetlabs.com/issues/4872

To summarize, if puppet contains a declaration:

file { '/foo':

    ensure  => 'link',

    target  => '/bar'

    replace => false,

}

...and '/foo' already exists as a dangling symlink (pointing to a file that does not exist), then puppet will change the symlink to point back to '/bar'.

Desired Behavior:

Puppet should respect replace => false and not replace the symlink.

Actual Behavior:

As described above, puppet replaces the symlink.

I looked at the code and I think the current behavior is the same in master, though I don't have the means to test it myself. These parts seem relevant:

lib/puppet/type/file/target.rb

     def insync?(currentvalue)

      if [:nochange, :notlink].include?(self.should) or @resource.recurse?

        return true

      elsif ! @resource.replace? and Puppet::FileSystem.exist?(@resource[:path])

        return true

      else

lib/puppet/file_system.rb

  # Determines if a file exists by verifying that the file can be stat'd.

  # Will follow symlinks and verify that the actual target path exists.

  #

  # @return [Boolean] true if the named file exists.

  #

  # @api public

  #

  def self.exist?(path)

    @impl.exist?(assert_path(path))

  end 

I think that for this functionality, the file resource code should instead use a function that does not follow symlinks. Puppet is supposed to be managing the symlink, and the target (present or not) is irrelevant. When creating a symlink, puppet correctly does not care if the target exists.

Thanks,
Corey

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Puppet Version: 6.14.0
Puppet Server Version: N/A
OS Name/Version: CentOS 7.7

When running `puppet parser validate path/to/bolt/plan.pp` it failed until i passed in `–tasks`, which was not present in the `–help` output of `puppet --help` or `puppet parser --help` or `puppet parser validate --help`.

Desired Behavior:

The `–tasks` parameter is shown when we pass in `--help`.

Actual Behavior:

$ puppet parser --help

USAGE: puppet parser <action> Interact directly with the parser.OPTIONS:

  --render-as FORMAT             - The rendering format to use.

  --verbose                      - Whether to log verbosely.

  --debug                        - Whether to log debug information.ACTIONS:

  dump        Outputs a dump of the internal parse tree for debugging

  validate    Validate the syntax of one or more Puppet manifests.See 'puppet help parser' or 'man puppet-parser' for full help.

$ puppet parser validate --help

USAGE: puppet parser validate [<manifest>] [<manifest> ...]This action validates Puppet DSL syntax without compiling a catalog or

syncing any resources. If no manifest files are provided, it will

validate the default site manifest.RETURNS: Nothing, or the first syntax error encountered.OPTIONS:

  --render-as FORMAT             - The rendering format to use.

  --verbose                      - Whether to log verbosely.

  --debug                        - Whether to log debug information.See 'puppet help parser' or 'man puppet-parser' for full help.

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

Whilst trying to use trusted facts for my puppet device, I noticed the `puppet device --target devicename` fail with the error "OBJ_txt2obj: first num too large". However, manually requesting the cert with `puppet ssl` does work and behaves as expected. Guessing it's related to PUP-9746, or at least a similar issue.

Desired Behavior: First `puppet device` run should request a cert with correct extension requests

Actual Behavior: First `puppet device` run fails with "Cannot create CSR with extension request extension_name: OBJ_txt2obj: first num too large"

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

of course eventually dependency cycles are found, but it would be convenient if we were able to communicate this earlier in development

Note: This issue has been mirrored from Puppet's Jira issue tracker. Changes
made here will not be synced back to the source. Please follow the Jira link
below to find more details, to comment, or to contribute a pull request. See
this repository's README for more contribution information!

We had some puppet agents run unexpectedly. I was tasked with trying to figure out if the system clock had changed, thus kicking them off, or if someone had manually ran them. However, we discovered that puppet does not report to event viewer the name of the user under which puppet is running.

It would be beneficial if puppet reported the user (SYSTEM/Local) that puppet is running under.