We use _*pe_patch*_ and for debian we have used the option autoremove = true to clean up old kernels among other things. Yet, we see that this leaves many old kernel versions in the state "rc" instead of doing what "apt purge kernel...." would do, i.e. cleaning up properly. Is this a bug or a a very conservative behaviour on the part of the pe_patch module? Does anyone know?

I don't think there is a way to purge them. do kernel packages even have any config files left behind? I'd just ignore them, unless you want to run

aptitude purge ~c

occasionally

even unattended-upgrades doesn't purge old kernel packages, it just removes the packages

oh there is an

autopurge

subcommand of

apt-get

that would do it

Morning..Has anyone run into the scenario where after upgrqading to v2025.11.2, that the pe_postgres_info fact shows both Version 14 and Version 17 info together in the fact.. as opposed to just the 17 info as expected?

Hi. Curios mind wants to know. why 2023.8.11 has puppet agent 8.21.0, but 2025.11.3 only 8.20.0 ?

We have put in a lot of effort to clean up our code in terms of not using toplevel facts, and are now enforcing include_legacy_facts = false. However, it seems the GUI does not have completion support for the modern syntax of "os.name", "os.release.major" and so on when filtering on facts. Up till now we have started writing "osfam.." and presto we find the right fact to filter on. Now we have enter the full name and chose "Add..." The old adage "no good deed goes unpunished" comes to mind 🙂 So, is there a way to support completion for the new syntax?

Is there any way of using the rugged git shipped with PE with an external Git provider that requires mutual TLS over HTTPS (no ssh).

Customer wants to set the r10k

ignore_branch_prefixes

setting in code manager. We identified that this setting must be done in two locations: 1.

puppet_enterprise::master::code_manager::sources:

2. in

pe_r10k::sources

. Is this correct? Customer runs on PE2025.11.0.

Hi Puppet Enterprise team, raising a concern about PE lifecycle planning. The official support lifecycle page (puppet.com/products/puppet-enterprise/support-lifecycle) still says PE 2026.0 is "expected August 2026" and that PE 2025.y standard support ends "August 2026 (projected)". Both dates have passed, and the page hasn't been updated or explained. Customers plan upgrades against these commitments. When they slip without notice, we can't plan responsibly, especially with PE 2023.8 support ending February 27, 2027. Please keep this page current and authoritative, with firm GA and end-of-support dates and a last-updated date. For an enterprise product this is table stakes. I'd also urge you to reconsider the "Latest / Latest-1" model. Under it, every release is effectively short-term: at most about 12 months of full support, then 12 months of fixes only. That forces a major upgrade across the whole fleet roughly every year. Enterprises need long-lived, predictable support windows, which is exactly what LTS provided. Is there any chance an LTS track comes back?

Today is the date we were given by our rep for 2026 being available, is that still happening or did it get pushed back?

PE office has begun. I'll be around for the next hour or so to answer questions

that's a wrap for today - next office hour is in two weeks

Office hours have started back up? That’s cool.

I think Steve mixed up the channel. he is the only one who shows up in #CFD8Z9A4T

ah, ok

Yeah, Steve's been great about keeping those office hours going this whole time! If more folks happen to see it here in the PE channel, maybe it makes sense to have it here instead?

I mean, I dropped most of the other groups except #C0W298S9G, #C19V5U41Z, #C7GP57T50, #C0AQD72F8, and #C11LCKKQ9

yes, apologies, I did indeed get the incorrect channel but the PE office hour is fortnightly

pe_status_check fact has a bug

# grep -w ss /opt/puppetlabs/puppet/modules/pe_status_check/lib/facter/pe_status_check.rb
    result = Facter::Core::Execution.execute("ss -onp state established '( dport = :8143 )' ", { timeout: PEStatusCheck.facter_timeout })
    result = Facter::Core::Execution.execute("ss -onp state established '( dport = :8142 )' ", { timeout: PEStatusCheck.facter_timeout })

because it doesn't specify protocol. ss tries every one and generates SELinux denials What's interesting, other fact in the same module does it correctly

# grep -w ss /opt/puppetlabs/puppet/modules/pe_status_check/lib/facter/agent_status_check.rb
      socket_state = Facter::Core::Execution.execute("ss -tone state established '( dport = :8142 )' ", { timeout: PEStatusCheck.facter_timeout })

might be the flags

@helindbe has left the channel

@vchepkov I've 4000 primaries and a valid rbac token to authenticate to the API. However I don't have a client cert. Any idea how I can determine the PE version? The

/status/v1/services

APIs all require a certificate 😞

great job perforce

# curl --insecure --header "$auth_header" https://$(hostname -f):8143/orchestrator/v1/ --silent | jq .info
{
  "title": "Application Management API (EXPERIMENTAL)",
  "description": "Multi-purpose API for performing application management operations",
  "warning": "This version of the API is experimental, and may change in backwards-incompatible ways in the future",
  "version": "0.1",
  "license": {
    "name": "Puppet Enterprise License",
    "url": "<https://puppetlabs.com/puppet-enterprise-components-licenses>"
  }
}

there really could have been an actual version number

mhm each PE release should have the facter/facts task and I can read

pe_server_version

thinking

I made Claude to write me custom resources to support everything ldap/rbac. I can DM everything to you?

I would just need to strip internal stuff

ah sure!

In case anyone is still paying attention If you're on PE 2025.12 with the database-backed CA: upgrading 2025.12.0 -> 2025.12.1 breaks. The installer only looks for ca_crt.pem on disk, which isn't there after cleanup-fs, so it tries to create a new CA and fails halfway. I switched back with ca_storage_export and the upgrade is going through now. Also, ca_storage_export/import don't refresh user_data.conf, so run puppet infrastructure recover_configuration afterwards or the installer picks up the old backend. I didn't find either in the known issues.

i do

puppet plan run

this triggers an orchestrator plan run, which does a hiera query, which does eyaml, which results in

Error was parsing issue: certificate issuer is an empty distinguished name

. afaik PE did something to hiera-eyaml on encryption level, but i do decryption here? the plan runs in the orchestration service, so in its java/jruby? when i do

puppetserver gem list hiera-eyaml

i get

hiera-eyaml (5.0.1, 4.3.0)

… this seems not so good, having two versions here?