Jira (PUP-10153) file_line no longer documented on Puppet.com
Title: Message Title Paul Anderson created an issue Puppet / PUP-10153 file_line no longer documented on Puppet.com Issue Type: Improvement Assignee: Unassigned Attachments: Screen Shot 2019-12-02 at 11.01.57 AM.png, Screen Shot 2019-12-02 at 11.09.43 AM.png Created: 2019/12/02 10:10 AM Priority: Normal Reporter: Paul Anderson file_line is an important resource, part of stdlib. I noticed recently that it's no longer documented anywhere in puppet.com. I'm not sure why. https://puppet.com/docs/puppet/latest/type.html doesn't list it. (probably because it's supposed to be documented elsewhere) It's not searchable from puppet.com: it's not documented under stdlib on the forge (see attached picture): Add Comment
Jira (BOLT-1505) Broken link in Bolt Hands-on workshop
Title: Message Title
Paul Anderson created an issue
Puppet Task Runner / BOLT-1505
Broken link in Bolt Hands-on workshop
Issue Type:
Story
Assignee:
Unassigned
Created:
2019/08/07 12:36 PM
Priority:
Normal
Reporter:
Paul Anderson
Proceeding through the Hands-on workshop, one reaches this page: https://puppetlabs.github.io/bolt/lab/04-running-scripts/ Unfortunately, the link to the bash script points to a non-existant URL: curl -O https://puppetlabs.github.io/bolt/lessons/lesson1-10/src/bashcheck.sh And so one downloads a 404 HTML page without realizing there is an error. The rest of the exercise goes downhill quickly... $ curl -O https://puppetlabs.github.io/bolt/lessons/lesson1-10/src/bashcheck.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9339 100 9339 0 0 200k 0 -::- -::- -::- 202k $ bolt script run bashcheck.sh -n Started on node2... Started on node3... Started on node1... Failed on node3: The command failed with exit code 2 STDERR: /tmp/aca9c3cb-84ab-4c84-ab89-d5453348913b/bashcheck.sh: line 1: syntax error near unexpected token `newline' /tmp/aca9c3cb-84ab-4c84-ab89-d5453348913b/bashcheck.sh: line 1: `' Failed on node1: The command failed with exit code 2 STDERR: /tmp/adb88758-9f69-460b-978c-10438798e4ff/bashcheck.sh: line 1: syntax error near unexpected token `newline' /tmp/adb88758-9f69-460b-978c-10438798e4ff/bashcheck.sh: line 1: `' Failed on node2: The command failed with exit code 2 STDERR: /tmp/0a0556a2-6b34-401c-8f8a-6f3be4775d3a/bashcheck.sh: line 1: syntax error near unexpected token `newline' /tmp/0a0556a2-6b34-401c-8f8a-6f3be4775d3a/bashcheck.sh: line 1: `' Failed on 3 nodes: node1, node2, node3 Ran on 3 nodes in 3.42 seconds $ {{}} {{}}
Jira (FACT-1885) Facter doesn't like the notify flag on routing table entries
Title: Message Title Paul Anderson updated an issue Facter / FACT-1885 Facter doesn't like the notify flag on routing table entries Change By: Paul Anderson Summary: Facter doesn't like the notify flag on routing table entries for bionic on Win10 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.21036.1558775340246%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1885) Facter doesn't like the notify flag on routing table entries for bionic on Win10
Title: Message Title Paul Anderson updated an issue Facter / FACT-1885 Facter doesn't like the notify flag on routing table entries for bionic on Win10 Change By: Paul Anderson Summary: Facter doesn't like the notify flag on routing table entries for bionic on Win10 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.21032.1558775280672%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9721) Facter routing table process issues for Bionic on Windows
Title: Message Title Paul Anderson created an issue Puppet / PUP-9721 Facter routing table process issues for Bionic on Windows Issue Type: Improvement Assignee: Unassigned Created: 2019/05/25 2:07 AM Environment: Windows 10 Pro Version 1903 OS Build 18362.116 Enabled "Windows Services for Linux" Installed Ubuntu from Microsoft store installed puppet6-release-bionic.deb root@Freyir:~# apt-show-versions puppet-agent puppet-agent:amd64/bionic 6.4.2-1bionic uptodate Priority: Normal Reporter: Paul Anderson facter > /dev/null 2019-05-25 03:03:38.127149 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'none 169.254.0.0/16 dev eth0 proto unspec metric 256' 2019-05-25 03:03:38.128702 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'none 169.254.97.104 dev eth0 proto unspec metric 256' 2019-05-25 03:03:38.130061 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'none 169.254.255.255 dev eth0 proto unspec metric 256' 2019-05-25 03:03:38.131062 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'none 224.0.0.0/4 dev eth0 proto unspec metric 256' 2019-05-25 03:03:38.132016 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'none 255.255.255.255 dev eth0 proto unspec metric 256' 2019-05-25 03:03:38.132991 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got 'none 224.0.0.0/4 dev eth1 proto unspec metric 256' 2019-05-25 03:03:38.133845 WARN puppetlabs.facter - Could not process routing table entry: Expected a destination followed by key/value pairs, got
Jira (PUP-9582) RPM provider is not idempotent
Title: Message Title Paul Anderson commented on PUP-9582 Re: RPM provider is not idempotent Branan Riley Yes, that did it. 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-9582) RPM provider is not idempotent
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-9582
RPM provider is not idempotent
Change By:
Paul Anderson
Assume a simple use case, making sure that a node has the correct puppet release repo: package { 'Puppet6 repo': # source => 'https://yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm',source => 'puppet6-release-el-7.noarch.rpm',ensure => present,provider => rpm, }If you puppet apply this once, it works as expected. If you apply it a second (or subsequent times) you'll get this error:Error: Execution of '/bin/rpm -i ./puppet6-release-el-7.noarch.rpm' returned 1: package puppet6-release-6.0.0-1.el7.noarch is already installedError: /Stage[main]/Main/Package[Puppet6 repo]/ensure: change from 'absent' to 'present' failed: Execution of '/bin/rpm -i ./puppet6-release-el-7.noarch.rpm' returned 1: package puppet6-release-6.0.0-1.el7.noarch is already installedThis implementation is therefore not idempotent. For context: I am using RPM instead of Yum because I am trying to do a quick-and-dirty installation of the Puppet6 release repo , e.g. by pulling it down from the web: package { 'Puppet repo':source => 'https://yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm',ensure => present,provider => rpm, } While troubleshooting, I noticed this also failed when using a local RPM .
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9582) RPM provider is not idempotent
Title: Message Title
Paul Anderson created an issue
Puppet / PUP-9582
RPM provider is not idempotent
Issue Type:
New Feature
Assignee:
Unassigned
Created:
2019/03/26 10:38 AM
Environment:
CentOS Linux release 7.2.1511 in vagrant ('puppetlabs/centos-7.2-64-nocm' box) Puppet 6.0.5
Priority:
Normal
Reporter:
Paul Anderson
Assume a simple use case, making sure that a node has the correct puppet release repo: package { 'Puppet6 repo': # source => 'https://yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm', source => 'puppet6-release-el-7.noarch.rpm', ensure => present, provider => rpm, } If you puppet apply this once, it works as expected. If you apply it a second (or subsequent times) you'll get this error: Error: Execution of '/bin/rpm -i ./puppet6-release-el-7.noarch.rpm' returned 1: package puppet6-release-6.0.0-1.el7.noarch is already installed Error: /Stage[main]/Main/Package[Puppet6 repo]/ensure: change from 'absent' to 'present' failed: Execution of '/bin/rpm -i ./puppet6-release-el-7.noarch.rpm' returned 1: package puppet6-release-6.0.0-1.el7.noarch is already installed This implementation is therefore not idempotent. For context: I am using RPM instead of Yum because I am trying to do a quick-and-dirty installation of the Puppet6 release repo, e.g. package { 'Puppet repo': source => 'https://yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm', ensure => present, provider => rpm, } I noticed this also failed when using a local RPM.
Jira (FACT-1380) Restore --timing option to native facter
Title: Message Title Paul Anderson commented on FACT-1380 Re: Restore --timing option to native facter I came up with a quick and dirty bash one-liner that is neither elegant nor guaranteed accurate, but was enough to help the user get a rough order of magnitude read on each of their facts. for fact in `facter -p | egrep '^\w+\s=>' | cut -f 1 -d "="`; do echo $fact; time /usr/local/bin/facter -p $fact > /dev/null; done 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-1380) Restore --timing option to native facter
Title: Message Title Paul Anderson updated an issue Facter / FACT-1380 Restore --timing option to native facter Change By: Paul Anderson Labels: PS linux regression windows 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-1380) Restore --timing option to native facter
Title: Message Title Paul Anderson commented on FACT-1380 Re: Restore --timing option to native facter Robert Petersson Can you tell us what further information you're looking for? 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-1380) Restore --timing option to native facter
Title: Message Title Paul Anderson commented on FACT-1380 Re: Restore --timing option to native facter This came up for a user I was speaking with today. 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 Paul Anderson commented on FACT-1870 Re: Stdout in facts invalidates formatted output (yaml/json) To echo Martin Jackson, I had a conversation today where the output of Factor -j is being consumed by other (non-puppet) tooling, and should therefore just work... We should strongly consider ensuring that -y or -j should always produce parsable output. 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-6716) Error when purging local users on Windows
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6716
Error when purging local users on Windows
Change By:
Paul Anderson
This a significant customer, KPN user .FROM THE CUSTOMER USER :We want to control the local users with Puppet and purge any unmanaged user for audit compliance and security purposes. When I configure this in the below manifest I get the following error: Error: /Stage[main]/Main/Resources[user]: Failed to generate additional resources using 'generate': comparison of String with 499 failed Can this please be fixed.user { ['Administrator', 'guest']: ensure => present }resources { 'user': purge => true }As a generic rule of thumb you can expect us to use Puppet and all classes on every Windows edition available from 2003 and up, although 2008 and up is really the current scope, don't care too much about 2003. I just tested and this doesn't work on Windows 2012R2 either. I've never tested it before, we're in the process of putting this compliancy rule in Puppet so this is the first time I run into this. It looks like a bug to me, tt work fine (as expected) for for example the group resource or host resource and even type/providers we created ourselves.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-8908) Resource status of "failed_to_restart" is not included in reports for individual resources
Title: Message Title Paul Anderson commented on PUP-8908 Re: Resource status of "failed_to_restart" is not included in reports for individual resources Jacob Helwig Thanks for the clarification. That's helpful! 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-8908) Resource status of "failed_to_restart" is not included in reports for individual resources
Title: Message Title Paul Anderson commented on PUP-8908 Re: Resource status of "failed_to_restart" is not included in reports for individual resources I think there are a few users interested in this topic would would strongly agree with Eric Sorenson. Let's make sure it's pulled into the 5.5.x backlog if possible 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 (BOLT-575) Framework to pipe output of one task as input to another
Title: Message Title Paul Anderson updated an issue Puppet Task Runner / BOLT-575 Framework to pipe output of one task as input to another Change By: Paul Anderson I am a Puppet practitioner working in a large enterprise infrastructure. In order to abstract away complexity, I need to run one (or more) tasks that generate some necessary and useful output and pass it to another task in the task plan as parameters to the task. Here are some example scenarios:# I have configuration stored in Hiera, and I need to do a hiera lookup to find the appropriate node-specific data, and then run a command with that data on the target node; I don't want to sync the hiera files across my infrastructure.# I have secrets encrypted in eYAML, so I need to run one task on the MOM or CM to retrieve the decrypted secret for one node and then run a second task on a target node using that secret; I don't want to distribute the eyaml keys further than necessary# As above, but using some other source of truth (a secret store such as Vault, Conjur, or CyberArk come to mind), so I have to run a task on a special node to get the data and then run a second task on a target node that has no access to the source of truth; I don't want to allow more nodes access to the secret stores than necessary, or deal with manifold least-privilege and node-specific secret store credentials.# I need to perform an orchestration task involving clustering. The cluster requires some sort of shared secret to establish a trust relationship. The secret is generated on one system as part of one task and then passed to other tasks run on other members of the cluster; Managing this data in hiera would be too time consuming (better to get it as a fact for each node after configuration).Although it would be complicated, it is possible to imagine a scenario in which a Puppet practitioner would need to do all four of these scenarios for a single node in a single task plan . Therefore some way to cache output so it could be assembled and then passed as parameters to tasks later in the task plan would be appropriate. Finally, as secrets are a likely use case, we need to consider how to prevent leakage, whatever that might mean. Add Comment
Jira (BOLT-575) Framework to pipe output of one task as input to another
Title: Message Title Paul Anderson updated an issue Puppet Task Runner / BOLT-575 Framework to pipe output of one task as input to another Change By: Paul Anderson I am a Puppet practitioner working in a large enterprise infrastructure. In order to abstract away complexity, I need to run one (or more) tasks that generate some necessary and useful output and pass it to another task in the task plan as parameters to the task. Here are some example scenarios:# I have configuration stored in Hiera, and I need to do a hiera lookup to find the appropriate node-specific data, and then run a command with that data on the target node; I don't want to sync the hiera files across my infrastructure.# I have secrets encrypted in eYAML, so I need to run one task on the MOM or CM to retrieve the decrypted secret for one node and then run a second task on a target node using that secret; I don't want to distribute the eyaml keys further than necessary# As above, but using some other source of truth (a secret store such as Vault, Conjur, or CyberArk come to mind), so I have to run a task on a special node to get the data and then run a second task on a target node that has no access to the source of truth; I don't want to allow more nodes access to the secret stores than necessary , or deal with manifold least-privilege and node-specific secret store credentials. # I need to perform an orchestration task involving clustering. The cluster requires some sort of shared secret to establish a trust relationship. The secret is generated on one system as part of one task and then passed to other tasks run on other members of the cluster; Managing this data in hiera would be too time consuming (better to get it as a fact for each node after configuration).Although it would be complicated, it is possible to imagine a scenario in which a Puppet practitioner would need to do all four of these scenarios for a single node. Therefore some way to cache output so it could be assembled and then passed as parameters to tasks later in the task plan would be appropriate. Finally, as secrets are a likely use case, we need to consider how to prevent leakage, whatever that might mean. Add Comment
Jira (BOLT-575) Framework to pipe output of one task as input to another
Title: Message Title Paul Anderson updated an issue Puppet Task Runner / BOLT-575 Framework to pipe output of one task as input to another Change By: Paul Anderson I am a Puppet practitioner working in a large enterprise infrastructure. In order to abstract away complexity, I need to run one (or more) tasks that generate some necessary and useful output and pass it to another task in the task plan as parameters to the task. Here are some example scenarios:# I have configuration stored in Hiera, and I need to do a hiera lookup to find the appropriate node-specific data, and then run a command with that data on the target node; I don't want to sync the hiera files across my infrastructure. # I have secrets encrypted in eYAML, so I need to run one task on the MOM or CM to retrieve the decrypted secret for one node and then run a second task on a target node using that secret; I don't want to distribute the eyaml keys further than necessary # As above, but using some other source of truth (a secret store such as Vault, Conjur, or CyberArk come to mind), so I have to run a task on a special node to get the data and then run a second task on a target node that has no access to the source of truth; I don't want to allow more nodes access to the secret stores than necessary # I need to perform an orchestration task involving clustering. The cluster requires some sort of shared secret to establish a trust relationship. The secret is generated on one system as part of one task and then passed to other tasks run on other members of the cluster; Managing this data in hiera would be too time consuming (better to get it as a fact for each node after configuration).Although it would be complicated, it is possible to imagine a scenario in which a Puppet practitioner would need to do all four of these scenarios for a single node. Therefore some way to cache output so it could be assembled and then passed as parameters to tasks later in the task plan would be appropriate. Finally, as secrets are a likely use case, we need to consider how to prevent leakage, whatever that might mean. Add Comment
Jira (BOLT-575) Framework to pipe output of one task as input to another
Title: Message Title Paul Anderson created an issue Puppet Task Runner / BOLT-575 Framework to pipe output of one task as input to another Issue Type: Improvement Assignee: Unassigned Created: 2018/06/06 9:39 PM Priority: Normal Reporter: Paul Anderson I am a Puppet practitioner working in a large enterprise infrastructure. In order to abstract away complexity, I need to run one (or more) tasks that generate some necessary and useful output and pass it to another task in the task plan as parameters to the task. Here are some example scenarios: I have configuration stored in Hiera, and I need to do a hiera lookup to find the appropriate node-specific data, and then run a command with that data on the target node; I don't want to sync the hiera files across my infrastructure. I have secrets encrypted in eYAML, so I need to run one task on the MOM or CM to retrieve the decrypted secret for one node and then run a second task on a target node using that secret; I don't want to distribute the eyaml keys further than necessary As above, but using some other source of truth (a secret store such as Vault, Conjur, or CyberArk come to mind), so I have to run a task on a special node to get the data and then run a second task on a target node that has no access to the source of truth; I don't want to allow more nodes access to the secret stores than necessary I need to perform an orchestration task involving clustering. The cluster requires some sort of shared secret to establish a trust relationship. The secret is generated on one system as part
Jira (BOLT-542) It should be easy to query PuppetDB with Bolt
Title: Message Title
Paul Anderson updated an issue
Puppet Task Runner / BOLT-542
It should be easy to query PuppetDB with Bolt
Change By:
Paul Anderson
As a system administrator using Open Source Puppet, or Puppet Enterprise in a context where the Puppet task interface is sub-optimal (edge cases involving the certs directory , perhaps), I would like to query PuppetDB for a list of nodes to run an ad-hoc task against. Today, such functionality can be accomplished using something like this:{{curl -X GET http://puppetdb.mydomain.edu:8080/v3/facts/fqdn | jq '.[] | .value' | sed 's/"//g' > target_nodes.txt}}Alternately, it may make more sense to query a Puppet infrastructure for managed nodes (e.g. those with a signed and un-revoked certificate)
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
Jira (BOLT-542) It should be easy to query PuppetDB with Bolt
Title: Message Title Paul Anderson created an issue Puppet Task Runner / BOLT-542 It should be easy to query PuppetDB with Bolt Issue Type: Improvement Assignee: Unassigned Created: 2018/05/24 7:19 AM Priority: Normal Reporter: Paul Anderson As a system administrator using Open Source Puppet, or Puppet Enterprise in a context where the Puppet task interface is sub-optimal, I would like to query PuppetDB for a list of nodes to run an ad-hoc task against. Today, such functionality can be accomplished using something like this: curl -X GET http://puppetdb.mydomain.edu:8080/v3/facts/fqdn | jq '.[] | .value' | sed 's/"//g' > target_nodes.txt Alternately, it may make more sense to query a Puppet infrastructure for managed nodes (e.g. those with a signed and un-revoked certificate) Add Comment
Jira (PUP-8395) Exec Parity for Windows
Title: Message Title Paul Anderson updated an issue Puppet / PUP-8395 Exec Parity for Windows Change By: Paul Anderson In Linux, Puppet typically runs as root (full privileges) and can leverage the exec resource's user parameter to run a command as a local user. In Windows, this parity is lacking and it's increasingly causing problems for Puppet users. It would be nice to run things as a local user.This issue is further compounded by common Microsoft System Administration use cases, where various pieces of software are installed and run as domain service accounts. For instance, the SQL Server module does it with [some gnarly Ruby in a provider to set domain credentials in 3 places | https://github.com/puppetlabs/puppetlabs-sqlserver/blob/master/lib/puppet/provider/sqlserver_features/mssql.rb#L7 -L8 ] by passing parameters to the installer. I suggest writing a custom installation provider for software requiring a service account is not a reasonable ask for a typical user who is an experienced Windows admin and nascent Puppet practitioner.There is a large and growing amount of Microsoft enterprise software (SQL Server, SCOM, SCCM, SCVMM) that recommends or requires the use of a domain service account, and there's not currently a good way to address it. Feature parity (and perhaps going a little further to support Domain Accounts) would be a good start, especially if this exec allows users to get the automation done while we determine if other features are needed. (For instance, passing a Microsoft Domain user credential to the package resource).Finally, field experience indicates this is complicated further by Mandatory Access Controls. These may limit the ability of any service running as Local System to interact with the wider world using domain credentials. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Jira (PUP-8395) Exec Parity for Windows
Title: Message Title Paul Anderson created an issue Puppet / PUP-8395 Exec Parity for Windows Issue Type: New Feature Affects Versions: PUP 5.3.3 Assignee: Unassigned Components: Types and Providers Created: 2018/01/24 11:46 PM Environment: Windows Priority: Normal Reporter: Paul Anderson In Linux, Puppet typically runs as root (full privileges) and can leverage the exec resource's user parameter to run a command as a local user. In Windows, this parity is lacking and it's increasingly causing problems for Puppet users. It would be nice to run things as a local user. This issue is further compounded by common Microsoft System Administration use cases, where various pieces of software are installed and run as domain service accounts. For instance, the SQL Server module does it with some gnarly Ruby in a provider by passing parameters to the installer. I suggest writing a custom installation provider for software requiring a
Jira (PUP-6739) Error running puppet with non-existent and non-default environment
Title: Message Title Paul Anderson commented on PUP-6739 Re: Error running puppet with non-existent and non-default environment Melissa Stone I agree that if I put my end user had on, and I set the environment in [main], and Puppet explodes, and double checking the documentation doesn't give me any reason to prefer the [agent] environment, that the current documentation is misleading. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- 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-6739) Error running puppet with non-existent and non-default environment
Title: Message Title Paul Anderson commented on PUP-6739 Re: Error running puppet with non-existent and non-default environment Melissa Stone I see how I was unclear in my communication (I'm not talking about the notice/warning; it's the crash!). The issue does not occur when someone sets their environment in the agent section of the configuration. However, if one sets the environment in the [main] section on a Puppet-managed system running only the agent, they will encounter this error. This is quickly reproducible via puppet config set agent other_than_production and then puppet help. Also, to your documentation point, [the current documentation]( https://puppet.com/docs/puppet/5.3/config_file_main.html#config-sections) would seem to indicate that setting the environment in [main] should be fine, since one would assume no [server] functions would occur on an agent-only node: main is the global section used by all commands and services. It can be overridden by the other sections. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- 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-6739) Error running puppet with non-existent and non-default environment
Title: Message Title
Paul Anderson commented on PUP-6739
Re: Error running puppet with non-existent and non-default environment
Melissa Stone,
I think the drop dead simple most people encounter this issue is that they, like all good sysadmins, want to remove the warning they see on non-production managed puppet nodes (not the server):
Notice: Local environment: 'production' doesn't match server specified node environment 'development', switching agent to 'development'.
Some people see that and get concerned and do something like this: https://groups.google.com/forum/#!topic/puppet-users/RjdQ7jXLx5w
The unfortunate issue is that that advice USED to work, but now causes fireworks. I suppose it could still work if we added an additional resource to the base profile: {{class profile::base { ... ini_setting { "puppet_environment": ensure => present, path => '/etc/puppet/puppet.conf', section => 'agent', setting => 'environment', value => $::environment, }
file { 'create empty local environment on agent nodes so puppet commands don't explode' : ensure => present, path => "/etc/puppetlabs/code/environments/$ {environment}
, } ... }}} (This is related to your second scenario).
Add Comment
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
--
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-1545) Exit code is always 0
Title: Message Title Paul Anderson commented on FACT-1545 Re: Exit code is always 0 A colleague bumped into something similar where there was a problem with code deployment. They THOUGHT the new custom fact was present, but it wasn't due to the most recent code not being deployed. They looked many places until they found out that it wasn't that the fact was returning an empty string, it was that the fact was missing. 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 (PUP-6739) Error running puppet with non-existent and non-default environment
Title: Message Title Paul Anderson commented on PUP-6739 Re: Error running puppet with non-existent and non-default environment Jesse Reynolds When this bug is rearing its ugly head, everything is broken including puppet help The workaround is to slap --environment production as a closing argument to the puppet command. 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 (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson commented on PUP-6554 Re: Can't run puppet resource on agent with environment specified in main section Nicholas Fagerlund, I've been watching traffic on this issue and related tickets for awhile. I'd like to point out two distinctions that I think the team would do well to be aware of: 1. The current behavior is a stack trace. That's bad and should get some sort of immediate triage. The tool should at least exit gracefully with an error message 2. Once that initial fatal error is resolved, then yes, the tool should work as it had previously done. Having an environment set (so as to not get the warning in your logs) and then running a local puppet command (where the environment directory doesn't exist) shouldn't be a problem. 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-1545) Exit code is always 0
Title: Message Title
Paul Anderson commented on FACT-1545
Re: Exit code is always 0
IIRC this came up during a fundamentals training. It was a suggestion from one of the students.
If one is using facter stand alone and needs the check whether or not a fact exists or not, they could check the output of facter (as opposed to the exit code as being discussed here).
I'm having a hard time imagining the edge case where someone needs to know if a fact exists but is empty (e.g. {fluffy => { bunny => "" }
}) versus does not exist { fluffy => { kitten => "" }} )
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-1545) Exit code is always 0
Title: Message Title Paul Anderson created an issue Facter / FACT-1545 Exit code is always 0 Issue Type: Bug Affects Versions: FACT 3.4.1 Assignee: Unassigned Created: 2016/12/07 8:03 AM Priority: Normal Reporter: Paul Anderson If facter is run against a non-existant fact, it still returns success. One might assume it should return a non-zero exit code: #Ask for a fact that doesn't exist root@paul:~ # facter fluffy.bunny #Check the exit status root@paul:~ # echo $? 0 Add Comment
Jira (PUP-6552) Regression: Redhat / Debian / Ubuntu can't specify 'init' provider
Title: Message Title Paul Anderson commented on PUP-6552 Re: Regression: Redhat / Debian / Ubuntu can't specify 'init' provider Thomas Mueller, In this case, it's an issue of supporting a 3rd party-provided commercial init script that is intended to run both on Solaris and RHEL. I presume the customer accepts the inherent limitations of the script provided by their software vendor, just that they want Puppet to be able to start and stop it such as it is. 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 (PUP-6739) If $environment is set and $server is not set, running any 'puppet' command will result in search for environment directory locally on agent
Title: Message Title Paul Anderson commented on PUP-6739 Re: If $environment is set and $server is not set, running any 'puppet' command will result in search for environment directory locally on agent I should probably say that I'm very much in support of the suggested resolution to this issue: If $server is not set, it should throw an appropriate error if it's required. The solution is more important. I'm just double checking that I understand the failure scenario correctly, but that may be secondary to solving the problem. 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 (PUP-6739) If $environment is set and $server is not set, running any 'puppet' command will result in search for environment directory locally on agent
Title: Message Title
Paul Anderson commented on PUP-6739
Re: If $environment is set and $server is not set, running any 'puppet' command will result in search for environment directory locally on agent
Just to double check myself:
No IP address to 'puppet' {{[[root@el-7 ~]# cat /etc/hosts 127.0.0.1 el-7.puppetlabs.vm el-7 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6}}
'puppet' isn't reachable {{[root@el-7 ~]# ping puppet ping: unknown host puppet}}
No environments {{[root@el-7 ~]# ls -l /etc/puppetlabs/code/environments/ total 0}}
Empty puppet.conf except for server (set to an empty string) and certname {{[root@el-7 ~]# cat /etc/puppetlabs/puppet/puppet.conf [main] server = [agent] certname = el-7.puppetlabs.vm}}
Let's run some puppet commands and see what happens:
{{[[root@el-7 ~]# puppet config print server
[root@el-7 ~]# puppet config print server --environment dev /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'dev' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute' from /usr/local/bin/puppet:5:in `'}}
{{[[root@el-7 ~]# puppet config print environment production [root@el-7 ~]# puppet config print environment --environment ""
[root@el-7 ~]# puppet config print environment --environment dev /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'dev' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute' from /usr/local/bin/puppet:5:in `'}}
So there seems to be something slightly more to it than just the fact that the production environment is created by default, as it seems to work without error if:
1. No server is set and the production environment directory is deleted 2. No server is set and an empty environment is specified (although you didn't say anything about nothing being set)
If I've missed something, what's the scenario to get the Puppet::Environments::EnvironmentNotFound error for production?
Jira (PUP-6739) If $environment is set and $server is not set, running any 'puppet' command will result in search for environment directory locally on agent
Title: Message Title Paul Anderson commented on PUP-6739 Re: If $environment is set and $server is not set, running any 'puppet' command will result in search for environment directory locally on agent Jeremy Adams, I think something's hard-coded about as well: Install a puppet agent Run 'puppet help' and it works in the default (production) environment Run 'puppet help --environment production' and it works, because environments/production exists rm -Rf /etc/puppetlabs/environments/production Run 'puppet help' and it still works, but should fail because there's no environments/production directory Run 'puppet help --environment production' and it still works, but should fail because there's no environments/production directory 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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson commented on PUP-6713 Re: Vim should highlight data types in a class definition Tobias Wolter, PUP-6725 opened and linked 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 (PUP-6725) Vim should work with heredocs
Title: Message Title Paul Anderson created an issue Puppet / PUP-6725 Vim should work with heredocs Issue Type: New Feature Affects Versions: PUP 4.6.2 Assignee: Lindsey Smith Components: Community Created: 2016/09/22 8:21 AM Priority: Normal Reporter: Paul Anderson See PUP-6713 for information. Add Comment
Jira (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson commented on PUP-6713 Re: Vim should highlight data types in a class definition Some additional investigation has been done between Tobias Wolter and myself: I wrote a quick puppet manifest to install a puppet developer environment (specifically vim, vim-puppet and puppet-lint): https://gist.github.com/hpcprofessional/03100e873b244da48f46fcd1d207bdb2 I saw some inconsistent behavior between puppetlabs/puppet-syntax-vim and rodjek/puppet-vim, and Tobias Wolter did too. A screen shot of a slightly more complicated example is attached. Notice the issue starts on line 8: 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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6713 Vim should highlight data types in a class definition Screen shots provided by Tobias Wolter Change By: Paul Anderson Attachment: Screenshot from 2016-09-20 13-28-50.png Attachment: Screenshot from 2016-09-20 13-38-20.png 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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6713 Vim should highlight data types in a class definition Change By: Paul Anderson Attachment: Screen Shot 2016-09-19 at 15.24.07.png 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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title
Paul Anderson commented on PUP-6713
Re: Vim should highlight data types in a class definition
Additional info:
User provided a sample use case trying to validate paths. Here is a sample:
class vim_syntax
Unknown macro: { Pattern[/A[A-Za-z_-1-9 ./] $path_to_somewhere Pattern[/A[A-Za-z_-1-9 ./] $path_to_somewhere_else String $my_string }
For convenience, here is the regex in action: http://rubular.com/r/yPZ9EQsIBn
Suspect code is here: https://github.com/rodjek/vim-puppet/blob/d881b93dc4a8ed1374ad44439aeeb47808a6b91a/syntax/puppet.vim#L19-L28
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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6713 Vim should highlight data types in a class definition Change By: Paul Anderson Environment: https://github.com/puppetlabs/puppet-syntax-vim also https://github.com/rodjek/vim-puppet on Vim 7 , code that includes .4 on Ubuntu/Debian 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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson commented on PUP-6713 Re: Vim should highlight data types in a class definition I started a private e-mail chain with the user to get some additional details that were not in the tweets. I will post updates as they become available. 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 (PUP-6713) Vim should highlight data types in a class definition
Title: Message Title Paul Anderson created an issue Puppet / PUP-6713 Vim should highlight data types in a class definition Issue Type: New Feature Affects Versions: PUP 4.6.2 Assignee: Eric Sorenson Components: Community Created: 2016/09/19 1:13 PM Environment: https://github.com/puppetlabs/puppet-syntax-vim also https://github.com/rodjek/vim-puppet on Vim 7, code that includes Priority: Normal Reporter: Paul Anderson Source: @towo on Twitter https://twitter.com/towo/status/777600724985315328 Does anybody have a puppet.vim that actually does highlighting of data types in a class definition? Pattern[...] breaks a lot of things.— Tobias Wolter (@towo) September 18, 2016 @puppetize You lot maybe? Even your officialish repo (https://t.co/lSVtsu6J77) is broken in that regard.— Tobias Wolter (@towo) September 18, 2016
Jira (PUP-3042) If a catalog has a dependency cycle, it does not count as failed
Title: Message Title Paul Anderson commented on PUP-3042 Re: If a catalog has a dependency cycle, it does not count as failed After discussing this issue with a user experiencing this issue, they suggest that in their opinion, failed is failed and doesn't need granular data in the console. (The user is concerned about a cluttered console interface). That said, if anyone on the UX team (or engineering) is interested in discussing the potential console remedy with this user, let me know. 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-6575) Disambiguate puppet agent -t and puppet apply -t with quick feedback
Title: Message Title Paul Anderson commented on PUP-6575 Re: Disambiguate puppet agent -t and puppet apply -t with quick feedback And of course, the classic fundamentals use of puppet apply -t should work, too: root@solaris11:/shared# /usr/local/bin/puppet apply -t hello.pp Info: Loading facts Info: Loading facts Info: Loading facts Notice: Compiled catalog for solaris11.puppetlabs.vm in environment production in 0.04 seconds Info: Applying configuration version '1470249265' Notice: hello Notice: /Stage[main]/Main/Notify[hello]/message: defined 'message' as 'hello' Notice: Applied catalog in 0.05 seconds 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-6575) Disambiguate puppet agent -t and puppet apply -t with quick feedback
Title: Message Title
Paul Anderson commented on PUP-6575
Re: Disambiguate puppet agent -t and puppet apply -t with quick feedback
This is another valid use case that shouldn't be broken by this new feature:
root@solaris11:/shared# /usr/local/bin/puppet apply -t notify { "hello": }
Info: Loading facts Info: Loading facts Info: Loading facts Notice: Compiled catalog for solaris11.puppetlabs.vm in environment production in 0.04 seconds Info: Applying configuration version '1470249167' Notice: hello Notice: /Stage[main]/Main/Notify[hello]/message: defined 'message' as 'hello' Notice: Applied catalog in 0.05 seconds
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-6575) Disambiguate puppet agent -t and puppet apply -t with quick feedback
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6575 Disambiguate puppet agent -t and puppet apply -t with quick feedback Change By: Paul Anderson Both new and experienced users alike will accidentally type "puppet apply -t" when they mean to do a puppet run (puppet agent -t)puppet apply -t is a valid use case, and should not be changed as it could affect those using masterless puppet. If the client were to detect that puppet apply -t was run, no file argument was given, no input has been fed on standard in and that it was waiting for input, it could print an informational message, such as:" INFO Info : puppet Puppet apply ready for input on stdin"Then it would prevent confusion as people wait 2.. 5... 10... seconds (or going for coffee) before thinking that puppet has hung, hitting CTRL-C to break, running "puppet agent -t" like they meant to and kicking themselves for making this mistake AGAIN... 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-6575) Disambiguate puppet agent -t and puppet apply -t with quick feedback
Title: Message Title Paul Anderson commented on PUP-6575 Re: Disambiguate puppet agent -t and puppet apply -t with quick feedback This use case is valid and shouldn't be broken by this new feature. root@solaris11:/shared# /usr/local/bin/puppet apply -t < hello.pp Info: Loading facts Info: Loading facts Info: Loading facts Notice: Compiled catalog for solaris11.puppetlabs.vm in environment production in 0.05 seconds Info: Applying configuration version '1470249024' Notice: hello Notice: /Stage[main]/Main/Notify[hello]/message: defined 'message' as 'hello' Notice: Applied catalog in 0.04 seconds 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-6575) Disambiguate puppet agent -t and puppet apply -t with quick feedback
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6575 Disambiguate puppet agent -t and puppet apply -t with quick feedback Change By: Paul Anderson Both new and experienced users alike will accidentally type "puppet apply -t" when they mean to do a puppet run (puppet agent -t)puppet apply -t is a valid use case, and should not be removed, but if changed as it could affect those using masterless puppet. If the client were to detect that puppet apply -t was run, no file argument was given, no input has been fed on standard in and that it was waiting for input, it could print an informational message, such as:"INFO: puppet apply ready for input on stdin"Then it would prevent confusion as people wait 2.. 5... 10... seconds (or going for coffee) before thinking that puppet has hung before realizing the issue , hitting CTRL-C to break , running "puppet agent -t" like they meant to and kicking themselves for making this mistake AGAIN . .. 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-6575) Disambiguate puppet agent -t and puppet apply -t with quick feedback
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6575 Disambiguate puppet agent -t and puppet apply -t with quick feedback Change By: Paul Anderson Summary: Disambiguate puppet agent -t and puppet apply -t with quick feedback 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-6575) Disambiguate puppet agent -t and puppet apply -t
Title: Message Title Paul Anderson created an issue Puppet / PUP-6575 Disambiguate puppet agent -t and puppet apply -t Issue Type: New Feature Affects Versions: PUP 4.5.3 Assignee: Kylo Ginsberg Components: Client Created: 2016/08/03 11:25 AM Priority: Normal Reporter: Paul Anderson Both new and experienced users alike will accidentally type "puppet apply -t" when they mean to do a puppet run (puppet agent -t) puppet apply -t is a valid use case, and should not be removed, but if the client were to detect that puppet apply -t was run, no input has been fed on standard in and that it was waiting for input, it could print an informational message, such as: "INFO: puppet apply ready for input on stdin" Then it would prevent confusion as people wait 2.. 5... 10... seconds thinking that puppet has hung before realizing the issue hitting CTRL-C to break.
Jira (PUP-6397) File autorequire in Mount causes dependency loops
Title: Message Title Paul Anderson commented on PUP-6397 Re: File autorequire in Mount causes dependency loops I like Matt's Proposal because it would allow someone to describe the proper state of a mounted filesystem and have it implemented in a single puppet run. I don't want to overthink the issue, but there's one potentially unresolved issue: Should it be possible to set the permissions of the directory BEFORE it is mounted and the final permissions are set? For instance, an admin may want to make sure that a directory has very restrictive permissions before it is mounted so that if the mounting were to fail, or if there were an unexpected ordering issue, files wouldn't get written to the local file system. Only after the mount happened would less restrictive permissions be set. 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-1477) SELinux fact not being correctly detected
Title: Message Title Paul Anderson created an issue Facter / FACT-1477 SELinux fact not being correctly detected Issue Type: Bug Affects Versions: FACT 3.3.0 Assignee: Unassigned Created: 2016/07/29 1:04 PM Environment: RHEL 6 and RHEL 7 Priority: Normal Reporter: Paul Anderson I'm working with a user who had to write their own fact to parse the output of sestatus. I was surprised and did a little digging. They have found that on their systems, Facter says that SE Linux is enabled but permissive. However, it is disabled. (I assume that some kernel module is loaded that causes the appropriate /sys data to be populated, but SE Linux is not enabled) Here's the code for our SE Linux fact: https://github.com/puppetlabs/facter/blob/4a495e877d68648b6315b1a68755627de4c3c52d/lib/src/facts/linux/operating_system_resolver.cc#L61 Basically, the assumptions are not true for this user: [root@rhel7 ~]# facter -p selinux true [root@rhel7 ~]# grep selinuxfs /proc/self/mounts selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0 [root@rhel7 facter]# cat /sys/fs/selinux/enforce 0 [root@rhel7
Jira (PUP-6561) PUP-6099 breaks mounted filesystem permissions
Title: Message Title Paul Anderson commented on PUP-6561 Re: PUP-6099 breaks mounted filesystem permissions Reading PUP-6099 again, I wonder if this scenario would be proper behavior... Consider an admin doing a manual task to mount a filesystem on a new server: 1. Creating the mount point directory (mkdir -p, etc) 2. Mounting the filesystem (mount, etc. which gives all new permissions to the mount point) 3. Changing permissions/ownership of the mountpoint (chown, chmod, chgrp, etc.) We don't have a good way to model this using only a File and Mount resource... I'm of the opinion that Mount needs new capabilities: Either cover for 1 by creating the parent directory, then allowing the File resource to cover step 3 Or use File to cover for step 1 and then have optional parameters ($owner, $group, $mode) to set permissions after the filesystem is mounted. In keeping with Puppet as a State Modeling Language, I would suggest that the File resource should model the end state, and so Mount should automagically create the parent directory, since the parent directory must necessarily exist in order to mount on top of it. There is also a third school of thought, which I think causes a dilemma for end-users which Puppet would get caught in the middle of: Just leave the current behavior and let Puppet sort it out. in this case, the security-minded folks would be upset that the permissions on a mounted filesystem are wrong for 1/2 an hour. Additionally, something may break if permissions/ownership is wrong for that puppet run or users may not have full use of the system. Considering all these things, I think the best option is: 1. for Mount to create its parent directory if it needs to, possibly with a parameter to disable that behavior. 2. for the auto require of any identically located file resource be switched with an auto before 3. The documentation be updated to indicate that in the case of a mount, the identically named file resource will apply to the MOUNTED directory's permissions caveat: I'm not able to check the status of mount permissions after a refresh is sent to Mount and it remounts... That would be good data to consider, too... Add Comment
Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6554 Can't run puppet resource on agent with environment specified in main section Change By: Paul Anderson CS Impact: When these four things are true, the customer user can't use puppet client commands on their nodes as expected:1. Code manager with separate environments2. Nodes in an environment other than production3. Mcollective in use4. environment=[non-production] specified in [main] section of puppet.confThe have to do mental gymnastics to understand why they must add --environment production to every puppet help, puppet resource, etc. command to make it work. 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-6561) PUP-6099 breaks mounted filesystem permissions
Title: Message Title Paul Anderson commented on PUP-6561 Re: PUP-6099 breaks mounted filesystem permissions Hat tip to Ben Ford Explicitly specifying a relationship seems to address the autrequires issue: Mount['/apps'] -> File['/apps'] That said, one still needs to make sure /apps exists. In our case, it is being taken care of by the LVM module's exec. I still think we need an intelligent solution with respect to mount that: Creates mountpoint if missing -> Mounts file system -> Manages mountpoint ownership/permissions I will open a doc ticket to publicize Ben Ford's elegant solution. 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-6561) PUP-6099 breaks mounted filesystem permissions
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6561
PUP-6099 breaks mounted filesystem permissions
Change By:
Paul Anderson
Because one can only manage a file resource ONCE, PUP-6099 causes scenarios with mounted filesystems to break.Consider the following scenario:{{include lvmfile { ['/apps'] :ensure => directory,owner => nobody,group => nobody,mode => '0700',}physical_volume { '/dev/sdb':ensure => present,}volume_group { 'vg0':ensure => present,physical_volumes => '/dev/sdb',}lvm::logical_volume { 'apps':volume_group => 'vg0',size => '1G',fs_type => 'ext3',mountpath_require => false, # before => File['/apps'], #This is the desired effect, but causes a cyclical dependency. {}}}With the above code, the permissions on /apps are not set correctly as described in the file resource until the next puppet run, in which case /apps may be unavailable or have security issues or ??? for half an hour by default.To address the issue, the user may feel the need to do silly things, such as this:{{lvm::logical_volume { 'apps':volume_group => 'vg0',size => '1G',fs_type => 'ext3',mountpath_require => false,} ->exec { '/bin/chown nobody /apps' : } ->exec { '/bin/chgrp nobody /apps' : } ->exec { '/bin/chmod 0700 /apps' : }}}I would therefore suggest we come up with a solution that allows us to intelligently address this situation:create directory -> mount filesystem -> manage ownership/permissionsThe puppetlabs-lvm module avoids this by using an exec to create the directory, which would then allow a file resource to manage the directory ownership/permissions afterwards.Perhaps we could add a parameter that defaults to current behavior, that if toggled would not auto require the parent directory?
Add Comment
Jira (PUP-6561) PUP-6099 breaks mounted filesystem permissions
Title: Message Title
Paul Anderson created an issue
Puppet / PUP-6561
PUP-6099 breaks mounted filesystem permissions
Issue Type:
Bug
Affects Versions:
PUP 4.5.2
Assignee:
Kylo Ginsberg
Components:
Client
Created:
2016/07/28 7:30 AM
Priority:
Normal
Reporter:
Paul Anderson
Because one can only manage a file resource ONCE,
PUP-6099
causes scenarios with mounted filesystems to break.
Consider the following scenario:
{{
include lvm
file { ['/apps'] : ensure => directory, owner => nobody, group => nobody, mode => '0700', }
physical_volume { '/dev/sdb': ensure => present, }
volume_group { 'vg0': ensure => present, physical_volumes => '/dev/sdb', }
lvm::logical_volume { 'apps': volume_group => 'vg0', size => '1G', fs_type => 'ext3', mountpath_require => false, before => File['/apps'], { }
}} With the above code, the permissions on /apps are not set correctly as described in the file resource
Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6554 Can't run puppet resource on agent with environment specified in main section Change By: Paul Anderson CS Impact: When these three four things are true, the customer can't use puppet client commands on their nodes as expected:1. Code manager with separate environments2. Nodes in an environment other than production3. Mcollective in use4. environment=[non-production] specified in [main] section of puppet.confThe have to do mental gymnastics to understand why they must add --environment production to every puppet help, puppet resource, etc. command to make it work. 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-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6554
Can't run puppet resource on agent with environment specified in main section
Change By:
Paul Anderson
See also https://tickets.puppetlabs.com/browse/PUP-6048Given a traditional Prod, Dev, Test scenario, and a desire to use MCollectiveGiven the desire to configure an environment in the agent's puppet.conf to cut down on log messagesGiven the need to put the environment setting in [main] and not [agent] so that MCollective also knows the environmentIf one manually runs puppet commands on a non-production client node , such as puppet resource, one gets an error:[root@dev-node ~]# puppet resource service puppet ensure=running enable=true/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'development' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute' from /usr/local/bin/puppet:5:in `'However, if one impersonates the production environment, it works as expected:[root@dev-node ~]# puppet resource service puppet ensure=running enable=true --environment productionNotice: /Service[puppet]/ensure: ensure changed 'stopped' to 'running'service { 'puppet': ensure => 'running', enable => 'true',}This inconsistency is frustrating to customers, regardless of the reasoning behind it. It requires retraining of their staff doing manual operations and lots of comments in their cron jobs, etc.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6554 Can't run puppet resource on agent with environment specified in main section Change By: Paul Anderson Labels: customer 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-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6554
Can't run puppet resource on agent with environment specified in main section
Change By:
Paul Anderson
See also https://tickets.puppetlabs.com/browse/PUP-6048Given a traditional Prod, Dev, Test scenario, and a desire to use MCollectiveGiven the desire to configure an environment in the agent's puppet.conf to cut down on log messagesGiven the need to put the environment setting in [main] and not [agent] so that MCollective also knows the environmentIf one manually runs puppet commands on a non-production client, such as puppet resource, one gets an error:[root@dev-node ~]# puppet resource service puppet ensure=running enable=true/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'development' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute' from /usr/local/bin/puppet:5:in `'However, if one lies about impersonates the production environment, it works as expected:[root@dev-node ~]# puppet resource service puppet ensure=running enable=true --environment productionNotice: /Service[puppet]/ensure: ensure changed 'stopped' to 'running'service { 'puppet': ensure => 'running', enable => 'true',}This inconsistency is frustrating to customers, regardless of the reasoning behind it. It requires retraining of their staff doing manual operations and lots of comments in their cron jobs, etc.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6554 Can't run puppet resource on agent with environment specified in main section Change By: Paul Anderson Affects Version/s: PUP 4.5.2 Environment: RHEL 7 Master and AgentCopy default production environment to "development"Have console refresh modulesCreate development environment group in classifier, pin the agentConfigure agent to include "environment = development" in the main section of puppet.confDo puppet runs to everyones satisfaction CS Impact: When these three things are true, the customer can't use puppet client commands on their nodes as expected:1. Code manager with separate environments2. Nodes in an environment other than production3. Mcollective in use4. environment=[non-production] specified in [main] section of puppet.conf The have to do mental gymnastics to understand why they must add --environment production to every puppet help, puppet resource, etc. command to make it work. Component/s: Breaking Change See also https://tickets.puppetlabs.com/browse/PUP-6048Given a traditional Prod, Dev, Test scenario, and a desire to use MCollectiveGiven the desire to configure an environment in the agent's puppet.conf to cut down on log messagesGiven the need to put the environment setting in [main] and not [agent] so that MCollective also knows the environmentIf one manually runs puppet commands on a non-production client, such as puppet resource, one gets an error:[root@dev-node ~]# puppet resource service puppet ensure=running enable=true/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'development' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run' from
Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson created an issue Puppet / PUP-6554 Can't run puppet resource on agent with environment specified in main section Issue Type: Bug Assignee: Unassigned Created: 2016/07/27 6:32 AM Priority: Normal Reporter: Paul Anderson 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
Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section
Title: Message Title Paul Anderson commented on PUP-6554 Re: Can't run puppet resource on agent with environment specified in main section See also https://tickets.puppetlabs.com/browse/PUP-6048 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-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6552
Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Change By:
Paul Anderson
Discovered this while working with a customer to migrate from a PE 3.x to 2016.2In puppet 3.x, This service definition worked equally well for Solaris 10 and 11 and RedHat 6 and 7:service{ $service_name : tag => 'mytag', hasrestart => false, hasstatus => true, provider => 'init', }In puppet PE 2016.2, it works well for Solaris 10 and 11. However, Redhat 6 and 7 fail: Provider init is not functional on this hostIf the provider is changed to redhat, it fails differently: Service[]/enable) change from false to true failed: Could not enable : Execution of '/sbin/chkconfig --add ' returned 1: service does not support chkconfig [Service name censored to protect the innocent]
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-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title Paul Anderson commented on PUP-6552 Re: Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad. I understand a PS Engineer has encountered a similar situation with Ubuntu. 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-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title Paul Anderson updated an issue Puppet / PUP-6552 Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad. Change By: Paul Anderson Environment: RHEL 6 and 7Solaris 10 and 113rd party commercial software that runs on both RHEL and Solaris 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-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6552
Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Change By:
Paul Anderson
Discovered this while working with a customer to migrate from a PE 3.x to 2016.2In puppet 3.x, This service definition worked equally well for Solaris 10 and 11 and RedHat 6 and 7:service{ $service_name : tag => ' volatile mytag ', hasrestart => false, hasstatus => true, provider => 'init', }In puppet 2016.2, it works well for Solaris 10 and 11. However, Redhat 6 and 7 fail: Provider init is not functional on this hostIf the provider is changed to redhat, it fails differently: Service[]/enable) change from false to true failed: Could not enable : Execution of '/sbin/chkconfig --add ' returned 1: service does not support chkconfig [Service name censored to protect the innocent]
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-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6552
Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Change By:
Paul Anderson
Discovered this while working with a customer to migrate from a PE 3.x to 2016.2In puppet 3.x, This service definition worked equally well for Solaris 10 and 11 and RedHat 6 and 7:service{ $service_name : tag => 'volatile', hasrestart => false, hasstatus => true, provider => 'init', }In puppet 2016.2, it works well for Solaris 10 and 11. However, Redhat 6 and 7 fail: Provider init is not functional on this hostIf the provider is changed to redhat, it fails differently: Service[]/enable) change from false to true failed: Could not enable : Execution of '/sbin/chkconfig --add ' returned 1: service does not support chkconfig [Service name censored to protect the innocent]
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-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6552
Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Change By:
Paul Anderson
Discovered this while working with a customer to migrate from a PE 3.x to 2016.2 Basically In puppet 3.x , a 3rd party writes commercial software This service definition worked equally well for RedHat and Solaris . They have a hand crafted init script that works for both Solaris 10 and Redhat, BUT that script is not compatible with upstart or systemd. (run the script, start the service, etc...) 11 and RedHat 6 and 7: Thus service{ $service_name : tag => 'volatile' , the redhat hasrestart => false, hasstatus => true, provider can => ' t start the script while the init provider on Solaris can do it perfectly well. ', } These days init forces Redhat In puppet 2016.2 , Debian it works well for Solaris 10 and Ubuntu to use their own providers (Upstart, SystemD, etc 11 . )Consequently However , the customer Redhat 6 and 7 fail: Provider init is left with a difficult choice, should they hack puppet or hack their commercial application, each with support implications. not functional on this host I'll work with If the customer provider is changed to get specific code and output and open + link a private ticket with the relevant information. redhat, it fails differently: Service[]/enable) change from false to true failed: Could not enable : Execution of '/sbin/chkconfig --add ' returned 1: service does not support chkconfig
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6552) Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad.
Title: Message Title Paul Anderson created an issue Puppet / PUP-6552 Forcing Redhat, Debian and Ubuntu away from Init provider in all circumstances is bad. Issue Type: Bug Affects Versions: PUP 4.5.3 Assignee: Kylo Ginsberg Components: Breaking Change, Types and Providers Created: 2016/07/26 2:54 PM Environment: RHEL 6 and 7 Solaris 10 and 11 3rd party software that runs on both RHEL and Solaris Priority: Normal Reporter: Paul Anderson Discovered this while working with a customer to migrate from a PE 3.x to 2016.2 Basically, a 3rd party writes commercial software for RedHat and Solaris. They have a hand crafted init script that works for both Solaris and Redhat, BUT that script is not compatible with upstart or systemd. (run the script, start the service, etc...) Thus, the redhat provider can't start the script while the init provider on Solaris can do it perfectly well. These days init forces Redhat, Debian and Ubuntu to
Jira (PUP-6226) Puppet resource fails with --environment setting
Title: Message Title Paul Anderson created an issue Puppet / PUP-6226 Puppet resource fails with --environment setting Issue Type: Bug Affects Versions: PUP 4.4.1 Assignee: Unassigned Created: 2016/04/22 10:52 AM Environment: RHEL 7.2 Student VM Priority: Normal Reporter: Paul Anderson root@paul:~ # puppet resource service --environment=foo /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'foo' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute' from /opt/puppetlabs/bin/puppet:5:in `'
Jira (PUP-6092) Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
Title: Message Title
Paul Anderson updated an issue
Puppet / PUP-6092
Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
Change By:
Paul Anderson
Comment:
{{file { 'c:/hidden': ensure => directory,}exec { 'Make hidden': command => 'attrib +h c:/hidden', path => $::path, onlyif => 'if (-Not (Get-ItemPro{{monospaced text}}perty -Path C:\hidden).mode | select-string h) {exit 1}', provider => 'powershell', require => File['c:/hidden'],}Hat tip to [~nate.mccurdy]}}
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-6092) Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
Title: Message Title
Paul Anderson commented on PUP-6092
Re: Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
file { 'c:/hidden': ensure => directory, }
exec { 'Make hidden': command => 'attrib +h c:/hidden', path => $::path, _onlyif_ => 'if (-Not (Get-ItemProperty -Path C:\hidden).mode | select-string h) {exit 1}
', provider => 'powershell', require => File['c:/hidden'], }
Hat tip to Nate McCurdy
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-6092) Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
Title: Message Title Paul Anderson commented on PUP-6092 Re: Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive) Right now, PS is using work arounds for this. We have to exec out to powershell set these attributes, and there's not a good way to check the attributes to perform conditional logic. It's a hack, it's ugly and the customer doesn't like it. That said, this isn't impacting the delivery schedule for any customer. It's just a feature request at this point. 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-6092) Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
Title: Message Title Paul Anderson commented on PUP-6092 Re: Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive) Craig Gomes is unavailable for a few days and suggested that Ethan Brown may be able to put eyes on this. 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-6092) Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive)
Title: Message Title Paul Anderson created an issue Puppet / PUP-6092 Identify Windows-specific file/folder flags in Windows (e.g. hidden, archive) Issue Type: New Feature Affects Versions: PUP 4.4.0 Assignee: Kylo Ginsberg Components: Client Created: 2016/03/24 10:09 AM Environment: A Windows system with a file or folder with the hidden attribute set, e.g. C:\hidden Puppet agent installed Priority: Normal Reporter: Paul Anderson Puppet describe file "c:\hidden" does not provide any way to identify if that file is hidden. In Linux, identifying hidden files is .trivial and not an attribute. However, the Windows platform does this very differently. The file provider for windows (whether POSIX or Windows, i'll let the Dev's decide) should indicate the relevant attributes, including its hidden-ness, archive-iness, etc. Additionally, the ability to easily set these attributes would be nice, rather than having to call an exec to powershell, attrib.exe, etc.
