Jira (FACT-3080) facter.conf facts and fact-groups sections make facter very slow.
Title: Message Title Tom Parker created an issue Facter / FACT-3080 facter.conf facts and fact-groups sections make facter very slow. Issue Type: Bug Assignee: Unassigned Attachments: facter-no-facts-groups-section.conf, facter-no-facts-section.conf, facter-no-ttls.conf, full-facter.conf Created: 2021/10/06 9:36 AM Environment: CentOS 7 Puppet-agent 7.11 Priority: Normal Reporter: Tom Parker Having a facter.conf file causes facter to slow down dramatically. All files have been attached for reference. Time for puppet facts show (full-facter.conf) real 5m51.406s user 5m42.813s sys 0m4.949s Time for puppet facts show (facter-no-ttls.conf) real 5m54.552s user 5m45.233s sys 0m5.734s Time for puppet facts show (facter-no-facts-section.conf) real 2m30.101s user 2m2.598s sys 0m10.459s Time for puppet facts show (facter-no-fact-groups-section.conf) real 1m45.888s user 1m33.713s sys 0m9.433s Time for no facter.conf at all. real 1m41.443s user 1m29.070s sys 0m9.653s
Jira (FACT-3079) Caching not working for some custom facts
Title: Message Title Tom Parker created an issue Facter / FACT-3079 Caching not working for some custom facts Issue Type: Bug Assignee: Unassigned Attachments: facter.conf, yum, yum-facter-debug.log Created: 2021/10/06 7:31 AM Environment: Puppet 7.11 on CentOS 7 Priority: Normal Reporter: Tom Parker I have configured facter to cache and block several core and custom facts (puppet 7.11) and I am finding that the behaviour is odd. The example that I have attached here is from the puppetlabs-yum module that declares 3 custom facts: - yum_package_updates (This is the primary fact that does all the work) - yum_has_updates (returns the value of yum_package_updates.any?) yum_updates (returns the value of yum_package_updates.length) My facter.conf file (attached) declares a yum group that contains these 3 facts but when I run puppet only the yum_package_updates fact is cached (cache file attached). This seems to cause the other two dependent facts (yum_has_updates and yum_updates) to force the resolution (not from cache) of the main yum_package_updates fact. I can also see in the debug logs that it seems to use the cache sometimes but then lose the cached value and resolve it again. It also states that the cache file is expired, missing or corrupt but the file is fresh, created by facter itself and the ttl is 6 hours. If I specify all 3 facts in the cache individually (not in a group) the caching behaviour seems to work properly.
Jira (PUP-7931) Support HTTPS Compression on report upload
Title: Message Title Tom Parker commented on PUP-7931 Re: Support HTTPS Compression on report upload Hello, has there been any progress on this ticket? Would it be possible to also include the same for puppet facts upload? It would also benefit from compression. Could it not just be a puppet.conf setting for compress_uploads = true (–compress_uploads) and let the administrator enable it once they are sure their server side can handle decompressing the payloads? 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.210137.1505138923000.18814.1619474640036%40Atlassian.JIRA.
Jira (FACT-2924) Facter fails "closed" if the facter.conf file is invalid
Title: Message Title Tom Parker updated an issue Facter / FACT-2924 Facter fails "closed" if the facter.conf file is invalid Change By: Tom Parker Attachment: facter.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.383703.1611082995000.160985.1615311240032%40Atlassian.JIRA.
Jira (FACT-2924) Facter fails "closed" if the facter.conf file is invalid
Title: Message Title
Tom Parker commented on FACT-2924
Re: Facter fails "closed" if the facter.conf file is invalid
This is still not 100% fixed. On puppet-agent.x86_64 0:7.4.1-1.el7 I can't even run a puppet agent --version without a crash. My badly formatted facter.conf (caused by erroneously converting to json unstead of hocon) is: {{{ }} {{ "facts": { }} {{ "blocklist": null, }} {{ "ttls": [ }} {{ { }} {{ "EC2": "1 day" }} {{ } }} {{ ] }} {{ } }} } [LIVE] gredb1 [k: gredb]:~ # puppet agent --version Traceback (most recent call last): 21: from /opt/puppetlabs/puppet/bin/puppet:4:in `' 20: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 19: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 18: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:12:in `' 17: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 16: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 15: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:15:in `' 14: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 13: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb:10:in `' 11: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb:13:in `' 10: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options.rb:40:in `init' 9: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:12:in `init' 8: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:24:in `augment_all' 7: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:93:in `augment_facts' 6: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:93:in `new' 5: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:16:in `initialize' 4: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:83:in `load_facts_ttls' 3: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:83:in `each' 2: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:84:in `block in load_facts_ttls' 1: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:106:in `ttls_to_seconds' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:106:in `*': nil can't be coerced into Integer (TypeError)
Jira (FACT-2924) Facter fails "closed" if the facter.conf file is invalid
Title: Message Title Tom Parker updated an issue Facter / FACT-2924 Facter fails "closed" if the facter.conf file is invalid Change By: Tom Parker With facter 4 shipped with puppet 7.1 is if the facter.conf file is invalid facter fails to load at all which prevents all subsequent puppet runs. This means that instead of being able to fix the problem with a puppet run the administrator has to login to any affected server and fix the file by hand. Would it be possible to fail "open" if the file is invalid? Log an error and run with all defaults? This would at least allow puppet to fix the problem on a subsequent run. 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
Jira (FACT-2924) Facter fails "closed" if the facter.conf file is invalid
Title: Message Title Tom Parker created an issue Facter / FACT-2924 Facter fails "closed" if the facter.conf file is invalid Issue Type: Bug Assignee: Unassigned Created: 2021/01/19 11:03 AM Priority: Normal Reporter: Tom Parker With facter 4 shipped with puppet 7.1 is the facter.conf file is invalid facter fails to load at all which prevents all subsequent puppet runs. This means that instead of being able to fix the problem with a puppet run the administrator has to login to any affected server and fix the file by hand. Would it be possible to fail "open" if the file is invalid? Log an error and run with all defaults? This would at least allow puppet to fix the problem on a subsequent run. Add Comment
Jira (FACT-2922) Add --timing to puppet facts show
Title: Message Title Tom Parker created an issue Facter / FACT-2922 Add --timing to puppet facts show Issue Type: Improvement Assignee: Unassigned Created: 2021/01/15 10:28 AM Priority: Normal Reporter: Tom Parker facter --timing is incredibly useful to find slow facts on my systems however with the removal of the --puppet flag it only shows the built in facts. Would it be possible to have the --timing flag added to the puppet facts show command to show slow puppet fact resolutions as well? Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-9967) puppet plugin download doesn't respect the server variable in puppet.conf
Title: Message Title Tom Parker commented on PUP-9967 Re: puppet plugin download doesn't respect the server variable in puppet.conf Thanks 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.321330.1565991716000.9875.1576267380219%40Atlassian.JIRA.
Jira (PUP-9967) puppet plugin download doesn't respect the server variable in puppet.conf
Title: Message Title Tom Parker commented on PUP-9967 Re: puppet plugin download doesn't respect the server variable in puppet.conf Is there a user section or a general section where server and proxy variables can be defined that would apply to all connections to the master? 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.321330.1565991716000.9737.1576265460068%40Atlassian.JIRA.
Jira (PUP-10106) Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb
Title: Message Title Tom Parker commented on PUP-10106 Re: Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb Thanks Josh Cooper. I will have to do some experiments to see how other applications on my system behave with .ls.cbn vs ls.cbn including python and older versions of ruby. For everything so far with the exception of puppet/ruby the ls.cbn has always matched. I appreciate you keeping this ticket open. The behaviour is indeed odd between ENV[no_proxy] and puppet.conf no_proxy although the .domain seems to be pretty consistent across the various environments and applications. 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.330903.157151114.2734.1571844600615%40Atlassian.JIRA.
Jira (PUP-10106) Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb
Title: Message Title Tom Parker commented on PUP-10106 Re: Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb Further testing shows that the issue is in the handling of no_proxy for a domain match. NO_PROXY="ls.cbn, localhost, puppet, 127.0.0.1" fails. NO_PROXY="glycon.ls.cbn, ls.cbn, localhost, puppet, 127.0.0.1" works. As far as I know this is incorrect behaviour as ls.cbn should match *.ls.cbn 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.330903.157151114.8509.1571517780048%40Atlassian.JIRA.
Jira (PUP-10106) Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb
Title: Message Title Tom Parker created an issue Puppet / PUP-10106 Since update to puppet 5.5.17 puppetdb forge module cannot connect to puppetdb Issue Type: Bug Affects Versions: PUP 5.5.17 Assignee: Unassigned Created: 2019/10/19 11:52 AM Priority: Normal Reporter: Tom Parker Puppet Version: 5.5.17 Puppet Server Version: 5.3.10 OS Name/Version: CentOS 7 Since the update to puppet agent 5.5.17 the puppetdb forge module is using the configured proxy server and ignoring the no_proxy setting when trying to validate the connection to puppetdb. This worked properly on 5.5.16. My environment proxy settings are: *http_proxy=http://ottinstall.ls.cbn:3128* *ftp_proxy=http://ottinstall.ls.cbn:3128* *https_proxy=http://ottinstall.ls.cbn:3128* no_proxy=ls.cbn, localhost, puppet, 127.0.0.1 My puppetdb server is: *https://glycon.ls.cbn:8081* Desired Behavior: Respect the no_proxy value ls.cbn and not proxy connections to https://glycon.ls.cbn:8018 Actual Behavior: opening connection to ottinstall.ls.cbn:3128... opened <- "CONNECT glycon.ls.cbn:8081 HTTP/1.1\r\nHost: glycon.ls.cbn:8081\r\n\r\n" -> "HTTP/1.1 403 Forbidden\r\n" -> "Server: squid/3.5.20\r\n" -> "Mime-Version: 1.0\r\n" -> "Date: Sat, 19 Oct 2019 18:46:40 GMT\r\n" -> "Content-Type: text/html;charset=utf-8\r\n" -> "Content-Length: 3448\r\n" -> "X-Squid-Error: ERR_ACCESS_DENIED 0\r\n" -> "Vary: Accept-Language\r\n" -> "Content-Language: en\r\n" -> "X-Cache: MISS from ottinstall.ls.cbn\r\n" -> "X-Cache-Lookup: NONE from ottinstall.ls.cbn:80\r\n" -> "Via: 1.1 ottinstall.ls.cbn (squid/3.5.20)\r\n" -> "Connection: keep-alive\r\n" -> "\r\n" Conn close because of connect error 403 "Forbidden" Notice: Unable to connect to puppetdb server (https://glycon.ls.cbn:8081): 403 "Forbidden"
Jira (PUP-9967) puppet plugin download doesn't respect the server variable in puppet.conf
Title: Message Title Tom Parker created an issue Puppet / PUP-9967 puppet plugin download doesn't respect the server variable in puppet.conf Issue Type: Bug Assignee: Unassigned Created: 2019/08/16 2:41 PM Priority: Normal Reporter: Tom Parker Puppet Version: 5.5.14 Puppet Server Version: 5.5.14 OS Name/Version: Debian 9 Desired Behavior: puppet plugin download should use the [agent] values in puppet.conf for making http connections to the puppet master. Actual Behavior: if --server is not on the command line and 'puppet' doesn't resolve the action fails Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PDB-4332) Unknown variable: 'postgresql::server::encoding' when puppetdb::manage_dbserver: false
Title: Message Title Tom Parker commented on PDB-4332 Re: Unknown variable: 'postgresql::server::encoding' when puppetdb::manage_dbserver: false I figured out what I was doing wrong. It's not a bug if you RTFM and include the correct submodules for the servers that will be puppetdb::servers. I had the entire puppetdb class loaded with manage_dbserver: false which doesn't work. 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 (PDB-4332) Unknown variable: 'postgresql::server::encoding' when puppetdb::manage_dbserver: false
Title: Message Title Tom Parker created an issue PuppetDB / PDB-4332 Unknown variable: 'postgresql::server::encoding' when puppetdb::manage_dbserver: false Issue Type: Bug Assignee: Unassigned Created: 2019/04/05 5:32 PM Priority: Normal Reporter: Tom Parker If you set: puppetdb::manage_dbserver: false (for example when the puppetdb is on different server) the postgresql::server class never gets called so the postgresql::server:: variables are not set. With strict_variables= true this causes a fatal error that currently can't be worked around without editing either the postgreql module code or the puppetdb module code. Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Unknown variable: 'postgresql::server::encoding'. (file: /etc/puppetlabs/code/environments/testing/modules/postgresql/manifests/server/db.pp, line: 8, column: 17) (file: /etc/puppetlabs/code/environments/testing/modules/puppetdb/manifests/database/postgresql.pp, line: 34) Add Comment
Jira (PUP-9553) Exported resources are deleted if a node runs in different environment
Title: Message Title Tom Parker commented on PUP-9553 Re: Exported resources are deleted if a node runs in different environment I have several things I can do as a workaround but I still don't think there should be collisions between environments for facts, and exported resources (or really anything). Should the environments not be kept isolated from each other completely? Everything else is now separate (per-environment hiera, per-environment modules) but we don't have a separation in puppetdb 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-9553) Exported resources are deleted if a node runs in different environment
Title: Message Title Tom Parker created an issue Puppet / PUP-9553 Exported resources are deleted if a node runs in different environment Issue Type: Bug Assignee: Unassigned Created: 2019/03/08 3:36 PM Priority: Normal Reporter: Tom Parker I am using puppet environments to apply very different collections of modules on the same node. I have an environment to download (but not install) packages overnight and one that just runs password changes all triggered from my puppet master using mcollective. The problem that I run into is that if I run puppet agent --environment download all of the exported resources from environment production are removed from pupetdb. Then, any nodes that are collecting those resources will delete the associated configuration if puppet is run on the collector before a production run happens again on the exporter. I know that since pdb 2.0 puppet db is environment aware and I'm wondering if there is any way to no clobber my exported resources across environment runs. Add Comment
Jira (PUP-6386) Error: Failed to apply catalog: Validation of File[xxxxxxx] failed: You cannot specify a remote recursion without a source
Title: Message Title
Tom Parker created an issue
Puppet / PUP-6386
Error: Failed to apply catalog: Validation of File[xxx] failed: You cannot specify a remote recursion without a source
Issue Type:
Bug
Affects Versions:
PUP 4.5.0
Assignee:
Kylo Ginsberg
Components:
Client, Server
Created:
2016/06/03 11:32 PM
Priority:
Normal
Reporter:
Tom Parker
This file resource fails when catalog_terminus = static_compiler
file {'/etc/ppp/peers': ensure => directory, source => "puppet:///modules/ppp/peers", recurse => remote, sourceselect => all, require => Package[$packages], }
The error generated is: Error: Failed to apply catalog: Validation of File[/etc/ppp/peers] failed: You cannot specify a remote recursion without a source at /etc/puppetlabs/code/modules/ppp/manifests/init.pp:9
I am running puppetserver 2.4.0-1puppetlabs1 on Debian and puppet 4.5.0 on my client.
Jira (FACT-823) Facter truncates interface names and then cannot load their data
Title: Message Title Tom Parker created an issue Facter / FACT-823 Facter truncates interface names and then cannot load their data Issue Type: Bug Affects Versions: FACT 2.0.2 Assignee: Eric Sorenson Components: Community Created: 2015/02/12 3:19 PM Environment: SuSE Linux Enterprize 11 SP3 Priority: Normal Reporter: Tom Parker I have several devices managed with puppet that use GRE tunnels with long interface names. Facter truncates the names of the devices when enumerating them and then cannot load the data. Device Names: tun_dnl_sps_0: tun_dnl_sps_2: tun_dnl_sps_4: tun_dnl_tgu_0: tun_dnl_tgu_2: tun_dnl_tgu_4: Puppet output: Info: Loading facts Device "tun_dnl_t" does not exist. Device "tun_dnl_t" does not exist. Device "tun_dnl_t" does not exist. Device "tun_dnl_t" does not exist. Device "tun_dnl_s" does not exist. Device "tun_dnl_s" does not exist. Device "tun_dnl_s" does not exist. Device "tun_dnl_s" does not exist. Device "tun_dnl_t" does not exist. Device "tun
