You need to add these to your

PE Master

group class lists

That’s on the page I directed you to.

Hello all. I'm working on a rspec test for a module and I'm getting an error I've not seen before.

This message was deleted.

# frozen_string_literal: true require 'spec_helper' describe 'pce_base' do on_supported_os.each do |os, os_facts| context "on #{os}" do let(:facts) do os_facts.merge( { pce_environment: 'prod', branch_name: 'prod' }, ) end let(:params) do { $nagios_master => '22.33.5.23', $basic_auth_username => 'pce-puppet', $basic_auth_password => 'ENC[PKCS12,M...]', $rp_env => 'prod', } end it { is_expected.to compile } end end end

At the scale of thousands of agents, a scheduler using

fqdn_rand

to distribute run start times is the best way to ensure thundering herds don’t happen. The

reidmv/puppet_run_scheduler

module can configure that nicely, along with optional rules for defining maintenance windows that runs are confined to: https://forge.puppet.com/modules/reidmv/puppet_run_scheduler

not if set in proper (agent) section 🙂

This message was deleted.

Upgrading from Puppet 5 to 6 I noticed that the jolokia metrics API endpoint for the puppet server no longer responds starting from version

6.17.0

. Installing version

6.16.1

produces a working endpoint. Performing on the puppet server a

curl <http://localhost:8180/jolokia/read/java.util.logging:type=Logging/LoggerNames>

delivers a 200 and the accompanied data. With the failing

6.17.0

and onwards up to

6.19.0

I get a stalled connection. Debugging the puppet server with strace I notice no accept() to accept the connection on the socket. https://puppet.com/docs/puppet/6/server/release_notes.html#puppet-server-6170 release notes show, to the best of my knowledge, no reason why this should no longer work. Could this be a bug, a changed feature forgotten to mention in the release notes or am I doing something wrong?

I have two vmware templates, one for RHEL7 and one for RHEL8. Both templates, download, install and configure the puppet client. On RHEL7, it checks in with the puppetmaster and continues to do so. On RHEL8, it checks in with the puppetmaster, configures itself. Then it breaks. To get it working again, I have to rm the cert, clean the puppetserver, then run puppet. After that, it works every time. But I can't have this manual intervention and I don't know how to troubleshoot it. Any guess as to what's happening here?

This message was deleted.

This message was deleted.

👋 Hello, team!

👋

This message was deleted.

I've got a puppet server somewhat connected to a secondary PuppetDB server. I'm using the Puppetdb module here. When I run the puppet agent on my puppet server, I get "Notice: Unable to connect to puppetdb server (https://puppetdb.example.com:8081): certificate verify failed [certificate revoked for CN=puppetdb.example.com]". Obviously somewhere there's a certificate problem. The strange thing is, the PuppetDB does update and I can see the failure on the Puppeboard/PuppetDB server so my puppet server is communicating with the puppet DB. I've scoured the Puppetdb docs at Puppet and have tried everything I can think of. Again, I'm confident it's a certificate issue. The strange thing is: I've got a lab puppet server/puppet DB that works great; the puppet manifest runs fine and there's no warning about a revoked certificate. With the exception of the puppet server and puppet db names the puppet manifests are identical (or so I think). Anybody got some hints as to how I can debug this problem?

I've got a puppet server somewhat connected to a secondary PuppetDB server. I'm using the Puppetdb module here. When I run the puppet agent on my puppet server, I get "Notice: Unable to connect to puppetdb server (https://puppetdb.example.com:8081): certificate verify failed [certificate revoked for CN=puppetdb.example.com]". Obviously somewhere there's a certificate problem. The strange thing is, the PuppetDB does update and I can see the failure on the Puppeboard/PuppetDB server so my puppet server is communicating with the puppet DB. I've scoured the Puppetdb docs at Puppet and have tried everything I can think of. Again, I'm confident it's a certificate issue. The strange thing is: I've got a lab puppet server/puppet DB that works great; the puppet manifest runs fine and there's no warning about a revoked certificate. With the exception of the puppet server and puppet db names the puppet manifests are identical (or so I think). Anybody got some hints as to how I can debug this problem? If I do a curl from my puppet server to the puppetdb server and use the certificate at /etc/puppetlabs/puppetserver/ca/ca_crt.pem, then I have no problems (at least with curl) so I know that I've got good CA information. I just don't know what certificates/CA certificates that the puppet server is using to connect with the puppet DB. I've checked jetty.ini on the DB server and all looks well. curl https://puppetdb.example.com:8081 --cacer /etc/puppetlabs/puppetserver/ca/ca_crt.pem { "version" : "7.10.1" } [root@puppetserver ca]#

I've got a puppet server somewhat connected to a secondary PuppetDB server. I'm using the Puppetdb module here. When I run the puppet agent on my puppet server, I get "Notice: Unable to connect to puppetdb server (https://puppetdb.example.com:8081): certificate verify failed [certificate revoked for CN=puppetdb.example.com]". Obviously somewhere there's a certificate problem. The strange thing is, the PuppetDB does update and I can see the failure on the Puppeboard/PuppetDB server so my puppet server is communicating with the puppet DB. I've scoured the Puppetdb docs at Puppet and have tried everything I can think of. Again, I'm confident it's a certificate issue. The strange thing is: I've got a lab puppet server/puppet DB that works great; the puppet manifest runs fine and there's no warning about a revoked certificate. With the exception of the puppet server and puppet db names the puppet manifests are identical (or so I think). Anybody got some hints as to how I can debug this problem? If I do a curl from my puppet server to the puppetdb server and use the certificate at /etc/puppetlabs/puppetserver/ca/ca_crt.pem, then I have no problems (at least with curl) so I know that I've got good CA information. I just don't know what certificates/CA certificates that the puppet server is using to connect with the puppet DB. I've checked jetty.ini on the DB server and all looks well. curl https://puppetdb.example.com:8081 --cacer /etc/puppetlabs/puppetserver/ca/ca_crt.pem { "version" : "7.10.1" } [root@puppetserver ca]# I'm not sure if this helps but my working server is using TLSv1.2 to talk to the PuppetDB server while my non-working server tries to use TLSv1.3 and fails with "TLSv1.3 73 Alert (Level: Fatal, Description: Certificate Revoked)"

I've got a puppet server somewhat connected to a secondary PuppetDB server. I'm using the Puppetdb module here. When I run the puppet agent on my puppet server, I get "Notice: Unable to connect to puppetdb server (https://puppetdb.example.com:8081): certificate verify failed [certificate revoked for CN=puppetdb.example.com]". Obviously somewhere there's a certificate problem. The strange thing is, the PuppetDB does update and I can see the failure on the Puppeboard/PuppetDB server so my puppet server is communicating with the puppet DB. I've scoured the Puppetdb docs at Puppet and have tried everything I can think of. Again, I'm confident it's a certificate issue. The strange thing is: I've got a lab puppet server/puppet DB that works great; the puppet manifest runs fine and there's no warning about a revoked certificate. With the exception of the puppet server and puppet db names the puppet manifests are identical (or so I think). Anybody got some hints as to how I can debug this problem? If I do a curl from my puppet server to the puppetdb server and use the certificate at /etc/puppetlabs/puppetserver/ca/ca_crt.pem, then I have no problems (at least with curl) so I know that I've got good CA information. I just don't know what certificates/CA certificates that the puppet server is using to connect with the puppet DB. I've checked jetty.ini on the DB server and all looks well. curl https://puppetdb.example.com:8081 --cacer /etc/puppetlabs/puppetserver/ca/ca_crt.pem { "version" : "7.10.1" } [root@puppetserver ca]# I'm not sure if this helps but my working server is using RHEL7 with TLSv1.2 to talk to the PuppetDB server while my non-working server is RHEL8 and tries to use TLSv1.3 and fails with "TLSv1.3 73 Alert (Level: Fatal, Description: Certificate Revoked)"

It is not revoked as far as I can tell. The PuppetDB server is checking in with the Puppet server itself via the puppet agent.

Strangely, the report DOES generate and gets pushed to the postgresql back end. All my clients are showing up in Puppetboard. It's just the puppet server itself when it's doing this check

I'm sure the openssl check will fail. Curl fails unless I specify the ca_crt.pem file from the command line: curl https://nfiv-puppdb-02p.nfii.com:8081/pdb/meta/v1/version --cacer /etc/puppetlabs/puppetserver/ca/ca_crt.pem { "version" : "7.10.1" }

message has been deleted

My RHEL7 server which is running the same puppet code (of course pointing to a different puppetdb) has no issues.

how we can copy all files under files directory to a directory on agent? the point getting them all at once

I highly recommend converting the directory to a tarball and using the archive module

puppet/archive specifically

See the

puppet-archive

module at https://forge.puppet.com/puppet/archive?src=slack&channel=puppet

or putting the files into a repo of some sort and using puppetlabs/vcs_repo