I’d also see if you can do what you want with the puppet/python module rather than roll it your own

See the

puppet-python

module at https://forge.puppet.com/puppet/python?src=slack&channel=puppet

Hi, all! Now the puppet-yum module will fully support DNF modules *stream* management, I'd like to start the trip to full support for DNF modules profiles management, and need some guidance to get things going. My question: where do I send this as a feature request for core package type dnfmodule provider? I know issue tracker was moved recently (or is it in the way still?), but I can't find the correct place to report the needed feature. This is what brought everything here: • Findings ◦ package type dnfmodule provider has a couple issues supporting DNF modules ▪︎ It's not clear whether it will (un)install a package or module profile ▪︎ It doesn't manage actual DNF modules, only individual modules with point actions, what lacks: • (Un)installing multiple profiles (weird, but with real use cases) • Managing profiles while keeping enabled stream ◦ Implementing such capabilities in package type seems to me too hacky abusing ▪︎ Currently, it hacks the package type parameter names to DNF module streams and profiles. But I feel it gets more and more hacky. • Discussions ◦ Held in #C11LCKKQ9, #C0W1Y5VL0 and #C0W298S9G, ending up in the accepted PR mentioned above ◦ Somewhat agreeded roadmap ▪︎ puppet-yum module • Implement stream management in yum module # Done ▪︎ Core package type dnfmodule provider • Implement multi-profile management • Deprecate stream management ▪︎ Docs • Thoroughly explain everything ◦ Including the part that package type with dnfmodule provider (un)installs profiles, not packages

See the

puppet-yum

module at https://forge.puppet.com/puppet/yum?src=slack&channel=puppet

We're having quite big catalogs, which take about 15-30 seconds to be inserted in puppetdb. Are there any pointers on how to speed that up? I tried playing around with postgresql settings as well as puppetdb settings, but somewhat I have no clue what knob to turn. Log messages for puppetdb like: [15716 ms] 'replace catalog' command (15d2443c) processed for

Hello People Recently I have upgraded my postgresql from 10 to 11 as my puppetdb is on version 7.17.1 but post upgrade my DB services are not working fine and the error I am getting is 2024-04-08T080327.194Z ERROR [p.p.c.services] The read-database user is not configured properly because it has privileges other than SELECT on the puppetdb tables 2024-04-08T080327.194Z ERROR [p.p.c.services] The read-database user is not configured properly because it has ownership of tables Can someone please help me, this is impacting the PRD env

When I compare everything w.r.t to postgresql10 and 11 conf, all are identical

Sorry if this has allready been shared but https://blog.rubygems.org/2024/03/31/rubygems-and-xz.html they have done an internal audit not just of the software used to run RubyGems.org itself, but also every gem that has ever been published. RubyGems.org is not vulnerable to this issue and no gem currently published on RubyGems.org contains the vulnerable liblzma library.

Hi @bastelfreak These are the logs I am getting on my postgres server 2024-04-08 114105.221 GMT [1743] FATAL: connection to client lost 2024-04-08 114105.259 GMT [1754] LOG: could not send data to client: Broken pipe 2024-04-08 114105.259 GMT [1754] FATAL: connection to client lost 2024-04-08 114105.574 GMT [1748] LOG: unexpected EOF on client connection with an open transaction 2024-04-08 114106.305 GMT [1746] LOG: unexpected EOF on client connection with an open transaction 2024-04-08 114108.873 GMT [1747] LOG: unexpected EOF on client connection with an open transaction 2024-04-08 114109.138 GMT [1745] LOG: could not send data to client: Broken pipe 2024-04-08 114109.138 GMT [1745] FATAL: connection to client lost 2024-04-08 114109.633 GMT [1762] LOG: could not send data to client: Broken pipe 2024-04-08 114109.633 GMT [1762] FATAL: connection to client lost 2024-04-08 114112.160 GMT [1760] LOG: could not send data to client: Broken pipe 2024-04-08 114112.160 GMT [1760] FATAL: connection to client lost And on my puppetdb node I am getting this one 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@174c42fd marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@334e8281 marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@55ca6ce8 marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@34b63ccb marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@347c938e marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@4523dade marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@322e3a6d marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@7c51e12f marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.267Z WARN [c.z.h.p.ProxyConnection] PDBReadPool - Connection org.postgresql.jdbc.PgConnection@46c4c73f marked as broken because of SQLSTATE(08006), ErrorCode(0) org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.282Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.282Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. 2024-04-08T114021.281Z ERROR [p.p.middleware] #error { :cause Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend. :message Rollback failed handling "An I/O error occurred while sending to the backend." :data {:rollback #error { [java.lang.Thread run Thread.java 750]]}, :handling #error { :message An I/O error occurred while sending to the backend

not sure if your postgresql is actually working

My service is working fine at server level

Following hiera config:

- rewrite_cond:
          - "/var/www/%{literal('%REQUEST_URI')} !-f"

creates:

RewriteCond /var/www/%REQUEST_URI !-f

Now according to https://www.puppet.com/docs/puppet/7/hiera_merging.html#interpolation_functions-literal-function shouldn't this result with ?

RewriteCond /var/www/%{REQUEST_URI} !-f

Question: how do folks generally manage puppetdb / postgresql? The puppetdb module on the forge seems to refer to outdated dependencies.

(this is a bit off topic, sorry in advance...) On EL9, the journal uses the default 4GiB size limit but the rsyslog written /var/log/messages is rotated based only on time. This just bit me because of, ironically, an issue with an rsyslog module generating error messages. My question is: has anyone tried setting a default

size

limit in

logrotate.conf

(for all log files)?

No. I go a different route and purge rsyslog

I've thought about doing that. What are you using for shipping logs?

systemd-journald has that built in. some customers use that, others use filebeat to ship to elastic

I've been considering fluentbit since I'm already using it for k8s nodes

Ah that should work as well

Good Day All, The Puppet Team has investigated, assessed, and prioritized the impact of the newly announced XZ utils vulnerability (CVE-2024-3094). The Puppet team has determined that Per the conditions of the XZ vulnerability, the Puppet Product suite and build infrastructure are not impacted. Please let us know if you have any additional questions about this announcement. Thank you.

the more you know Modules Team is about to start up in #CFD8Z9A4T

indeed _🦊Vox Pupuli monthly sync; see calendar event for info_ is about to start up in #CFD8Z9A4T

meeting 🧑‍🏫Puppet Core Team is about to start up in #CFD8Z9A4T

Afternoon. Had to regenerate certs on my master because I needed to add the ip addresses of the master + 2 compilers to dns alt names. I followed this guide. Once I did that everything was able to connect except now whenever i run "puppet agent -t" on master/compiler/any of my agents I get the following error.

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Failed to execute '/pdb/cmd/v1?checksum=<blah>&version=5&certname=(FQDN of machine)&command=replace_fact&producer-timestamp=<blah>' on at least 1 of the following 'server_urls': <https://server.name:8081>
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog: skipping run

Hi, is there a known issue with Puppet7.29 / Facter / Debian Bookworm ? The domain fact is not correct.

. core default [root@ip-172-22-36-140 ~]# puppet facts networking.fqdn
{
  "networking.fqdn": "ip-172-22-36-140.."
}
. core default [root@ip-172-22-36-140 ~]# puppet facts networking.hostname
{
  "networking.hostname": "ip-172-22-36-140"
}
. core default [root@ip-172-22-36-140 ~]# puppet facts networking.domain
{
  "networking.domain": "."
}

Just asking before i dig deeper into this.

Hi guys, I have a stupid question. I get lost in the require, before ordering. code:

mount { '/var/lib/postgresql':
  ensure => mounted,
  before => Class['a'],
}

class a {
  class { 'b':
  }

  class { 'c':
  }
}

If I have a resource has specified 'before' parameter. Does it mean that the classes "b" and "c" must go before the mount resource?

I'm having a heck of a time -- yet again -- connecting my Puppet server to Puppetdb. I did have this working in the past but I screwed up the certificates on my puppet server (or maybe my puppetdb server) and now I'm getting this error:

1 Notice: Unable to connect to puppetdb server (<https://puppetdb.example.com:8081>): certificate verify failed [unable to get local issuer certificate for CN=<http://puppetdb.example.com|puppetdb.example.com>]

I've seen this problem in the past and I resolved it (somehow!) but I'm not sure where to go. The puppet server is a separate server from the PuppetDB server. The PuppetDB server also contains the Postgres database. I'm in a Catch-22 here, because my puppet server can't fix itself because it can't talk to the Puppetdb server. The firewall is open between the two. Puppetdb is running as well as Postgres. I have a feeling it's a certificate issue. I'm using self-signed certificates for the PuppetDB part but I've also tried putting in real certificates signed with my internal CA. I have the internal CA in /etc/puppetlabs/puppetdb/ssl as well as the real certificates. I've updated jetty.inii and restarted puppetdb but the puppet server still complains. I've even tried disconnecting puppetDB from the puppet server, but that didn't work. Is there something else I should be trying? Again, I did have this problem when I first started with PuppetDB but -- like a doofus -- I didn't document (or I didn't know) the fix. Thanks!

Soooo, how bad would it be if I re-created a legacy fact

which one do you need?