We don't have a place to report bugs now? puppet --noop runs consume resource schedules. In Puppet 8 (resource_harness.rb), perform_changes() writes ':checked' to state.yaml even in noop mode, and scheduled?() decides from ':checked'. So a noop run inside a schedule's range counts as that period's evaluation, and the next real run skips the resource. ':synced' is already guarded with '!resource.noop?'; ':checked' should be too. A noop run should not update state.

There's https://github.com/puppetlabs/core_issues but I have no idea how/if Perforce addresses issues left there. Might be an issue in OpenVox as well and we'd love an issue to investigate if you're so inclined. We use GitHub issues on https://github.com/openvoxproject/openvox.

@vchepkov: Bugs can be reported on the Support portal: support.perforce.com That's the best way to get things into the queue and prioritized. If you don't have access to the support portal, the core_issues repo that @Nick B linked to could work too.

Hi there, I worked a bit with AI do enhance windows run time by working on dsc_base_provider. I opened this MR github.com/puppetlabs/ruby-pwsh/pull/400 The time gain is quite important, and

validation_mode => resource

becomes the fastest and most reliable way to manage resource. I tried to be as precise and detailed as possible in the PR , thus the long text. Hopefully we can work on that and the depending PRs together if anything needs to be changed or discussed

We have an unfortunate situation where we need to keep 10 Oracle Linux 6 servers under Puppet management for up to a year longer. However newer versions don't support it any longer. I thought we could connect them using SSH instead, but then we seem to loose all facts. Any way we can still collects facts on servers with no agents but with ssh connection?

can't you stick to an older puppet agent?

puppet agent 7 should be available for EL6?

Both stdlib and the latest version of PE Advanced seem to no longer list OL6 as a valid node OS. But I don't know if it will jusrt stop working or just no longer offfically supported...

You are on EL6, who cares about support? 😄

and if a latest version of a module doesn't work on your EL7 node, you can always put them in another environment and just don't update the module

puppet agent 7 can talk to puppetserver/pe-puppetserver/openvoxserver 7/8/9

We, just want them to not fall under the Puppet "radar" so we can see that we still have them. But with ssh there is no way to just be able to filter on os.family = RedHat and os.release.major = 6, to see this list of shame. And yes, I've been contemplating making a branch to freeze their modules. But that will not help them if we upgrade to a new puppet version that leaves them high and dry (for all the obvious reasons). Any chance the OL6 agent will still run even if not officially supported? 🙂

Run with what? new PE versions? new module versions?

There is a good change the last agent shipped for OL6 (Puppet 7?) would still connect to and send facts/reports to a Puppet 8 or 9 server.

Definitely no tests guaranteeing that, but there also hasn't been much, if any, breaking change in the APIs.

I can verify this. My gui is almost all API based and the upgrade to 9 broke nothing at all. It was a seamless upgrade

as I said above, puppet agent 7 is available for OL6/EL6 and can speak to puppetserver 8 and 9

I was wondering whether the OL6 puppet agent will still be able to report facts, even if stdlib and the next point release of PE claims to have given up official support. But it seems then that, since they have existing agents and don't need to register and donwload them from the server, we might be able to make these agents hang on a bit longer by the skin of their teeth? 🙂

yes

and if you notice issues during module updates, just don't update them. just copy the environment and move the ancient agents to it

Yes, I am leaning more towards this solution than using only ssh. And a branch will help somewhat towards freezing their environment until their way-too-belated demise. I sure wish puppet could gather facts with ssh like ansible... for situations like these. 🙂

well you can do that. just run

puppet facts upload

but if you can keep running the agent, why stop it

Just put your OL6 to an empty environment, so agent won't do anything, just report facts

No stdlib required then

Aaah...yes, that is another option of course. We don't need to provision anything more. Just keep the life support system working... 🙂

Any timeline for when PDK will support RHEL10 properly? My team is a little frustrated and has resorted to using Jig... Support case references: #01666786 & #01659385 github.com/puppetlabs/pdk-templates/issues/676 "If we need to write tests differently, I don't have a problem with that, but there is no documentation I can find on what is expected or best practice."

I replaced my expired API key in the forge but my Puppet core test nodes are still getting HTTP 401 responses when trying to

dnf update

. Yes, I updated the 'password' value with the new API key. Yes, the user name is 'forge-key'.

Any idea what version(s) the fixes for the "GitLab RCE Flaws" will make it into? ruby-lang.org/en/news/…/regexp-fixes-for-gitlab-cves On the server side, I see JRuby uses the joni port of onigama for regexp. the current jruby security policy is that 9.4.x is still being supported for security updates And they're definitely working on it on the joni side, but it's described as "potentially leading to DoS" rather than as an RCE.