Puppet Community

<https://www.puppet.com/docs/puppet/8/lang_data_regexp.html#lang_data_regexp|https://www.puppet.com/docs/puppet/8/lang_data_regexp.html#lang_data_regexp>

I think you use a too old ruby version. ot doesnt understand the newer syntax in the ruby files

Usually I just take the command found in the nodes section for adding new nodes

"6.17.0" is my agent version for class pe_repo::platform::windows_x86_64

This is the entry for PE master so I guess my agent version needs to be 6.17.0

PE 2019 uses Puppet 6 (which is also dead)

something seems to be mixed up in your environment :)

I upgraded our puppet instances and prod is version 2021.7.2

time to upgrade the agents and your console data I guess

What command can i run on the agent to upgrade the version to something puppet master would work with

is there a reason for using 2021.7.2 and not 2021.7.4?

the PE docs have some examples on how to install the agent. the best option depends on your environment

cacert="$(puppet config print localcacert)"
uri="https://$(puppet config print server):8140/packages/current/install.bash"

curl --cacert "$cacert" "$uri" | sudo bash

I found this script to run but the upgrade was done based on the old version

The team wanted to test the upgrade making sure everything works before pushing for another

Also upgrades are done like twice a quarter or something so it all depends

you should have upgraded the agents first. now thes are broken

how did it end up with such an old agent?

<https://www.puppet.com/releases/202174|https://www.puppet.com/releases/202174>

you can get agents there or from your primary (when comfigured correctly)

<http://downloads.puppetlabs.com/windows/>

That’s the agents

And make sure you have Powershell 5 or higher before doing that

Could not get metadata for puppet:///pe_packages/2021.7.2/windows-x86_64/puppet-agent-x64.msi

I think the msi is missing on your puppetserver

yes. it is called puppetserver since quite some time

Where is the msi suppose to be on the puppetserver if it does exist?

you can check through <https://www.puppet.com/docs/pe/2021.7/upgrading_agents.html|https://www.puppet.com/docs/pe/2021.7/upgrading_agents.html>

Did not find anything helpful on doc to help

this is a compile error, so the agent didnt run so it did not updste the yaml file

we usually query puppetdb for the last successful run and check for everything older than an hour

and use puppetboard to check for broken/outdated nodes

So that's what I would expect, but from run to run, this file gets updated:

```&lt;   fact_generation: 1.6848575620097108
&lt;   plugin_sync: 4.008013729006052
&lt;   startup_time: 0.252203135
&lt;   total: 11.628223415
&lt;   last_run: 1689108380
---
&gt;   fact_generation: 1.614125226973556
&gt;   plugin_sync: 0.8516313870204613
&gt;   startup_time: 0.251019469
&gt;   total: 5.984049656
&gt;   last_run: 1689109105```
and of course the timestamp on the last_run_summary.yaml is also updated

ah yeah, but there was no complete/successful run

I am not sure if last_run_report.yaml is more helpful

write paragraphs, <@U1PC2RAH0>

:smile: :smile:

lol… and it’s all you, man.  :smile: :smile: :smile:

Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Could not get metadata for puppet:///pe_packages/2021.7.2/windows-x86_64/puppet-agent-x64.msi

This is the message I see when running puppet agent -t and it appears the agent I'm trying to use is the correct version

You can create a PV on a device w/o partitioning 

And yes.. better to keep this in provisioning step if possible 

<@UNNE9882X> I know, and I am using it already .... but I started using the partition /dev/sdb1 on all the other servers already...

Then I’d try to search for a partitioning module

I had no real need before so not really aware of any

I would be worried about `parted` rewriting the wrong partition label, possibly because it gets the wrong device. Might be able to guard against that if you can identify the devices by UUID

But yeah, I would do this during provisioning rather than Puppet, especially since presumably you don't need to be doing this every catalog run.

I think I'm going to comment this out... I leave this manifest, but I comment out the `include ...`  statement

I caused data loss in the test environment :slightly_smiling_face:
in test I had GPT disk table, but I was grepping for msdos:
```parted -s ${dev_name} print | grep -q msdos```
and I destroyed existing data :stuck_out_tongue:

Doh! That's what test environments are for I guess :slightly_smiling_face:

Imho, something should be left to provisioning step - this is one of them

if you want to use the repository created by you, you need to set a purge option for apt repositories, which means, the repositories that are not created by you, will be deleted.

Good point but won't help in my case. We want to allow 3rd party repos (unmanaged) to be added if needed.

I can try and use an `apt::source` resource to remove the default google-chrome repo and re-create it myself with a different name. Seems messy though.

that's even better... you can possibly use:
apt::source with "ensure =&gt; absent"

In case anyone else has the same issue, I dug through the postinst script and cronjob used by google-chrome, and I came up with the following solution

```# Configure the google-chrome apt repository
class hg_workstation::google_chrome (
  String $repo_name = 'google-chrome',
  String $keyring_file = "/etc/apt/keyrings/${repo_name}.asc",
  String $keyring_url = '<https://dl.google.com/linux/linux_signing_key.pub>',
  String $defaults_file = '/etc/default/google-chrome',
) {
  file { $defaults_file:
    ensure  =&gt; 'file',
    content =&gt; "repo_add_once='false'\nrepo_reenable_on_distupgrade='false'",
  }
  -&gt; file { $keyring_file:
    ensure =&gt; 'file',
    owner  =&gt; 'root',
    group  =&gt; 'root',
    mode   =&gt; '0644',
    source =&gt; $keyring_url,
  }
  -&gt; apt::source { $repo_name:
    ensure =&gt; 'absent',
  }
  -&gt; apt::source { "${repo_name}-browser":
    architecture =&gt; 'amd64',
    comment      =&gt; 'Google Chrome',
    location     =&gt; '<https://dl.google.com/linux/chrome/deb>',
    release      =&gt; 'stable',
    repos        =&gt; 'main',
    keyring      =&gt; $keyring_file,
    require      =&gt; File[$defaults_file],
  }
}```
Basically you need to create a config file at `/etc/default/chrome`
```repo_add_once='false'
repo_reenable_on_distupgrade='false'```
Then you need to ensure the default google-chrome repo is absent
And finally, you can recreate your own source file and pull down the gpg key.

we just purge unmanaged apt sources, and configure the google chrome apt source with the rest of our apt sources

Would be an ideal solution, but we need to allow unmanaged apt sources because these are laptop/desktop devices for end-users.

So they need to be able to add extra software repos if required.

But Google Chrome is a core app for us so needs to be installed always

we solve that by having a `file` resource place an empty file in `/etc/apt/sources.list.d` with no content or source attributes. so users can put whatever they want in there, and puppet won't touch it.

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

Depends on where `puppet-agent` development is at when the need for a fix is discovered.

If 7.25.0 had just shipped and there was no finished feature work pending a release, then the security fix would likely come out as 7.25.1

If 7.26.0 was scheduled to ship within a few weeks, then the security fix would likely just be added to 7.26.0.

but for 2021.7.3 (LTS), it does not get feature updates anymore, since it is LTS? It only gets security updates? So next should be 7.24.1?

LTS means that large feature updates that require extensive re-works or changes in default behavior are not landed. Small features with no disruption are sometimes added.

The 2021.7.5 release will include Puppet 7.25.0, or a later version.

the LTS "flag" will then move to 2021.7.5?

2021.7 is the LTS release series. 2021.7.5 would just be the latest release in that series.

Which is to say: upgrading from any 2021.7 release to the latest 2021.7.5 release should be free of disruptive or breaking changes.

Compared to 2023.2.0 -&gt; 2023.3.0 which will likely bring in Puppet 8.

if you translate that to open source puppet.  As long as you stay within major version. say version 7, you should be free of disruptive or breaking changes.

you really need to subscribe to the vox pupuli mailinglist so I don't have to approve every of your messages :smile:

what do you see in /etc/puppetlabs/puppet/ssl on the agent?

maybe the agent is started before the fqdn is configured properly

that’s what i’m thinking.  But how do I fix it?

check which files you have in the ssl dir

no :) we need to check which certs were generated

I think your suggestion is correct about agent starting before the fqdn is configured.. but i’m not sure how to go around it…

I configure puppet.conf and csr before I install puppet in provisioning script

I usually add the full fqdn as certname to puppet.comf

i’m configuring puppet.conf in kickstart as well

okay.  Sorry if it’s a dumb question, but while i have you guys here.  Should i just use facts for it?

nope, that's where it fails you :slightly_smiling_face:

```lang en_US
keyboard --xlayouts='us'
timezone America/New_York --utc
rootpw blahblahblha--iscrypted
reboot
text

url --url=URL

bootloader --location=mbr --append="rhgb quiet crashkernel=auto"
zerombr
clearpart --all --initlabel

……………..

auth --passalgo=sha512 --useshadow
selinux --enforcing
firewall --enabled
skipx
firstboot --disable
%packages
@^minimal-environment
puppet-agent


%end

%post --log=/root/ks-post.log

chvt6

systemctl disable firewalld
systemctl enable iptables
systemctl enable puppet
systemctl disable initial-setup-graphical
systemctl disable initial-setup-text
update-crypto-policies --set LEGACY

echo -e "[agent]\nenvironment=master" &gt; /etc/puppetlabs/puppet/puppet.conf
echo "server=myserver" &gt;&gt; /etc/puppetlabs/puppet/puppet.conf
echo "runtimeout = 2h"  &gt;&gt; /etc/puppetlabs/puppet/puppet.conf

%end```

i’ve been using the same kickstart configs for many OS versions… i already installed multiple installations with this particular kickstart, but having issues only with one host.  It is VERY old.

yes if i run puppet agent --test, everything is working properly.

is it now using the localhost cert or did puppet create new ones

but puppet is still trying to run (looking at /var/log/messages) with the same certificate error message (localhost.localdomain)

any chance you run puppet agent -t as normal user and not as root?

I am windering why it works for you on the cli but the daemon doesnt work

i ran puppet agent --test as a test user that i created

and it works fine when you run it as root?

if i run puppet agent --test, everything is working.

should i modify puppet service to make sure dns/network is ready before it starts?

i don’t know if it’s related to a very old hardware, potentially very slow.

<https://serverfault.com/questions/867830/systemd-start-service-only-after-dns-is-available> - something like that..

but service is already after network-online.target.  Should dns-ready.service be there as well?

./etc/hostname is empty, which weird too.

that's what I thought, kickstart doesn't configure hostanme

but i used the same kickstart to many OS’s already and it worked just fine.  I will check my dhcp setup… But why is puppet agent --test working now as expected?

hostname command returns correct information.

and if i manually restart puppet service, it’s all good.

there is a chance it’s set with puppet’s configuration.

maybe in post section `hostname -f &gt; /etc/hostname`

as i said, it worked fine on 20 hosts i already setup

You can open support ticket, but it's a timing issue

do the others also have an empty /etc/hostname file?

all others are fully puppetized.  Let me see if it’ll make a difference

it’ll take some time.. will let you know.  Thank you, guys.  As always, i appreciate your help.

well i just looked through our puppet code (agent is still running) and /etc/hostname is set by puppet.

as i said, it could be a really old hardware..

I recommend setting /etc/hostname and /etc/hosts in the kickstart

I feel like /etc/hostname is part of provisioning and not puppet's business

well another solution is to add a reboot after puppet configuration to kickstart.  That fixed the problem as well..

For the kickstart--&gt;puppet system I maintain, there are three different places I set the hostname.
1. In the kickstart config:
```network --bootproto=dhcp --device=bootif --hostname=<http://foo.example.com|foo.example.com>```
2. Via a %post section:
```cat &lt;&lt; 'EOF' &gt; /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=<http://foo.example.com|foo.example.com>

GATEWAY=10.1.2.3
NOZEROCONF=yes
NM_CONTROLLED=no
EOF```
3. Also in a %post section:
```cat &lt;&lt; 'EOF' &gt;&gt; /etc/hosts
10.1.2.8           <http://foo.example.com|foo.example.com> foo
EOF```

The first of those is probably the important one, and the others could probably be moved to puppet, but I haven't tried.

This is for a setup where the kickstart config is dynamically generated; I don't know how portable that approach is to a static file.

I'm running a foreman puppet master server and typically I import the environment from the git branch I created into foreman and then manally change the `environment` in foreman before running the agent.  I was wondering if I can keep the server with the environment selected in foreman..and just run the agent with `--environment=new_env --noop` and get that to work?

I'm currently getting an error saying `local env &lt;env&gt; doesn't match server specified environment 'production', restarting agent run with environment 'production'`

you have an ENC that is forcing the environment

So how can I tell the agent to not use the ENC and use what I specify as environment?

You can't, it would defeat a purpose of ENC. You need either assign that node your testing environment or allow nodes to use any environment

Google points to this, not sure how it's up to date <https://github.com/joshuabaird/foreman_noenv>

More accurately, the agent cannot choose to ignore the enc. But the enc can tell the compiler to let the agent choose by not returning an `environment` key. (what that plugin :point_up: allows.)

is r10k still maintained? Or will it become abandonware?

yes indeed, but the disclaimer got me thinking

it is embedded in PE, I dont think it will die soon

with puppet opensource you can use g10k. It's a drop-in replacement, and it's much faster.

yes but I prefer something backed by puppet itself. In any other case we better maintain our own automatisation in case they decide to kill it off

<@UD8PZL6L9> do you use only modules backed by puppetlabs or also community modules?
g10k deserves a try IMO.
g10k is probably faster than your git server allows it.
r10k is probably faster than the ruby GIL permits (I don't remember if they enabled threads).
When you realize that it's 50 times faster (not kidding) you won't care who's the maintainer.

only modules backed by puppetlabs others are homemade. In fact most of them are homemade

G10k might be faster but r10k is fast enough for us. A puppet “build” takes like 6 minutes to validate, download deps and do rspec testing, the deploy time at the end is piddly comparatively. 

<@U114TKH5M> makes perfectly sense.
In our case, only few modules have a CI that lasts too much.
The last version of r10k that I used (5 years ago) did not have threads, and it was taking around 4 minutes to deploy the code. g10k takes 15 seconds.
It was quite a difference, and I wonder how long it would take now.

Oh I never saw it that bad, also we send the quest to r10k and let it run async

It was like maybe 30s at the outside last time I poked directly at it, with quite a few but not hundreds of modules. 

we have a lot of modules (legacy application, stale modules, small applications) perhaps more than 150 ...

image.png

<@U114TKH5M> 235... don't know if we still use all these repos. Let's say we 200 + Forge modules

The README in the r10k repo is accurate.  While Puppet will continue to maintain r10k for as long as it is needed for Puppet Enterprise, we will not be adding any new features.

I'm trying to create a service hook in Azure DevOps with Puppet server and for some reason I'm getting a error: "Cannot get DNS address for host '<http://puppet.pacific.nexttravel.com|puppet.pacific.nexttravel.com>'