Puppet Community

Looks like `Facter::Util::Resolution` just passes `.exec` through to `Facter::Core::Execution`:

<https://github.com/puppetlabs/facter/blob/main/lib/facter/custom_facts/util/resolution.rb#L21-L31>

So, it’s all `Facter::Core::Execution` in the end.

And the comment indicates that is for Facter 1.x compatibility with `Resolution.exec` marked deprecated.

it's still used by many modules, puppetlabs/ too

cc <@U11HA7VJ7> getting rid of `Facter::Util::Resolution` usage might be a good candidate for any round of module maintenance.

maybe it doesn't watch threads. heh.  I appreciate the attempt tho.

can puppet enterprise load more than once license file?  or can i put multiple licenses in one file?

no idea why i got 2 licenses from the purchasing department

ultimately, that's a question for Puppet Support, but my assumption is that it is a single license file

me too, but somehow my code sets the file as &lt;companyinitials&gt;_license.key and it loads it, but it was so long ago i dont remember if i set a config var somewhere to load it or if its just doing some magic loading

<https://puppet.com/docs/pe/2019.8/purchasing_and_installing_a_license_key.html>

<@UCUE8H9U7> you'll need to disable filebuckets prior to upgrading

thanks <@U11567REE> Will I lose all my existing filebucket data?

It'll still be there on the server, but it won't be addressable, e.g. `puppet filebucket list --local` on the server won't show the old content

using PE 2019.8.x and looking to go to 2021.x with remote filebucket enable breaks agent upgrades due to the change in the digest_algorithm (changed from md5 to Sha256). Whats the best process of updating? Should you update filebucket on all servers and agents to sha256 before going to Puppet 7? When you change your digest algorithm I am assuming you would lose all previous filebucket data? From what I can see on Google, there is no official way to upgrade to Puppet 7 with remote filebucket enabled and handling this algorithm change.

2.5.0 is the latest version of the `puppetlabs-comply` module available. The 2.5.1 release of Comply fixed an issue with GKE compatibility and should be compatible with the 2.5.0 module. Module compatibility is only affected when a new version of the CIS scanner is shipped with comply --- which only happens in .y releases or greater.

Seeing a Kubernetes certificate on port 30303 indicates that TLS certificates aren’t configured for Comply. Make sure the “Config” tab of the Admin console on port 8800 is configured according to the docs, and that the latest version of the application is deployed in the “Version History” tab:

<https://puppet.com/docs/comply/2.x/com-tls-cfg.html>

If you’re still seeing issues after checking the certificates, open a ticket at <http://support.puppet.com|support.puppet.com> and we can dig in further to get it sorted.

Thanks <@U11MDJNGZ>
I did follow this guide and the system showed that it was `ready to deploy` I will continue to investigate and will log tickets with support if I can't get to the bottom of this.

Zombie thread bump, but wouldn’t this immediately consume the entire heap? is the heap not needed for anything else?

One thing the docs don’t cover is whether `puppetserver_ram_per_jruby` is a startup value, a hard limit, or what.

If your ram_per_jruby is set ‘too low’, what happens to the rest of the heap? just unused?

Do you have the various ttl options configured in puppetdb?

that will automatically purge old nodes/reports

I don’t believe so?  Assume those are in the pe console under master?

<https://puppet.com/docs/pe/2019.0/config_puppetdb.html#ariaid-title5>

ah yes. there should also be something similar to report_purge_ttl

node_ttl : “30d” ? I can’t find the docs on this

and in general you can block huge facts you don't need to keep the database small from the beginning. if PuppetDB does some cleanup, that's logged to the puppetdb.log

node_purge_ttl and node_ttl are the same I think

node_ttl is how long node doesn't send reports before in marked as deactivated

node_purge_ttl is when to purge node after it became deactivated

you can also reduce report_ttl if you don't need them for too long

The `pe_database` module can reduce the absolute size by de-fragmenting the DB tables on a weekly schedule:

<https://forge.puppet.com/modules/puppetlabs/pe_databases>

That’s bundled with PE starting in 2019.8.8:

<https://puppet.com/docs/pe/2019.8/release_notes_pe.html#enhancements_pe_x-y-8-databases-module-included-installation>

2019.8 also stores reports and events in tables that are partitioned by day --- this makes it easier and cheaper to drop days of data, keeps the tables from being fragmented (append-only write loads don’t cause dead rows), and also makes queries for date ranges more efficient because the entire dataset does not have to be queried.

<https://forge.puppet.com/modules/puppetlabs/pe_databases/1.2.0> (looks like only 1.2 version does) assuming the metadata is correct

I can’t recall if there were any breaks in 2.0 that would have invalidated compatibility with 2019.0 --- but testing against 2019.0 was dropped because that version has been End of Life for a significant period of time.

That’s also on by default in 2021.4 and newer.

The capability was added to 2019.8.8, but left off by default because on by default is an inappropriate change for a LTS patch release.

Turning it on in 2019.8 is highly encouraged though.

ah thats the new param. I am curently migrating from 2019 to 2021. on 2021 I addes the module explicitly to my profile

Adding the module explicitly isn’t recommended with the latest versions. `pe_databases` is now a built-in component and trying to manage it using a different method can create risk.

`puppet_metrics_collector` is another one that is built-in now and on by default in 2021.

I had to direct download it.  Will use puppet apply to run for now.

ok was able to clean up 39G.  Was expecting more though.

why else would this db be so large?  Is this normal?

Maybe some clues here?
```# du -ks /opt/puppetlabs/server/data/postgresql/11/data/*|sort -n```

&lt; 100 G isn’t that crazy. Usual cause of large table sizes are reports. One or more of:

• Lots of nodes
• Lots of change activity
• Overly verbose resource patterns (e.g. recursive file resources, execs that log War and Peace levels of output, tons of audit resouces, etc.)
• Leaving everything in `noop` instead of letting Puppet enforce state

yeah the database isn’t actually that large, using puppet backup which doesn’t really detail how big everything is individually.  So there might be a large file I need to delete.

In my /opt/puppetlabs/server/data/postgresql/puppetdb directory I have two large files

PG_9.4_201409291
PG_9.6_201608131

I am guessing one of these can go (9.4).  Is it safe to remove this older file?

there is a plan for that :slightly_smiling_face:

No. It’s a `puppet infra` subcommand. The upgrader notes it after a DB migration.

```puppet infrastructure run remove_old_postgresql_versions```

Although, I can’t recall if that is present in 2019.0 or if it showed up later in the 2019.x series. `puppet infra run --help` might list it.

2019.0 is pretty ancient at this point :wink:

I assume I can upgrade to 2021.6 from 2019.0?

No, 2021 only supports upgrades from 2019.8:

<https://puppet.com/docs/pe/2021.6/upgrading_pe.html#upgrading_pe>

The LTS releases are cut points where upgrade support is trimmed and re-organized.

I will build a new infra once 2022 LTS is released, chance to start fresh

then 2019.8.11 and be upgraded to 2021.6 or will there be a time machine problem where I can’t upgrade to the future?

<https://puppet.com/docs/pe/2019.8/upgrading_pe.html#puppetdb-migrations>

Do I combine both of these sql items or use the 2nd one for pe 2019.0?

Or was this part of the pe_databases commands?

If you’re asking about step 2.b., nither of those is part of `pe_databases`. `pe_databases` just compacts the DB tables without removing data. These commands delete all the reports in order to speed up the database migrations in the upgrade.

If upgrading from 2019.0, you’d want to use just the second SQL block, captioned “For PE versions earlier than 2019.3”

no in OSS and PE you should never run newer agents than server side components

it might work but we don’t test for that

wanted to play with the lazy loading of deferred functions

I’d be concerned that maybe some server side changes were made for that.  I’m not sure

from the code I read it's only agent side, but I might be missing something. In the past I used random agent versions with quite some success. But in this particular environment I need to stay compatible/supported by PE support people

I feel like I saw a SERVER ticket float by in relation to deferred functions so that’s why I bring it up

guess I will just wait for the next PE release

is that a valid command?  it should gather data from hiera and classifier to update nodes and user_data.conf

there’s a little bit of a circular dependency on certain keys though

ah, I see it in cron. geez, I think when command is that long it warrants an extra script

Seems a better default:
```puppet_enterprise::master::recover_configuration::pe_environment: "%{server_facts.environment}"```

2019.8 lists RedHat 6 i386:

<https://puppet.com/docs/pe/2019.8/supported_operating_systems.html#supported_operating_systems>

No support for RedHat 5.

2021.6, also RedHat 6 i386:

<https://puppet.com/docs/pe/2021.6/supported_operating_systems.html#supported_operating_systems>

Please don’t laugh.  Is puppet 32 bit agents on x86 still alive?  Client is using i386 for el-5 and el-6

I think I found an issue with the infrastructure upgrade compiler plan