Puppet Community

is there a way to setup puppetserver ca to use EC instead of RSA, specifically ECDSA?

is there a way to setup puppetserver ca to use EC instead of RSA?

i tried setting `key_type=ec`  in `/etc/puppetlabs/puppet/puppet.conf`, no luck

No. Puppet is hardcoded to using RSA in quite a few places.

gotcha, heads up FIPS on RHEL8+ disables RSA so, need to switch to EC

whats the purpose of the setting then? for agent certificates?

Looks like it controls the private key type that agents generate -- which feeds into the certificate request.

The CA can't pick which key types are used. It can only sign or not sign a request.

"Sweet! I can upgrade RHEL 7 to 8 without replacing the OS."
&gt; FIPS not supported.
:angry-cry:

:allthethings: _:teacher:PE Console_ is about to start up in <#CFD8Z9A4T|>

Couple of questions…
First, when running `puppet apply` what’s the best way to get the generated catalog stored on disk?
I got it working with `catalog_cache_terminus = json` and `client_datadir = &lt;some_path&gt;` specified in puppet.conf.

But that causes a problem, which leads to my 2nd question…
Is `--no-use_cached_catalog` expected to work with `puppet apply`?  It doesn’t appear to be since the debug output always shows “using cached catalog for …” due to those settings in my first question.

There's some network maintenance going on, might be an unintended side effect.

woot, thanks. Is the maintenance over, or should I expect a few more blips in the near future

Hello! I'm Nathan, from the team doing the maintenance. We are still working on the network, but we think the Forge should be unaffected.

<@U02FES2R54G> getting 502s again from Forge :disappointed:

Thank you for the heads up, and sorry to disappoint! We're on it.

Just exploring the possibility … i did read in a google forum dated 2013 that we should operate with only one CA.. even in a multi master setup.

One approach we have seen is where people setup mutual trust between CAS on different Puppet Infrastructures using <https://github.com/fervidus/puppet_ca_utils>

Allowing agents to be transferred between them

As suggested by the module the main issue of a HA CA setup ist the sync of the signed certificate and the other ca relevant data. So in theories you just need to ensure that these are in sync between the CA Servers. (could maybe an NFS share, GlusterFS or Ceph) Then you just need a Failover software like keepalived on top to failover the virtual ip oder use a separate Loadbalancer in front. (for example HAProxy+Keepalived)
Just so the theorie. This one is also on our bucket list at some point.:sweat_smile:

There are bits of CA state that are stored and incremented in files (CRL, next serial number, inventory). The current architecture assumes only one processes is operating on these files --- so shared storage isn't an easy solution.

Hey <@U11MDJNGZ>, I looked into it and you are correct… but even if it is a shared storage like ceph or nfs… and we ensure that at any given point of time only one CA server is communicating to these files (like an active passive setup of CA alone.)

Do you think it is still going to cause an issue….

Active/passive is better, but there is still risk with  two processes pointed at the same state.

JFYI: Your Active/passive setup with keepalived for example could also work with a shutdown puppetserver process.
So you run only the puppetserver process only on the active system and only when the failover happend you start the puppetserver on the new Active system.

<@U047TJ03KT7> This is exactly what we had in mind…

so at any time only one process is in charge of manipulating the CRL , invenoty and serial file…

One approach we have seen is where people setup mutual trust between CAS on different Puppet Infrastructures using <https://github.com/fervidus/puppet_ca_utils>

Allowing agents to be transfered between thewm

fyi "Internal Server Error - Request ID: 01GH1CDQBZS4N8DNECFYWK46T4" for <https://puppet.com/docs/puppet/7/lang_data_number.html>

I'm pretty sure that most of regulars here had already moved on, but thanks for offering. :+1:

image.png

I believe the default timeout for a Windows service resource (I’m guessing that’s what this is?) is 30 seconds

Maintenance completed and all systems are operational again. :tada:

aaaah
```# facter -p aio_agent_version```
(no such fact)

yep, Puppet Inc. doesnt provide an AIO package

I think that’s backwards <@U1PC2RAH0>
The built-in OS repo packages aren’t the AIO package (`puppet-agent`), so don’t have that fact built-in.

But the official Puppet repo packages do.

Is there an official Puppet package for Arch (or a .tgz) or should this check in puppet-labs/manifests/init.pp be changed?
```138   if (getvar('::aio_agent_version') == undef) {
139     fail('The puppet_agent module does not support pre-Puppet 4 upgrades.')
140   }```


Or do I fib and have the Arch node get a custom fact for aio_agent_version?

Well, even more relevant here, the `puppetlabs-puppet_agent` module doesn’t support Arch linux.

See the `puppetlabs-puppet_agent` module at <https://forge.puppet.com/puppetlabs/puppet_agent?src=slack&amp;channel=puppet>

use theforeman/puppet to manage your agents :)

See the `theforeman-puppet` module at <https://forge.puppet.com/theforeman/puppet?src=slack&amp;channel=puppet>

Oof, what would one usually do when they encounter a module like this which expect a very stale version of libraries? <https://forge.puppet.com/modules/puppet/sslcertificate/dependencies>

Especially when a lot of stuff is dependant upon stdlib

• <https://forge.puppet.com/modules/puppetlabs/stdlib|puppetlabs/stdlib> (&gt;= 4.13.1 &lt; 7.0.0)<https://forge.puppet.com/modules/puppetlabs/powershell|puppetlabs/powershell> (&gt;= 1.1.1 &lt; 3.0.0)


current stdlib is 8.5.0, powershell 5.2.0

Oh. I’d just ignore that, personally.
I’d deploy the module to a new Puppet environment, ignoring any dependent module specifications, test its functionality, and then deploy to `production` after that.