Jira (PUP-9752) Systemd should be default service provider for Debian buster
Title: Message Title Martin Jackson commented on PUP-9752 Re: Systemd should be default service provider for Debian buster https://github.com/mhjacks/puppet/pull/1 will set systemd as the default service provider for Debian 10 and for the forthcoming sid/bullseye 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.312293.1560388027000.45793.1560388140069%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9752) Systemd should be default service provider for Debian buster
Title: Message Title
Martin Jackson updated an issue
Puppet / PUP-9752
Systemd should be default service provider for Debian buster
Change By:
Martin Jackson
Summary:
{brief summary of issue} Systemd should be default service provider for Debian buster
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.312293.1560388027000.45792.1560388080545%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9752) {brief summary of issue}
Title: Message Title
Martin Jackson created an issue
Puppet / PUP-9752
{brief summary of issue}
Issue Type:
Improvement
Assignee:
Unassigned
Created:
2019/06/12 6:07 PM
Priority:
Normal
Reporter:
Martin Jackson
Puppet Version: (all released agent versions) Puppet Server Version: OS Name/Version: Debian 10 The systemd provider is not a default for Debian 10 (buster) as released. Thus services that only have systemd .service files and not init scripts won't be managed properly. Desired Behavior: Systemd should be the default for 10 (buster's release number) and probably also the forthcoming bullseye/sid. Actual Behavior: Running a puppetlabs-provided puppet-agent package on current buster (currently unsupported, I understand) results in services not being managed correctly.
Add Comment
Jira (FACT-1870) Stdout in facts invalidates formatted output (yaml/json)
Title: Message Title Martin Jackson commented on FACT-1870 Re: Stdout in facts invalidates formatted output (yaml/json) So, without a doubt, using almost any method but puts will do this. We're switching most of ours to warn. The question is, since the output is processed correctly by whatever mechanism is used natively by the puppet agent, it doesn't seem too much of a stretch to expect facter running on its own to generate syntactically valid output. Maybe we're the only ones who have ever written custom facts that do this. I understand it's not entirely unfair to blame the code (don't use puts, right?) but at the same time, since it works inside puppet, it seems like it should work outside puppet, too. Right now, there doesn't seem to be a way to get facter to replicate what happens inside a puppet run, in terms of generating correct json/yaml. Is there prior art of people doing "the right" thing by using puts inside facts like this? 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 (FACT-1870) Stdout in facts invalidates formatted output (yaml/json)
Title: Message Title Martin Jackson commented on FACT-1870 Re: Stdout in facts invalidates formatted output (yaml/json) Except that in other parts of the ecosystem it already does. The way puppet invokes it, it doesn't have this problem, regardless of output to stdout or stderr, so it's rather startling to see a JSON parser barf on something puppet can handle internally. 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-7613) DNF should be default package provider for Fedora
Title: Message Title Martin Jackson created an issue Puppet / PUP-7613 DNF should be default package provider for Fedora Issue Type: Improvement Assignee: Unassigned Created: 2017/06/01 8:19 PM Priority: Normal Reporter: Martin Jackson Fedora < 24 are now end-of-life. Fedora has used dnf as the default package manager since Fedora 22 (and it's been an option since Fedora 18). Every new Fedora release requires a commit to add the new version as a default for that version; but it is now an entrenched default and is the established successor to yum. People who want other behavior can still override the default if they wish. I'll submit a PR. Add Comment
Jira (FACT-1544) Facter leaves behind cached facts if you enable fact TTLs in facter.conf and then remove those TTLs
Title: Message Title Martin Jackson commented on FACT-1544 Re: Facter leaves behind cached facts if you enable fact TTLs in facter.conf and then remove those TTLs That's completely fair. 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-1466) Facter warns aboutIt difficulty parsing routing entries on Fedora 24
Title: Message Title Martin Jackson created an issue Facter / FACT-1466 Facter warns aboutIt difficulty parsing routing entries on Fedora 24 Issue Type: Bug Assignee: Unassigned Created: 2016/07/19 5:15 PM Priority: Normal Reporter: Martin Jackson Under some circumstances (such as when running libvirtd with the standard NAT network, or any situation where the route output includes "linkdown"), Facter complains about not being able to parse route output: 2016-07-19 19:04:33.871180 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got '192.168.6.0/24 dev br6 proto kernel scope link src 192.168.6.1 metric 425 linkdown' 2016-07-19 19:04:33.872683 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'fe80::/64 dev br6 proto kernel metric 256 linkdown pref medium' Here is the ip route output: 192.168.1.0/24 proto zebra metric 20 nexthop via 192.168.5.2 dev br5 weight 1 nexthop via 192.168.5.3 dev br5 weight 1 192.168.4.0/24 proto zebra metric 20 nexthop via 192.168.5.2 dev br5 weight 1 nexthop via 192.168.5.3 dev br5 weight 1 192.168.5.0/24 dev br5 proto kernel scope link src 192.168.5.15 metric 425 192.168.6.0/24 dev br6 proto kernel scope link src 192.168.6.1 metric 425 linkdown 192.168.129.0/24 dev br900 proto kernel scope link src 192.168.129.15 metric 425 rpm -qf /usr/sbin/ip iproute-4.4.0-3.fc24.x86_64 It is not clear that this actually causes a problem, but the warning messages are a bit jarring.
Jira (FACT-1244) xenu vs. xen0 difference not recognized by Puppet
Title: Message Title Martin Jackson commented on FACT-1244 Re: xenu vs. xen0 difference not recognized by Puppet We also noticed this. We're using a variation of Sylvain's custom fact as a workaround. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-1413) External facts do not override custom Ruby facts that have confines or a non-default weight
Title: Message Title Martin Jackson commented on FACT-1413 Re: External facts do not override custom Ruby facts that have confines or a non-default weight Given that the documentation currently states that has_weight must be > 0, would it be inappropriate to ask that test cases be added for scenarios where has_weight == 0? Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-5649) "syncversion" maybe obsolete for selmodule type in Fedora >= 23
Title: Message Title Martin Jackson created an issue Puppet / PUP-5649 "syncversion" maybe obsolete for selmodule type in Fedora >= 23 Issue Type: Bug Affects Versions: PUP 4.3.1 Assignee: Kylo Ginsberg Components: Types and Providers Created: 2016/01/04 6:31 PM Environment: Fedora F22 packages/Puppet 4.3.1 code running on Fedora 23 Priority: Normal Reporter: Martin Jackson Under CentOS 7, semodule -l (which the selmodule provider uses to check the loaded module version) returns a version number, e.g. (from CentOS 7): root@srv-cfgmgt ~ semodule -l abrt 1.4.1 accountsd 1.1.0 acct 1.6.0 afs 1.9.0 aiccu 1.1.0 aide 1.7.1 ajaxterm 1.0.0 alsa 1.12.2 Under Fedora 23, the output looks like this (e.g. no version specified):
Jira (PUP-1635) current thread not owner after Puppet Agent receives USR1 signal
Title: Message Title
Martin Jackson commented on an issue
Re: current thread not owner after Puppet Agent receives USR1 signal
I see the same behavior on Fedora 20 with the system ruby interpreter and the puppetlabs puppet package. This is triggered through the mco puppet runonce MCollective plugin.
Mar 9 18:10:13 ori puppet-agent[4858]: Caught USR1; calling reload Mar 9 18:10:13 ori puppet-agent[5047]: Could not autoload puppet/indirector/node/rest: current thread not owner Mar 9 18:10:13 ori puppet-agent[5047]: Unable to fetch my node definition, but the agent run will continue: Mar 9 18:10:13 ori puppet-agent[5047]: Could not autoload puppet/indirector/node/rest: current thread not owner Mar 9 18:10:13 ori puppet-agent[5047]: Could not autoload puppet/feature/external_facts: current thread not owner Mar 9 18:10:13 ori puppet-agent[5047]: Failed to apply catalog: Could not autoload puppet/feature/external_facts: current thread not owner
[root@ori ~]# ruby -v ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-linux]
[root@ori ~]# rpm -qa | grep puppet mcollective-puppet-common-1.7.0-1.fc20.noarch mcollective-puppet-agent-1.7.0-1.fc20.noarch puppetlabs-release-20-10.noarch puppet-3.4.3-1.fc20.noarch
Add Comment
Puppet / PUP-1635
current thread not owner after Puppet Agent receives USR1 signal
We're running the Puppet Agent daemonised, with {{splay}} enabled. We use the {{USR1}} signal to trigger an immediate reload and catalog run, bypassing the splay setting. This works fine in our other Ruby environment (1.9.3, various patch levels), but when testing under Ruby 2.0.0 and 2.1.0, we noticed that the signal would cause the catalog run to fai...
