I doubt environment name is a huge secret 🙂

[root@puppet-0 manifests]# sudo -u puppet ls -l /etc/puppetlabs/code/environments/azure_dev_ict/manifests/site total 4 -rw-r--r--. 1 root root 281 Oct 6 17:47 00_all_nodes.pp -rw-r--r--. 1 root root 541 Oct 11 16:00 default.pp -rw-r--r--. 1 root root 213 Oct 8 21:34 foreman.pp -rw-r--r--. 1 root root 186 Oct 8 21:34 puppetdb.pp -rw-r--r--. 1 root root 220 Oct 8 21:34 puppet-test.pp -rw-r--r--. 1 root root 169 Oct 8 21:34 puppet-X.pp

shouldn’t all that belong to puppet:puppet ?

not really, one would expect, but not necessary

that means that code deployment is run by root

This message was deleted.

on our onPremise servers it is the same permission situation, and there it works without any problem ^^

am I losing my mind? I thought a recently saw a puppetlabs github repo that supplied all the various workflows needed for modules and control repos, but pdk workflows is all I'm now finding. I believe the readme compared it to vox's modulesync (or based on it or something)

hmm, but what have modulsync to do with the node-definitions ? ... i thought that where not related things.

I'm talking about the github actions, not modulesync. It was just referenced in the readme.

Has Puppet released any response to the curl vulnerability? I think curl is vendored in?

We will ship a version of curl patched against CVE-2023-38545 and CVE-2023-38546 in our next puppet-agent releases that will go out soon (7.27.0 and 8.3.0)

@Michael Hashizume, did you maybe had in your past a case like my problem ?

This message was deleted.

This message was deleted.

I had a cycle in my puppet config, which my Agent detected…

puppet-agent[22789]: (Exec[letsencrypt certonly <http://www.catalogue.nationalarchives.gov.uk|www.catalogue.nationalarchives.gov.uk>] => Letsencrypt::Certonly[<http://www.catalogue.nationalarchives.gov.uk|www.catalogue.nationalarchives.gov.uk>] => Class[Letsencrypt] => Class[Letsencrypt::Plugin::Nginx] => Package[python3-certbot-nginx] => Class[Letsencrypt::Plugin::Nginx] => Letsencrypt::Certonly[<http://www.catalogue.nationalarchives.gov.uk|www.catalogue.nationalarchives.gov.uk>] => Exec[letsencrypt certonly <http://www.catalogue.nationalarchives.gov.uk|www.catalogue.nationalarchives.gov.uk>])

However, I have now updated the config to remove the cycle, but the Agent doesn’t seem to see the new config from the Server even when I restart it - any ideas?

have you done an r10k ?

@Jan Fickler Yes, several times:

sudo /opt/puppetlabs/bin/r10k deploy environment production -pv
INFO	 -> Deploying environment /etc/puppetlabs/code/environments/production
INFO	 -> Environment production is now at e14d34b3250d62b0ed7607a5607845357f38c5ab
...

You can see in revision `e14d34b3`… that I have commented out the

letsencrypt

aspect here: https://github.com/nationalarchives/ctd-omega-puppet/commit/e14d34b3250d62b0ed7607a5607845357f38c5ab So I can’t understand where the cycle which involves letsencrypt is coming from as I have removed that from my config. Are there caches somewhere that I need to clear?

This message was deleted.

hi. we’re using SRV records in our environment and are seeing a recently provisioned host failing puppet agent runs with output like this

Debug: Resolving service 'fileserver' using Puppet::HTTP::Resolver::SRV
Debug: Searching for SRV records for domain: <http://domain.edu|domain.edu>
Debug: Found 0 SRV records for: <http://_x-puppet-fileserver._tcp.domain.edu|_x-puppet-fileserver._tcp.domain.edu>

we don’t have a SRV record added to dns for

_x-puppet-fileserver

, but it hasn’t caused failures before. the agent version is 7.26.0 on rocky 8.7. is this SRV record a recent addition? i didn’t see it in docs, which is why we don’t have it in dns. we’re trying to determine if this issue is some weird networking issue on our side or what. when popping into puppet’s embedded ruby via

irb

, the host also can’t resolve SRV records but can resolve regular A records and such. any ideas?

SRV support hasn't changed in awhile (here are the issues I know about) but the agent does verify if the environment it's configured to run in exists on the server. https://github.com/puppetlabs/puppet/blob/919779c77a3323a80c7749a16c2c767353ff5265/lib/puppet/configurer.rb#L530 IIRC that will trigger a

fileserver

specific SRV lookup

Is there a way in Puppet to say, "only replace this file if this other file exists?"

The only suggestion I've found is https://serverfault.com/a/516919/313521 which (a) doesn't work as stated (though the comments contain some approaches that do work), and (b) even using the working approaches, will pollute logs with exec outcomes all the time.

why do you want that?

that's an antipattern

Does that mean there is no way to do it?

there's a reason why there's no clean way to do it, at least

you can always write a fact that confines on a file and use that as a conditional

but again, why do you want that?

you should decide if that file exists, not something else