[Puppet Users] Re: Trouble after Agent upgrade -- Error: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given)
A quick update on this one: With Patrick's help, we were able to re-produce the issue in AWS. The root cause appears to be that the Puppet::Provider class includes the Puppet::Util module, which also happens to have a Puppet::Util::Package sub-module. So, depending on the load order of puppet/util/package and puppet/provider/package files, providers using the new PackageTargatable class could trip this error as there is a window where Puppet::Provider::Package may actually be the Puppet::Util::Package module. TL/DR: Including a module in Ruby brings in more than just methods. A JIRA bug is open and a PR is up with changes to the package providers to ensure the right files are required before class inheritance happens: https://tickets.puppetlabs.com/browse/PUP-9794 Thanks a bunch to everyone who reported this issue and especially to Patrick Whitney for working with us to troubleshoot it. -Charlie On Friday, June 21, 2019 at 11:10:30 AM UTC-7, Jeff Cheng wrote: > > We're seeing similar issues with the official v6.5.0 docker image when > running in circleci: > circleci@default-d4c9fa03-e104-4e3d-bb5e-3510a1a9eed8:~/project$ docker > run --rm puppet/puppet-agent-ubuntu:6.5.0 resource --types > Error: Could not autoload puppet/provider/package/gem: superclass must be > a Class (Module given) > Error: Could not autoload puppet/type/package: Could not autoload puppet/ > provider/package/gem: superclass must be a Class (Module given) > Error: Could not parse application options: Could not autoload puppet/type > /package: Could not autoload puppet/provider/package/gem: superclass must > be a Class (Module given) > > Running with v6.4.2 works fine on the same box: > circleci@default-d4c9fa03-e104-4e3d-bb5e-3510a1a9eed8:~/project$ docker > run --rm puppet/puppet-agent-ubuntu:6.4.2 resource --types > augeas > cron > exec > file > filebucket > group > host > mount > notify > package > resources > schedule > scheduled_task > selboolean > selmodule > service > ssh_authorized_key > sshkey > stage > tidy > user > whit > yumrepo > zfs > zone > zpool > > > On Thursday, June 20, 2019 at 4:53:34 PM UTC-4, Patrick Whitney wrote: >> >> Hello Everyone, >> >> I hope you can help. >> >> Our puppet agent was updated to version 6.5.0 on our servers last night. >> Things are working fine, except for two servers are throwing the error >> below (SNIP #1).A little digging found I could reproduce the error by >> running 'facter -p' or 'puppet facts' (SNIP #2). Trying to identify >> exactly what is going on, I got as far as running the offending ruby script >> (package_provider.rb) and it also returns the error, but, at least with a >> stack trace (SNIP #3). >> >> Does anyone have any idea what we've encountered? >> >> Any help would be greatly appreciated. >> >> Thanks! >> -Pat >> >> >> >> SNIP #1 >> >> # puppet agent -t >> Info: Using configured environment 'production' >> Info: Retrieving pluginfacts >> Info: Retrieving plugin >> Info: Retrieving locales >> Info: Loading facts >> Error: Could not autoload puppet/provider/package/gem: superclass must >> be a Class (Module given) >> Error: Facter: error while resolving custom facts in /opt/puppetlabs/ >> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/ >> provider/package/gem: superclass must be a Class (Module given) >> Info: Caching catalog for eu-assist.aws-eu.int.luminoso.com >> Info: Applying configuration version '1561063233' >> Notice: Applied catalog in 15.24 seconds >> >> >> SNIP #2 >> # puppet facts > /dev/null >> Error: Could not autoload puppet/provider/package/gem: superclass must >> be a Class (Module given) >> Error: Facter: error while resolving custom facts in /opt/puppetlabs/ >> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/ >> provider/package/gem: superclass must be a Class (Module given) >> # facter -p > /dev/null >> 2019-06-20 20:42:36.539351 ERROR puppetlabs.facter - error while >> resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/ >> package_provider.rb: Could not autoload puppet/provider/package/gem: >> superclass must be a Class (Module given) >> >> SNIP #3 >> # /opt/puppetlabs/puppet/bin/ruby >> /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb >> Traceback (most recent call last): >> 15: from /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb:11: >> in `' >> 14: from >> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in >> >> `require' >> 13: from >> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in >> >> `require' >> 12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package >> .rb:9:in `' >> 11: from >> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package.rb:10:in ` >> ' >> 10: from >> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/metatype/manager.rb:127:in >> >> `newtype' >> 9: from
Re: [Puppet Users] Core Modules with Puppet pre6?
On Fri, Jun 21, 2019 at 12:51 AM Martin Alfke wrote: > > Hi, > > has anyone tried what will happen if we place the Puppet 6 core modules in a > Puppetfile when still having a Puppet 5.x agent? > Will the agent still use the built-in types/providers? > > e.g. > Puppetfile: > mod 'puppetlabs/mount_core', :latest > mod 'puppetlabs/augeas_core', :latest > mod 'puppetlabs/zfs_core', :latest > mod 'puppetlabs/yumrepo_core', :latest > mod 'puppetlabs/host_core', :latest > mod 'puppetlabs/selinux_core', :latest > mod 'puppetlabs/zone_core', :latest > mod 'puppetlabs/cron_core', :latest > mod 'puppetlabs/sshkeys_core', :latest > mod 'puppetlabs/nagios_core', :latest > mod 'puppetlabs/mailalias_core', :latest > mod 'puppetlabs/macdslocal_core', :latest > mod 'puppetlabs/maillist_core', :latest > mod 'puppetlabs/k5login_core', :latest > > Many thanks, > Martin > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/7213AA1A-AE0F-4E03-8135-78D57B02C3BD%40getmailspring.com. > For more options, visit https://groups.google.com/d/optout. I would expect puppetserver6 to use the core modules during compilation, while all agents should pluginsync the core modules and use their type/providers during catalog application, taking precedent over the versions in the puppet-agent 5.x package. This is one of the reasons we had to make the yumrepo_core module retain compatiblility with 5.x agents: https://github.com/puppetlabs/puppetlabs-yumrepo_core/commit/d751a380d7aea5ba88b3571a342039dfae3621e4 Josh -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unrcB%3DFmtQ9fiqenSGdzOBqJUXkqq21e8NFQav5sZDPSg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] stdlib module causes puppet failure
On Thu, Jun 20, 2019 at 10:45 AM Michael Watters wrote: > > I'm having an issue with the puppetlabs-stdlib module causing compilation > failures using the puppet apply command. > > > Error: Class 'stdlib' is already defined (file: > > /mnt/live/puppeteer/conf.d/puppet/modules/stdlib/manifests/init.pp, line: > > 16); cannot redefine (file: > > /mnt/live/puppeteer/conf.d/puppet/modules/stdlib/manifests/init.pp, line: > > 16) on node host.example.com > > The command used to apply our manifest is as follows. > > puppet apply -d --noop --modulepath=puppet/modules --hiera_config=hiera.yaml > ./ > > > > This node is running Fedora 29 with the puppet-headless package. No changes > have been made to the manifest and I'm able to apply the same code on other > nodes with an older version of puppet. Does anybody know how to resolve this > or what would cause puppet to include the same class twice? You may be running into https://tickets.puppetlabs.com/browse/PUP-9602. Try deleting /mnt/live/puppeteer/conf.d/puppet/.resource_types Josh > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/e93ac4af-6e04-4aae-96dc-0362b4290f50%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2Bu97umjNLEJ37QfAda%3DW28%2BW44KMqeS%2Bej675WMWDRU%2B3fO_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Trouble after Agent upgrade -- Error: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given)
We're seeing similar issues with the official v6.5.0 docker image when running in circleci: circleci@default-d4c9fa03-e104-4e3d-bb5e-3510a1a9eed8:~/project$ docker run --rm puppet/puppet-agent-ubuntu:6.5.0 resource --types Error: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given) Error: Could not autoload puppet/type/package: Could not autoload puppet/ provider/package/gem: superclass must be a Class (Module given) Error: Could not parse application options: Could not autoload puppet/type/ package: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given) Running with v6.4.2 works fine on the same box: circleci@default-d4c9fa03-e104-4e3d-bb5e-3510a1a9eed8:~/project$ docker run --rm puppet/puppet-agent-ubuntu:6.4.2 resource --types augeas cron exec file filebucket group host mount notify package resources schedule scheduled_task selboolean selmodule service ssh_authorized_key sshkey stage tidy user whit yumrepo zfs zone zpool On Thursday, June 20, 2019 at 4:53:34 PM UTC-4, Patrick Whitney wrote: > > Hello Everyone, > > I hope you can help. > > Our puppet agent was updated to version 6.5.0 on our servers last night. > Things are working fine, except for two servers are throwing the error > below (SNIP #1).A little digging found I could reproduce the error by > running 'facter -p' or 'puppet facts' (SNIP #2). Trying to identify > exactly what is going on, I got as far as running the offending ruby script > (package_provider.rb) and it also returns the error, but, at least with a > stack trace (SNIP #3). > > Does anyone have any idea what we've encountered? > > Any help would be greatly appreciated. > > Thanks! > -Pat > > > > SNIP #1 > > # puppet agent -t > Info: Using configured environment 'production' > Info: Retrieving pluginfacts > Info: Retrieving plugin > Info: Retrieving locales > Info: Loading facts > Error: Could not autoload puppet/provider/package/gem: superclass must be > a Class (Module given) > Error: Facter: error while resolving custom facts in /opt/puppetlabs/ > puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/ > provider/package/gem: superclass must be a Class (Module given) > Info: Caching catalog for eu-assist.aws-eu.int.luminoso.com > Info: Applying configuration version '1561063233' > Notice: Applied catalog in 15.24 seconds > > > SNIP #2 > # puppet facts > /dev/null > Error: Could not autoload puppet/provider/package/gem: superclass must be > a Class (Module given) > Error: Facter: error while resolving custom facts in /opt/puppetlabs/ > puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/ > provider/package/gem: superclass must be a Class (Module given) > # facter -p > /dev/null > 2019-06-20 20:42:36.539351 ERROR puppetlabs.facter - error while > resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/ > package_provider.rb: Could not autoload puppet/provider/package/gem: > superclass must be a Class (Module given) > > SNIP #3 > # /opt/puppetlabs/puppet/bin/ruby > /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb > Traceback (most recent call last): > 15: from /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb:11: > in `' > 14: from > /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in > > `require' > 13: from > /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in > > `require' > 12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package. > rb:9:in `' > 11: from > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package.rb:10:in ` > ' > 10: from > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/metatype/manager.rb:127:in > `newtype' > 9: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload. > rb:215:in `loadall' > 8: from > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:79:in ` > loadall' > 7: from > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:79:in > `each' > 6: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload. > rb:81:in `block in loadall' > 5: from > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:66:in ` > load_file' > 4: from > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:66:in > `load' > 3: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/ > package/gem.rb:1:in `' > 2: from > /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in > > `require' > 1: from > /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in > > `require' > /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/ > package_targetable.rb:23:in `': Could not autoload > puppet/provider/package/gem: superclass must be a Class (Module given) > (Puppet::Error) > > -- You received this message because you are subscribed to the Google Groups
Re: [Puppet Users] fips and non fips agent rpms
On Thu, Jun 20, 2019 at 9:05 AM 'slig...@verizon.net' via Puppet Users wrote: > > Hello, > > We are using some fips and some non-fips agent. Proper agent rpm (fips or non > fips based on current configuration) has been installed, however, after agent > installation, if we were to update a agent from fips to non-fips or > vice-a-verse, will the old agent rpm still function? The fips and non-fips packages have the same name, but different releases. So if you switch from one to the other, the old one will be removed. That said, we don't test switching, as we assume the matching package is installed from the start. $ rpm -qi puppet-agent Name: puppet-agent Version : 6.5.0 Release : 1.redhatfips7 ... $ rpm -qi puppet-agent Name: puppet-agent Version : 6.5.0 Release : 1.el7 > Just running puppet agent -t seems to be working , but in that case not sure > what is different between fips and non-fips agent? The fips agent is compiled against system openssl and does not contain a vendored openssl: $ ldd /opt/puppetlabs/puppet/lib/libfacter.so | grep libssl libssl.so.10 => /lib64/libssl.so.10 (0x7fefbab83000) Whereas the non-fips agent is compiled against puppet's vendored openssl: $ ldd /opt/puppetlabs/puppet/lib/libfacter.so | grep libssl libssl.so.1.1 => /opt/puppetlabs/puppet/lib/libssl.so.1.1 (0x7f705127f000) If you install a non-fips puppet-agent on a fips-enabled host, it will use the vendored openssl. While it will "work", I wouldn't recommend it, because it will subvert the system's openssl. If you install a fips puppet-agent on a non-fips-enabled host, then it should work provided the system openssl is compatible with our ruby. The puppet ruby code is the same for both fips and non-fips. At runtime, puppet detects if fips is enabled, and if so, removes md5 from its list of supported checksums. This affects filebucketing and retrieving file contents from "puppet:///" sources. Also some operations like `puppet module install` cannot be performed due to its reliance on md5. That will be changing in the near future though. Josh > > Thanks > > M > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/59879625-fca7-4696-997a-ce4d598da63e%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unZ08CkNbkrwahzXgqAMUdi-%2BvtnX7xrqK7AfCKpiCUOA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Trouble after Agent upgrade -- Error: Could not autoload puppet/provider/package/gem: superclass must be a Class (Module given)
Hi Charlie,
Thanks for the help!
# Fact: package_provider
#
# Purpose: Returns the default provider Puppet will choose to manage
packages
# on this system
#
# Resolution: Instantiates a dummy package resource and return the provider
#
# Caveats:
#
require 'puppet/type'
require 'puppet/type/package'
Facter.add(:package_provider) do
setcode do
if defined? Gem && Gem::Version.new(Facter.value(:puppetversion).split('
')[0]) >= Gem::Version.new('3.6')
Puppet::Type.type(:package).newpackage(:name => 'dummy', :allow_virtual
=> 'true')[:provider].to_s
else
Puppet::Type.type(:package).newpackage(:name => 'dummy')[:provider].
to_s
end
end
end
On Thursday, June 20, 2019 at 6:36:13 PM UTC-4, Charlie Sharpsteen wrote:
>
> Could you post the content of package_provider.rb? Since that is in
> cache/lib/facter, it is a custom fact and the specifics of its
> implementation could shed some light on what is happening.
>
> -Charlie
>
>
> On Thursday, June 20, 2019 at 1:53:34 PM UTC-7, Patrick Whitney wrote:
>>
>> Hello Everyone,
>>
>> I hope you can help.
>>
>> Our puppet agent was updated to version 6.5.0 on our servers last night.
>> Things are working fine, except for two servers are throwing the error
>> below (SNIP #1).A little digging found I could reproduce the error by
>> running 'facter -p' or 'puppet facts' (SNIP #2). Trying to identify
>> exactly what is going on, I got as far as running the offending ruby script
>> (package_provider.rb) and it also returns the error, but, at least with a
>> stack trace (SNIP #3).
>>
>> Does anyone have any idea what we've encountered?
>>
>> Any help would be greatly appreciated.
>>
>> Thanks!
>> -Pat
>>
>>
>>
>> SNIP #1
>>
>> # puppet agent -t
>> Info: Using configured environment 'production'
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Retrieving locales
>> Info: Loading facts
>> Error: Could not autoload puppet/provider/package/gem: superclass must
>> be a Class (Module given)
>> Error: Facter: error while resolving custom facts in /opt/puppetlabs/
>> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/
>> provider/package/gem: superclass must be a Class (Module given)
>> Info: Caching catalog for eu-assist.aws-eu.int.luminoso.com
>> Info: Applying configuration version '1561063233'
>> Notice: Applied catalog in 15.24 seconds
>>
>>
>> SNIP #2
>> # puppet facts > /dev/null
>> Error: Could not autoload puppet/provider/package/gem: superclass must
>> be a Class (Module given)
>> Error: Facter: error while resolving custom facts in /opt/puppetlabs/
>> puppet/cache/lib/facter/package_provider.rb: Could not autoload puppet/
>> provider/package/gem: superclass must be a Class (Module given)
>> # facter -p > /dev/null
>> 2019-06-20 20:42:36.539351 ERROR puppetlabs.facter - error while
>> resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/
>> package_provider.rb: Could not autoload puppet/provider/package/gem:
>> superclass must be a Class (Module given)
>>
>> SNIP #3
>> # /opt/puppetlabs/puppet/bin/ruby
>> /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb
>> Traceback (most recent call last):
>> 15: from /opt/puppetlabs/puppet/cache/lib/facter/package_provider.rb:11:
>> in `'
>> 14: from
>> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>>
>> `require'
>> 13: from
>> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>>
>> `require'
>> 12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package
>> .rb:9:in `'
>> 11: from
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/package.rb:10:in `
>> '
>> 10: from
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/metatype/manager.rb:127:in
>>
>> `newtype'
>> 9: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload
>> .rb:215:in `loadall'
>> 8: from
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:79:in `
>> loadall'
>> 7: from
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:79:in
>> `each'
>> 6: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload
>> .rb:81:in `block in loadall'
>> 5: from
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:66:in `
>> load_file'
>> 4: from
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/autoload.rb:66:in
>> `load'
>> 3: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/
>> package/gem.rb:1:in `'
>> 2: from
>> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>>
>> `require'
>> 1: from
>> /opt/puppetlabs/puppet/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
>>
>> `require'
>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/
>> package_targetable.rb:23:in `': Could not autoload
>> puppet/provider/package/gem: superclass must be a Class (Module given)
>> (Puppet::Error)
>>
>>
--
You
Re: [Puppet Users] Sensitive type?
On 2019-06-20 13:31, Jason McMahan wrote:
Good day,
We were attempting to secure passwords appearing in files.
In the node manifest we changed
$password = lookup("user_cred.${username}.${domain_lookup}.password"))
to
$password =
Sensitive(lookup("user_cred.${username}.${domain_lookup}.password"))
In the resources file it correctly redacted the password, but when i open
C:\ProgramData\PuppetLabs\puppet\var\client_data\catalog\.json
It shows the password in plain text under the section
/etc/puppetlabs/code/environments/sensitive/site/profile/manifests/windows/domain/join.pp
but still redacted under the section
/etc/puppetlabs/code/environments/sensitive/modules/domain_membership/manifests/init.pp
How can redact the password in all locations?
Any help is greatly appreciated, thank you very much.
The catalog contains sensitive information in clear text and sets a flag
that the resource parameter is sensitive. You must treat a catalog as
sensitive information.
If you are seeing "redacted" in your catalog that means that compilation
transformed a Senstivie value into a String and used the string value in
the catalog. That must be a problem in your manifests (or a module).
The recommended secure way to handle secrets is to use the `Deferred`
feature in Puppet 6 and to use an external secrets server - for example
Vault. The Deferred feature make it possible to call functions on the
agent and this is used to lookup secrets with the agent's credentials.
Thus, there is never a secret in clear text during compilation, and thus
also not in the catalog. When the looked up value is produced on the
agent, it sets the clear text value in the resource and sets the flag
that indicates that it is sensitive. This is a signal to the puppet
resource harness to redact the information in reports and logs. A custom
provider may need to be reviewed and modified to ensure that it does not
spill a secret (for example, it may need to be changed to check if a
resource attribute is flagged as sensitive before logging it).
Hope that helps.
Best,
- henrik
Jason
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ed5873cf-a60b-4b66-b3f2-ad7f7714f9c3%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/qei3ui%242v73%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Core Modules with Puppet pre6?
Hi, has anyone tried what will happen if we place the Puppet 6 core modules in a Puppetfile when still having a Puppet 5.x agent? Will the agent still use the built-in types/providers? e.g. Puppetfile: mod 'puppetlabs/mount_core', :latest mod 'puppetlabs/augeas_core', :latest mod 'puppetlabs/zfs_core', :latest mod 'puppetlabs/yumrepo_core', :latest mod 'puppetlabs/host_core', :latest mod 'puppetlabs/selinux_core', :latest mod 'puppetlabs/zone_core', :latest mod 'puppetlabs/cron_core', :latest mod 'puppetlabs/sshkeys_core', :latest mod 'puppetlabs/nagios_core', :latest mod 'puppetlabs/mailalias_core', :latest mod 'puppetlabs/macdslocal_core', :latest mod 'puppetlabs/maillist_core', :latest mod 'puppetlabs/k5login_core', :latest Many thanks, Martin -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7213AA1A-AE0F-4E03-8135-78D57B02C3BD%40getmailspring.com. For more options, visit https://groups.google.com/d/optout.
