Jira (PUP-11591) file type parses MLS file contexts incorrectly.
Title: Message Title
Steve Traylen updated an issue
Puppet / PUP-11591
file type parses MLS file contexts incorrectly.
Change By:
Steve Traylen
*Puppet Version:* 7.17.0*Puppet Server Version:* 7.17.0*OS Name/Version:* CentOS 7 and CentOS 9 at least.When the file type encounters an selinux context with an MLS component.e.g. note the extra unusual c110,c289 below. {noformat} ls -lZ /etc/httpd/conf/http.conf -rw-r--r--. 1 root root system_u:object_r:httpd_config_t:s0:c110,c289 6 Jul 11 16:12 /etc/httpd/conf/http.conf{noformat} the selrange is incorrectly parsed as 's0:c110,c289' and not 's0' as it should be.The result is this considered a mismatch with desired configuration and puppet attempts to set the selrange to s0 which it does.However the mis parse remains and so puppet will forever try and change theselrange from ' 's0:c110,c289' to 's0'Steps to reproduce.Install CentOS 7 or 9 (probably 8 is okay as well just not tested.dnf install -y podman httpdThe context of /etc/httpd/conf/httpd.conf is now a perfectly normal: {noformat} ls -lZ /etc/httpd/conf/httpd.conf-rw-r--r--. 1 root root system_u:object_r:httpd_config_t:s0 12005 Jun 16 18:44 /etc/httpd/conf/httpd.conf{noformat} and puppet parses this perfectly as {noformat} # puppet resource file /etc/httpd/conf/httpd.conffile { '/etc/httpd/conf/httpd.conf': ensure => 'file', content => '{sha256}55b3dd635b5a56ebee1fe890d7372ec25c215cef0c0f3dd8f2bc5ae6e323da12', ctime=> '2022-07-11 15:37:15 +0200', group=> 0, mode => '0644', mtime=> '2022-06-16 18:44:10 +0200', owner=> 0, provider => 'posix', selrange => 's0', selrole => 'object_r', seltype => 'httpd_config_t', seluser => 'system_u', type => 'file',}{noformat} Now introduce MLS to equation. {noformat} podman run -it -v /etc/httpd:/etc/httpd:Z fedora /bin/bash{noformat} and now outside the container: {noformat} ls -lZ /etc/httpd/conf/http.conf-rw-r--r--. 1 root root system_u:object_r:httpd_config_t:s0:c110,c289 6 Jul 11 16:12 /etc/httpd/conf/http.conf{noformat} Note that the c110,c289 has quite correctly appeared.However the resource parse of this is: {noformat} file { '/etc/httpd/conf/http.conf': ensure => 'file', content => '{sha256}c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2', provider => 'posix', selrange => 's0:c110,c289', selrole => 'object_r', seltype => 'httpd_config_t', seluser => 'system_u',}{noformat} The selrange is wrong and it should be still 's0'This is mismatch as compared to {noformat} # matchpathcon /etc/httpd/conf/http.conf /etc/httpd/conf/http.conf system_u:object_r:httpd_config_t:s0{noformat} and so puppet pointless trys pointlessly tries to set the selrange back to s0 which it does but this is then a loop. {noformat} # puppet resource file /etc/httpd/conf/http.conf 'content=foobar'Notice: /File[/etc/httpd/conf/http.conf]/selrange: selrange changed 's0:c110,c289' to 's0'file { '/etc/httpd/conf/http.conf': ensure => 'file', content =>
Jira (PUP-11591) file type parses MLS file contexts incorrectly.
Title: Message Title Steve Traylen created an issue Puppet / PUP-11591 file type parses MLS file contexts incorrectly. Issue Type: Bug Affects Versions: PUP 7.17.0 Assignee: Unassigned Components: Types and Providers Created: 2022/07/11 7:33 AM Environment: CentOS 7 and 9 at least. Priority: Normal Reporter: Steve Traylen Puppet Version: 7.17.0 Puppet Server Version: 7.17.0 OS Name/Version: CentOS 7 and CentOS 9 at least. When the file type encounters an selinux context with an MLS component. e.g. note the extra unusual c110,c289 below. ls -lZ /etc/httpd/conf/http.conf -rw-r--r--. 1 root root system_u:object_r:httpd_config_t:s0:c110,c289 6 Jul 11 16:12 /etc/httpd/conf/http.conf the selrange is incorrectly parsed as 's0:c110,c289' and not 's0' as it should be. The result
Jira (FACT-3115) virt-what-1.22-1 changes virtual=kvm to virtual=redhat
Title: Message Title Steve Traylen commented on FACT-3115 Re: virt-what-1.22-1 changes virtual=kvm to virtual=redhat Adding virt-what backto puppet-agent would of course help here - https://tickets.puppetlabs.com/browse/PA-4423 which is probably why that ticket has jumped into some action. Anyone looking for quick stop gap, a custom fact to override this particular case virtual.rb Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.444600.1650614566000.16376.1650632460033%40Atlassian.JIRA.
Jira (FACT-3115) virt-what-1.22-1 changes virtual=kvm to virtual=redhat
Title: Message Title Steve Traylen updated an issue Facter / FACT-3115 virt-what-1.22-1 changes virtual=kvm to virtual=redhat Change By: Steve Traylen Attachment: virtual.rb Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.444600.1650614566000.16375.1650632400180%40Atlassian.JIRA.
Jira (FACT-3115) virt-what-1.22-1 changes virtual=kvm to virtual=redhat
Title: Message Title Steve Traylen created an issue Facter / FACT-3115 virt-what-1.22-1 changes virtual=kvm to virtual=redhat Issue Type: Bug Affects Versions: FACT 4.2.5 Assignee: Unassigned Components: Facter 4 Created: 2022/04/22 1:02 AM Priority: Normal Reporter: Steve Traylen The package virt-what-1.22-1.el9.x86_64 just landed in CentOS 9 . This upgrade changes virt-what's output from # virt-what kvm to # virt-what redhat
Jira (FACT-3112) Stack trace on invalid facts.d entry
Title: Message Title
Steve Traylen created an issue
Facter / FACT-3112
Stack trace on invalid facts.d entry
Issue Type:
Improvement
Affects Versions:
FACT 4.2.5
Assignee:
Unassigned
Components:
Facter 4
Created:
2022/03/31 12:50 AM
Environment:
CentOS 7 puppet-agent-7.12.0.7.g9fc268bde-4.config8s.x86_64
Priority:
Normal
Reporter:
Steve Traylen
We had a bad fact.s fact:
/etc/facter/facts.d/queue.py
{ "": }
That is invalid json:
#
Jira (FACT-3106) No virt-what in puppet-agent 7 so is_virtual is wrong
Title: Message Title Steve Traylen commented on FACT-3106 Re: No virt-what in puppet-agent 7 so is_virtual is wrong For similar reasons requiring pciutils for lspci is also a good idea. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.434970.1644582226000.3624.1647448980033%40Atlassian.JIRA.
Jira (FACT-3106) No virt-what in puppet-agent 7 so is_virtual is wrong
Title: Message Title Steve Traylen updated an issue Facter / FACT-3106 No virt-what in puppet-agent 7 so is_virtual is wrong Change By: Steve Traylen In factor the is_virtual and other similar facts is are very dependent upon thevirt-whatcommand being availabe available . Since this commit to puppet-agent[https://github.com/puppetlabs/puppet-agent/commit/a1a06ba3f42419e]virt-what was removed from the puppet-agent package.I expect it may have been an unintentional consequence to stop these core facts from working out of the box with the puppet-agent package?Installing the system provide provided virt-what and everything works again but this should be a dep or at least documented if that is the way forward. For reference some history on the subject.https://tickets.puppetlabs.com/browse/FACT-822 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group
Jira (FACT-3106) No virt-what in puppet-agent 7 so is_virtual is wrong
Title: Message Title Steve Traylen created an issue Facter / FACT-3106 No virt-what in puppet-agent 7 so is_virtual is wrong Issue Type: Improvement Affects Versions: FACT 4.2.7 Assignee: Unassigned Components: Facter 4 Created: 2022/02/11 4:23 AM Environment: puppet-agent 7 facter 4 Priority: Normal Reporter: Steve Traylen In factor the is_virtual and other similar facts is very dependent upon the virt-what command being availabe. Since this commit to puppet-agent https://github.com/puppetlabs/puppet-agent/commit/a1a06ba3f42419e virt-what was removed from the puppet-agent package. I expect it may have been an unintentional consequence to stop these core facts from working out of the box with the puppet-agent package? Installing the system provide virt-what and everything works again but this should be a dep or at least documented if that is the way forward. For reference some history on the subject. https://tickets.puppetlabs.com/browse/FACT-822
Jira (FACT-3099) Caching UTF8 values results in "\\xCC" from ASCII-8BIT to UTF-8
Title: Message Title Steve Traylen commented on FACT-3099 Re: Caching UTF8 values results in "\\xCC" from ASCII-8BIT to UTF-8 Should have added that with facter 3.14.15 the cache is created correctly as UTF-8. ``` file /opt/puppetlabs/facter/cache/cached_facts/EC2 /opt/puppetlabs/facter/cache/cached_facts/EC2: UTF-8 Unicode text, with very long lines ``` and the returned value from cache is UTF-8. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.424265.1637249217000.10512.1637249940059%40Atlassian.JIRA.
Jira (FACT-3099) Caching UTF8 values results in "\\xCC" from ASCII-8BIT to UTF-8
Title: Message Title
Steve Traylen updated an issue
Facter / FACT-3099
Caching UTF8 values results in "\\xCC" from ASCII-8BIT to UTF-8
Change By:
Steve Traylen
This is with the ec2_userdata fact but I expect true for any fact where the value is UTF-8 and the fact is cached.Userdata is utf-8{noformat}curl --silent http://169.254.169.254/openstack/latest/user_data | grep --color='auto' -P "[^[:ascii:]]" - [ vdb, /build1, "xfs", "nofail̦", "0", "0" ]{noformat}When this is cached via a configuration of {noformat}facts: { ttls: [ { "EC2": "7 days" } ]}{noformat}Then this results in a debug of{noformat}facter --debug ec2_userdata[2021-11-18 16:13:40.964313 ] DEBUG Facter::Util::Resolvers::Http - Request to http://169.254.169.254/latest/api/token failed with error code 404 [2021-11-18 16:13:42.090980 ] DEBUG Facter::CacheManager - EC2 facts cache file expired, missing or is corrupt [2021-11-18 16:13:42.091039 ] DEBUG Facter::CacheManager - caching values for EC2 facts Traceback (most recent call last): 15: from /opt/puppetlabs/puppet/bin/facter:10:in `' 14: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/cli/cli_launcher.rb:23:in `start' 13: from /opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/base.rb:485:in `start' 12: from /opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch' 11: from /opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command' 10: from /opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run' 9: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/cli/cli.rb:124:in `query' 8: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb:454:in `to_user_output' 7: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb:521:in `resolve_facts_for_user_query' 6: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/fact_manager.rb:29:in `resolve_facts' 5: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/cache_manager.rb:38:in `cache_facts' 4: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/cache_manager.rb:166:in `write_cache' 3: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/cache_manager.rb:166:in `each' 2: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/cache_manager.rb:175:in `block in write_cache' 1: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/json/common.rb:286:in `pretty_generate'/opt/puppetlabs/puppet/lib/ruby/2.7.0/json/common.rb:286:in `generate': "\\xCC" from
Jira (FACT-3099) Caching UTF8 values results in "\\xCC" from ASCII-8BIT to UTF-8
Title: Message Title
Steve Traylen created an issue
Facter / FACT-3099
Caching UTF8 values results in "\\xCC" from ASCII-8BIT to UTF-8
Issue Type:
Bug
Affects Versions:
FACT 4.2.5
Assignee:
Unassigned
Components:
Facter 4
Created:
2021/11/18 7:26 AM
Priority:
Normal
Reporter:
Steve Traylen
This is with the ec2_userdata fact but I expect true for any fact where the value is UTF-8 and the fact is cached. Userdata is utf-8
curl --silent http://169.254.169.254/openstack/latest/user_data | grep --color='auto' -P "[^[:ascii:]]"
- [ vdb, /build1, "xfs", "nofail̦", "0", "0" ]
When this is cached via a configuration of
facts: {
Jira (FACT-3097) hypervisor.kvm = openstack is null for facter 4
Title: Message Title Steve Traylen commented on FACT-3097 Re: hypervisor.kvm = openstack is null for facter 4 debug log on facter 4 is [2021-11-18 14:53:07.653582 ] DEBUG Facter::Core::Execution::Posix - Executing command: virt-what [2021-11-18 14:53:07.702762 ] DEBUG Facter::Core::Execution::Posix - Executing command: lspci [2021-11-18 14:53:07.704784 ] DEBUG Facter::Core::Execution::Posix - Failed while executing 'lspci': No such file or directory - lspci [2021-11-18 14:53:07.705000 ] DEBUG Facts::Linux::Hypervisors::Vmware - No Vmware hypervisor detected. [2021-11-18 14:53:07.705066 ] DEBUG Facts::Linux::Hypervisors::Kvm - Detected product name: OpenStack Compute [2021-11-18 14:53:07.705122 ] DEBUG Facts::Linux::Hypervisors::Kvm - Detected hypervisor OpenStack Compute [2021-11-18 14:53:07.705333 ] DEBUG Facts::Linux::Hypervisors::Kvm - Detected bios vendor: SeaBIOS [2021-11-18 14:53:07.705375 ] DEBUG Facts::Linux::Hypervisors::Kvm - Detected manufacturer: RDO [2021-11-18 14:53:07.705527 ] DEBUG Facts::Linux::Hypervisors::Xen - No Xen hypervisor detected.
Jira (FACT-3098) partitions fact can break on non readable /broken filesystem
Title: Message Title
Steve Traylen commented on FACT-3098
Re: partitions fact can break on non readable /broken filesystem
Please close this. With a newer facter 4 all is good.
# facter --version && facter partitions
4.2.5
{
/dev/vda1 => {
filesystem => "xfs",
mount => "/",
size => "160.00 GiB",
size_bytes => 171797626368,
uuid => "632f04d6-0d40-44f5-ad88-8adede6434d4"
}
}
Jira (FACT-3098) partitions fact can break on non readable /broken filesystem
Title: Message Title Steve Traylen created an issue Facter / FACT-3098 partitions fact can break on non readable /broken filesystem Issue Type: Bug Affects Versions: FACT 4.0.44 Assignee: Unassigned Components: Facter 4 Created: 2021/11/18 5:28 AM Priority: Normal Reporter: Steve Traylen Actually with /opt/puppetlabs/puppet/bin/facter-ng --version 4.0.49 results in /opt/puppetlabs/puppet/bin/facter-ng partitions [2021-11-18
Jira (FACT-3097) hypervisor.kvm = openstack is null for facter 4
Title: Message Title
Steve Traylen created an issue
Facter / FACT-3097
hypervisor.kvm = openstack is null for facter 4
Issue Type:
Bug
Affects Versions:
FACT 4.2.5
Assignee:
Unassigned
Components:
Facter 4
Created:
2021/11/18 4:30 AM
Priority:
Normal
Reporter:
Steve Traylen
With facter 3.14.15
# facter hypervisors
{
kvm => {
openstack => true
}
}
Jira (PUP-11167) Provider redhat must have features 'maskable' to set 'enable' to 'mask' during rspec-puppet testing
Title: Message Title Steve Traylen commented on PUP-11167 Re: Provider redhat must have features 'maskable' to set 'enable' to 'mask' during rspec-puppet testing Please re-consider this won't fix. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.406490.1625845962000.151448.1633952100033%40Atlassian.JIRA.
Jira (PUP-10814) Impossible to systemctl mask non-existing service
Title: Message Title
Steve Traylen updated an issue
Puppet / PUP-10814
Impossible to systemctl mask non-existing service
Change By:
Steve Traylen
*Puppet Version: 6.15.0* *Puppet Server Version: 6.15.0* *OS Name/Version: CentOS 8*puppet apply the following snippet{noformat}service{'non-existing.service': ensure => mask,}{noformat}results in. {noformat}Error: Could not disable foobar non-existing .service: Error: /Stage[main]/Main/Service[non-existing.service]/enable: change from 'false' to 'mask' failed: Could not disable foobar.service:{noformat} *Desired Behavior:*A service can be masked irrespective of if the unit exists.{noformat}systemctl mask non-existing.serviceUnit non-existing.service does not exist, proceeding anyway.Created symlink /etc/systemd/system/non-existing.service → /dev/null.{noformat}and this is desirable since you want to mask things to stop a vendor settingwinning later.puppet should proceed with the above mask for a non-existant service. *Actual Behavior:*The non-existant unit is not masked.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10814) Impossible to systemctl mask non-existing service
Title: Message Title Steve Traylen created an issue Puppet / PUP-10814 Impossible to systemctl mask non-existing service Issue Type: Bug Affects Versions: PUP 6.15.0 Assignee: Unassigned Components: Catalog Application Created: 2020/12/08 4:10 AM Environment: // code placeholder Priority: Normal Reporter: Steve Traylen Puppet Version: 6.15.0 Puppet Server Version: 6.15.0 OS Name/Version: CentOS 8 puppet apply the following snippet
Jira (PUP-10626) puppet node deactivate and external CA - cert revocation can't be disabled
Title: Message Title Steve Traylen commented on PUP-10626 Re: puppet node deactivate and external CA - cert revocation can't be disabled Close this. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.369661.1597828121000.31262.1599465780119%40Atlassian.JIRA.
Jira (PUP-10626) puppet node deactivate and external CA - cert revocation can't be disabled
Title: Message Title Steve Traylen commented on PUP-10626 Re: puppet node deactivate and external CA - cert revocation can't be disabled Thanks for replying, A bit more info. It seems to be more to do with CRL download then certificate revoke. Attached configuration and trace of a node deactivate. It's probably also worth adding that puppet agent -t -v results in a warning. Info: Certificate revocation is disabled, skipping CRL download and checking puppet agent --genconfig | grep certificate_revoca certificate_revocation = false which is guess default for agent section of configuration file. Now puppet node deactivate webafs617.cern.ch does work if I explicitly add puppet node deactivate webafs617.cern.ch certificate_revocation = false to the main section. So if anything the only problem is that default value for puppet agent and puppet node deactivate seems to be different. In real life not actual problem here for us. We can set "certificate_revocation = false" . We shoudl probably actually enable CRLs of course but that is a different problem. puppet.conf trace.txt Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.369661.1597828121000.22049.1598262240337%40Atlassian.JIRA.
Jira (PUP-10626) puppet node deactivate and external CA - cert revocation can't be disabled
Title: Message Title Steve Traylen updated an issue Puppet / PUP-10626 puppet node deactivate and external CA - cert revocation can't be disabled Change By: Steve Traylen Attachment: trace.txt Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.369661.1597828121000.22039.1598262060231%40Atlassian.JIRA.
Jira (PUP-10626) puppet node deactivate and external CA - cert revocation can't be disabled
Title: Message Title Steve Traylen updated an issue Puppet / PUP-10626 puppet node deactivate and external CA - cert revocation can't be disabled Change By: Steve Traylen Attachment: puppet.conf Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.369661.1597828121000.22038.1598262060190%40Atlassian.JIRA.
Jira (PUP-10626) puppet node deactivate and external CA - cert revocation can't be disabled
Title: Message Title Steve Traylen created an issue Puppet / PUP-10626 puppet node deactivate and external CA - cert revocation can't be disabled Issue Type: Bug Affects Versions: PUP 6.15.0 Assignee: Unassigned Created: 2020/08/19 2:08 AM Priority: Normal Reporter: Steve Traylen Puppet Version: 6.15.0 Puppet Server Version: 6.11.1 OS Name/Version: CentOS 7 When using an external certificate authority it's assumed that a working puppet-ca endpoint is not required. However `puppet node deactivate` always attempts a revocation and fails as a result. Desired Behavior: puppet node deactivate foo.example.org should delete node from PDB as is the case with puppetdb 5 Actual Behavior: With puppet 6 puppet node deactivate b7g19n0014.cern.ch Error: Request to https://puppet:8140/puppet-ca/v1 failed after 0.004 seconds: Failed to open TCP connection to puppet:8140 (getaddrinfo: Name or service not known) Wrapped exception: we have no configuration for ca_server so default puppet is chosen. For info we are running pupetserver with: cat /etc/puppetlabs/puppetserver/services.d/ca.cfg puppetlabs.services.ca.certificate-authority-disabled-service/certificate-authority-disabled-service
Jira (FACT-2535) Implement to_s on ResolvedFact
Title: Message Title Steve Traylen commented on FACT-2535 Re: Implement to_s on ResolvedFact Just adding that `.to_s` used to happen with facter 3.11.6 at least. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.353994.1585839979000.29026.1585840980135%40Atlassian.JIRA.
Jira (BOLT-924) Support kerberos puppetdb endpoint
Title: Message Title
Steve Traylen commented on BOLT-924
Re: Support kerberos puppetdb endpoint
Got a bit further with this , now with a configuration.
puppetdb:
krb: true
server_urls: ["https://constable.example.ch:9081"]
then
bolt command run uptime -q 'facts[certname] { name = "hostgroup" and value = "aiadm/nodes/login" }'
works as expected and queries puppetdb with a kerberos token. This is still using rubygem-curb, httpi and socksify as extra gem dependencies. There is probably a lighter way to do it. https://github.com/cernops/bolt/commit/addeb4fd2decddd3e59b3ee09bf1e74de4bfd291 and deps. https://github.com/cernops/puppet-runtime/commit/71ff7c0c94202436c8fab350bde8c2d01c3a8b7f https://github.com/cernops/puppet-runtime/commit/28fc46338b9f6bb5fca5a9359b3cc73d83028da3 I'll deploy this tommorow for for some user feedback.
Add Comment
Jira (BOLT-859) System level configuration e.g /etc/puppetlabs/bolt
Title: Message Title Steve Traylen commented on BOLT-859 Re: System level configuration e.g /etc/puppetlabs/bolt Was advised to expand the use case here . So as well as central bolt configuration a central inventory file would also be useful. So typical case for is we have ~100 folk running remote procedures on puppet managed nodes. We would want to centrally maintain (with puppet) an inventory file and a configuration. We would centrally manage e.g puppetdb endpoints but in the inventory file we would also maintain maybe many groups of nodes represented as a puppetdb queries of the clusters which we already have our infrastructure split up into. In ideal world inventory files could be extended of over riden from a user based files but not a necessity. I think this ticket is an exact duplicate of BOLT-821 one by the way. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.277020.1537792033000.34857.1559738640575%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3801) PuppetDB migration stuck (31) fact_values.
Title: Message Title Steve Traylen commented on PDB-3801 Re: PuppetDB migration stuck (31) fact_values. Close.me. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9498) Calling hiera first nullifies lookup_options.
Title: Message Title
Steve Traylen updated an issue
Puppet / PUP-9498
Calling hiera first nullifies lookup_options.
Change By:
Steve Traylen
This change in behaviour occurred between 5.4.0 and 5.5.0If the hiera function is called on a module namespace $a = hiera(module::foo)before any lookup call $ = lookup('module::bar)on that same namespace then lookup_options on the module level data is never looked up.All subsequent lookups (or hiera) can then be wrong.Attached is a test case module.bundle install # The following command will fail tests bundle exec rake test# The following command will pass testsPUPPET_VERSION=5.4.0 bundle updatePUPPET_VERSION=5.4.0 bundle exec rake testThe failing file is{noformat}class lookupparam::hierafirst { $notusedhiera = hiera('lookupparam::notusedhiera',foobar) $notusedlookup = lookup('lookupparam::notusedlookup',String,'first',foobar) $testparam = lookup('lookupparam::testparam') notify{$testparam:}} {noformat}The call of hiera('lookupparam::notusedhiera') is enough to beak break all the other lookups and in particular in this case $testparam ignores the lookup_options which are present in the module level data.In addition this hardly ever happens in real would since modules typically have parameters and that is enough to cause the lookup. The particular case where we run into this was {noformat}class whatever ( $a = 'abc',) inherits whatever::params { ...}class whatever { $myvar = hiera('whatever::param') }{noformat}Closing this won't fix is fine with me. To trigger this you must usethe deprecated hiera function and lookup_options in the same module and thatis probably a bad idea anyway.
Add Comment
Jira (PUP-9498) Calling hiera first nullifies lookup_options.
Title: Message Title
Steve Traylen updated an issue
Puppet / PUP-9498
Calling hiera first nullifies lookup_options.
Change By:
Steve Traylen
This change in behaviour occurred between 5.4.0 and 5.5.0If the hiera function is called on a module namespace $a = hiera(module::foo)before any lookup call $ = lookup('module::bar)on that same namespace then lookup_options on the module level data is never looked up.All subsequent lookups (or hiera) can then be wrong.Attached is a test case module.bundle install # The following command will fail tests bundle exec rake test# The following command will pass testsPUPPET_VERSION=5.4.0 bundle updatePUPPET_VERSION=5.4.0 bundle exec rake testThe failing file is{noformat}class lookupparam::hierafirst { $notusedhiera = hiera('lookupparam::notusedhiera',foobar) $notusedlookup = lookup('lookupparam::notusedlookup',String,'first',foobar) $testparam = lookup('lookupparam::testparam') notify{$testparam:}} {noformat}The call of hiera('lookupparam::notusedhiera') is enough to break all the other lookups and in particular in this case $testparam ignores the lookup_options which are present in the module level data.In addition this hardly ever happens in real would since modules typically have parameters and that is enough to cause the lookup. The particular case where we run into this was {noformat}class whatever ( $a = 'abc',) inherits whatever::params { ...}class whatever ::params { $myvar = hiera('whatever::param') }{noformat}Closing this won't fix is fine with me. To trigger this you must usethe deprecated hiera function and lookup_options in the same module and thatis probably a bad idea anyway.
Add Comment
Jira (PUP-9498) Calling hiera first nullifies lookup_options.
Title: Message Title
Steve Traylen created an issue
Puppet / PUP-9498
Calling hiera first nullifies lookup_options.
Issue Type:
Bug
Affects Versions:
PUP 5.5.8
Assignee:
Unassigned
Attachments:
puppet-lookupparam-3.0.0.tar.gz
Components:
Compiler
Created:
2019/02/14 5:12 AM
Priority:
Normal
Reporter:
Steve Traylen
This change in behaviour occurred between 5.4.0 and 5.5.0 If the hiera function is called on a module namespace $a = hiera(module::foo) before any lookup call $ = lookup('module::bar) on that same namespace then lookup_options on the module level data is never looked up. All subsequent lookups (or hiera) can then be wrong. Attached is a test case module. bundle install
The following command will fail tests bundle exec rake test
The following command will pass tests PUPPET_VERSION=5.4.0 bundle update PUPPET_VERSION=5.4.0 bundle exec rake test
The failing file is
class
Jira (PUP-9345) Resource defaults are no longer evaluation-order independent
Title: Message Title
Steve Traylen commented on PUP-9345
Re: Resource defaults are no longer evaluation-order independent
It's probably obvious but should have said:
File{
mode => '0777',
}
file{'/tmp/junk.txt':
ensure => file,
content => "content\n",
}
with the default specified first works just fine.
Add Comment
Jira (PUP-9345) Resource defaults are no longer evaluation-order independent
Title: Message Title
Steve Traylen updated an issue
Puppet / PUP-9345
Resource defaults are no longer evaluation-order independent
Change By:
Steve Traylen
*Puppet Version: 6.0.4 *Puppet Server Version: n/a *OS Name/Version: CentOS 7.From the [docs|https://puppet.com/docs/puppet/5.5/lang_defaults.html#behavior]:Resource defaults are evaluation-order independent — that is, a default affects resource declarations written both above and below it.This is no longer the case since release 4.10.5.*Desired Behavior:*puppet apply the following manifest:{noformat}file{'/tmp/junk.txt': ensure => present, content => "junk\n",}File{ mode => '0777',}{noformat}This should result in a file with ownership mode '0777'.Running with puppet 4.9.4:{noformat}Notice: /Stage[main]/Main/File[/tmp/file.txt]/ensure: defined content as '{md5}477fbe8ae54fcb5effa415227ec05cb4'Notice: Applied catalog in 0.07 seconds-rwxrwxrwx. 1 straylen c3 13 Dec 6 20:36 /tmp/file.txt{noformat}*Actual Behavior:*Running with current HEAD 6.0.4+{noformat}rm /tmp/file.txt && bundle exec puppet apply ~/tmp/apply.pp && ls -l /tmp/file.txtNotice: Compiled catalog for aiadm83.cern.ch in environment production in 0.05 secondsNotice: /Stage[main]/Main/File[/tmp/file.txt]/ensure: defined content as '{md5}477fbe8ae54fcb5effa415227ec05cb4'Notice: Applied catalog in 0.32 seconds-rw-r--r--. 1 straylen c3 13 Dec 6 20:35 /tmp/file.txt{noformat}The file is not '0777' as the defaults were never applied.Running a git bisect the patch that introduced this behaviour is[https://github.com/puppetlabs/puppet/commit/38413cd78c61fe34d2ee343ef773a07b4786f65a]Note the same behaviour is observed in both a simple manifest like above or if global default parameters are attempted via the site.pp file.
Add Comment
Jira (PUP-9345) Resource defaults are no longer evaluation-order independent
Title: Message Title
Steve Traylen created an issue
Puppet / PUP-9345
Resource defaults are no longer evaluation-order independent
Issue Type:
Bug
Affects Versions:
PUP 6.0.4
Assignee:
Unassigned
Components:
Compiler
Created:
2018/12/06 11:43 AM
Priority:
Normal
Reporter:
Steve Traylen
*Puppet Version: 6.0.4 *Puppet Server Version: n/a *OS Name/Version: CentOS 7. From the docs: Resource defaults are evaluation-order independent — that is, a default affects resource declarations written both above and below it. This is no longer the case since release 4.10.5. Desired Behavior: puppet apply the following manifest:
file{'/tmp/junk.txt':
ensure => present,
content => "junk\n",
}
Jira (BOLT-924) Support kerberos puppetdb endpoint
Title: Message Title Steve Traylen commented on BOLT-924 Re: Support kerberos puppetdb endpoint We got something working but only by switching to httpi https://its.cern.ch/jira/browse/AI-5303 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-924) Support kerberos puppetdb endpoint
Title: Message Title Steve Traylen created an issue Puppet Task Runner / BOLT-924 Support kerberos puppetdb endpoint Issue Type: New Feature Affects Versions: BOLT 0.21.8 Assignee: Unassigned Components: CLI Created: 2018/10/12 5:09 AM Priority: Normal Reporter: Steve Traylen We expose our puppetdb via a kerberos endpoint. Looks like: https://github.com/zenchild/gssapi/wiki may offer a solution. Add Comment
Jira (BOLT-859) System level configuration e.g /etc/puppetlabs/bolt
Title: Message Title Steve Traylen created an issue Puppet Task Runner / BOLT-859 System level configuration e.g /etc/puppetlabs/bolt Issue Type: New Feature Affects Versions: BOLT 0.21.8 Assignee: Unassigned Components: CLI Created: 2018/09/24 5:27 AM Priority: Normal Reporter: Steve Traylen Hi, I think it would be useful to support a default system level configuration file. e.g. /etc/puppetlabs/bolt/bolt.yaml for instance. This would allow one centrally maintained configuration to be used by many users of bolt on a system. Add Comment
Jira (PDB-3801) PuppetDB migration stuck (31) fact_values.
Title: Message Title Steve Traylen commented on PDB-3801 Re: PuppetDB migration stuck (31) fact_values. In reality not stuck - stage 31 just takes 14 hours for us Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3801) PuppetDB migration stuck (31) fact_values.
Title: Message Title Steve Traylen created an issue PuppetDB / PDB-3801 PuppetDB migration stuck (31) fact_values. Issue Type: Bug Affects Versions: PDB 4.4.0 Assignee: Unassigned Components: PuppetDB Created: 2017/12/27 1:17 AM Environment: Upgrade puppetdb 2.3.8 -> 4.4.0 CentOS 7 Postgres 9.6.2 35.7 K hosts. Priority: Normal Reporter: Steve Traylen Trying to test the schema update on a dump of current 2.3.8 puppetdb database. The migration appears to get stuck during 31. 2017-12-26 17:05:16,725 INFO [c.z.h.HikariDataSource] PDBWritePool - is starting.
Jira (FACT-1558) Facter fails if current working directory has been removed.
Title: Message Title Steve Traylen commented on FACT-1558 Re: Facter fails if current working directory has been removed. Reported again to me, so someone else hit this. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1558) Facter fails if current working directory has been removed.
Title: Message Title Steve Traylen commented on FACT-1558 Re: Facter fails if current working directory has been removed. In life just once, I was debugging something in the plugin sync directory, removed some modules so the directory was removed and then this error occured. The fact that a core dump is created triggers abrt which raises an operations alarm of crashed puppet-agent. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1558) Facter fails if current working directory has been removed.
Title: Message Title Steve Traylen commented on FACT-1558 Re: Facter fails if current working directory has been removed. Would be good catch this I'd say. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1640) Add Puppet settings as facts
Title: Message Title Steve Traylen commented on FACT-1640 Re: Add Puppet settings as facts The existing puppet_settings.rb from stdlib is very much in this area. A few more values in that is probably enough. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1640) Add Puppet settings as facts
Title: Message Title
Steve Traylen commented on FACT-1640
Re: Add Puppet settings as facts
A use case from
FACT-475
.
$bar = some_function($::fqdn)
file{'/etc/facter/facts.d/myfact.txt':
ensure => present,
content => "foo=${bar}\n"
}
Not having a hard coded value above would be nice. More
Add Comment
Jira (FACT-475) Default external-dir should be exposed as a core fact
Title: Message Title Steve Traylen commented on FACT-475 Re: Default external-dir should be exposed as a core fact Currently not even '/etc/puppetlabs' is available as a fact, that would probably do. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-475) Default external-dir should be exposed as a core fact
Title: Message Title
Steve Traylen commented on FACT-475
Re: Default external-dir should be exposed as a core fact
Hi,
Yes we have a use case.We calculate facts within manifests to deploy static files. e.g.
$bar = some_function($::fqdn)
file{'/etc/facter/facts.d/myfact.txt':
ensure => present,
content => "foo=${bar}\n"
}
Having a fact for /etc/facter/facts.d would avoid us having to hard code that path.
The obvious question is why bother to write the fact foo given we already have it's value during the compilation. We use the fact value from puppetdb for inventory calculations.
Add Comment
Jira (PUP-7577) augeas does not error if no suitable lens found
Title: Message Title
Steve Traylen created an issue
Puppet / PUP-7577
augeas does not error if no suitable lens found
Issue Type:
Bug
Affects Versions:
PUP 4.8.1
Assignee:
Unassigned
Created:
2017/05/19 12:59 AM
Environment:
puppet-agent-1.8.2.10.g44e8319-1.ai7.x86_64
Labels:
augeas
Priority:
Normal
Reporter:
Steve Traylen
There are various similar reports but I could not find an existing bug.
Running an augeas type when a suitable lens cannot be found results in no augeas change and so no puppet notification.
Running pupept apply with
augeas {
Jira (PUP-7189) Add a fact value to log entries for subsequent classification
Title: Message Title Steve Traylen commented on PUP-7189 Re: Add a fact value to log entries for subsequent classification > I'm not quite sure what you're getting at. Are you trying to associate the error with catalog compilation for a specific node? What would that fact be associated with? The fact would be associated with the node which produced the compilation error. Currently the fqdn is logged and this is of course very important and useful But one more fact would allow logs to be grouped by that fact very easily. So if my computer centre is cut up into partitions of nodetype=webserver , nodetype=databases, nodetypes=appplication. Then being to have that fact on the log line as well as the fqdn would make classification by nodetype so much easier. Clearly the particular factname should be a configuration. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7189) Add a fact value to log entries for subsequent classification
Title: Message Title Steve Traylen updated an issue Puppet / PUP-7189 Add a fact value to log entries for subsequent classification Change By: Steve Traylen Summary: Add a fact value to log entries for subsequen subsequent classification Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7189) Add a fact value to log entries for subsequen classification
Title: Message Title Steve Traylen created an issue Puppet / PUP-7189 Add a fact value to log entries for subsequen classification Issue Type: New Feature Assignee: Unassigned Created: 2017/02/08 1:37 AM Priority: Normal Reporter: Steve Traylen Currently a pupetserver log typically looks like 2017-02-08 10:26:16,804 ERROR [qtp786679167-66] [puppetserver] Puppet Evaluation Error: A substring operation does not accept a String as a character index. Expected an Integer at /mnt/puppetnfsdir/environments/rtb4/ modules/dbhadoop/manifests/hive.pp:152:59 on node lxbrf39c04.cern.ch I think it would be super useful if a configuration could be added custom_log_format or custom_log_facts that would add a particular fact. e.g mynodetype=mywebserver or something. This would make classification of the logs by some predefined value a lot easier. Add Comment
Jira (PUP-4686) environment_timeout is not loaded from [master] section.
Title: Message Title Steve Traylen commented on PUP-4686 Re: environment_timeout is not loaded from [master] section. https://docs.puppet.com/puppet/4.8/environments_configuring.html#environmentpath it is indeed documented now that environmentpath must be in [main] let's close this and say environmnet_timeout must also be in main. Close me. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (HI-127) Allow escaping %{...} in hiera data to avoid replacement (add literal function)
Title: Message Title
Steve Traylen assigned an issue to Unassigned
Hiera / HI-127
Allow escaping %{...} in hiera data to avoid replacement (add literal function)
Change By:
Steve Traylen
Assignee:
Steve Traylen
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (HI-127) Allow escaping %{...} in hiera data to avoid replacement (add literal function)
Title: Message Title
Steve Traylen assigned an issue to Steve Traylen
Hiera / HI-127
Allow escaping %{...} in hiera data to avoid replacement (add literal function)
Change By:
Steve Traylen
Assignee:
Steve Traylen
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5646) fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
Title: Message Title Steve Traylen commented on PUP-5646 Re: fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used. Many thanks to all. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5646) fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
Title: Message Title Steve Traylen commented on PUP-5646 Re: fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used. It's not the distribution between host A and host B that is at sub optimal. It is the relationship between fqdn_rand(N) and fqdn_rand(M) on the one host which are seeded identically. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5646) fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
Title: Message Title
Steve Traylen commented on PUP-5646
Re: fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
I have some deployed numbers now for comparison. For a weekly cron job
cron{'/bin/true':
hour => fqdn_rand(24),
min => fqdn_rand(60),
day => fqdn_rand(7)
}
There should be 24 * 60 * 7 = 10080 possible slots for the above cron job.
production env with 14865 hosts only 638 slots are used.
qa env with 1878 hosts we are using 1699 slots.
The qa env has the proposed change.
Add Comment
Jira (PUP-5646) fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
Title: Message Title
Steve Traylen created an issue
Puppet / PUP-5646
fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
newresults.dat, newresults.png, results.dat, results.png, test_fqdn.rb
Created:
2016/01/04 7:15 AM
Priority:
Normal
Reporter:
Steve Traylen
Take the very typical code for once per day cron on 5 hosts named 1.example.org, 2.example.org , ...
cron{'/bin/true':
minute => fqdn_rand(60),
hour=> fqdn_rand(24)
Jira (PUP-5646) fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used.
Title: Message Title Steve Traylen commented on PUP-5646 Re: fqdn_rand in real world - only 336 of possible 1440 daily cron slots ever used. https://github.com/puppetlabs/puppet/pull/4543 implements to the trivial change to include max in the seed input. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5153) Catch yum stacktraces in yum-helper.py
Title: Message Title Steve Traylen created an issue Puppet / PUP-5153 Catch yum stacktraces in yum-helper.py Issue Type: Improvement Affects Versions: PUP 3.8.0 Assignee: Unassigned Created: 2015/09/02 5:33 AM Labels: yum Priority: Normal Reporter: Steve Traylen python /usr/share/ruby/vendor_ruby/puppet/provider/package/yumhelper.py can produces ugly stack traces which are also caught by abrt... Given these are normally just transient errors it would be good to catch these as yum does. Steps to reproduce: 1. Vandalize a yum reposiotry metadata file e.g enter a non-existent hostname. [myrepo]
Jira (PUP-4686) environment_timeout is not loaded from [master] section.
Title: Message Title Steve Traylen commented on PUP-4686 Re: environment_timeout is not loaded from [master] section. To some extent I have long avoided any problem I had my moving the configuration to [main] Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4686) environment_timeout is not loaded from [master] section.
Title: Message Title Steve Traylen commented on PUP-4686 Re: environment_timeout is not loaded from [master] section. I should have added a comment about that. We observed it the sense we can easily more than double the network traffic by moving the setting around, i.e flipping from 0 (ignored 180) to 180. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4686) environment_timeout is not loaded from [master] section.
Title: Message Title Steve Traylen updated an issue Puppet / PUP-4686 environment_timeout is not loaded from [master] section. Attached is a full puppet.conf we are using (the password in there is redundant.) With this despite it containing e_t = 180 puppet config print | grep environment_timeout environment_timeout = 0 This is still with 3.7.5. Will try with 4.X sometime. Change By: Steve Traylen Attachment: puppet.conf Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
Jira (PUP-4686) environment_timeout is not loaded from [master] section.
Title: Message Title Steve Traylen commented on PUP-4686 Re: environment_timeout is not loaded from [master] section. Even if applicable to agent it should work in master also. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4686) environment_timeout is not loaded from [master] section.
Title: Message Title Steve Traylen created an issue Puppet / PUP-4686 environment_timeout is not loaded from [master] section. Issue Type: Bug Affects Versions: PUP 3.7.5 Assignee: Unassigned Created: 2015/06/03 5:08 AM Priority: Normal Reporter: Steve Traylen With a configuration of [main] [master] environmentpath = /mnt/puppetnfsdir/environments
Jira (FACT-348) Facter should provide a convenient way to cache values
Title: Message Title Steve Traylen commented on FACT-348 Re: Facter should provide a convenient way to cache values This would be useful. For instance the ec2 facts which poll our nova master quite a bit. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4196) agent command line options ignored running under systemd
Title: Message Title Steve Traylen commented on PUP-4196 Re: agent command line options ignored running under systemd Forking the service does avoid the problem for sure but there are benefits to leaving it as a simple. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4196) agent command line options ignored running under systemd
Title: Message Title Steve Traylen updated an issue Puppet / PUP-4196 agent command line options ignored running under systemd Change By: Steve Traylen Summary: agentcommandlineoptionsignoredrunning under systemd Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4196) agent command line options ignored running systemd
Title: Message Title Steve Traylen created an issue Puppet / PUP-4196 agent command line options ignored running systemd Issue Type: Bug Affects Versions: PUP 3.7.4 Assignee: Kylo Ginsberg Components: Client Created: 2015/03/13 4:37 AM Environment: CentOS 7 puppet 3.7.4 ruby 2.0.0p353 Labels: systemd Priority: Normal Reporter: Steve Traylen
Jira (PUP-4196) agent command line options ignored running under systemd
Title: Message Title Steve Traylen commented on PUP-4196 Re: agent command line options ignored running under systemd Steps to reproduce: Start with a working CentOS 7 agent. Set PUPPET_EXTRA_OPTS=--masterport=22 -d Start service systemctl start puppet.service Check process table it will have masterport preset. In reality puppet will continue to work perfectly but it should be trying to connect to the master on port 22 and failing. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (HI-118) There's no way to set resolution_type when using data bindings
Title: Message Title
Steve Traylen commented on HI-118
Re: There's no way to set resolution_type when using data bindings
Thisi is not possible since hiera_array cannot be used as a lookup functions. However if it were possible the following might work so long as it's the winning setting under current data binding.
---
mymodule::settings:
- value1
- value2
- {hiera_array('mymodule::settings')}
clearly some potential recursion problems but.
Add Comment
This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e)
Jira (PUP-2916) yumrepo fails to honour custom reposdir
Title: Message Title
Steve Traylen commented on an issue
Re: yumrepo fails to honour custom reposdir
Looking at 3.7.1 the logic is
def self.reposdir(conf='/etc/yum.conf', dirs=['/etc/yum.repos.d', '/etc/yum/repos.d'])
reposdir = find_conf_value('reposdir', conf)
dirs reposdir if reposdir
which says use the following if the directories exist
/etc/yum.repos.d
/etc/yum/repos.d
reposdir value
It ignores them if the directory does not exist. So if your delete /etc/yum.repos.d the old behaviour is restored of writing to reposdir , this is a workaroud.
I agree though this is undesirable. A 'reposdir' setting in the yum.conf should always win since that is what is actually used by yum.
p.s very happy to see yumrepo type is much improved overall.
Add Comment
Puppet / PUP-2916
yumrepo fails to honour custom reposdir
With yum.conf containing reposdir=/etc/yum.repos.d/custom all was well with 3.4.3 and puppet managed the repo files correctly. Since the 3.5 changes to yumrepo, it no longer uses the custom repodir, so writes the repo files to the wrong
Jira (PUP-1592) Puppet excessively stats the filesystem when looking for defined types
Title: Message Title Steve Traylen updated an issue Puppet / PUP-1592 Puppet excessively stats the filesystem when looking for defined types Out of interest we just backported this patch to puppet 3.4.3 and it made a huge difference for us in our environment so thanks. pm2.png - load on puppet masters pm3.png - puppet run durations. we can quite literally throw some puppet masters away now. Change By: Steve Traylen Attachment: pm2.png Attachment: pm3.png Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this
Jira (PUP-2524) ruby types missing on agent are completely ignored
Title: Message Title Steve Traylen created an issue Puppet / PUP-2524 ruby types missing on agent are completely ignored Issue Type: Bug Affects Versions: 3.4.3 Assignee: Unassigned Created: 09/May/14 7:58 AM Environment: SL6 ruby 1.8.7 puppet-3.4.3 Priority: Normal Reporter: Steve Traylen If a ruby type is missing on agent node then the agent runs to completion without incident apparently with everything okay despite the type being present in the catalog. Steps to reproduce. Delete a ruby type from a node. rm -rf /var/lib/puppet/lib/puppet/type/fts3config.rb Set pluginsync to false so the type is not downloaded again so we can demonstrate the point. puppet agent -t -v -d runs just fine. The log contains all the notify and subscribe events for the instance. Debug: /Stage[main]/Fts::Config/Fts3config[roles/Public]/notify: subscribes to Service[fts-server] Debug:
Jira (PUP-2524) A ruby type missing on agent is completely ignored
Title: Message Title Steve Traylen updated an issue Puppet / PUP-2524 A ruby type missing on agent is completely ignored Change By: Steve Traylen Summary: Aruby types type missingonagentiscompletelyignored Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2524) A ruby types missing on agent is completely ignored
Title: Message Title Steve Traylen updated an issue Puppet / PUP-2524 A ruby types missing on agent is completely ignored Change By: Steve Traylen Summary: A rubytypesmissingonagent are is completelyignored Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2524) A ruby type missing on agent is completely ignored
Title: Message Title
Steve Traylen commented on an issue
Re: A ruby type missing on agent is completely ignored
A more generic example, remove a type that is provided by the puppet package
rm /usr/lib/ruby/site_ruby/1.8/puppet/type/augeas.rb
and puppet agent runs to completion without incident despite there being augeas resources in the catalog.
Add Comment
Puppet / PUP-2524
A ruby type missing on agent is completely ignored
If a ruby type is missing on agent node then the agent runs to completion without incident apparently with everything okay despite the type being present in the catalog. Steps to reproduce. Delete a ruby type from a node. {code} rm -rf /var/lib/puppet/lib/puppet/type/fts3config.rb {code} Set pluginsync to false so the type is not downloa...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
Jira (HI-115) hiera recursive guard
Title: Message Title
Steve Traylen updated an issue
Hiera / HI-115
hiera recursive guard
Change By:
Steve Traylen
Therecursiveguardisactivatedifthesamevariableisreferencedtwice.Forexample: {code} global.yamla:'%{b}-%{b}' {code} hieraa {code} /usr/lib/ruby/vendor_ruby/hiera/recursive_guard.rb:13:in`check':Detectedin[b](Hiera::InterpolationLoop) {code} Alsotheerrormessageisnotveryinformative.
Add Comment
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
