Not a bug, just the current design. I think it would need to be a feature request to add an environment option to the RBAC capability. There's a bit of a dichotomy of environment philosophy within different parts of PE. The current plan design is based on the idea that there should be a limited number of environments for development and testing and that most everything should live in

production

. In the short term, if you want to enforce RBAC, you need to promote the plan.

k, limitation , not a bug. But if you use multiple control repositories for multi-tenants, having plans in one of them is quite limiting

In general, the Console can only "see" plans that are in the Production environment.

nope. you can run plan from any environment

Right. But the content for form entry and validation comes from Production, if I recall correctly.

image.png

Seems should be an option in rbac too

If you use the RBAC API to create the permission, you can specify any plan name, and the orchestrator will use the permissions, even if you are running in an alternative environment. The issue with listing all the plans in all environments is that it can be quite expensive to compute if you have a lot of environments. We certainly could offer an option to choose the environment to select the plan from, which would limit that search, but technically the permission isn't limited to an environment.

ah, so I can do it with a curl, I will try

The final bit of Puppetfile pain on 2023.8.2 is now clear. No amount of cache clearing would get things to work. The r10k deploy in non-incremental mode didn't work. It would still check out a version of the module w/o all of the tags until I added a

:default_branch => 'main'

to the entry and then it was fine.

Puppet agent 8.11.0 fails on facts from the puppet/gluster module whereas it didn't under 8.8.1. On Rocky 8, the @gnome-desktop package group pulls in the gluster cli which then causes the facts in the gluster module to attempt

gluster peer status --xml

. When there is no gluster running, you get the error message

Connection failed. Please check if gluster daemon is operational.

Under 8.8.1, the fact continued on its merry way and everything was fine. Under 8.11.0, the puppet run fails with

Error: Facter: error while resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/gluster.rb Malformed XML: Content at the start of the document (got 'Connection failed. Please check if gluster daemon is operational.')
Line: 1
Position: 65
Last 80 unconsumed characters:

What changed in 8.11?

fixed the glitch? where is this fact defined? https://github.com/voxpupuli/puppet-gluster/blob/master/lib/facter/gluster.rb#L14C1-L14C47

Lines 16 to 26 define the binary if it finds gluster in the path, then line 39 fails

One difference between Puppet 8.8.1 and 8.11 is that the Ruby version went from 3.2.4 to 3.2.5. About the only item of note in the .5 release notes is that the REXML gem was updated to address a CVE: https://www.ruby-lang.org/en/news/2024/07/26/ruby-3-2-5-released/ So, it's quite likely that the REXML suddenly got very strict about not trying to parse stuff that isn't XML as it had just been burnt by a security issue in parsing.

that would make sense

This rings a bell . . . we had another user run into an issue with updated REXML that ended up being due to encoding https://github.com/ruby/rexml/issues/231

The fix there was to update how the affected module read in data https://github.com/puppetlabs/puppetlabs-chocolatey/pull/369

I want to setup a simple zip file transfer between Linux (PS) and windows puppet agent, to save and apply my modified settings I am told on the internet I have to restart PE but no matter what I do the settings return to the default even after file saving and restarting ubuntu. The internet offers suggestions like: sudo service puppetserver restart, sudo service puppetserver stop, sudo systemctl restart puppetserver,sudo systemctl stop puppetserver,sudo systemctl start puppetserver but none of them work, I know PE is installed correctly the command returns a version number of 2025.2.0.

is there a way to completely disable

crl_refresh_interval

on puppet agent upgrade from 7.32.1 to 8.11.0? I tried setting

crl_refresh_interval = 0

in puppet.conf on aganet but that didn't work...

also in case

enable_infra_crl

is set to false, how will that affect legacy compile masters?

Why do you want to disable crl_refresh_interval ?

We have a service dependent on it that would refresh each time crl is refreshed and it would affect our production servers... We will probably modify it later on, but was wandering if there is a way to prevent it's refresh upon upgrade as it will also cause service restart.

👋 n00b here, trying to adjust a module for teamviewer or more specifically when the module applies to the endpoint, to stop the service, alter a file, start the service but what I have is not working.

You can't to that this way

service has to have a desired state, your catalog would fail to compile due to duplicate declaration

Normally you don't need to stop the service to edit configuration file. Is it really a requirement ?

also, I think you will add that line every single puppet run. you need a match attribute

as per Teamviewer support yes but I just tested and editing + restarting the service seems to work

so just notify service