Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness commented on FACT-3201 Re: Facter should report macOS "extra" version from Rapid Security Response updates Opened https://github.com/puppetlabs/facter/pull/2568 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485206.1683227494000.11068.1683227940026%40Atlassian.JIRA.
Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness commented on FACT-3201 Re: Facter should report macOS "extra" version from Rapid Security Response updates I'm working on a pull request to fix this. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485206.1683227494000.11067.1683227520113%40Atlassian.JIRA.
Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness created an issue Facter / FACT-3201 Facter should report macOS "extra" version from Rapid Security Response updates Issue Type: Improvement Assignee: Unassigned Components: Facter 4 Created: 2023/05/04 12:11 PM Priority: Normal Reporter: Clay Caviness Starting with macOS 13, Apple can use a "Rapid Security Response" process to push small system updates out. When one of these is applied, a new ProductVersionExtra field is output from the sw_vers command: $ sw_vers ProductName: macOS ProductVersion: 13.3.1 ProductVersionExtra: (a) BuildVersion: 22E772610a
Jira (PDB-5643) PQL parsing of OR clauses can result in OOM errors
Title: Message Title
Joshua Partlow updated an issue
PuppetDB / PDB-5643
PQL parsing of OR clauses can result in OOM errors
Change By:
Joshua Partlow
There seems to be enough inefficiency in [instaparse|https://github.com/Engelberg/instaparse] such that large(ish) sets of OR clauses can eat up available memory.In a 2021.7.2 e2-custom-4-10240 GCP test instance with 1G allocated to puppetdb's heap, this query was enough to oom in ~3m:{code}reports { latest_report? = true and (certname = "foo22" orcertname = "foo21" orcertname = "foo20" orcertname = "foo19" orcertname = "foo18" orcertname = "foo17" orcertname = "foo16" orcertname = "foo15" orcertname = "foo14" orcertname = "foo13" orcertname = "foo12" orcertname = "foo11" orcertname = "foo10" orcertname = "foo9" orcertname = "foo8" orcertname = "foo7" orcertname = "foo6" orcertname = "foo5" orcertname = "foo4" orcertname = "foo3" orcertname = "foo2" orcertname = "foo1" )}{code}The effect is exponential. Calling it with 21 OR clauses, the query succeeded in 31s, with 20 in 7s, with 19 in 4s, and so on back down to <1 once you reach 16 clauses.We'll need to see if our grammar can be tweaked again to avoid this, similar to what Rob did in PDB-5260, or if we're looking at a parser re-write to fix this. WORKAROUNDS: Use IN instead of a set of ORs; or wrap the ORs in parentheses, although in general an IN will be faster on the postgres side once this eventually parses and postgres is actually running it. ACTION:Look through and see if there is an improvement using instaparse. Do not necessarily re-write the parser just for this bug.
Add Comment
Jira (PDB-5643) PQL parsing of OR clauses can result in OOM errors
Title: Message Title Cas Donoghue updated an issue PuppetDB / PDB-5643 PQL parsing of OR clauses can result in OOM errors Change By: Cas Donoghue Story Points: 1 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485181.1683145604000.11054.1683225840035%40Atlassian.JIRA.
Jira (PDB-5643) PQL parsing of OR clauses can result in OOM errors
Title: Message Title
Cas Donoghue updated an issue
PuppetDB / PDB-5643
PQL parsing of OR clauses can result in OOM errors
Change By:
Cas Donoghue
There seems to be enough inefficiency in [instaparse|https://github.com/Engelberg/instaparse] such that large(ish) sets of OR clauses can eat up available memory.In a 2021.7.2 e2-custom-4-10240 GCP test instance with 1G allocated to puppetdb's heap, this query was enough to oom in ~3m: {code} reports { latest_report? = true and (certname = "foo22" orcertname = "foo21" orcertname = "foo20" orcertname = "foo19" orcertname = "foo18" orcertname = "foo17" orcertname = "foo16" orcertname = "foo15" orcertname = "foo14" orcertname = "foo13" orcertname = "foo12" orcertname = "foo11" orcertname = "foo10" orcertname = "foo9" orcertname = "foo8" orcertname = "foo7" orcertname = "foo6" orcertname = "foo5" orcertname = "foo4" orcertname = "foo3" orcertname = "foo2" orcertname = "foo1" )}{code} The effect is exponential. Calling it with 21 OR clauses, the query succeeded in 31s, with 20 in 7s, with 19 in 4s, and so on back down to <1 once you reach 16 clauses.We'll need to see if our grammar can be tweaked again to avoid this, similar to what Rob did in PDB-5260, or if we're looking at a parser re-write to fix this. ACTION:Look through and see if there is an improvement using instaparse. Do not necessarily re-write the parser just for this bug.
Add Comment
This message was sent by Atlassian
Jira (FACT-3200) Facter throws ``Error while resolving custom fact fact=''``
Title: Message Title Gavin Didrichsen assigned an issue to Josh Cooper Facter / FACT-3200 Facter throws ``Error while resolving custom fact fact=''`` Change By: Gavin Didrichsen Assignee: Josh Cooper Resolution: Fixed Status: Open Resolved Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485195.1683187201000.11043.168322559%40Atlassian.JIRA.
Jira (FACT-3200) Facter throws ``Error while resolving custom fact fact=''``
Title: Message Title
Gavin Didrichsen commented on FACT-3200
Re: Facter throws ``Error while resolving custom fact fact=''``
Hi Josh Cooper. You're absolutely right...sorry for the false alarm here. I didn't realize that this module had a custom fact that was expecting the presence of ``/etc/puppetlabs/puppet/ssl/private_keys/# {Puppet.settings[:certname]} .pem'``. Once the File.exists?() check was added then the error went away.
require 'puppet'
require 'yaml'
require 'net/ssh'
Facter.add(:usage, type: :aggregate) do
chunk(:sshkey) do
private_key_file = File.join('/etc/puppetlabs/puppet/ssl/private_keys', Puppet.settings[:certname] + '.pem')
identifier = Puppet.settings[:certname]
if File.exists?(private_key_file)
key = OpenSSL::PKey::RSA.new(File.read(private_key_file))
type = key.ssh_type
Jira (FACT-3188) Error on on Solaris non-global zone after upgrading to PE2021.7.2
Title: Message Title Josh Cooper updated an issue Facter / FACT-3188 Error on on Solaris non-global zone after upgrading to PE2021.7.2 Change By: Josh Cooper Priority: High Major Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.481890.1677480699000.11032.1683223200133%40Atlassian.JIRA.
Jira (PUP-11723) Remove dependency on private class Concurrent::RubyThreadLocalVar
Title: Message Title Josh Cooper updated an issue Puppet / PUP-11723 Remove dependency on private class Concurrent::RubyThreadLocalVar Change By: Josh Cooper Puppet relies on the Concurrent::RubyThreadLocalVar class which was removed in 1.2.0, see https://github.com/ruby-concurrency/concurrent-ruby/issues/986#issuecomment-1400997040We explicitly rely on the Ruby implementation when running on JRuby because of a bug, see PUP-9931 and https://github.com/puppetlabs/puppet/commit/9182bc3dd2576f409a6d01fb5c08d392670e90a2For now we've pinned back to < 1.2 (PUP-11722) but we should look into not relying on a private class and remove our concurrent-ruby pin. Grooming:* Replace removed class with Concurrent::ThreadLocalVar, see commit where RubyThreadLocalVar was removed https://github.com/ruby-concurrency/concurrent-ruby/commit/30465396 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To
Jira (FACT-3180) Facter mixes up OracleLinux and Redhat
Title: Message Title Aria Li assigned an issue to Aria Li Facter / FACT-3180 Facter mixes up OracleLinux and Redhat Change By: Aria Li Assignee: Aria Li Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.479622.1674731331000.10970.1683216060024%40Atlassian.JIRA.
Jira (PUP-11847) User resources on AIX call lsgroup command multiple times, adding a lot of time to puppet runs
Title: Message Title Patrick Grant updated an issue Puppet / PUP-11847 User resources on AIX call lsgroup command multiple times, adding a lot of time to puppet runs Change By: Patrick Grant When the users are managed on AIX, this calls the lsgroup command. When connected to both Ldap and local directories, this can call can take a significant amount of time. (In the case of the customer I'm raising this on behalf of, 23 seconds per call) When multiple users are managed this can add a considerable amount of time to your puppet run (customer case had 10 users managed , puppet runs were totaling 5 minutes +), running the same command. Is there any way this lsgroup can be run once for all user resources on this OS?~* Please see Zendesk Support tab for further comments and attachments.~ Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop
Jira (PUP-11847) User resources on AIX call lsgroup command multiple times, adding a lot of time to puppet runs
Title: Message Title Patrick Grant updated an issue Puppet / PUP-11847 User resources on AIX call lsgroup command multiple times, adding a lot of time to puppet runs Change By: Patrick Grant Summary: User resources on AIX call lsgroup command multiple times , adding a lot of time to puppet runs Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485200.1683213405000.10954.1683213600038%40Atlassian.JIRA.
Jira (PUP-11847) User resources on AIX call lsgroup command multiple times
Title: Message Title Patrick Grant updated an issue Puppet / PUP-11847 User resources on AIX call lsgroup command multiple times Change By: Patrick Grant When the users are managed on AIX, this calls the lsgroup command. When connected to both Ldap and local directories, this can call can take a significant amount of time. (In the case of the customer I'm raising this on behalf of, 23 seconds per call) When multiple users are managed this can add a considerable amount of time to your puppet run, running the same command. Is there any way this lsgroup can be run once for all user resources on this OS?~* Please see Zendesk Support tab for further comments and attachments.~ Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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
Jira (PUP-11847) User resources on AIX call lsgroup command multiple times
Title: Message Title Charmaine Pritchett updated an issue Puppet / PUP-11847 User resources on AIX call lsgroup command multiple times Change By: Charmaine Pritchett Zendesk Ticket Count: 1 Zendesk Ticket IDs: 51867 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485200.1683213405000.10952.1683213480042%40Atlassian.JIRA.
Jira (PUP-11847) User resources on AIX call lsgroup command multiple times
Title: Message Title Charmaine Pritchett updated an issue Puppet / PUP-11847 User resources on AIX call lsgroup command multiple times Change By: Charmaine Pritchett Labels: jira_escalated Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485200.1683213405000.10951.1683213420132%40Atlassian.JIRA.
Jira (PUP-11847) User resources on AIX call lsgroup command multiple times
Title: Message Title Patrick Grant created an issue Puppet / PUP-11847 User resources on AIX call lsgroup command multiple times Issue Type: Improvement Assignee: Unassigned Created: 2023/05/04 8:16 AM Priority: Normal Reporter: Patrick Grant When the users are managed on AIX, this calls the lsgroup command. When connected to both Ldap and local directories, this can call can take a significant amount of time. When multiple users are managed this can add a considerable amount of time to your puppet run, running the same command. Is there any way this can be run once for all user resources on this OS? * Please see Zendesk Support tab for further comments and attachments. Add Comment This message
Jira (FACT-3200) Facter throws ``Error while resolving custom fact fact=''``
Title: Message Title Josh Cooper commented on FACT-3200 Re: Facter throws ``Error while resolving custom fact fact=''`` Facter on its own won't try to load /etc/puppetlabs/puppet/ssl/private_keys/scd4pe-9c8d30-0.us-west1-c.c.customer-support-scratchpad.internal.pem. I'm guessing this is coming from another fact. Can you run with "facter usage --trace --debug" and include/attach the stack trace? Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485195.1683187201000.10947.1683212460025%40Atlassian.JIRA.
Jira (FACT-3200) Facter throws ``Error while resolving custom fact fact=''``
Title: Message Title Gavin Didrichsen created an issue Facter / FACT-3200 Facter throws ``Error while resolving custom fact fact=''`` Issue Type: Bug Assignee: Unassigned Created: 2023/05/04 1:00 AM Priority: Normal Reporter: Gavin Didrichsen When I run a plan against nodes on GCP, I always see the following non-fatal error: Facter throws ``Error while resolving custom fact fact=''` See replication and workaround in Description section. Desired Behaviour Notice: /Stage[main]/Main/Notify[Hello, world!]/message: defined 'message' as 'Hello, world!' changed: 1, failed: 0, unchanged: 0 skipped: 0, noop: 0 Actual Behaviour
