Puppet Community

does anyone at puppetlabs have an ETA for a rocky/alma/redhat 9 release of pdk?

Speaking of compatibility…. has anyone at Puppet any thoughts or guidance around Mac OS Ventura?

Repo transferred!
<https://github.com/voxpupuli/puppet-puppet_certificate>

you can add --debug or similar and also set a loglevel. set it to very very verbose and check the output

--debug dont work for me (debug only work). But is not very very verbose.
```[2022-10-29 22:25:38 - DEBUG] Fetching '<mailto:git@gitlab.com|git@gitlab.com>:notstrong/puppet.git' to determine current branches.
[2022-10-29 22:25:39 - INFO] Using Puppetfile '/etc/puppetlabs/code/environments/dev/Puppetfile'
[2022-10-29 22:25:39 - INFO] Using Puppetfile '/etc/puppetlabs/code/environments/main/Puppetfile'
[2022-10-29 22:25:39 - INFO] Deploying environment /etc/puppetlabs/code/environments/dev
[2022-10-29 22:25:39 - DEBUG] Updating /etc/puppetlabs/code/environments/dev to dev
[2022-10-29 22:25:39 - INFO] Environment dev is now at ba42b88a266bcb82d751e20502750b31be32e79f
[2022-10-29 22:25:39 - DEBUG] Purging unmanaged environments for deployment...```
i add apache modole, i dont download :disappointed:

my log is `--verbose debug` command stdout :disappointed:

can you check the local Puppetfile thst r10k deployed and verify that your latest changes are in there?

after r10k deploy the Puppetfile is update from latest commit. (but not module downloaded)

sorry, already late here. you missed --puppetfike

with that, the whole env is deployed. without, only the controlrepo

sure. your welcome. maybe consider installing the r10k gem, the ubuntu package is usually quite old (and slow/lacks features)

and deprecated ^^
```/usr/lib/ruby/vendor_ruby/faraday/options.rb:166: warning: Capturing the given block using Proc.new is deprecated; use `&amp;block` instead
/usr/lib/ruby/vendor_ruby/faraday/options.rb:166: warning: Capturing the given block using Proc.new is deprecated; use `&amp;block` instead
/usr/lib/ruby/vendor_ruby/faraday/options.rb:166: warning: Capturing the given block using Proc.new is deprecated; use `&amp;block` instead
/usr/lib/ruby/vendor_ruby/faraday/options.rb:166: warning: Capturing the given block using Proc.new is deprecated; use `&amp;block` instead
/usr/lib/ruby/vendor_ruby/faraday/options.rb:166: warning: Capturing the given block using Proc.new is deprecated; use `&amp;block` instead```


but, issue is open and close :slightly_smiling_face:
<https://bugs.launchpad.net/ubuntu/+source/ruby-faraday/+bug/1958629>

In the case of provisioning a user account and sshkeypair to multiple servers (we don't have linux servers directory bound atm) would this best be done as a site level profile? such as (env)/site-modules/profile/useraccounts/(useraccount).pp ?

I've always thought of "best practice" as being slightly malleable depending on the team / orgainisation, and their needs.  If you think the above makes sense for you and it's not a surprise to your team, I'd do that.

What I do is put

`create_resources(ssh_authorized_key, lookup('ssh_authorized_keys', Optional[Hash], {strategy =&gt; 'deep'}, {}))`

in my base.pp file and then put all of the users I want in ./data/common.yaml.

Yes, I should be using a .each loop.  That's on my radar.

Generally recommend against using the ssh_authorized_keys type. Most of the time it's easier to set a ssh_key dir in sshd server config and dump files there.

Definitely not SSH’ing to the Puppet server.

Standard practice is for each Puppet developer/code-contributor to clone your Puppet repo to their workstation, write their changes in a feature branch, push that feature branch up to the git repo, then have that feature-branch deployed to the Puppet server as a new environment.

And what would be best practice in absence of a control repo: just doing a raw clone of the environment from the puppetserver onto another system and developing locally?

in absence of a control-repo; introduce a control-repo

I'm trying to sell that, right now in my work environment we have a directory structure and are using CI/CD to sync the content within /modules but nothing beyond that to my knowledge.

We butted heads a little bit on the topic.

and then for testing; you can work with a new branch in the control-repo that acts as new environment and put test nodes into it/write automated tests for it

a control-repo will make a lot of the stuff way easier for you

With a control repo, how would one pull the repo down to a dev VM and execute locally?

The entire Puppet comunity, and all of the tooling and documentation for developing Puppet code, have moved towards a control repo as *the* way to maintain Puppet code.

why do you want to pull it into a test VM?

Is R10k the primary control repo strategy or are there other solutions?

you create a new branch, push that, puppetserver deploys that, you tell the dev VM to run a puppet agent against that env (roughly explained)

r10k is the standard, and it assumes you’re using a control repo.

g10k is a r10k reimplementation, but in go and faster

you can run a webhook on the puppetserver. everytime you push to the gitserver, it notifies the webhook, which then runs r10k

depending on firewalling on corporate networks, you could also run a bamboo job for each git push, which runs r10k on bamboo and then scp's it to the puppetserver, or bamboo agent runs on the puppetserver directly or it ssh's into puppetserver and then runs r10k