Error while resolving custom fact fact='puppetdb_version'

[damluk]

Debian 12, Puppetserver 7.9.5, PuppetDB 7.12.1.

Error: Facter: Error while resolving custom fact fact='puppetdb_version', resolution='<anonymous>': undefined method `strip' for nil:NilClass

    output.split(':').last.strip

setcode do
  output = Facter::Core::Execution.execute('puppetdb --version')
  output.split(':').last.strip                                                                                                                                                                                                                                                                      
end

$ /usr/sbin/puppetdb --version
Available subcommands:
  version                 Display version information
  services                Run PuppetDB
  upgrade                 Upgrade to latest version and exit
  benchmark               Run development-only benchmarking tool
  fact-storage-benchmark
  help                    Display usage summary
For help on a given subcommand, invoke it with -h

$ /usr/sbin/puppetdb version
version=7.12.1
target_schema_version=80

[Geod24]

Introduced in #404
Reverting to v8.0.1 will work around the issue, otherwise look at the comment I posted in the PR.

[smortex]

$ /usr/sbin/puppetdb --version

That's not a path I would expect on Debian…

What/How did you install? You seem to be using PuppetServer 7 / PuppetDB 7 on Debian 12 for which Puppet does not provide AIO packages. I think you can cast your voice here: puppetlabs/community#65

Regarding the root cause, the version string comes from the puppetdb wrapper generated by ezbake (this code seems to be 10 years old):

https://github.com/puppetlabs/ezbake/blob/5eec28239e177f14a3a6eaafc305119c6b375dfb/resources/puppetlabs/lein-ezbake/staging-templates/cli-app.erb#L60

FYI, the FreeBSD packages are built using the tarballs from https://downloads.puppetlabs.com/puppetdb/ and don't have this issue. Either there was an issue in older releases that got fixed, or the installation method you use give you a weird puppetdb script.

[damluk]

Regarding the root cause, the version string comes from the puppetdb wrapper generated by ezbake (this code seems to be 10 years old):

https://github.com/puppetlabs/ezbake/blob/5eec28239e177f14a3a6eaafc305119c6b375dfb/resources/puppetlabs/lein-ezbake/staging-templates/cli-app.erb#L60

This is from [1]. Are you saying that upstream PuppetDB 7.12.1 does not have a puppetdb executable that behaves like Debian's?

[1] https://packages.debian.org/bookworm/all/puppetdb/filelist

[smortex]

This is from [1]. Are you saying that upstream PuppetDB 7.12.1 does not have a puppetdb executable that behaves like Debian's?

[1] packages.debian.org/bookworm/all/puppetdb/filelist

Ah, you are using the Debian packages! I did not realized they also had a PuppetDB package.

Well, the Debian packages are maintained by the Debian project the way that fit them, but that's not what Puppetlabs "officially" support. That being said, Debian 12 support is still lagging behind (see puppetlabs/community#65)

So, even if older versions of PuppetDB where reporting versions differently, a fix is unlikely to be released for this old release (1.5 year) by Puppetlabs, and I don't see Debian changing the behavior of what they ship to be compatible with technology released 1 year after the release.

My short term recommendation would therefore be to stick to an older version of the module for now, and when Debian 12 AIO packages are available, switch to that.

[damluk]

This is from [1]. Are you saying that upstream PuppetDB 7.12.1 does not have a puppetdb executable that behaves like Debian's?
[1] packages.debian.org/bookworm/all/puppetdb/filelist

Ah, you are using the Debian packages! I did not realized they also had a PuppetDB package.

Well, the Debian packages are maintained by the Debian project the way that fit them, but that's not what Puppetlabs "officially" support. That being said, Debian 12 support is still lagging behind (see puppetlabs/community#65)

Debian packages lack behind upstream almost always. But it is very unusual that Debian changes the CLI so drastically. You linked to a bash wrapper of something. Is that the real puppetdb executable? Maybe the Debian package just does not ship the wrapper? Or is PuppetDB 7.12.1 too old to be supported by this module - even the upstream version?

My short term recommendation would therefore be to stick to an older version of the module for now, and when Debian 12 AIO packages are available, switch to that.

Where are those AIO packages? I cannot find puppetdb on https://apt.puppet.com/

[rwaffen]

back then i tested this on rhel, will try again and see if it can be fixed somehow

[smortex]

But it is very unusual that Debian changes the CLI so drastically. You linked to a bash wrapper of something. Is that the real puppetdb executable? Maybe the Debian package just does not ship the wrapper?

This template is used to generate the wrapper that is part of the Puppetlabs tarballs and packages. But per policy, Debian does not use this and build their packages from source. This wrapper is not in the same repo as the puppetdb package, so my guess is that this is the reason why it is not in the Debian package in the end.

Or is PuppetDB 7.12.1 too old to be supported by this module - even the upstream version?

As stated above, this code was added 10+ years ago, so the 7.12.1 tarball has the expected wrapper. This is only an issue when installing the Debian package provided by the Debian project.

Where are those AIO packages? I cannot find puppetdb on apt.puppet.com

Yeah, PuppetServer / PuppetDB packages are still not available for Debian 12. You can vote here to say that you too are affected by this and make this being properly prioritized:
puppetlabs/community#65