Puppet Community

the `cmd` window I'm using is running as administrator

Ah, you’;re not using the `powershell` module?
<https://forge.puppet.com/modules/puppetlabs/powershell>

I have to copy module to bolt module dir and use bolt?

Either that, or add "/etc/puppetlabs/..../modules" to the <https://puppet.com/docs/bolt/latest/bolt_project_reference.html#modulepath|modulepath> entry in the Bolt project's `bolt-project.yaml`

Assuming the user can read from that modulepath.

But it's probably better to just add the module to the Bolt project's <https://puppet.com/docs/bolt/latest/bolt_project_reference.html#modules|modules> entry in `bolt-project.yaml` and install it with `bolt module install`

I see, module developed locally. Is it same with Puppet Enterprize?

I mean adding same module to two different places does not  seem right

I highly recommend using that whenever you want to `exec` a Powershell script.
You use it by installing that module then setting `provider =&gt; 'powershell'` in the exec.

`command =&gt; "&amp; C:\path\to\script.ps1",`

tangent; if they or anyone else is interested in owning Razor, it's in the toy chest and up for adoption. <https://github.com/puppetlabs-toy-chest/razor-server>

<https://puppet.com/docs/pe/2019.1/how_razor_works.html>

You sent out a note about adopting software somewhere ?  Where was that

I did a blog the other day, <https://puppet.com/blog/the-evolution-of-puppet-community/>

But the <https://github.com/puppetlabs-toy-chest|Toy Chest org> itself talks about how to adopt a repo too.

I don’t, client does.  Still going strong.

<https://puppetcommunity.slack.com/archives/C0W298S9G/p1650410450033049|https://puppetcommunity.slack.com/archives/C0W298S9G/p1650410450033049>

there is also a thread about it on the mailing list

Releases like that would ordinarily be handled as a `-2` in the RPM release number, but it sounds like their build system is restricted in what it can do. :shrug:

<https://groups.google.com/d/msgid/puppet-dev/CAFH7jMXnKW_9J4%2BzksyPUdLXAEr-rqTuKmpwm0dWJyS5%3Dsc8hA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer|https://groups.google.com/d/msgid/puppet-dev/CAFH7jMXnKW_9J4%2BzksyPUdLXAEr-rqTuKmpwm0dWJyS5%3Dsc8hA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer>

`puppet-agent` is the package name, and is versioned separately than `puppet` is.
Most of the time those versions are the same, but if there’s ever a packaging issue, they bump `puppet-agent` without bumping `puppet`.

Looks like it.  The problem with that they run into trouble is an actual bug fix comes along later and they need to release a `puppet` 6.27.1.

RPMs handle repackaging the same product version using the  `-1` in `6.27.0-1` (the "Release:" in RPM-speak)

That separates the product version from the package and avoids those kind of issues.

ahh yeah… that’s definitely a landmine.
Though they’d probably just go to 6.27.2 or something.

Yeah, looks like they'd have to now.  I guess that means the RPM would be 6.72.2-1, treating the -1 as a static string, like an extended period or something. :stuck_out_tongue:

It would be less weird if Puppet's README.md didn't make a point that it uses semantic version numbers, because SemVer is intended to track public API changes and _<https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api|not>_<https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api| changed deps>.

it's honestly a missing bit in semver itself too, there are a _lot_ of orgs that use semver with that problem

I’m not sure 6.27.0-1 would have been the right thing because:

• It’s a Linux-ism that may not transfer to the other platforms that `puppet-agent` is built for.
• This wasn’t strictly a packaging change in the sense that we didn’t re-package the same code but with some tweaks to the build flags or other packaging logic. There were new bits, and in some cases new library versions, pulled in to fix CVEs.

The bottom line is that the `puppet-agent` version is not, and never was, the same thing as the `puppet` version. They just happen to match most of the time.

When they don't happen to match, it makes the Puppet docs inaccurate in a lot of places, because―other than the platform lifecycle page―the product and package version are used interchangeably or reversed.

For instance: the latest docs for Puppet 6 are for Puppet 6.27.1, which doesn't currently exist and is not delivered by any package.

And the docs' release notes claim that Puppet 6.27.0 was never released, when the Puppet 6.27.0 release is what the 6.27.1 package delivers.

The `-1` doesn't have to be a prescription for every platform; my point was that packaging formats provide mechanisms to version package-only changes independently from the products.  And even if they didn't, it would be simpler and clearer to take that concept and just add a digit to the package's version e.g., `6.27.0.1`

When AIO installers were first introduced with Puppet 4.x, they tried to explicitly different versions between packages and components, and the result was confusion.  Without looking it up: which `puppet-agent` package provided Puppet 4.10.12?

(That might be a bad example; <@U11MDJNGZ> might be one of the few that will remember :stuck_out_tongue:

It got better when the package version started to reflect the Puppet version (_most_ of the time) starting in 5.x

Because Puppet isn't merely a component of the `puppet-agent` AIO―the point of that package is to deliver Puppet + everything required to run Puppet―Puppet is the first among equals.  (If Ruby wasn't required to run puppet, it wouldn't be in the package.  But puppet always would be.)

So admins are likely to make the same mistake as the Puppet docs already do, and equate the two.

But the current mismatch is slightly more risky than the Puppet 4.x / puppet-agent 1.y days, because when the versions match _almost all of the time_, it's easy to assume they always do

And that assumption is not bad―they _ought_ to match, judging by other AIOs.  For instance: Bolt is also packaged as an AIO.   It even includes Puppet, but since the point of the package is to install Bolt + everything it needs, the package version reflects the version of Bolt.

Sure, the package numbers usually match because the Puppet or Bolt release schedule is usually what drives creation of new packages.

But, some allowance has to be made for unplanned releases that don’t involve the primary component. If `Facter::Core::Execution.execute` was found to damage the system in some edge case, that would be a critical bug that needs to be fixed with all speed. In those cases, we focus on fixing the impacted component and producing a new package. In that situation, making changes to the Puppet version number would be at best a distraction and at worst an impediment to getting a fix out as soon as possible.

So. The version numbers diverge during black swan events and re-sync by the next release.

I agree, but those allowances doesn't extend to docs with the wrong versions (especially release notes), and they shouldn't have to extend to a package misrepresenting its primary payload.

I disagree that the package is misrepresenting anything. In the scenario above with a fix to Facter, the .z version of Facter would increment  and the Puppet version would stay the same, because no changes. The .z version of the `puppet-agent` package would increment because there are net new bug fixes relative to the last `puppet-agent` package.

It doesn't matter if the   `puppet-agent` version is supposed to be independent from the the `puppet` version; everyone naturally thinks it's the same, including the website.

The release notes even use them interchangeably; right now they say Puppet 6.27.0 was never released

Sure. The system isn’t perfect. But I think a strong argument can be made that this is, so far, the least confusing incarnation that has been tried.

Confusion only exists in those rare cases where a bug fix comes up that does not involve the primary component and is critical enough that it cannot wait for the next natural release of the primary component.

In contrast, the `puppet-agent` 1.x vs `puppet` 4.x situation confused everyone all the time :wink:

Puppet is clearly more important than facter to the version of the `puppet-agent` AIO.   That's demonstrated by the need to resync the Puppet and `puppet-agent` versions in next release.  That doesn't happen for the hypothetical facter version that changed.

Yeah 1.x vs 4.x was head-scratching at every new engagement

But this is subtly more dangerous, because now my release notes actually document the wrong versions.

Can this be solved by updating the documentation to say that puppet agent will always be at or in the same micro as puppet, and that puppet skips patch vers to stay with the aio?

No, because the Puppet doc _version_ tracks the package, not the actual Puppet version

Sure, Puppet is more important than Facter. But spending time and risk (the more packaging pipelines you light up, the more chance that some automation has a bad day) on a cosmetic bump to the Puppet version may not be more important than getting non-Puppet bug fixes out.

And it already basically documents that difference on the platform lifecycle page

Seems to me like this is primarily a docs problem.
If there was a clear distinction between `puppet-agent` the package and `puppet` the software in the main release notes landing page, no one would be having this argument.

The bump isn't cosmetic―when this happens, the docs (even the release notes) are referring  the wrong versions.  But they assume what everyone else does. and probably should.

It would take more than a warning on the landing page because 6.27.1 is only a `puppet-agent` AIO version, but these are the Puppet docs, not the `puppet-agent` docs.

And the conditions for this argument would still be present, because the driving problem is that the correlation was a natural assumption for the docs to make―the problem is that releng is driving the product versions and not the other way around.

That's what I mean... It's not clear which docs we're looking at when we land on the "Puppet" docs.

For black swan events, a `puppet-agent-6.27.0.1` would be better than a mismatched (and possibly non-existent) version of Puppet

The Puppet docs _should_ be for the Puppet version (6.27.0), not the `puppet-agent` version (6.27.1).

Puppet is used as a component in other AIOs, like Bolt and PE.  But if a PE version shipped with Puppet 2.7.0 right now, there are no docs for it.

But that's not a problem, either―if the X.Y.Z versions of Puppet and the `puppet-agent` AIO match. :stuck_out_tongue:

I am honestly still not sure why this is such a massive deal, but I would be fine with the agent having a .4th for aio changes, but I bet someone else will want it the other way

It's hard to appreciate at first, because a surface view of the problem looks like a simple "black swan" AIO packaging hack.  It's easy to forget there's an entire ecosystem that relies on the component version and not the package (and why).

take a look at <https://tickets.puppetlabs.com/browse/SERVER-1543|https://tickets.puppetlabs.com/browse/SERVER-1543> and the linked ticket at the bottom. that might help you

to be specific, check out my comment in server-1543 (Tim Meusel) and <https://github.com/puppetlabs/puppet/commit/c36f71853c086b98e075f010e652af30968ff54c|https://github.com/puppetlabs/puppet/commit/c36f71853c086b98e075f010e652af30968ff54c> . that setting might help you

So something like this?  No joy unfortunately.
```[agent]
    classfile = $statedir/classes.txt
    default_schedules = false
    environment = production
    localconfig = $vardir/localconfig
    masterport = 8140
    noop = false
    report = true
    report_include_system_store = true
    runinterval = 1800
    splay = false
    splaylimit = 1800
    usecacheonfailure = true```

Tried it in the `main` section of the puppet.conf too.  No luck.

on which agent/server version are you? did you set it on the server?

I cannot remember if I could make it work or not

but reports are processed by the server, not the agent

I set it in the puppet.conf on the server which is also where the apply is running and the report submission is failing.
```root@provisioning:/home/rje/puppet# cat /etc/puppetlabs/puppet/puppet.conf
# file managed by puppet
[main]
    basemodulepath = /etc/puppetlabs/code/environments/common:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules:/usr/share/puppet/modules
    certname = <http://provisioning.someplace.com|provisioning.someplace.com>
    codedir = /etc/puppetlabs/code
    environmentpath = /etc/puppetlabs/code/environments
    hiera_config = $confdir/hiera.yaml
    hostprivkey = $privatekeydir/$certname.pem { mode = 640 }
    logdir = /var/log/puppetlabs/puppet
    pluginfactsource = puppet:///pluginfacts
    pluginsource = puppet:///plugins
    privatekeydir = $ssldir/private_keys { group = service }
    report_include_system_store = true
    reports = foreman
    rundir = /var/run/puppetlabs
    server = <http://provisioning.someplace.com|provisioning.someplace.com>
    show_diff = false
    ssldir = /etc/puppetlabs/puppet/ssl
    vardir = /opt/puppetlabs/puppet/cache

[agent]
    classfile = $statedir/classes.txt
    default_schedules = false
    environment = production
    localconfig = $vardir/localconfig
    masterport = 8140
    noop = false
    report = true
    runinterval = 1800
    splay = false
    splaylimit = 1800
    usecacheonfailure = true

[master]
    autosign = /etc/puppetlabs/puppet/autosign.conf { mode = 0664 }
    ca = true
    certname = <http://provisioning.someplace.com|provisioning.someplace.com>
    external_nodes = /etc/puppetlabs/puppet/node.rb
    logdir = /var/log/puppetlabs/puppetserver
    node_terminus = exec
    parser = current
    rundir = /var/run/puppetlabs/puppetserver
    ssldir = /etc/puppetlabs/puppet/ssl
    storeconfigs = false
    strict_variables = false
    vardir = /opt/puppetlabs/server/data/puppetserver
root@provisioning:/home/rje/puppet#```

any idea why the chocolatey module would be inserting semicolons into the package installation command like this? I'm getting invalid path errors. I've tried all combinations of single and double quotation marks

`nginx;"--params: '\/installLocation:C:\Program;Files\NGINX\'"`

this is my code for the install

```  package { 'NGINX':
    ensure          =&gt; '1.21.6',
    name            =&gt; 'nginx',
    provider        =&gt; 'chocolatey',
    install_options =&gt; '--params "/installLocation:C:\\Program Files\\NGINX"',
  }```

Yep, Puppet's autoquoting requires this. Gross indeed.

It's not Chocolatey module specific - it's EVERYTHING in Puppet.

just found you have to split on every space

Try making `install_options` an array.
```install_options =&gt; ['--params', '/installLocation:C:\Program Files\NGINX'],```

just found this example in the docs... this is ugly
```'"/INSTALLDIR=""C:\Program', 'Files\somewhere"""'```


yep, Chocolatey doesn't do this. Puppet auto-quotes spaces.

The module simply explains how to keep Puppet from doing what it does. It does this with everything with spaces

whoever first thought that spaces in pathnames were a good idea :facepalm: