looks at his customers with PE 2019

there probably folks out there running on Puppet 3, doesn't make it reasonable 🙂

yep!

systemd experts, does

RuntimeMaxSec

suppose to kill a stuck job on it's own or I need to add some additional config? I have to kill r10k once in a blue moon and the only way to do it is with -9

that should kill it

unless it's type=oneshot

nope, simple

and it doesn't

are you on an ancient systemd?

was added on systemd 229 and older versions should just ignore the setting

mhm

the #systemd IRC channel was quite helpful and friendly to me in the past. maybe they can help

I've never run into that. I fire r10k across Bolt from our CI/CD runner machine

Upgraded to 2023.8.0 and started seeing this message when trying to delete the old Puppet Agent packages , what can I do about it?

[Error]: An error has occurred while running orchestrated job. The orchestration service returned an error response. See the orchestration services log file for more details. (status 401: {"kind":"puppetlabs.rbac/token-revoked","msg":"Authentication token has been revoked."}

Ran this on the primary

sudo puppet infrastructure run remove_old_pe_packages pe_version=current

ah no it's https://portal.perforce.com/s/

Hey everybody Just wanted to let everyone know that we have now completed the reinstatement of admins. We have restored community moderators as of today and reinstated the former community lead into the channel. If there is anything still missing please do not hesitate to get in touch. Thanks David

PE question... We had a crl expire and I resolved by injecting an updated one... After this activity.. the main puppet server fails when running the agent... And I am not sure of the next steps...

[root@<puppet main server name redaction> ~]# puppet agent -t
Info: Refreshing CA certificate
Info: CA certificate is unmodified, using existing CA certificate
Info: Refreshing CRL
Error: certificate verify failed [CRL has expired for CN=<puppet main server name redaction>]
Error: certificate verify failed [CRL has expired for CN=<puppet main server name redaction>]

The rest of the puppet agents in this environment all run fine.. What am I forgetting to do to have the main puppet server see the new crl when running its agent

I'm not sure how to investigate this. Any suggestions?

Question on reducing the number of untrusted self-signed certificates within Puppet services. The US Government and the agency I work for has a very low tolerance for non-compliance with TLS specifications; everything must have a valid, trusted cerificate, TLS protocols must be >= TLS1.1, ciphers must be strong, etc. We have been able to replace the Puppet console’s web certificate with a trusted commercial (or US Government CA-issued certificate) sucessfully, but what about the other services such as the classifier API endpoint (4433), the PuppetDB (8081), Puppetserver (8140), Orchestrator(8142, 8143). I understand that the Puppetserver runs its own CA to offer server<->client privacy and authentication, but is there ANY way that we can replace some of these services with custom, trusted CA-issued certificates?

you really don't want to do that

you can, but it's messy

Also, the explanation that HSTS is not required because it is not public-facing is simply not true. HSTS is still required, and is a very simple header.

followup: Buried in above thread I might be able to correct this with an pe_nginx::directive. I’ll look into that.

be careful though. In the past augeas wasn't able to parse all proper nginx config

I bet it still can't do

include includeSubDomains

, so don't add that

I won’t need includeSubdomains.

Latest version of PE doesn't really use /etc/puppetlabs/code anymore right?

Should I clear that directory out