Jira (PUP-11066) optional_param does not set Integer to optional for custom ruby functions
Title: Message Title john commented on PUP-11066 Re: optional_param does not set Integer to optional for custom ruby functions Ciprian Badescu can yuo provide more information why this bug was closed as wont fix. it seems like the last update from Josh Cooper proposed a solution that could work i.e. def optional_param(type, name) internal_param(Puppet::Pops::Types::TypeFactory.optional(type), name) @max += 1 end however i dont see any reason why that solution and this bug was rejected Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Jira (PUP-11369) The pw user provider should support creating system users
Title: Message Title john commented on PUP-11369 Re: The pw user provider should support creating system users can you provide evidence that this is actually failing, the comment in the PR dose not indicate any bug to me 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.425101.1638134345000.27791.1662464640039%40Atlassian.JIRA.
Jira (PDB-4503) (docs) documentation for puppetdb_query function
Title: Message Title john commented on PDB-4503 Re: (docs) documentation for puppetdb_query function this seems to be a duplicate of PDB-3655 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.324581.1568320726000.33876.1621244520061%40Atlassian.JIRA.
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title john commented on FACT-2907 Re: networking: add binding flags to bindings6 entries As mentioned in the PR, the current implementation only exposes the lower 8 bits and not the extended flags (specificity it misses mngtmpaddr). however I'm fine if you want to close this issue i can raise another for the additional flags if needed 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.382127.1609866134000.27799.1620385320025%40Atlassian.JIRA.
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title
john updated an issue
Facter / FACT-2907
networking: add binding flags to bindings6 entries
Change By:
john
It would be nice if we could update the networking.$iface. bundings6 bindings6 entries to also include binding flags. As an example given the following:{code:bash}% sudo ip -6 addr show dev en0 2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ffinet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft foreverinet6 2001:db8::1/64 scope global valid_lft forever preferred_lft foreverinet6 fe80:::bbff:febb:/64 scope link valid_lft forever preferred_lft forever{code}It would be nice to get the following facts{code:Ruby}'en0' => { 'bindings6' => [{ address => "2001:db8:::bbff:febb:", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global" 'flags' => ['mngtmpaddr', 'dynamic']},{ address => "2001:db8::1", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global"},{ address => "fe80:::bbff:febb:", netmask => ":::::", network => "fe80::" 'scope' => "link"} ]{code}The flags are useful when deciding which addresses to configure daemons to bind to. for instance i would not want a daemon to bind to any binding6 which has either the dynamic or temporary Further i think this could be used in determining the network.ip6 fact. for instance we have environment that have static ipv6 addresses as well as a SLAAC address. I think in this instance when there multiple bindings the ones which have flags of mngtmpaddr or dynamic should no be prefered as the primary. however (at least in our environment) the SLAAC address is prefered (see below){code:bash}% sudo ip -6 addr show dev private 6: private: mtu 1500 state UP qlen 1000inet6 2620:0:861:101:1a66:daff:fea3:af25/64 scope global mngtmpaddr dynamic valid_lft 2591993sec preferred_lft 604793secinet6 2620:0:861:101:10:64:0:245/64 scope global valid_lft forever preferred_lft foreverinet6 fe80::1a66:daff:fea3:af25/64 scope link valid_lft forever preferred_lft forever{code} {code:bash}% sudo facter -p networking.interfaces.private { bindings => [{ address => "10.64.0.245", netmask => "255.255.252.0", network => "10.64.0.0"} ], bindings6 => [{ address => "2620:0:861:101:1a66:daff:fea3:af25", netmask => ":::::", network => "2620:0:861:101::"},{ address => "2620:0:861:101:10:64:0:245", netmask => ":::::", network => "2620:0:861:101::"},{ address => "fe80::1a66:daff:fea3:af25", netmask => ":::::", network => "fe80::"} ], ip => "10.64.0.245", ip6 => "2620:0:
Jira (FACT-2913) Are legacy facts deprecated or will they
Title: Message Title john commented on FACT-2913 Re: Are legacy facts deprecated or will they Possibly related https://github.com/puppetlabs/puppet/pull/8492 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.382977.1610465169000.127168.1611825240022%40Atlassian.JIRA.
Jira (FACT-2913) Are legacy facts deprecated or will they
Title: Message Title john updated an issue Facter / FACT-2913 Are legacy facts deprecated or will they Change By: john Could someone provide some guides guiduns or a pointer to the future of legacy facts. specifically; Are there plans to deprecate legacy-facts, If so what is the timeline for this. Or can we assume that legacy facts will always be available/supported 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.382977.1610465169000.112805.1610465460029%40Atlassian.JIRA.
Jira (FACT-2913) Are legacy facts deprecated or will they
Title: Message Title john created an issue Facter / FACT-2913 Are legacy facts deprecated or will they Issue Type: New Feature Assignee: Unassigned Components: DOCS Created: 2021/01/12 7:26 AM Priority: Normal Reporter: john Could someone provide some guides or a pointer to the future of legacy facts. specifically; Are there plans to deprecate legacy-facts, If so what is the timeline for this. Or can we assume that legacy facts will always be available/supported Add Comment This message was se
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title
john updated an issue
Facter / FACT-2907
networking: add binding flags to bindings6 entries
Change By:
john
It would be nice if we could update the networking.$iface.bundings6 entries to also include binding flags. As an example given the following:{code:bash}% sudo ip -6 addr show dev en0 2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ffinet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft foreverinet6 2001:db8::1/64 scope global valid_lft forever preferred_lft foreverinet6 fe80:::bbff:febb:/64 scope link valid_lft forever preferred_lft forever{code}It would be nice to get the following facts{code:Ruby}'en0' => { 'bindings6' => [{ address => "2001:db8:::bbff:febb:", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global" 'flags' => ['mngtmpaddr', 'dynamic']},{ address => "2001:db8::1", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global"},{ address => "fe80:::bbff:febb:", netmask => ":::::", network => "fe80::" 'scope' => "link"} ]{code}The flags are useful when deciding which addresses to configure daemons to bind to. for instance i would not want a daemon to bind to any binding6 which has either the dynamic or temporary Further i think this could be used in determining the network.ip6 fact. for instance we have environment that have static ipv6 addresses as well as a SLAAC address. I think in this instance when there multiple bindings the ones which have flags of mngtmpaddr or dynamic should no be prefered as the primary. however (at least in our environment) the SLAAC address is perfered prefered (see below) {code:bash}% sudo ip -6 addr show dev private 6: private: mtu 1500 state UP qlen 1000inet6 2620:0:861:101:1a66:daff:fea3:af25/64 scope global mngtmpaddr dynamic valid_lft 2591993sec preferred_lft 604793secinet6 2620:0:861:101:10:64:0:245/64 scope global valid_lft forever preferred_lft foreverinet6 fe80::1a66:daff:fea3:af25/64 scope link valid_lft forever preferred_lft forever{code} {code:bash}% sudo facter -p networking.interfaces.private { bindings => [{ address => "10.64.0.245", netmask => "255.255.252.0", network => "10.64.0.0"} ], bindings6 => [{ address => "2620:0:861:101:1a66:daff:fea3:af25", netmask => ":::::", network => "2620:0:861:101::"},{ address => "2620:0:861:101:10:64:0:245", netmask => ":::::", network => "2620:0:861:101::"},{ address => "fe80::1a66:daff:fea3:af25", netmask => ":::::", network => "fe80::"} ], ip => "10.64.0.245", ip6 => "2620:0:
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title
john updated an issue
Facter / FACT-2907
networking: add binding flags to bindings6 entries
Change By:
john
It would be nice if we could update the networking.$iface.bundings6 entries to also include binding flags. As an example given the following:{code:bash} % sudo ip -6 addr show dev en0 2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ffinet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft foreverinet6 2001:db8::1/64 scope global valid_lft forever preferred_lft foreverinet6 fe80:::bbff:febb:/64 scope link valid_lft forever preferred_lft forever{code}It would be nice to get the following facts{code:Ruby}'en0' => { 'bindings6' => [{ address => "2001:db8:::bbff:febb:", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global" 'flags' => ['mngtmpaddr', 'dynamic']},{ address => "2001:db8::1", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global"},{ address => "fe80:::bbff:febb:", netmask => ":::::", network => "fe80::" 'scope' => "link"} ]{code}The flags are useful when deciding which addresses to configure daemons to bind to. for instance i would not want a daemon to bind to any binding6 which has either the dynamic or temporary Further i think this could be used in determining the network.ip6 fact. for instance we have environment that have static ipv6 addresses as well as a SLAAC address. I think in this instance when there multiple bindings the ones which have flags of mngtmpaddr or dynamic should no be prefered as the primary. however (at least in our environment) the SLAAC address is perfered{code:bash}% sudo ip -6 addr show dev private 6: private: mtu 1500 state UP qlen 1000inet6 2620:0:861:101:1a66:daff:fea3:af25/64 scope global mngtmpaddr dynamic valid_lft 2591993sec preferred_lft 604793secinet6 2620:0:861:101:10:64:0:245/64 scope global valid_lft forever preferred_lft foreverinet6 fe80::1a66:daff:fea3:af25/64 scope link valid_lft forever preferred_lft forever{code} {code:bash}% sudo facter -p networking.interfaces.private { bindings => [{ address => "10.64.0.245", netmask => "255.255.252.0", network => "10.64.0.0"} ], bindings6 => [{ address => "2620:0:861:101:1a66:daff:fea3:af25", netmask => ":::::", network => "2620:0:861:101::"},{ address => "2620:0:861:101:10:64:0:245", netmask => ":::::", network => "2620:0:861:101::"},{ address => "fe80::1a66:daff:fea3:af25", netmask => ":::::", network => "fe80::"} ], ip => "10.64.0.245", ip6 => "2620:0:861:101:1a66:daff:fea3
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title
john updated an issue
Facter / FACT-2907
networking: add binding flags to bindings6 entries
Change By:
john
It would be nice if we could update the networking.$iface.bundings6 entries to also include binding flags. As an example given the following:{code:bash}2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ffinet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft foreverinet6 2001:db8::1/64 scope global valid_lft forever preferred_lft foreverinet6 fe80:::bbff:febb:/64 scope link valid_lft forever preferred_lft forever{code}It would be nice to get the following facts{code:Ruby}'en0' => { 'bindings6' => [{ address => "2001:db8:::bbff:febb:", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global" 'flags' => ['mngtmpaddr', 'dynamic']},{ address => "2001:db8::1", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global"},{ address => "fe80:::bbff:febb:", netmask => ":::::", network => "fe80::" 'scope' => "link"} ]{code}The flags are useful when deciding which addresses to configure daemons to bind to. for instance i would not want a daemon to bind to any binding6 which has either the dynamic or temporary Further i think this could be used in determining the network.ip6 fact. for instance we have environment that have static ipv6 addresses as well as a SLAAC address. I think in this instance when there multiple bindings the ones which have flags of mngtmpaddr or dynamic should no be prefered as the primary. however (at least in our environment) the SLAAC address is perfered{code:bash}% sudo ip -6 addr show dev private [16:57:07] 6: private: mtu 1500 state UP qlen 1000inet6 2620:0:861:101:1a66:daff:fea3:af25/64 scope global mngtmpaddr dynamic valid_lft 2591993sec preferred_lft 604793secinet6 2620:0:861:101:10:64:0:245/64 scope global valid_lft forever preferred_lft foreverinet6 fe80::1a66:daff:fea3:af25/64 scope link valid_lft forever preferred_lft forever{code} {code:bash}% sudo facter -p networking.interfaces.private [16:57:28] { bindings => [{ address => "10.64.0.245", netmask => "255.255.252.0", network => "10.64.0.0"} ], bindings6 => [{ address => "2620:0:861:101:1a66:daff:fea3:af25", netmask => ":::::", network => "2620:0:861:101::"},{ address => "2620:0:861:101:10:64:0:245", netmask => ":::::", network => "2620:0:861:101::"},{ address => "fe80::1a66:daff:fea3:af25", netmask => ":::::", network => "fe80::"} ], ip => "10.64.0.245", ip
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title
john updated an issue
Facter / FACT-2907
networking: add binding flags to bindings6 entries
Change By:
john
It would be nice if we could update the networking.$iface.bundings6 entries to also include binding flags. As an example given the following:{code:bash}2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ffinet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft foreverinet6 2001:db8::1/64 scope global valid_lft forever preferred_lft foreverinet6 fe80:::bbff:febb:/64 scope link valid_lft forever preferred_lft forever{code} It would be nice to get the following facts {code:Ruby}'en0' => { 'bindings6' => [{ address => "2001:db8:::bbff:febb:", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global" 'flags' => ['mngtmpaddr', 'dynamic']},{ address => "2001:db8::1", netmask => ":::::", network => "2620:0:861:103::" 'scope' => "global"},{ address => "fe80:::bbff:febb:", netmask => ":::::", network => "fe80::" 'scope' => "link"} ]{code}The flags are useful when deciding which addresses to configure daemons to bind to. for instance i would not want a daemon to bind to any binding6 which has either the dynamic or temporary Further i think this could be used in determining the network.ip6 fact. for instance we have environment that have static ipv6 addresses as well as a SLAAC address. I think in this instance when there multiple bindings the ones which have flags of mngtmpaddr or dynamic should no be prefered as the primary. however (at least in our environment) the SLAAC address is perfered{code:bash}% sudo ip -6 addr show dev private [16:57:07]6: private: mtu 1500 state UP qlen 1000inet6 2620:0:861:101:1a66:daff:fea3:af25/64 scope global mngtmpaddr dynamic valid_lft 2591993sec preferred_lft 604793secinet6 2620:0:861:101:10:64:0:245/64 scope global valid_lft forever preferred_lft foreverinet6 fe80::1a66:daff:fea3:af25/64 scope link valid_lft forever preferred_lft forever{code} {code:bash}% sudo facter -p networking.interfaces.private [16:57:28]{ bindings => [{ address => "10.64.0.245", netmask => "255.255.252.0", network => "10.64.0.0"} ], bindings6 => [{ address => "2620:0:861:101:1a66:daff:fea3:af25", netmask => ":::::", network => "2620:0:861:101::"},{ address => "2620:0:861:101:10:64:0:245", netmask => ":::::", network => "2620:0:861:101::"},{ address => "fe80::1a66:daff:fea3:af25", netmask => ":::::", network => "fe80::"} ], ip => "10.64.0.245", ip6 => "2620:0:861:101:1a66:daff:fea3:af25", ma
Jira (FACT-2907) networking: add binding flags to bindings6 entries
Title: Message Title john created an issue Facter / FACT-2907 networking: add binding flags to bindings6 entries Issue Type: New Feature Assignee: Unassigned Created: 2021/01/05 9:02 AM Priority: Normal Reporter: john It would be nice if we could update the networking.$iface.bundings6 entries to also include binding flags. As an example given the following: 2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ff inet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2001:db8::1/64 scope global valid_lft forever preferred_lft forever
Jira (FACT-2843) scope6 fact should be per binding not per interface
Title: Message Title john updated an issue Facter / FACT-2843 scope6 fact should be per binding not per interface Change By: john Summary: scop6 facter scope6 fact should be per binding not per interface 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.375310.1603200299000.58797.1603205460027%40Atlassian.JIRA.
Jira (FACT-2843) scop6 facter should be per binding not per interface
Title: Message Title john created an issue Facter / FACT-2843 scop6 facter should be per binding not per interface Issue Type: Bug Affects Versions: FACT 4.0.43 Assignee: Unassigned Components: Facter 4 Created: 2020/10/20 6:24 AM Priority: Normal Reporter: john Interface can have multiple ipv6 addresses and each addresses can have a different scope. currently facter reports a scope6 fact at the interface level however it should more correctly report it at the binding level. As an example given the following interface: 2: en0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ff inet6 2001:db8:::bbff:febb:/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever
Jira (PUP-9372) Add collection operations to Puppet core
Title: Message Title john commented on PUP-9372 Re: Add collection operations to Puppet core > The PR has a few examples Adding a link for us mortals that can see it in tickets.puppetlabs.com https://github.com/puppetlabs/puppet/pull/7310 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.289683.1545348982000.52495.1602246720031%40Atlassian.JIRA.
Jira (PUP-6022) Typing local variables does not work - results in Error: This Type-Name has no effect
Title: Message Title john commented on PUP-6022 Re: Typing local variables does not work - results in Error: This Type-Name has no effect Henrik Lindberg thanks i hadn't noticed that the variable in `vartest::params` was not a parameter 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.120438.145747609.105483.1568884920320%40Atlassian.JIRA.
Jira (PUP-6022) Typing local variables does not work - results in Error: This Type-Name has no effect
Title: Message Title john commented on PUP-6022 Re: Typing local variables does not work - results in Error: This Type-Name has no effect I came across this issue while investigating a different problem and just wanted to clarify. first, thanks Henrik Lindberg for the great explanation however i believe the following needs clarifying Puppet 4.x does not support typing variables. Type aliases where introduced in puppet 4.4 so i think this should read "Puppet < 4.4.0 does not support typing variables. 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.120438.145747609.97046.1568372220165%40Atlassian.JIRA.
Jira (PDB-3743) ensure PDB 4.4.x can be run with puppetserver 5.x
Title: Message Title john commented on PDB-3743 Re: ensure PDB 4.4.x can be run with puppetserver 5.x Late to the party but same issue ii puppet 5.5.10-4 all configuration management system ii puppet-master 5.5.10-4 all configuration management system, master service ii puppet-master-passenger 5.5.10-4 all configuration management system, scalable master service ii puppet-terminus-puppetdb 6.2.0-3 all Puppet data warehouse ii puppetdb 4.4.0-1 all Puppet Labs puppetdb Reading the related issues seems the advice from the developers are just upgrade everything all at once 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.220054.1509640239000.46281.1565173981295%40Atlassian.JIRA.
Jira (FACT-1885) Facter doesn't like the notify flag on routing table entries
Title: Message Title john commented on FACT-1885 Re: Facter doesn't like the notify flag on routing table entries I think this is the same issue fixed in FACT-1916. the fix was pretty much "...give up trying to parse key/value pairs and scan for the keys we want" 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.276374.153736313.6298.1562247660154%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7814) HTTPS file sources with non-puppet-trusted certs can't be used
Title: Message Title John commented on PUP-7814 Re: HTTPS file sources with non-puppet-trusted certs can't be used I had a similar issue, however the ticket PUP-8889 Puppet Agent : cannot add certificates for HTTPS Franck Jouvanceau added a comment - 2018/06/06 5:04 AM helped a great deal, and now I confirm the solution described on the ticket works as a charm. 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.203766.1501710671000.3173.1562083620998%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1916) facter fails to parse routing table
Title: Message Title john commented on FACT-1916 Re: facter fails to parse routing table proposed fix https://github.com/puppetlabs/facter/pull/1775 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-1916) facter fails to parse routing table
Title: Message Title john created an issue Facter / FACT-1916 facter fails to parse routing table Issue Type: Bug Affects Versions: FACT 3.13.1 Assignee: Unassigned Created: 2019/05/02 6:17 AM Priority: Normal Reporter: john The facter module fails to parse entries from `ip show route` if the line has an even number of words but is not preceded with one of the known route types. The restriction to have an even number of words was added as part of FACT-1282 however its not clear from the bug report or the pull request why routes preceded with a route type should have an even number of words however normal entries don't. It seems that an assumption was made which assumed all entries emitted by `ip show route` are key value pairs however this is not the case as show by FACT-1394 and my current case which has an entry as follows (notice the option `mtu lock 1450`) 192.168.250.22 via 192.168.1.1 dev enx0050b6a21be3 mtu lock 1450 We are also tracking this issue via https://phabricator.wikimedia.org/T222356 Add Comment
Jira (FACT-1020) Support augeasversion in Facter 3
Title: Message Title john commented on FACT-1020 Re: Support augeasversion in Facter 3 looks like this is a problem in debian packaging as `apt-get install augeas-tools` fixed the issue 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-1020) Support augeasversion in Facter 3
Title: Message Title john commented on FACT-1020 Re: Support augeasversion in Facter 3 this is marked as fixed but i dont think it is and the last comment is not very helpfull root@jbond-buster:~# facter -v augeas 3.11.0 root@jbond-buster:~# facter -p augeas root@jbond-buster:~# facter -p augeasversion Add Comment
Jira (PUP-8983) validate_cmd creates tmp file with inconsistent permissions
Title: Message Title john commented on PUP-8983 Re: validate_cmd creates tmp file with inconsistent permissions have attempted a fix[1] for this. It is not a complete fix as the mode is not maintained. Further the uid/gid of the file on disk still takes preference over the `should` values. [1]https://github.com/puppetlabs/puppet/pull/6908 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-8983) validate_cmd creates tmp file with inconsistent permissions
Title: Message Title
john commented on PUP-8983
Re: validate_cmd creates tmp file with inconsistent permissions
re-ran the tests specifying a mode on the file type on the results are the same, i.e. the mode of the temp file is not set to the `should` state
file {'/tmp/test/test':
ensure => file,
owner => 'jbond',
group => 'jbond',
mode => '0555',
content => 'foobar',
validate_cmd => '/bin/false ',
}
root@dev:~# while true ; do ls -l /tmp/test/ | grep test ; done
-rw--- 1 root root 6 Jul 5 18:53 test20180705-18902-1r3rv8u
root@dev:~# touch /tmp/test/test
root@dev:~# chown jbond:jbond !$
Jira (PUP-8983) validate_cmd creates tmp file with inconsistent permissions
Title: Message Title
john created an issue
Puppet / PUP-8983
validate_cmd creates tmp file with inconsistent permissions
Issue Type:
Bug
Assignee:
Unassigned
Components:
Types and Providers
Created:
2018/07/05 9:55 AM
Priority:
Normal
Reporter:
john
Puppet Version: 5.5.0 Puppet Server Version: NA OS Name/Version: Linux & Mc OSX confirmed When the validate_cmd runs it creates a temporary file however the permissions it assigns to this temporary file are not related to the permissions defined on the file type object. Desired Behaviour: The temporary file used when running the validate command should have the exact same permissions as the file resources it is trying to create. e.g. with a file type of
file {'/tmp/test':
owner => 'foo',
group => 'bar',
mode => '0555',
validate_cmd => 'test -
Jira (PUP-5880) Support optional dependencies in Metadata.json
Title: Message Title john commented on PUP-5880 Re: Support optional dependencies in Metadata.json I would also like to see this specificly for the case of supporting multiple operating systems e.g. on debian require apt, on Redhat require yum etc Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574) -- 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-128) Hiera deep merge on hash doesn't have a "whiteout" or "remove this key" value
Title: Message Title john commented on HI-128 Re: Hiera deep merge on hash doesn't have a "whiteout" or "remove this key" value Im having the same issue, the knockout_prefix seems to have no affect 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 (PDB-2444) pogo games support
Title: Message Title john updated an issue PuppetDB / PDB-2444 pogo games support Change By: john Environment: Talk:CALL US 844-237-9635 Pogo TECHNICAL Support P.h.o.n.e N.u.m.b.e.r, Pogo Games TECH Support P.h.o.n.e N.u.m.b.e.r 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 (PDB-2444) pogo games support
Title: Message Title john created an issue PuppetDB / PDB-2444 pogo games support Issue Type: Bug Assignee: Unassigned Created: 2016/02/17 11:06 PM Priority: Normal Reporter: john CALL US_844-237-9635 Pogo TECHNICAL Support P.h.o.n.e N.u.m.b.e.r, Pogo Games TECH Support P.h.o.n.e N.u.m.b.e.r 844-237-9635 Pogo Games Support P.h.o.n.e N.u.m.b.e.r, Pogo Games Support P.h.o.n.e N.u.m.b.e.r 1. Pogo support p.h.o.n.e n.u.m.b.e.r, Pogo technical support p.h.o.n.e n.u.m.b.e.r, Pogo customer support p.h.o.n.e n.u.m.b.e.r, Pogo Help desk support p.h.o.n.e n.u.m.b.e.r, Pogo tech support p.h.o.n.e n.u.m.b.e.r, Pogo customer service p.h.o.n.e n.u.m.b.e.r Pogo support n.u.m.b.e.r, Pogo technical support n.u.m.b.e.r, Pogo customer support n.u.m.b.e.r, Pogo Help desk support n.u.m.b.e.r, Pogo tech support n.u.m.b.e.r, Pogo customer service n.u.m.b.e.r Pogo support games p.h.o.n.e n.u.m.b.e.r, Pogo games technical support p.h.o.n.e n.u.m.b.e.r, Pogo games customer support p.h.o.n.e n.u.m.b.e.r, Pogo games Help desk support p.h.o.n.e n.u.m.b.e.r, Pogo games tech support p.h.o.n.e n.u.m.b.e.r, Pogo games customer service p.h.o.n.e n.u.m.b.e.r Pogo games support n.u.m.b.e.r, Pogo games technical support n.u.m.b.e.r, Pogo games customer support n.u.m.b.e.r, Pogo games Help desk support n.u.m.b.e.r, Pogo games tech support n.u.m.b.e.r, Pogo games customer service n.u.m.b.e.r Pogo support p.h.o.n.e n.u.m.b.e.r, Pogo technical support p.h.o.n.e n.u.m.b.e.r, Pogo customer support p.h.o.n.e n.u.m.b.e.r, Pogo Help desk support p.h.o.n.e n.u.m.b.e.r, Pogo tech support p.h.o.n.e n.u.m.b.e.r, Pogo customer service p.h.o.n.e n.u.m.b.e.r Pogo support n.u.m.b.e.r, Pogo technical support n.u.m.b.e.r, Pogo customer support n.u.m.b.e.r, Pogo Help desk support n.u.m.b.e.r, Pogo tech support n.u.m.b.e.r, Pogo customer service n.u.m.b.e.r 844-237-9635# Pogo support p.h.o.n.e n.u.m.b.e.r, Pogo technical support p.h.o.n.e n.u.m.b.e.r, Pogo customer support p.h.o.n.e n.u.m.b.e.r, Pogo Help desk support p.h.o.n.e n.u.m.b.e.r, Pogo t
Jira (PUP-2553) Redhat service enable does not honour chkconfig or LSB Headers.
Title: Message Title john commented on an issue Re: Redhat service enable does not honour chkconfig or LSB Headers. Added pull request https://github.com/puppetlabs/puppet/pull/2643 Add Comment Puppet / PUP-2553 Redhat service enable does not honour chkconfig or LSB Headers. Using chkconfig on blindly sets the service on in runlevel 2,3,4,5. puppet should use chkconfig resetpriorities. when enabling services so that it honours the settings in the chkconfig and LSB Headers. 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-2553) Redhat service enable does not honour chkconfig or LSB Headers.
Title: Message Title john created an issue Puppet / PUP-2553 Redhat service enable does not honour chkconfig or LSB Headers. Issue Type: Bug Assignee: Kylo Ginsberg Components: Types and Providers Created: 13/May/14 9:08 AM Environment: Redhat Priority: Normal Reporter: john Original Estimate: 1 hour Remaining Estimate: 1 hour Using chkconfig on blindly sets the service on in runlevel 2,3,4,5. puppet should use chkconfig resetpriorities. when enabling services so that it honours the settings in the chkconfig and LSB Headers.
