Jira (PUP-10325) Custom file mode for lastrunreport as defined in puppet.conf is ignored
Title: Message Title
Josh Behrends created an issue
Puppet / PUP-10325
Custom file mode for lastrunreport as defined in puppet.conf is ignored
Issue Type:
Bug
Affects Versions:
PUP 6.13.0
Assignee:
Unassigned
Created:
2020/03/02 4:24 PM
Priority:
Normal
Reporter:
Josh Behrends
Puppet Version: 6.13.0 Puppet Server Version: 6.7.1 OS Name/Version: CentOS Linux release 7.7.1908 (Core) We just attempted to upgrade puppet agent from 6.8.1 to 6.13.0 and found that after the upgrade the file permissions on the "lastrunreport" file were reset and not honored to what was defined in our puppet.conf: Example:
[agent]
lastrunreport = /var/tmp/puppet/last_run_report.yaml { mode = 0664 }
lastrunfile = /var/tmp/puppet/last_run_summary.yaml { mode = 0664 }
Desired Behavior: Permissions should match what's defined in puppet.conf:
Jira (PUP-5549) package version behavior for epoch versioned rpm's in centos is broken.
Title: Message Title Josh Behrends commented on PUP-5549 Re: package version behavior for epoch versioned rpm's in centos is broken. Since DNF and YUM are two separate package providers shouldn't they have separate rules when it comes to package versioning for issues just like this? It feels like under the hood they are using the same code. I would think the same thing applies when we're talking YUM vs APT too. That's just my 2 cents without being knowledge about the code base. 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5549) package version behavior for epoch versioned rpm's in centos is broken.
Title: Message Title Josh Behrends created an issue Puppet / PUP-5549 package version behavior for epoch versioned rpm's in centos is broken. Issue Type: Bug Affects Versions: PUP 4.3.0 Assignee: Unassigned Created: 2015/11/25 10:41 AM Priority: Normal Reporter: Josh Behrends puppet-agent 1.3.0 CentOS 7 I just upgraded from puppet-agent 1.2.4 and all of a sudden I have multiple packages throwing the following notice every single puppet run: Notice: /Stage[main]/Logstash::Package/Logstash::Package::Install[logstash]/Package[logstash]/ensure: ensure changed '1:1.5.5-1' to '1.5.5-1' I'm not 100% positive, but it looks as though this change made be the culprit: https://tickets.puppetlabs.com/browse/PUP-5025 I tried adding the epoch to the begging of the version given to puppet and I get this:
Jira (PUP-5394) incorrect path being defined in puppet-agent's init script is causing gems to be installed into puppet's gem env.
Title: Message Title
Josh Behrends created an issue
Puppet / PUP-5394
incorrect path being defined in puppet-agent's init script is causing gems to be installed into puppet's gem env.
Issue Type:
Bug
Affects Versions:
puppet-agent 1.2.4
Assignee:
Unassigned
Created:
2015/10/19 12:21 PM
Priority:
Normal
Reporter:
Josh Behrends
OS: CentOS 6.x Puppet 4.2.2: puppet-agent-1.2.4-1.el6.x86_64 AND puppet-agent-1.2.6-1.el6.x86_64
Puppet is installing gems into the puppet provided ruby and not into the system ruby.
Steps to reproduce:
Add this to your node manifest: package {'redis': ensure => 'present', provider => 'gem', }
run "sudo service puppet restart" on your node. run "gem list" - You will find no redis gem. run "/opt/puppetlabs/puppet/bin/gem list" - Redis gem will be installed here!
With some help from the folks on IRC, I found that the init script shipped by puppetlabs has a path which causes the puppet daemon/service to use the puppet provided gem binary vs the system's gem binary.
$ cat /etc/init.d/puppet |grep PATH PATH=/opt/puppetlabs/puppet/bin:/usr/bin:/sbin:/bin:/usr/sbin
If I remove "/opt/puppetlabs/puppet/bin" from the path line and restart the service, the puppet deamon does the right thing and installs the gem into the system ruby.
Jira (PDB-2034) schema error on replace facts insert-facts-pv-pairs!
Title: Message Title Josh Behrends commented on PDB-2034 Re: schema error on replace facts insert-facts-pv-pairs! Heh, yup we are now in a good state now. Just commented here to make sure you guys knew the symptoms I found, and that this was happening in puppetdb v3.1 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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 (PDB-2034) schema error on replace facts insert-facts-pv-pairs!
Title: Message Title Josh Behrends updated an issue PuppetDB / PDB-2034 schema error on replace facts insert-facts-pv-pairs! Change By: Josh Behrends Affects Version/s: PDB 3.1.0 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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 (PDB-2034) schema error on replace facts insert-facts-pv-pairs!
Title: Message Title Josh Behrends commented on PDB-2034 Re: schema error on replace facts insert-facts-pv-pairs! The exact same issue effected us too! Except for us this issue ended up blocking all puppet runs to both of our puppet servers! This is should be marked as a critical issue. We're using puppetserver v2.1.1 and puppetdb v3.1.0 Before finding this ticket here is what my troubleshooting found: It started with my puppetdb machine running out of disk space, and dying. The culprit was the KahaDB folder which was full of .log files.. So I removed the contents of "/opt/puppetlabs/server/data/puppetdb/mq/localhost/" and started puppetdb. Everything was fine for about 24hrs, and then it happened again. So I adjusted down the store-usage and temp-usage down to 10gb/5gb, removed the KahaDB folders and started everything back up again. Then I got user complaints that puppet wasn't running. I found that puppetdb was up and logging nothing. Puppetserver was logging reqeusts for catalogs from clients, and then just doing nothing.. Poked around in the JMX interface for puppetdb and found the activemq broker's storage usage percent was at 100% used. There was also about 30 messages in the DLQ. I did a purge operation via JMX on the DLQ and all of a sudden puppetdb started logging entries, and puppetserver started working once again. Once I found the node that had this SAME fact referenced above I did a test puppet run. I found that every time puppet ran on that host puppetserver would submit the facts to puppetdb and then puppetdb would log the same stack trace described in this ticket and drop a message in the DLQ. At this point the internal activemq store usage would start to climb until it hit it's limit which wedged puppetdb, and also seemed to wedge BOTH of my puppetservers. Hope this brain dump helps fix this issue. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
