Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Travis Fields the attachment you posted - what version of Windows/msiexec? Works just fine with Windows Installer v5+/Win2008r2+. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Travis Fields updated an issue Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Change By: Travis Fields Attachment: Screen Shot 2015-07-24 at 4.28.10 PM.png Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 On the Windows 2003 box I have (non-R2 x86), it is using Windows Installer v3 - Windows ® Installer. V 3.01.4000.3959 (aka msiexec). Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1149) Refactor Linux/Mac/BSD code
Title: Message Title Michael Smith created an issue Facter / FACT-1149 Refactor Linux/Mac/BSD code Issue Type: Improvement Assignee: Unassigned Created: 2015/07/24 4:17 PM Priority: Normal Reporter: Michael Smith The OpenBSD port is duplicating some resolver code, refactor it to reduce code duplication. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c)
Jira (FACT-1148) Port Facter to OpenBSD
Title: Message Title Michael Smith assigned an issue to Jasper Lievisse Adriaanse Facter / FACT-1148 Port Facter to OpenBSD Change By: Michael Smith Assignee: Jasper Lievisse Adriaanse Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1148) Port Facter to OpenBSD
Title: Message Title Michael Smith created an issue Facter / FACT-1148 Port Facter to OpenBSD Issue Type: Epic Assignee: Unassigned Created: 2015/07/24 4:14 PM Priority: Normal Reporter: Michael Smith Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Ethan pointed to this - which validates that SSLv3 is no longer allowed with AWS - https://www.ssllabs.com/ssltest/analyze.html?d=s3.amazonaws.com&s=54.231.1.81 Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Travis Fields assigned an issue to Eric Williamson Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Change By: Travis Fields Assignee: Travis Fields Eric Williamson Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3053) SSL configuration with intermediate CA
Title: Message Title Celia Cottle commented on PUP-3053 Re: SSL configuration with intermediate CA Jeff McCune We actually have two customers now asking about the status of this feature? Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below. The fiddler log suggests that there is a valid SSLv3 tunnel. I've done a little searching to see what this indicates, whether the traffic actually makes it through. http://www.telerik.com/blogs/fiddler-and-modern-tls-versions Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Ryan Gard updated an issue Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Rob Reynolds Travis Fields Ethan Brown I attached a Fiddler trace for a passing installation on Windows 2008. Change By: Ryan Gard Attachment: fiddler_2008_passing.saz Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsTo upgrade from 3.7.5, you should employ one of the following means:* Use a means other than Puppet to upgrade Puppet * * You may need to run the upgrade twice unless manually performing the upgrade.* Look at implementing parts of MODULES-2040 to perform the upgradesh2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Erik L. commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. Ah, quite right! You Sir, are spot on Indeed I missed that detail, which was apparently of high importance. I changed my /etc/puppet/puppet.conf as follows: [main] usecacheonfailure=false reports = store,puppetdb [master] storeconfigs = true storeconfigs_backend = puppetdb And now it works like a charm. Thanks for helping me out here. Add Comment
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsTo upgrade from 3.7.5, you should employ one of the following means:* Use a means other than Puppet to upgrade Puppet * You may need to run the upgrade twice unless manually performing the upgrade.* Look at implementing parts of MODULES-2040 to perform the upgradesh2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.pup
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsTo upgrade from 3.7.5, you should employ one of the following means:* Use a means other than Puppet to upgrade Puppet * You may need to run the upgrade twice unless manually performing the upgrade.* Look at implementing parts of MODULES-2040 to perform the upgradesh2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.pup
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsTo upgrade from 3.7.5, you should employ one of the following means:* Use a means other than Puppet to upgrade Puppet* You may need to run the upgrade twice unless manually performing the upgrade.* Look at implementing parts of MODULES-2040 to perform the upgradesh2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.pup
Jira (PUP-1388) Add 'list' subcommand to filebucket
Title: Message Title Peter Huene updated an issue Puppet / PUP-1388 Add 'list' subcommand to filebucket Change By: Peter Huene Affects Version/s: PUP 4.2.1 Sprint: Client 2015-09-30 Scrum Team: Client Platform Story Points: 1 Fix Version/s: PUP 4.3.0 Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- 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 e
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Ryan Gard updated an issue Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Eric Williamson Joshua Partlow Ethan Brown I have attached a Fiddler capture of traffic from the msiexec command. Change By: Ryan Gard Attachment: fiddler.saz Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Carl D Hamann commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. I'm not sure if this makes a difference, but the documentation (https://docs.puppetlabs.com/puppetdb/latest/connect_puppet_master.html) shows the storeconfigs and storeconfigs_backend settings in the [master] section, rather than [main] Add Comment
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Erik L. commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. Okay, I tried step-by-step to see where things go wrong. First, I added two configuration files: /etc/puppet/puppetdb.conf [main] server_urls = https://puppet.mydomain.com:8081 /etc/puppet/routes.yaml --- master: facts: terminus: puppetdb cache: yaml Then I edited /etc/puppet/puppet.conf to contain the following:
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Joshua Partlow commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Or for win2003 we state that you have to set up a webserver with SSL that your win2003 agents can connect to, and use that as the source. I'm concerned about the additional edge cases - everything comes from pm.puppetlabs.com, except for win2003 which comes from downloads.puppetlabs.com - leading to new bugs. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Eric Williamson commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 ping Aaron Armstrong Joshua Partlow Michael Stahnke We may need to end up using https://downloads.puppetlabs.com here instead of pm if this is the case. Only code change to module would be to use the masters AIO version instead of latest. It will require testing changes to our pe_acceptance_tests/setup/agent_upgrade.rb script to specify the source parameter for testing nightlies. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2838) Puppet generates invalid .dot files due to missing escapes of quoted strings in resource names
Title: Message Title Verne Lindner commented on PUP-2838 Re: Puppet generates invalid .dot files due to missing escapes of quoted strings in resource names +1 Reid Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds commented on PUP-4925 Re: Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 From https://support.microsoft.com/en-us/kb/193625 12152 ERROR_HTTP_INVALID_SERVER_RESPONSE The server response could not be parsed. My guess is that if we visit that link from Windows 2003 we'll get something instead of the MSI. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Change By: Rob Reynolds Affects Version/s: puppet_agent 0.2.0 Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Change By: Rob Reynolds Component/s: Windows Component/s: PE Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4925) Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2
Title: Message Title Rob Reynolds moved an issue Puppet / PUP-4925 Puppet Agent - Failure to Upgrade Agent on Windows 2003 R2 Change By: Rob Reynolds Key: MODULES PUP - 2271 4925 Project: Forge Modules Puppet Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Carl D Hamann commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. If YAML parsing is the problem, you'll see this in the logs for the master: Puppet Cached facts for failed: Could not parse YAML data for facts : Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Erik L. commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. Option 3 could very well be it. I already had to hack "SafeYAML::OPTIONS[:default_mode] = :unsafe" into /usr/share/ruby/vendor_ruby/puppet/indirector/yaml.rb for puppet master to work, as suggested in this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1229703 Are there other yaml parsing files that may need patching? Can I somehow check if yaml parsing succeeds? In general, without PDB, puppet master does parse all yaml (both hiera and agent provided facts) correctly. Just to be sure, this is the correct contents for routes.yaml, right? — master: facts: terminus: puppetdb cache: yaml Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Carl D Hamann commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. The underlying cause is that facts are passed into compilation via indirection- they are saved and then found. The normal termini are yaml (cache) and puppetdb (terminus). Anything that causes the cache to be ignored will result in facts being loaded from PuppetDB -poisoned by the inclusion of trusted facts. The three causes I'm aware of, in decreasing order of frequency, are: 1) Time skew between agent and master causes cache to be considered stale. Should never happen when agent and master are on the same box. 2) routes.yaml causes master to check PuppetDB always. 3) YAML parsing fails. I've personally encountered this due to a plugin loading a different version of safe_yaml as a gem (Puppet vendors it in at 0.9.2) Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsTo upgrade from 3.7.5, you should employ one of the following means:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgradesh2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi /l*v "c:\PuppetInstall.log"}} along with any
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title Rob Reynolds commented on PUP-4924 Re: Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing I'm going to try to determine what causes the issue by adding the log into the package script. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsTo upgrade from 3.7.5, you should employ one of the following means:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgradesh2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi /l*v "c:\PuppetInstall.log" }} along with a
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]. We subsequently yanked the Windows versions of Puppet 3.7.5 and [notified puppet-dev/puppet-users| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We recommended users do one of the following to upgrade Puppet:* Use a means other than Puppet to upgrade Puppet* Look at implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade.We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities, like using psexec and/or winexe to perform an in-place reinstall for an affected 3.8.1 (or future) upgrade.h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systems To upgrade from 3.7.5, you should employ one of the following means:* Use other a means (not puppet) other than Puppet to perform the upgrade or look Puppet* Look at implementing parts of MODULES-2040 . to perform the upgrades h2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/pupp
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 ( after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies] ), and . We subsequently we yanked the Windows versions of Puppet 3.7.5 / sent out and [ a message to notified puppet-dev /puppet-users | https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that recommended users should look do one of the following to upgrade Puppet:* Use means other than Puppet to upgrade Puppet* Look at using implementing parts of MODULES-2040 to perform the upgrades* Possibly use the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade , but it is also affected by this issue . Now we We found out on 7/24 that using the puppetversion module to perform the upgrades also caused this behavior to occur. We are looking at other possibilities , like using psexec and/or winexe to perform an in-place reinstall for a borked an affected 3.8.1 installation (or future) upgrade .h2. Mitigation StepsWe're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsUse other means (not puppet) to perform the upgrade or look at implementing parts of MODULES-2040.h2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.This was discovered on 7/17/2015 (after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]), and subsequently we yanked the Windows versions of Puppet 3.7.5 / sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation. *Note:* This doesn't affect PE versions of 3 h2 . x agents for Windows as they were using a different process for identifying dependencies to pull in. Mitigation Steps *Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated 're updating the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. Puppet v4+ is unaffected since we switched to using puppet-agent to build the MSIs (which uses tags). We may evaluate more mitigation steps such as returning the versions of all components as part of smoke testing. h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsUse other means (not puppet) to perform the upgrade or look at implementing parts of MODULES-2040.h2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - se
Jira (PUP-4771) Static compiler only looks for file content in production environment
Title: Message Title Josh Cooper updated an issue Puppet / PUP-4771 Static compiler only looks for file content in production environment Change By: Josh Cooper Sprint: Client 2015-08-19 Scrum Team: Client Platform Story Points: 1 Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4771) Static compiler only looks for file content in production environment
Title: Message Title Josh Cooper updated an issue Puppet / PUP-4771 Static compiler only looks for file content in production environment Change By: Josh Cooper Component/s: Community Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4771) Static compiler only looks for file content in production environment
Title: Message Title Josh Cooper updated an issue Puppet / PUP-4771 Static compiler only looks for file content in production environment Change By: Josh Cooper Fix Version/s: PUP 4.3.0 Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 (after a [message was sent about upgrade issues|https://groups.google.com/forum/#!topic/puppet-users/Ij0FfFbBies]), and subsequently we yanked the Windows versions of Puppet 3.7.5 and / sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would produce the same outcome):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsUse other means (not puppet) to perform the upgrade or look at implementing parts of MODULES-2040.h2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties*Note:* Both PsExec and Winexe are known to send passwords in the clear. This is important to know if you are planning to run over an insecure network.For PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command shou
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used {{puppet apply}} but run as an agent would have produce the same effect outcome ):{noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsUse other means (not puppet) to perform the upgrade or look at implementing parts of MODULES-2040.h2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties*Note:* Both PsExec and Winexe are known to send passwords in the clear. This is important to know if you are planning to run over an insecure network.For PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME%password' --uninstall --interactive=0 //hostIP '
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade (I used { {puppet apply}} but run as an agent would have the same effect):{ noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround for non-upgraded systemsUse other means (not puppet) to perform the upgrade or look at implementing parts of MODULES-2040.h2. Workaround [Possible Solution] for affected systems (no ruby.exe)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties*Note:* Both PsExec and Winexe are known to send passwords in the clear. This is important to know if you are planning to run over an insecure network.For PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME%password' --uninstall --interactive=0 //hostIP 'msiexec /qn /i ht
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade {noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat} h2. Workaround for non-upgraded systems Use other means (not puppet) to perform the upgrade or look at implementing parts of MODULES-2040. h2. Workaround [Possible Solution] for affected systems ( possible solution no ruby.exe )Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties*Note:* Both PsExec and Winexe are known to send passwords in the clear. This is important to know if you are planning to run over an insecure network.For PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME%password' --uninstall --interactive=0 //hostIP 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h2. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade {noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h2. Workaround (possible solution)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties *Note:* Both PsExec and Winexe are known to send passwords in the clear. This is important to know if you are planning to run over an insecure network. For PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME %password ' --uninstall --interactive=0 //hostIP 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'{noformat}Tested with {{winexe -U 'robz' --uninstall --interactive=0 //169.169.169.12 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'}} and it fixed the borked ins
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely. h3 h2 . Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade {noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat} h3 h2 . Workaround (possible solution)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-propertiesFor PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME' --uninstall --interactive=0 //hostIP 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'{noformat}Tested with {{winexe -U 'robz' --uninstall --interactive=0 //169.169.169.12 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'}} and it fixed the borked install that occurred after the repro steps.It's recommended to use PSExec as it can run against multiple hosts as part of the command, where with winexe you
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h3. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade {noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h3. Workaround (possible solution)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-propertiesFor PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME' --uninstall --interactive=0 //hostIP 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'{noformat}Tested with {{winexe -U 'robz' --uninstall --interactive=0 //169.169.169.12 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'}} and it fixed the borked install that occurred after the repro steps. It's recommended to use PSExec as it can run against multiple hosts as part of the command, where with winexe you may need
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [defaults for 3.x to use tags|https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h3. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade {noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command,operable program or batch file.{noformat}h3. Workaround (possible solution)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-propertiesFor PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME' --uninstall --interactive=0 //hostIP 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'{noformat}Tested with {{winexe -U 'robz' --uninstall --interactive=0 //169.169.169.12 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'}} and it fixed the destroyed borked install that occurred after the repro steps.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title
Rob Reynolds updated an issue
Puppet / PUP-4924
Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Change By:
Rob Reynolds
When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take. We had a possible recommendation that users should look at using the [puppetversion module|https://forge.puppetlabs.com/opentable/puppetversion] to perform the upgrade, but it is also affected by this issue.Now we are looking at other possibilities using psexec and/or winexe to perform an in-place reinstall for a borked 3.8.1 installation. *Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the [ defaults for 3.x to use tags |https://github.com/puppetlabs/puppet/pull/4099] to mitigate this from future issues and will be examining changes to the build_defaults.yaml more closely.h3. Reproduction steps# Install Puppet 3.7.5 (I used x86 and noticed others with this issue were upgrading the x86 version). # Use a puppet script to apply the upgrade {noformat}package { 'Puppet': ensure => "3.8.1", source => "https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi", provider=> windows,}{noformat}# Try running puppet, you should get the following message:{noformat}C:\Users\Administrator>puppet'ruby' is not recognized as an internal or external command, operable program or batch file.{noformat}h3. Workaround (possible solution)Use PsExec or Winexe to rerun the install for Puppet MSI. The command should be {{msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi}} along with any MSI properties you may need to pass - see http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-propertiesFor PSExec the command must be run from a Windows machine and it should look something like:{noformat}TODO{noformat}For winexe (running from Linux), the command should look similar to:{noformat}winexe -U 'DOMAIN\\USERNAME' --uninstall --interactive=0 //hostIP 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'{noformat}Tested with {{winexe -U 'robz' --uninstall --interactive=0 //169.169.169.12 'msiexec /qn /i https://downloads.puppetlabs.com/windows/puppet-3.8.1.msi'}} and it fixed the destroyed install that occurred after the repro steps.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-4924 Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing Change By: Rob Reynolds When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. This is due to an incorrect version of Ruby being released with Puppet 3.7.5 (it was Ruby 2.1.5, caused by [8c73637a1e2e|https://github.com/puppetlabs/puppet/commit/8c73637a1e2e001008b674c8c5b63736aa7ab0a7], which is known to have compatibility issues with Puppet < 4). This was fixed later in [1173b42101da8|https://github.com/puppetlabs/puppet/commit/1173b42101da8a49f0fad1f2388ee22145805006]. This was discovered on 7/17/2015 and subsequently we yanked the Windows versions of Puppet 3.7.5 and sent out [a message to puppet-dev| https://groups.google.com/forum/#!msg/puppet-dev/VtqadVFJKLM/e28O_so11fMJ] indicating actions users should take.*Note:* This doesn't affect PE versions of 3.x agents for Windows as they were using a different process for identifying dependencies to pull in.*Note:* This is no longer an issue with Puppet v4 b/c we are using puppet-agent to build the MSIs and using tags. We also updated the defaults for 3.x to use tags to mitigate this from future issues and will be examining an Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- 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...@goog
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Kenneth Barber commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. It sounds like its querying PuppetDB (or else you would never see this error) and its also submitted, because the facts wouldn't be there otherwise. The log will show you when it stores 'stuff'. Seriously though, this error means for some reason during compilation, your master is going to PDB to get its facts, instead of using the ones it just received from the agent. Afaik, its generally always a) timing or b) routes.yaml but perhaps there is something else odd here. Most of the time though its one of those things, we've just missed something silly. Of course, after changing the relevant files you've restarted the various daemons right? Feel free to hit me up on IRC for more direct help, maybe we can walk through some stuff, I'm "ken_barber" on freenode at #puppet. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4924) Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing
Title: Message Title Rob Reynolds created an issue Puppet / PUP-4924 Puppet Windows - Upgrading from 3.7.5 causes Ruby.exe/Rubyw.exe to go missing Issue Type: Bug Assignee: Rob Reynolds Components: Windows Created: 2015/07/24 9:01 AM Labels: windows Priority: Major Reporter: Rob Reynolds When upgrading Puppet using Puppet on Windows (which isn't really recommended, see MODULES-2040), it can cause file locking. Add Comment
Jira (PUP-4822) Regression PMT cannot connect to forge on OSX
Title: Message Title
Josh Cooper updated an issue
Puppet / PUP-4822
Regression PMT cannot connect to forge on OSX
Change By:
Josh Cooper
The PMT fails to connect:{noformat}vfyfy4ou7ntrxfp:~ root# puppet module install puppetlabs-stdlibNotice: Preparing to install into /etc/puppetlabs/code/environments/production/modules ...Notice: Downloading from https://forgeapi.puppetlabs.com ...Error: Could not connect via HTTPS to https://forgeapi.puppetlabs.com Unable to verify the SSL certificateThe certificate may not be signed by a valid CAThe CA bundle included with OpenSSL may not be valid or up to date{noformat}However, using the system openssl, it does successfully connect:{noformat}vfyfy4ou7ntrxfp:~ root# openssl s_client -connect forgeapi.puppetlabs.com:443CONNECTED(0003)depth=1 /C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2verify error:num=20:unable to get local issuer certificateverify return:0---{noformat}It seems osx patches system openssl so it looks in the keystore, but that doesn't work for puppet-agent, because we compile openssl ourselves.The fix for PUP-3450 would fix this issue. Filing this as a separate issue because it affects OSX acceptance (which fails try to connect to the test forge). h4. WorkaroundCreate a file {{/opt/puppetlabs/puppet/ssl/cert.pem}} with the GeoTrust Global CA below, making sure permissions are not writable by non-root:{noformat}-BEGIN CERTIFICATE-MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9iYWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9mOSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIuT8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6cJmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmRCw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5aszPeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo1MwUTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrMTjAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1luMrMTjANBgkqhkiG9w0BAQUFAAOCAQEANeMpauUvXVSOKVCUn5kaFOSPeCpilKInZ57QzxpeR+nBsqTP3UEaBU6bS+5Kb1VSsyShNwrrZHYqLizz/Tt1kL/6cdjHPTfStQWVYrmm3ok9Nns4d0iXrKYgjy6myQzCsplFAMfOEVEiIuCl6rYVSAlk6l5PdPcFPseKUgzbFbS9bZvlxrFUaKnjaZC2mqUPuLk/IH2uSrW4nOQdtqvmlKXBx4Ot2/Unhw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==-END CERTIFICATE-{noformat}and PMT will work:{noformat}cpwj90x3cw44guh:~ root# /opt/puppetlabs/bin/puppet module install puppetlabs-stdlibNotice: Preparing to install into /etc/puppetlabs/code/environments/production/modules ...Notice: Downloading from https://forgeapi.puppetlabs.com ...Notice: Installing -- do not interrupt .../etc/puppetlabs/code/environments/production/modules└── puppetlabs-stdlib (v4.7.0) {noformat}
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Erik L. commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. The last guy on the mailinglist had his routes.yaml in the wrong directory. As the documentation suggests, I checked for the right directory: puppet master --configprint route_file /etc/puppet/routes.yaml And then placed the routes.yaml exactly there. I haven't really tested if PuppetDB itself is running correctly. I mean, of course it is running and I configured it according to the guideline, but I don't know if it actually works right. Could the error be caused by puppetmaster not being able to communicate with PuppetDB correctly? Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Erik L. commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. Thanks for your pointers. I am testing with the puppet agent on the puppet server itself, so they have the same clock. (As a side note, I do also run ntp on that machine.) I used that exact guide to set up the Puppet Master / PuppetDB-connection, and I copied the routes.yaml file literally from the example. I will take a look at the mailinglist to see if there are other suggestions. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4923) Exec resource can use facts comparison for onlyif and unless attributes
Title: Message Title
Joshuatly Tee created an issue
Puppet / PUP-4923
Exec resource can use facts comparison for onlyif and unless attributes
Issue Type:
New Feature
Assignee:
Unassigned
Created:
2015/07/24 8:26 AM
Priority:
Normal
Reporter:
Joshuatly Tee
Currently the onlyif and unless attribute for exec reference will only take a command and evaluate the command's exit code.
Request to add the feature to check variable or Facts and compare the value with a string provided, exec { "some exec": command => "/some/command", _onlyif_ => { $somefact == true }
, }
Add Comment
This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78a
Jira (FACT-1128) Intermittent failure attaching process to job object
Title: Message Title Branan Riley commented on FACT-1128 Re: Intermittent failure attaching process to job object My only concern is that if/when Facter is run in a Job intentionally, it might be done in such a way that we don't have permissions to use CREATE_BREAKAWAY_FROM_JOB. In that case all of the facts that require external executables would fail. I don't know how much I actually care about this. My instinct right now is "not much at all" Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Kenneth Barber commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. Erik L. its either a) the clocks between your master and agent are out of sync (ie. always use ntp) or b) your routes.yaml is not configured correctly on your puppetmaster: http://docs.puppetlabs.com/puppetdb/3.0/connect_puppet_master.html#edit-routesyaml There are a few threads on this on puppet-users also, this is the latest one: https://groups.google.com/forum/#!msg/puppet-users/jRedmcdBeP8/z8N4-GhUka8J Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilati
Title: Message Title Erik L. commented on PDB-949 Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. I am getting this same issue. Puppet master was working fine, until I installed PuppetDB and now I get this error. It is not clear to me what the state of this issue is, I see closed/wontfix, but the last couple of comments (May 2015) don't seem to explain why. Is there some workaround for this issue? Additionally I would like to add that although the bug is tagged PE 3.4, I am seeing this error with puppet-4.1.0-2.fc22.noarch and puppetdb-3.0.1-1.fc20.noarch. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4922) Downgrading Puppet on Windows may change the environment back to Production
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-4922 Downgrading Puppet on Windows may change the environment back to Production Change By: Rob Reynolds Labels: windows Scrum Team: Windows Story Points: 3 Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4922) Downgrading Puppet on Windows may change the environment back to Production
Title: Message Title Rob Reynolds created an issue Puppet / PUP-4922 Downgrading Puppet on Windows may change the environment back to Production Issue Type: Bug Assignee: Unassigned Components: Windows Created: 2015/07/24 7:33 AM Priority: Normal Reporter: Rob Reynolds When downgrading Puppet on Windows, the environment value can get set back to production. It looks like we use inifile addLine, which allows for the value to be updated during upgrades/downgrades based on the rememberedSetting. If someone sets the value after install, it's possible that the value will be changed back to production during downgrades (maybe also during upgrades). This can be worked around by always using PUPPET_AGENT_ENVIRONMENT during install/upgrades. http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#puppetagentenvironment Reference: Wix IniFile Puppet.wxs puppet.conf setting (updates with remembered value or default aka production)
Jira (PUP-2838) Puppet generates invalid .dot files due to missing escapes of quoted strings in resource names
Title: Message Title Scott Walker commented on PUP-2838 Re: Puppet generates invalid .dot files due to missing escapes of quoted strings in resource names Verne Lindner This ticket captures a bug in which the agent can generate dot files that aren't syntactically valid. If you use "--graph" on the master agent you get an example - in that case because of some unescaped quotes. My rationale is: the graph is now much more visible and so maybe customers are more likely to try out the --graph option on the agent. If they try it on their master in PE 2015.2 they'll run into the bug straight away. Beth Cornils I hadn't thought of deprecating - I like it. There's probably still value in expanded_relationships.dot for agent debugging purposes but there's less reason to use it compared with the others. Add Comment This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
