Jira (FACT-3075) Windows 2022 is detected as Windows 2019
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-3075 Windows 2022 is detected as Windows 2019 Change By: Kevin Reeuwijk Attachment: Screenshot 2021-09-22 at 14.38.22.png Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416781.1632314698000.136482.1632314820027%40Atlassian.JIRA.
Jira (FACT-3075) Windows 2022 is detected as Windows 2019
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-3075 Windows 2022 is detected as Windows 2019 Change By: Kevin Reeuwijk Attachment: Screenshot 2021-09-22 at 14.37.47.png Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416781.1632314698000.136480.1632314760113%40Atlassian.JIRA.
Jira (FACT-3075) Windows 2022 is detected as Windows 2019
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-3075 Windows 2022 is detected as Windows 2019 Change By: Kevin Reeuwijk Attachment: Screenshot 2021-09-22 at 14.38.22.png Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416781.1632314698000.136481.1632314760156%40Atlassian.JIRA.
Jira (FACT-3075) Windows 2022 is detected as Windows 2019
Title: Message Title Kevin Reeuwijk assigned an issue to Ciprian Badescu Facter / FACT-3075 Windows 2022 is detected as Windows 2019 Change By: Kevin Reeuwijk Assignee: Ciprian Badescu Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.416781.1632314698000.136479.1632314760068%40Atlassian.JIRA.
Jira (FACT-3075) Windows 2022 is detected as Windows 2019
Title: Message Title Kevin Reeuwijk created an issue Facter / FACT-3075 Windows 2022 is detected as Windows 2019 Issue Type: Bug Affects Versions: FACT 4.2.5, FACT 3.14.20 Assignee: Unassigned Components: Facter 3, Facter 4 Created: 2021/09/22 5:44 AM Environment: PE 2021.3.0 server Windows 2022 Datacenter node Priority: Normal Reporter: Kevin Reeuwijk As a Windows-oriented Puppet user, I want Facter to correctly report the os, operatingsystemmajrelease and operatingsystemrelease fact for a Windows 2022 node. On both Facter 3.x and 4.x, the os, operatingsystemmajrelease and operatingsystemrelease facts incorrectly report version 2019 for a node running Windows 2022. This prevents our customers from accurately targeting code to nodes. Add Comment
Jira (PDB-5108) [SPIKE] Protect pdb against data that will cause it to fall over
Title: Message Title Kevin Reeuwijk updated an issue PuppetDB / PDB-5108 [SPIKE] Protect pdb against data that will cause it to fall over Change By: Kevin Reeuwijk Zendesk Ticket IDs: #42915 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.395635.1618512193000.1.1618567920105%40Atlassian.JIRA.
Jira (PDB-5108) [SPIKE] Protect pdb against data that will cause it to fall over
Title: Message Title Kevin Reeuwijk updated an issue PuppetDB / PDB-5108 [SPIKE] Protect pdb against data that will cause it to fall over Change By: Kevin Reeuwijk Zendesk Ticket IDs: 42915 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.395635.1618512193000.0.1618567920059%40Atlassian.JIRA.
Jira (PDB-5108) [SPIKE] Protect pdb against data that will cause it to fall over
Title: Message Title Kevin Reeuwijk updated an issue PuppetDB / PDB-5108 [SPIKE] Protect pdb against data that will cause it to fall over Change By: Kevin Reeuwijk Zendesk Ticket IDs: #42915 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.395635.1618512193000.2.1618567920148%40Atlassian.JIRA.
Jira (PDB-5108) [SPIKE] Protect pdb against data that will cause it to fall over
Title: Message Title Kevin Reeuwijk updated an issue PuppetDB / PDB-5108 [SPIKE] Protect pdb against data that will cause it to fall over Change By: Kevin Reeuwijk Zendesk Ticket IDs: 42915 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.395635.1618512193000.11109.1618567860031%40Atlassian.JIRA.
Jira (FACT-3001) Debug output shows facter gets called thousands of times
Title: Message Title Kevin Reeuwijk created an issue Facter / FACT-3001 Debug output shows facter gets called thousands of times Issue Type: Improvement Affects Versions: FACT 4.0.51 Assignee: Unassigned Components: Facter 4 Created: 2021/03/29 8:58 AM Environment: Puppet Agent 7.4.1 agent run on Windows with --debug enabled: Priority: Normal Reporter: Kevin Reeuwijk When running a puppet agent run with --debug, the following block appears a whole lot in the output: 2021-03-29 03:38:48 -0700 Facter (debug): Loading internal facts 2021-03-29 03:38:48 -0700 Facter (debug): Loading all internal facts 2021-03-29 03:38:48 -0700 Facter (debug): Loading external facts
Jira (PUP-10960) Windows agent installer errors on environment mismatch
Title: Message Title Kevin Reeuwijk created an issue Puppet / PUP-10960 Windows agent installer errors on environment mismatch Issue Type: Improvement Affects Versions: PUP 7.4.1 Assignee: Unassigned Components: Windows Created: 2021/03/10 6:55 AM Priority: Normal Reporter: Kevin Reeuwijk When migrating a Puppet Agent from one PE environment to another, there can be a change in the puppet code environment the node is classified in. On Linux, this does not cause a problem. However on Windows, this error occurs during installation of the agent, using the PE oneline-installer: PS C:\Users\administrator.DREAMWORX> .\install.ps1 -v VERBOSE: Transferring package from source https://pe.dreamworx.nl:8140/packages/2021.0.0/windows-x86_64/puppet-agent-x64.msi VERBOSE: Downloading the Puppet Agent for Puppet Enterprise
Jira (FACT-2937) 'puppet facts show' logs error when stdlib is installed
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-2937 'puppet facts show' logs error when stdlib is installed Change By: Kevin Reeuwijk Comment: This breaks PE 2021.0.0 for me, I can't use the product at all in this state. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.386159.1612446678000.156120.1614786900131%40Atlassian.JIRA.
Jira (FACT-2937) 'puppet facts show' logs error when stdlib is installed
Title: Message Title Kevin Reeuwijk commented on FACT-2937 Re: 'puppet facts show' logs error when stdlib is installed This breaks PE 2021.0.0 for me, I can't use the product at all in this state. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.386159.1612446678000.156020.1614779400026%40Atlassian.JIRA.
Jira (PDB-4934) PuppetDB does not support username@hostname auth for Azure PostgreSQL
Title: Message Title
Kevin Reeuwijk updated an issue
PuppetDB / PDB-4934
PuppetDB does not support username@hostname auth for Azure PostgreSQL
Change By:
Kevin Reeuwijk
As a customer, I want to be able to use Azure PostgreSQL as my external PostgreSQL database for Puppet Enterprise. When attempting to use Azure PostgreSQL as an external database for PuppetDB (PE 2019.8.1), I encountered the problem that Azure requires the username for the Postgres connection to be in the {{username@hostname}} form, due to the way they publish access to PostgreSQL (as described [here|https://github.com/chef/chef-server/issues/1559]). I can manually modify {{database.ini}} to set the username to that format, but then you’ll see this in the logs:{noformat}clojure.lang.ExceptionInfo: Connected to database as "pe-puppetdb-migrator", not migrator "pe-puppetdb-migrator@pdb01"{noformat}It seems we have the same limitations as Chef has (see linked issue). This requirement from Azure stems from their architecture:{noformat}Azure Database for PostgreSQL has a gateway in front of the actual database servers that forwards connections from username@hostname to hostname as username.This means that once the connection is established, you will actually be connected as username, not username@hostname, and any database queries involving users should just use username (e.g. granting permissions).{noformat} Some issues I’ve encountered while trying to get this to work: * The [docs|https://puppet.com/docs/pe/2019.8/installing_postgresql.html#create_pe_databases_on_the_postgresql_instance] don’t tell you to also create a {{pe-puppetdb-migrator}} user * The [docs|https://puppet.com/docs/pe/2019.8/installing_postgresql.html#create_pe_databases_on_the_postgresql_instance] assume a Linux OS for the {{psql}} commands to create the users & databases. However, Azure PostgreSQL runs on Windows, which causes the locales to have different names. For Azure PostgreSQL, the {{ENCODING}} line needs to be changed to: {{ENCODING 'utf8' LC_CTYPE 'English_United States.1252' LC_COLLATE 'English_United States.1252' template template0;}} * You can’t specify {{username@hostname}} for the {{xxx_regular_db_user}} and {{xxx_migration_db_user}} settings in {{pe.conf}}, the {{@hostname}} part gets cutoff during installation. * I can manually re-add the {{@hostname}} back to the username in {{database.ini}} but then the queries also expect this for the connection, which they should not. And I can probably assume that another puppet run would overwrite the settings in {{database.ini}} again.
Jira (PDB-4934) PuppetDB does not support username@hostname auth for Azure PostgreSQL
Title: Message Title Kevin Reeuwijk created an issue PuppetDB / PDB-4934 PuppetDB does not support username@hostname auth for Azure PostgreSQL Issue Type: Bug Affects Versions: PDB 6.11.3 Assignee: Unassigned Components: PuppetDB Created: 2020/10/19 10:10 AM Priority: Normal Reporter: Kevin Reeuwijk As a customer, I want to be able to use Azure PostgreSQL as my external PostgreSQL database for Puppet Enterprise. When attempting to use Azure PostgreSQL as an external database for PuppetDB (PE 2019.8.1), I encountered the problem that Azure requires the username for the Postgres connection to be in the username@hostname form, due to the way they publish access to PostgreSQL (as described here). I can manually modify database.ini to set the username to that format, but then you’ll see this in the logs: clojure.lang.ExceptionInfo: Connected to database as "pe-puppetdb-migrator", not migrator "pe-puppetdb-migrator@pdb01" It seems we have the same limitations as Chef has (see linked issue). This requirement from Azure stems from their architecture:
Jira (PUP-5823) Puppet agent with splay on windows begets random interval between runs
Title: Message Title Kevin Reeuwijk commented on PUP-5823 Re: Puppet agent with splay on windows begets random interval between runs This issue causes runtimes to get reported as abnormal for Windows runs, see attached screenshot. When looker deeper at the metrics, the "Agent startup time (sec)" erroneously includes the splay wait time. The actual puppet run took a normal amount of seconds, but in the higher level reporting this is no longer visible. Especially on Windows, long agent runs are important to spot. Windows patching can cause a long puppet run, so when I first saw these long runtimes, I was worried all my nodes were continuously re-applying patches or something. With the current state, the agent runtime metric becomes completely useless, and will admins to disable splay. Please look at fixing this issue as we get more Windows customers. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.115341.1454671876000.81284.1591639080089%40Atlassian.JIRA.
Jira (PUP-5823) Puppet agent with splay on windows begets random interval between runs
Title: Message Title Kevin Reeuwijk updated an issue Puppet / PUP-5823 Puppet agent with splay on windows begets random interval between runs Change By: Kevin Reeuwijk Attachment: agent_startup_time.png Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.115341.1454671876000.81278.1591638840200%40Atlassian.JIRA.
Jira (PUP-5823) Puppet agent with splay on windows begets random interval between runs
Title: Message Title Kevin Reeuwijk updated an issue Puppet / PUP-5823 Puppet agent with splay on windows begets random interval between runs Change By: Kevin Reeuwijk Attachment: runtimes_windows.png Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.115341.1454671876000.81277.1591638840146%40Atlassian.JIRA.
Jira (PUP-10484) Unregistered yum subscription-manager confuses yum package provider
Title: Message Title Kevin Reeuwijk created an issue Puppet / PUP-10484 Unregistered yum subscription-manager confuses yum package provider Issue Type: Improvement Affects Versions: PUP 6.14.0 Assignee: Unassigned Components: Types and Providers Created: 2020/05/01 5:11 AM Environment: Somehow the subscription-manager.conf appeared in my system as I was setting up docker and docker-compose. It was not until later that I realized it broke puppet's package provider. Priority: Normal Reporter: Kevin Reeuwijk If the yum subscription-manager is enabled but not registered with an entitlement server, a warning will show in every output of the yum command: This system is not registered with an entitlement server. You can use subscription-manager to register. This confuses the yum package provider, causing Package resources to no longer be able to update packages. Steps to repro:
Jira (PUP-10365) puppet agent unable to fetch file from https source - Error: certificate verify failed
Title: Message Title
Kevin Reeuwijk commented on PUP-10365
Re: puppet agent unable to fetch file from https source - Error: certificate verify failed
I've developed this workaround that can be used in the mean time, simply add the following code to your baseline:
file_line { 'workaround-puppet-agent-6-14-ssl-issue':
ensure => present,
path => "${facts['rubysitedir']}/../../vendor_ruby/puppet/type/file/source.rb",
line => ' client.get(url, include_system_store: true) do |response|',
match => '^ client.get\(url\) do \|response\|',
}
Add Comment
Jira (PUP-1519) Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number
Title: Message Title Kevin Reeuwijk commented on PUP-1519 Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number Now published on the Forge: https://forge.puppet.com/puppetlabs/minimum_version Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.24581.1390679442000.19915.1581348722265%40Atlassian.JIRA.
Jira (PUP-1519) Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number
Title: Message Title Kevin Reeuwijk commented on PUP-1519 Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number As the PR was abandoned, I built a new module for this functionality here: https://github.com/puppetlabs/puppetlabs-minimum_version It provides a minimum_version() function (I renamed it) that can be added to PE by simply adding to module to the Puppetfile. This way it allows people to opt-in and won't break any existing functionality. The syntax is: minimum_version(String, String , Optional[String] , Optional[String] ) It is meant to be used in the ensure attribute of a package resource, like so: package { 'python': ensure => minimum_version('python', '2.7.5-77.el7_6') } To install the latest available version when the minimum version is not present: package { 'python': ensure => minimum_version('python', '2.7.5-77.el7_6', 'latest') } To install the latest available version of a gem when the minimum version is not present:
Jira (PUP-10224) Add ensure_at_least() function to PE for the package type
Title: Message Title Kevin Reeuwijk commented on PUP-10224 Re: Add ensure_at_least() function to PE for the package type This implementation would be specific to PE only, as it leverages the Package Inspector inventory data. It does not work for Open Source Puppet, hence I created it under the PE project instead of the PUP project. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.341101.1578317783000.15997.1578477000163%40Atlassian.JIRA.
Jira (PUP-1519) Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number
Title: Message Title Kevin Reeuwijk commented on PUP-1519 Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number A fix is possible through https://github.com/puppetlabs/puppetlabs-stdlib/pull/1038, as noted in PUP-10224 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.24581.1390679442000.15993.1578476762356%40Atlassian.JIRA.
Jira (PUP-10224) Add ensure_at_least() function to PE for the package type
Title: Message Title Kevin Reeuwijk commented on PUP-10224 Re: Add ensure_at_least() function to PE for the package type Josh Cooper the difference is that this time an actual fix has been built, that can be leveraged (see the PR). It's not a generic request to build something new, it's a request to adopt a fix that works. I worked on this with Reid Vandewiele and he acknowledges that this would fulfill a customer demand that has been there for 3+ years. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.341101.1578317783000.15950.1578476700187%40Atlassian.JIRA.
Jira (FACT-2258) Facter does not detect t3a instances on AWS
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-2258 Facter does not detect t3a instances on AWS Change By: Kevin Reeuwijk Affects Version/s: FACT 3.14.5 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.340118.1576692534000.4985.1576692960455%40Atlassian.JIRA.
Jira (BOLT-1527) Unable to cleanup temp directory if Task loaded a DLL
Title: Message Title Kevin Reeuwijk created an issue Puppet Task Runner / BOLT-1527 Unable to cleanup temp directory if Task loaded a DLL Issue Type: Bug Assignee: Unassigned Created: 2019/10/07 2:52 AM Environment: To reproduce, add this Puppet module to Bolt's Puppetfile and then run the windows_updates::install_kb task against a remote node over WinRM. Priority: Normal Reporter: Kevin Reeuwijk According to this article, Powershell is unable to fully unload a previously loaded DLL. The only way to unload a DLL is to end the Powershell session. This presents a problem to Bolt as it executes (Powershell-based) Bolt Tasks in-process when connecting via WinRM. As a result, if the Bolt Task loads a Powershell module that contains a DLL during execution, that module's DLL stays loaded after the Tasks completes. This will cause Bolt's cleanup phase to show these errors is the debug log: Executing command: Remove-Item -Force -Recurse -Path "C:\Users\Administrator\AppData\Local\Temp\chjzt3c5.ot3" stdout: stderr:
Jira (PUP-10057) User resource on Windows confuses domain and local accounts
Title: Message Title Kevin Reeuwijk created an issue Puppet / PUP-10057 User resource on Windows confuses domain and local accounts Issue Type: Bug Affects Versions: PUP 6.4.3 Assignee: Unassigned Components: Types and Providers, Windows Created: 2019/10/01 2:11 AM Priority: Normal Reporter: Kevin Reeuwijk Puppet Version: 6.4.3 (PE Agent from PE 2019.1.1) Puppet Server Version: PE 2019.1.1 OS Name/Version: Tested against Windows 2016 Behavior of the user resource goes wonky when an AD account exists that has the same name as the local user account you’re trying to manage on a Windows server that is domain-joined. Desired Behavior: Enforcing configuration of local user accounts on Windows domain-member servers works normally. Actual Behavior: When a user account exists locally on a member server, and a user account with the same name also exists in the Active Directory domain, this happens when setting `ensure=>absent` on that local user account: The first puppet run, the local user account is detected, and removed The second puppet run, the provider seems to detect the domain user account, and tries to delete the account again (from the local user database), which fails with this error: Could not set 'absent' on ensure: (in OLE method `Delete': ) OLE error code:800708AD in Active Directory The user name could not be found. HRESULT error code:0x80020009 Exception occurred. (file: /etc/puppetlabs/code/environments/development/site-modules/profile/manifests/base.pp, line: 98) Wrapped exception: (in OLE method `Delete': ) OLE error
Jira (BOLT-1156) Bolt's r10k should use %LOCALAPPDATA% for Windows cachedir
Title: Message Title Kevin Reeuwijk commented on BOLT-1156 Re: Bolt's r10k should use %LOCALAPPDATA% for Windows cachedir I managed to reliably reproduce this problem. The culprit is the HOMEDRIVE and HOMEPATH environment variables. When a Windows admin configures the "Home folder" of an Active Directory user to connect to a network drive, the HOMEDRIVE and HOMEPATH environment variables for the user will change on the Windows client: User with Home folder set to a network drive (H HOMEDRIVE = H: HOMEPATH = \ User with Home folder not configured HOMEDRIVE = C: HOMEPATH = \Users\username When 'bolt puppetfile install' runs the first time, it will attempt to create a .r10k directory in %HOMEDRIVE%%HOMEPATH%, which translates to H:\.r10k for the user with a home network drive, and C:\Users\testuser\.r10k for the user without a home network drive. If the user is disconnected from their network drive, r10k fails to create the .r10k folder and the errors in the screenshot appear. I have verified that running the following commands first will work as a temporary workaround: $Env:HOMEDRIVE = C: $Env:HOMEPATH = "\Users\$Env:USERNAME" If the user's home network drive is connected, r10k does work and no workaround is needed. However, having the .r10k folder created on the user's home network drive is undesirable. The same goes for the Bolt analytics file, which ends up at H:\.puppetabs\bolt\analytics.yaml in the connected home network drive scenario. These things should go to the user's profile, not their home network drive:. On Windows: r10k should use the LOCALAPPDATA environment variable Bolt should use the APPDATA environment variable
Jira (BOLT-1207) Bolt should inform users when there is a new version available
Title: Message Title
Kevin Reeuwijk commented on BOLT-1207
Re: Bolt should inform users when there is a new version available
I've seen more than a few cases where an error occurred due to the user (even SEs) running an old version of Bolt. One possibility is to augment only the error message with an update notification. For example:
Starting: plan test
Finished: plan test in 0.02 sec
{
"kind": "bolt/pal-error",
"msg": "Evaluation Error: Unknown function: 'puppetdb_query'. (file: /Users/kevin.reeuwijk/.puppetlabs/bolt/site-modules/test/plans/init.pp, line: 11, column: 13)",
"details": {
}
"updateinfo" : "You are running v1.2.0, the latest version is v1.26.0. Consider upgrading!"
}
Jira (BOLT-1466) Inventory configuration precedence is confusing
Title: Message Title Kevin Reeuwijk commented on BOLT-1466 Re: Inventory configuration precedence is confusing Can you force override the transport by specifying '--transport pcp' as a workaround? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.315922.1562780625000.12761.1562871420152%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1466) Inventory configuration precedence is confusing
Title: Message Title Kevin Reeuwijk commented on BOLT-1466 Re: Inventory configuration precedence is confusing Shouldn't the (expected) behavior be that if -n groupname is specified, that Bolt scopes its use of the inventoryfile to that group only? Maybe the --nodes parameter is too ambiguous for this to work reliably, and a --group parameter is needed to more clearly communicate intent? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.315922.1562780625000.12035.1562834880198%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1467) bolt_shim::command should execute via powershell on Windows
Title: Message Title Kevin Reeuwijk commented on BOLT-1467 Re: bolt_shim::command should execute via powershell on Windows If this gets resolved, the work should be shared with the puppetlabs/exec module so that we can finally get this module to natively support Powershell as well. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.315975.1562793707000.12033.1562834640087%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1207) Bolt should inform users when there is a new version available
Title: Message Title Kevin Reeuwijk commented on BOLT-1207 Re: Bolt should inform users when there is a new version available bolt update check would be a non-intrusive way of getting easy access to the desired info. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.301658.1553614758000.12030.1562834520267%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1467) bolt_shim::command should execute via powershell on Windows
Title: Message Title Kevin Reeuwijk created an issue Puppet Task Runner / BOLT-1467 bolt_shim::command should execute via powershell on Windows Issue Type: Improvement Assignee: Ethan Brown Created: 2019/07/10 2:21 PM Priority: Normal Reporter: Kevin Reeuwijk As a Bolt user, I want my command for Windows nodes to work in all scenarios, regardless of the chosen transport. Today there is in inconsistency between the WinRM transport and the PCP transport when using 'bolt command run' Under the WinRM transport the given command is executed via Powershell Under the PCP transport the given command is executed via the bolt_shim::command Task, which ends up running under cmd.exe and not Powershell Add Comment
Jira (BOLT-1318) Modulepath unable to handle folder names in uppercase characters on Windows
Title: Message Title Kevin Reeuwijk commented on BOLT-1318 Re: Modulepath unable to handle folder names in uppercase characters on Windows That's an elegant solution Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309321.1558130157000.61379.1561538940592%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1318) Modulepath unable to handle folder names in uppercase characters on Windows
Title: Message Title Kevin Reeuwijk commented on BOLT-1318 Re: Modulepath unable to handle folder names in uppercase characters on Windows I checked again with a couple of Bolt versions: Bolt 1.10 - no issue Bolt 1.20 - no issue Bolt 1.24 - no issue All three were able to correctly find the module when the modulepath is auto-generated. The user encountering the problem must have manually set the modulepath in bolt.yaml and used a lowercase path while the actual path container uppercase characters. So officially this is more user error than bug. But having said that, Windows users expect case insensitivity. We may want to evaluate handling the modulepath as specified in bolt.yaml as case insensitive on Windows specifically. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309321.1558130157000.59062.1561453200487%40Atlassian.JIRA. For more options, visit
Jira (BOLT-1318) Modulepath unable to handle folder names in uppercase characters on Windows
Title: Message Title Kevin Reeuwijk commented on BOLT-1318 Re: Modulepath unable to handle folder names in uppercase characters on Windows Cas Donoghue is that with the latest Bolt version? Because it seems this issue is then fixed in the latest version... This output is encouraging, as it was shown in all lower case in an older Bolt version: MODULEPATH: C:/DATA/modules:C:/DATA/site-modules:C:/DATA/site Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309321.1558130157000.58172.1561397820600%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1318) Modulepath unable to handle folder names in uppercase characters on Windows
Title: Message Title Kevin Reeuwijk commented on BOLT-1318 Re: Modulepath unable to handle folder names in uppercase characters on Windows except that the auto-generated modulepath is all lowercase, see the original ticket info: ```User has this Bolt project folder: `C:\DATA\workshop` with a bolt.yaml in it and subsequently the modulepath becomes c:/data/workshop/modules``` Notice that the modulepath didn't become `c:/DATA/workshop/modules`, but `c:/data/workshop/modules` So a quick fix could be to correctly auto-generate the modulepath so that it honors the source case of characters. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309321.1558130157000.57633.1561381380911%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1318) Modulepath unable to handle folder names in uppercase characters on Windows
Title: Message Title Kevin Reeuwijk created an issue Puppet Task Runner / BOLT-1318 Modulepath unable to handle folder names in uppercase characters on Windows Issue Type: Bug Assignee: Unassigned Created: 2019/05/17 2:55 PM Environment: User has this Bolt project folder: `C:\DATA\workshop` with a bolt.yaml in it and subsequently the modulepath becomes c:/data/workshop/modules However no tasks/plans are ever found there. If I manually force the modulepath (in bolt.yaml) to C:/DATA/workshop then it works Bolt needs to be completely case insensitive on Windows, otherwise this breaks everything Priority: Normal Reporter: Kevin Reeuwijk Bolt won’t handle folder names with one or more uppercase characters in the name incorrectly, when they are part of the modulepath. I encountered this while doing a Bolt Workshop at KPN. If the modulepath has a capitalized foldername in it, not Tasks or Plans are found in that module. It is as if the module is not there. Add Comment
Jira (BOLT-1247) As a end user I would like the debug flag to report when it a invalid task name is used and discarded
Title: Message Title Kevin Reeuwijk commented on BOLT-1247 Re: As a end user I would like the debug flag to report when it a invalid task name is used and discarded The actual tasks might not be invalid, but they may live inside of invalid modules (e.g. modules with invalid names). Such invalid modules should also be reported, since the individual tasks inside of that module will likely not be parsed at all. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6743) Classes should propagate schedule metaparameter to its contained resources
Title: Message Title
Kevin Reeuwijk commented on PUP-6743
Re: Classes should propagate schedule metaparameter to its contained resources
I just ran into this issue as well, where the following code didn't behave as expected:
windows_updates::kb { $kb :
ensure => 'present',
kb => $kb,
notify => Reboot['patch_window_reboot'],
schedule => 'patch_window'
}
schedule { 'maintenance_window':
range => '22:00 - 04:00',
weekday => 'Saturday',
}
reboot { 'patch_window_reboot':
apply=> 'finished',
Jira (BOLT-1186) Improve Bolt startup time on Windows redux
Title: Message Title Kevin Reeuwijk commented on BOLT-1186 Re: Improve Bolt startup time on Windows redux running Bolt 1.15 on my Windows server at home: bolt command run "echo hello" --nodes localhost --> 6.28 seconds bolt --> 5.07 seconds so it got a bit faster, but I’d still call it slow. For comparison on my Mac: bolt command run "echo hello" --nodes localhost --> 2.17 seconds bolt --> 2.33 seconds Basically it’s twice as slow on Windows. We could blame Windows Defender as it doubles the runtime, but the problem is that Ansible is lightning fast on Windows... Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1198) Support capitals in aliases and group names
Title: Message Title Kevin Reeuwijk created an issue Puppet Task Runner / BOLT-1198 Support capitals in aliases and group names Issue Type: Improvement Affects Versions: BOLT 1.14.0, BOLT 1.13.1, BOLT 1.13.0, BOLT 1.12.0, BOLT 1.11.0, BOLT 1.10.0 Assignee: Unassigned Components: bolt Created: 2019/03/21 3:04 PM Priority: Normal Reporter: Kevin Reeuwijk Using one or more capitals in an alias or group name in inventory.yaml will result in strange behavior, it will complain about invalid group names, but not specify that capitals are the problem. Especially for Windows users, the usage of one/more/all capitals in these sorts of names is very normal. They are not aware there could be anything illegal with them. This also raises a separate concern about having case-sensitivity yes or no, if capitals were to be fully supported. Again, for Windows users, they are used to such things being case-insensitive. At the minimum, if Bolt wouldn't support capitals in any way going forward, a useful error message should be shown to the user, informing them that capitals can't be used.
Jira (BOLT-1087) Create new boltdir docs page
Title: Message Title Kevin Reeuwijk commented on BOLT-1087 Re: Create new boltdir docs page The only real difference between [ bolt.yaml at root level ] and a Boltdir directory, is the grouping of contents. IMHO, when the intent is to have a project-specific set of Bolt code, just create a fresh directory, put a bolt.yaml in it, and work from there. However if the Bolt code shares a location with something else, for example your software source code, then using the bolt.yaml patterns isn't as neat as it will be unclear which files & folders belong to Bolt, and which belong to the other components of the project. In that case, group everything Bolt under a Boltdir. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1050) {{_run_as}} option clobbered by configuration.
Title: Message Title
Kevin Reeuwijk commented on BOLT-1050
Re: {{_run_as}} option clobbered by configuration.
From Alex Dreyer: "base64 -d /etc/puppetlabs/license.enc > /etc/puppetlabs/license.key" is not a single command so it won't work with sudo. The way we currently execute it turns into "sudo -u root base64 -d /etc/puppetlabs/license.enc" > /etc/puppetlabs/license.key Updating the documentation to explain this for run_command() would be helpful.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1050) {{_run_as}} option clobbered by configuration.
Title: Message Title
Kevin Reeuwijk commented on BOLT-1050
Re: {{_run_as}} option clobbered by configuration.
I'm experiencing confusing behavior with run_command() in a plan that gets called with
--user centos --run-as root
Any commands called like this will end up running as centos and with insufficient privileges, for example:
{
"kind": "bolt/run-failure",
"msg": "Plan aborted: run_command 'base64 -d /etc/puppetlabs/license.enc > /etc/puppetlabs/license.key' failed on 1 nodes",
"details": {
"action": "run_command",
"object": "base64 -d /etc/puppetlabs/license.enc > /etc/puppetlabs/license.key",
"result_set": [
{
"node": "35.180.221.85",
"status": "failure",
Jira (BOLT-1050) {{_run_as}} option clobbered by configuration.
Title: Message Title
Kevin Reeuwijk updated an issue
Puppet Task Runner / BOLT-1050
{{_run_as}} option clobbered by configuration.
Change By:
Kevin Reeuwijk
As described in BOLT-292 the {{ _run_on _run_as }} option to the run functions should take precedence over any configuration flags, either from config file, commandline, or inventory.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-608) Support local transport on windows
Title: Message Title Kevin Reeuwijk commented on BOLT-608 Re: Support local transport on windows +1 as this feature is needed to support workflows for Puppet Pipelines, where the app is deployed locally using Bolt Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9295) Notify resource exposing Sensitive data when message is raw Sensitive data
Title: Message Title
Kevin Reeuwijk created an issue
Puppet / PUP-9295
Notify resource exposing Sensitive data when message is raw Sensitive data
Issue Type:
Bug
Assignee:
Unassigned
Components:
Types and Providers
Created:
2018/10/31 8:09 AM
Priority:
Normal
Reporter:
Kevin Reeuwijk
Puppet Version: 6.0.2 Puppet Server Version: 2019.0.0 OS Name/Version: Mac OS X, also confirmed on Linux by customer The Notify{} resource will leak Sensitive data if the message is a raw value of Sensitive() type. It looks like the Notify{} resource is mishandling the processing of the message parameter if the input is a raw Sensitive datatype (not encapsulated in double quotes). Desired Behavior: No Sensitive data should be output in clear text. Actual Behavior: For example, in the following code both message 1 and 2 leak sensitive data:
$secret = Sensitive('s3cret')
notify { 'Sensitive message 1':
message => $secret,
}
Jira (PUP-9239) The Puppet config set command does not seem to work for --section flag
Title: Message Title
Kevin Reeuwijk updated an issue
Puppet / PUP-9239
The Puppet config set command does not seem to work for --section flag
Change By:
Kevin Reeuwijk
reported by [~kevin.reeuwijk]this still works normally:{code:java}puppet config set {code} But this looks like it does nothing:{code:java}puppet config set --section master{code} Repro'd on PE 2019.0.0 (GA) :{code:java}[root@master /]# puppet config set rich_data false --section master[root@master /]# puppet config print rich_data --section mastertrue[root@master /]# puppet config set rich_data false[root@master /]# puppet config print rich_datafalse{code} However, it turns out that the [master] section in puppet.conf *does* get updated correctly.What is broken is the "puppet config print rich_data --section master" command, as this outputs the wrong value.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To
Jira (PUP-9196) Host type raises error for use of whitespace in host_aliases attribute while array delimiter is a whitespace
Title: Message Title Kevin Reeuwijk created an issue Puppet / PUP-9196 Host type raises error for use of whitespace in host_aliases attribute while array delimiter is a whitespace Issue Type: Bug Affects Versions: PUP 6.0.0, PUP 5.5.6 Assignee: Unassigned Components: Language Created: 2018/10/03 6:34 AM Priority: Normal Reporter: Kevin Reeuwijk Puppet Version: verified on 5.5.x and 6.x Puppet Server Version: 2018.1 OS Name/Version: CentOS 7.5.1804 It's impossible to provide a valid array of host_aliases to the Host resource from the 'puppet resource' command line, due to an erroneous validation error in the Host type definition. On lines 39-41 of /opt/puppetlabs/puppet/vendor_modules/host_core/lib/puppet/type/host.rb it defines the array delimiter as a space: def delimiter ' ' end
Jira (BOLT-886) C:\Program Files\Puppet Labs\Bolt\bin\bolt.bat is non-functional
Title: Message Title Kevin Reeuwijk commented on BOLT-886 Re: C:\Program Files\Puppet Labs\Bolt\bin\bolt.bat is non-functional The Getting Started With Puppet training tells students (on Windows) to install the MSI and then they should be able to just run Bolt. So there is an expectation that it 'just works' after installation. It does on Linux, and it does in PowerShell as well since the additional PowerShell module gets auto-imported. If adding Bolt to the path is not done automatically, the MSI installer should finish with a message about this. E.g.: Bolt has now been installed and will work immediately in PowerShell, just type: bolt If you want to use Bolt in the standard Command Prompt as well, it's best to addto your PATH variable in Advanced System Settings. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-886) C:\Program Files\Puppet Labs\Bolt\bin\bolt.bat is non-functional
Title: Message Title Kevin Reeuwijk created an issue Puppet Task Runner / BOLT-886 C:\Program Files\Puppet Labs\Bolt\bin\bolt.bat is non-functional Issue Type: Bug Affects Versions: BOLT 0.24.0 Assignee: Unassigned Created: 2018/10/02 3:02 AM Priority: Major Reporter: Kevin Reeuwijk I installed Bolt 0.24 and noticed Bolt would only work in Powershell, but not in a standard Command Prompt. Two things were wrong: The system path was not updated to include C:\Program Files\Puppet Labs\Bolt\bin The contents of C:\Program Files\Puppet Labs\Bolt\bin\bolt.bat was wrong The contents of the bolt.bat file were: @ECHO OFF IF NOT "%~f0" == "~f0" GOTO :WinNT @"C:\ProgramFiles64folder\PuppetLabs\Bolt\bin\ruby.exe" "C:/ProgramFiles64folder/PuppetLabs/Bolt/bin/bolt" %1 %2 %3 %4 %5 %6 %7 %8 %9
Jira (BOLT-840) Include unvendored Puppet 6 content in Bolt
Title: Message Title Kevin Reeuwijk commented on BOLT-840 Re: Include unvendored Puppet 6 content in Bolt Finally, there is no way to force the puppet agent gem version when using the apply_prep() task in a plan. It always installs the latest version, which now means puppet6. Shouldn't we have a way to do something like this to force a different version if needed? apply_prep( agent_version => 5.5.4 ) or apply_prep( major_version => 5 ) Add Comment
Jira (BOLT-840) Include unvendored Puppet 6 content in Bolt
Title: Message Title Kevin Reeuwijk commented on BOLT-840 Re: Include unvendored Puppet 6 content in Bolt Also, I can't install bolt via yum through the puppet 6 repo: [centos@ip-172-31-8-247 ~]$ sudo rpm -Uvh https://yum.puppet.com/puppet/puppet-release-el-7.noarch.rpm Retrieving https://yum.puppet.com/puppet/puppet-release-el-7.noarch.rpm warning: /var/tmp/rpm-tmp.fGxB9Z: Header V4 RSA/SHA256 Signature, key ID ef8d349f: NOKEY Preparing... # [100%] Updating / installing... 1:puppet6-release-6.0.0-1.el7 # [100%] [centos@ip-172-31-8-247 ~]$ sudo yum list *puppet* Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: centos.mirror.fr.planethoster.net * extras: centos.mirror.fr.planethoster.net
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title Kevin Reeuwijk commented on FACT-1653 Re: External Facts from PowerShell do not parse structured output (JSON/YAML) Reid Vandewiele it looks like the lines are blurry on what valid is, since there is some auto-conversion happening. On Windows, all three (double-quoted, single-quoted and unquoted) work when fed to the ConvertFrom-Json cmdlet, which correctly double-quotes the fact name in the output JSON. In Puppet, having the fact unquoted fails but when single quoted it succeeds. So apparently there is some auto-conversion in PE too. Since it worked single-quoted, I left it like that as it provides much cleaner Powershell code (not having to escape double-quote characters). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title
Kevin Reeuwijk commented on FACT-1653
Re: External Facts from PowerShell do not parse structured output (JSON/YAML)
Larissa Lane you may want to include this in the GSWP training:
Basic facts: write a script that generates:
fact_name = fact_value
Structured facts: write a script that generates:
{'fact_name': }
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title
Kevin Reeuwijk commented on FACT-1653
Re: External Facts from PowerShell do not parse structured output (JSON/YAML)
Validated, this works:
$result = $PSVersionTable | ConvertTo-Json -Compress
Write-Host "{'a_test_fact':$result}"
It indeed fails if the fact name isn't quoted (single quotes do work fortunately). One way to validate if the user is generating valid JSON is to do this:
$result = $PSVersionTable | ConvertTo-Json -Compress
$test = "{'a_test_fact':$result}"
$test | ConvertFrom-Json
If the data isn't properly formatted (e.g. using = instead of a colon) then the ConvertFrom-Json command will fail. The only thing ConvertFrom-Json doesn't catch is if the fact name isn't quoted, as Windows automatically quotes this during the conversion. Thanks Branan Riley for the guidance!
Add Comment
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title Kevin Reeuwijk commented on FACT-1653 Re: External Facts from PowerShell do not parse structured output (JSON/YAML) OK, trying it with the output changes as suggested Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-1653 External Facts from PowerShell do not parse structured output (JSON/YAML) Change By: Kevin Reeuwijk Attachment: Screen Shot 2018-08-17 at 7.19.18 PM.png Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title Kevin Reeuwijk commented on FACT-1653 Re: External Facts from PowerShell do not parse structured output (JSON/YAML) This issue is not resolved in the latest version of facter (3.11.3 at time of this writing). Take this example external fact: $result = $PSVersionTable | ConvertTo-Json -Compress Write-Host "a_test_fact=$result" This should result in a structured fact in PE. However the actual fact in PE looks like the attached screenshot. It is clearly not getting detected as JSON data, and thus not getting parsed as such. If the -Compress option is not provided to Powershell, only the first line of JSON data ends up in PE. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group
Jira (BOLT-736) Make it easier to discover the local:true option for modules in the Puppetfile
Title: Message Title
Kevin Reeuwijk updated an issue
Puppet Task Runner / BOLT-736
Make it easier to discover the local:true option for modules in the Puppetfile
Change By:
Kevin Reeuwijk
Priority:
Normal Minor
Summary:
Give 'bolt puppetfile install' an option Make it easier to not delete existing discover the local:true option for modules in the Puppetfile
I'd like to be able to bundle my Bolt Task Plan with my application repo in a straightforward way. I've done this here for my Pipelines for Applications demo: [https://github.com/puppetlabs-seteam/PFA_NodeJS_SampleApp/tree/kevin]The Boltdir contains a Puppetfile for supporting modules and a custom 'sampleapp' module which contains my Bolt Task Plan to install all the prereqs for the application.Now ideally, my script would have just these 2 commands:{code}bolt puppetfile installbolt plan run sampleapp::prereqs{code}However if I run *bolt puppetfile install*, it will delete the sampleapp module and only install the modules in the Puppetfile. Since It took another engineer to teach me that there is no way to use a Boltdir with supporting modules together with different modulepath "local: true" option that contains the can be used to ensure r10k doesn't purge a pre-existing module with my plan ( s by name ) , I would need to make things . This capability will become more complicated than desired: * publish used for Bolt with the sampleapp module somewhere in a separate repo and put in the Puppetfile * checkout the code new apply function , run *bolt puppetfile install*, manually add the sampleapp module back in and push the code back to git.Right now I did the second option to get hence it working. The first option is the neatest, but I feel a simpler option should be available: {code}bolt puppetfile install --no-purge{code}This option would install better discoverable for new users to prevent them running into the modules in the Puppetfile but not delete existing modules in the Boltdir same problem .
Jira (BOLT-736) Give 'bolt puppetfile install' an option to not delete existing modules
Title: Message Title
Kevin Reeuwijk updated an issue
Puppet Task Runner / BOLT-736
Give 'bolt puppetfile install' an option to not delete existing modules
Change By:
Kevin Reeuwijk
I'd like to be able to bundle my Bolt Task Plan with my application repo in a straightforward way. I've done this here for my Pipelines for Applications demo: [https://github.com/puppetlabs-seteam/PFA_NodeJS_SampleApp/tree/kevin]The Boltdir contains a Puppetfile for supporting modules and a custom 'sampleapp' module which contains my Bolt Task Plan to install all the prereqs for the application.Now ideally, my script would have just these 2 commands:{code}bolt puppetfile installbolt plan run sampleapp::prereqs{code}However if I run *bolt puppetfile install*, it will delete the sampleapp module and only install the modules in the Puppetfile.Since there is no way to use a Boltdir with supporting modules together with different modulepath that contains the module with my plan(s), I would need to make things more complicated then than desired: * publish the sampleapp module somewhere in a separate repo and put in the Puppetfile * checkout the code, run *bolt puppetfile install*, manually add the sampleapp module back in and push the code back to git.Right now I did the second option to get it working. The first option is the neatest, but I feel a simpler option should be available: {code}bolt puppetfile install --no-purge{code}This option would install the modules in the Puppetfile but not delete existing modules in the Boltdir.
Add Comment
Jira (BOLT-736) Give 'bolt puppetfile install' an option to not delete existing modules
Title: Message Title Kevin Reeuwijk created an issue Puppet Task Runner / BOLT-736 Give 'bolt puppetfile install' an option to not delete existing modules Issue Type: Improvement Assignee: Unassigned Created: 2018/08/03 7:43 AM Priority: Normal Reporter: Kevin Reeuwijk I'd like to be able to bundle my Bolt Task Plan with my application repo in a straightforward way. I've done this here for my Pipelines for Applications demo: https://github.com/puppetlabs-seteam/PFA_NodeJS_SampleApp/tree/kevin The Boltdir contains a Puppetfile for supporting modules and a custom 'sampleapp' module which contains my Bolt Task Plan to install all the prereqs for the application. Now ideally, my script would have just these 2 commands: bolt puppetfile install bolt plan run sampleapp::prereqs However if I run bolt puppetfile install, it will delete the sampleapp module and only install the modules in the Puppetfile. Since there is no way to use a Boltdir with supporting modules together with different modulepath that contains the module with my plan(s), I would need to make things more complicated then desired: publish the sampleapp module somewhere in a separate repo and put in the Puppetfile checkout the code, run bolt
Jira (BOLT-735) #{owner} resolves to nothing in a container on Docker for Mac
Title: Message Title
Kevin Reeuwijk created an issue
Puppet Task Runner / BOLT-735
#{owner} resolves to nothing in a container on Docker for Mac
Issue Type:
Bug
Assignee:
Unassigned
Created:
2018/08/03 7:23 AM
Environment:
Docker for Mac 8.06.0-ce-mac70 (26399) centos:latest container
Priority:
Normal
Reporter:
Kevin Reeuwijk
When using the apply_prep() function in a Task Plan in Bolt 0.21.5, I get the following error when I run it in a centos:latest container under Docker for Mac 18.06.0-ce-mac70 (26399):
Starting: install puppet and gather facts on localhost
{
"kind": "bolt/run-failure",
"msg": "Plan aborted: run_task 'custom_facts' failed on 1 nodes",
"details": {
Jira (BOLT-523) I want to install modules with bolt
Title: Message Title Kevin Reeuwijk commented on BOLT-523 Re: I want to install modules with bolt I like the mental simplicity of puppet module install for installing modules for an ad-hoc tool, but I hear that code is too old and unwieldy to port to bolt unfortunately. The Puppetfile is a reasonable alternative and does make for easier porting of bolt modules to a different workstation. I'd say in normal mode it should work like docker build and look for the Puppetfile in the current working directory. Alternatively the user should be able to explicitly specify a path to the Puppetfile if they want to. In Boltdir mode the Puppetfile should indeed be expected in the root of the Boltdir. One item to keep in mind is that this creates one more place where you'd have to maintain module versions. A good longer term capability would be a bolt puppetfile update-check command that lists modules for which a newer version is available on the Forge. And ideally a bolt puppetfile update command that actually updates the versions of newer modules in the Puppetfile and installs the newer versions. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1653) External Facts from PowerShell do not parse structured output (JSON/YAML)
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-1653 External Facts from PowerShell do not parse structured output (JSON/YAML) Change By: Kevin Reeuwijk Affects Version/s: FACT 3.9.2 Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1779) Windows 2016 container not detected as virtual=docker by facter
Title: Message Title Kevin Reeuwijk updated an issue Facter / FACT-1779 Windows 2016 container not detected as virtual=docker by facter Added Dockerfile (which also copies run-puppet.cmd into the container), this can be used to recreate the container for testing. Change By: Kevin Reeuwijk Attachment: Dockerfile Attachment: run-puppet.cmd Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1779) Windows 2016 container not detected as virtual=docker by facter
Title: Message Title Kevin Reeuwijk moved an issue Facter / FACT-1779 Windows 2016 container not detected as virtual=docker by facter Change By: Kevin Reeuwijk Method Found: Needs Assessment Component/s: Facter Component/s: Windows Workflow: Documentation Scrum Team Workflow Key: DOC FACT - 1779 Project: Documentation [Internal] Facter Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (PUP-1974) Theme: Sensitive Data in Catalogs
Title: Message Title Kevin Reeuwijk commented on PUP-1974 Re: Theme: Sensitive Data in Catalogs Owen Rodabaugh customers fail audits when systems they manage have regulatory requirements on security and the auditor finds a catalog file on the system that contains plaintext secrets. From what KPN told me, they can pass the audits (for now) if the cleartext issues are limited to the Puppet server (i.e. PuppetDB and agent logs), but not if there are unprotected secrets on client machines. I've played around with the node_encrypt module, but it's Redact() function only works for arguments that were passed to the module it's called in. You can't simply protect any bit of information (like you can with Sensitive()), you really have to design the flow of information to work with how node_encrypt was designed. This isn't obvious at first, causing confusion for people who try to use the module and vague error messages that lead people to believe the module is broken. Which it isn't, the Redact() function is just designed for a very particular use case that doesn't cover all our needs. I agree that ideally the Sensitive data type comes with it's own built-in encryption. However this may take significantly longer to implement as it touches many points in the system. A good stopgap measure that would help customers like KPN today, is to encrypt the agent's catalog file on disk. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7981) Puppet extension for Linux disappeared from Azure
Title: Message Title Kevin Reeuwijk commented on PUP-7981 Re: Puppet extension for Linux disappeared from Azure Why wouldn't we have an extension handler for Linux? Linux is our main platform... Automation of cloud deployments is significantly easier when the agent can be bootstrapped as part of the VM deployment template. Why do Azure users have to use a custom script extension to do this while Chef does provide an extension for both Linux and Windows? Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7981) Puppet extension for Linux disappeared from Azure
Title: Message Title Kevin Reeuwijk created an issue Puppet / PUP-7981 Puppet extension for Linux disappeared from Azure Issue Type: Bug Assignee: Unassigned Created: 2017/09/22 7:10 AM Priority: Major Reporter: Kevin Reeuwijk It seems there has been some sort of regression around the Puppet extensions in Azure. The Puppet Agent extension for Linux has disappeared altogether, and the Puppet Agent extension for Windows is listed as "(Preview)" and has the following in it's description: "Additionally, you can extend automation to several key Windows functions, including the Windows Registry, IIS and PowerShell using modules available on the Puppet Forge, a repository of over 2,000 modules contributed by the Puppet community." Only 2000?? This looks like a description that's many years old... The main issue however is that for Linux users on Azure it looks like Chef is supported but Puppet is not! Please contact Microsoft and have them fix this! Add Comment
Jira (PUP-7831) Specifying a return type causes syntax error on puppet 4.7 in conflict with docs
Title: Message Title Kevin Reeuwijk commented on PUP-7831 Re: Specifying a return type causes syntax error on puppet 4.7 in conflict with docs Hi Jorie Tappa, please check https://docs.puppet.com/puppet/4.7/lang_write_functions_in_puppet.html which still shows syntax that includes the return type. The docs for this version should resemble the 4.6 version where the syntax doesn't have the return type syntax. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7851) puppet module build: packs source file permissions into the tarball
Title: Message Title
Kevin Reeuwijk updated an issue
Puppet / PUP-7851
puppet module build: packs source file permissions into the tarball
Change By:
Kevin Reeuwijk
When running {{puppet module build}} on a module the existing permissions on the files and directories are inherited into the tarball. If the source permissions are restrictive (0640 in my case), and the module gets deployed onto target systems using r10k (or similar tools) the resulting module installation exhibits surprising/unexpected behaviour. Especially when the deployment user is not the same as the user running the puppet master (e.g. r10k and foreman), the end-user has to add more scripting to workaround this.Leaking source permissions into the tarball is undesired from both a compatibility and a security perspective.Annoyingly, if the module is downloaded from Github is it does work, as Github doesn't inherit permissions. That's something all the components relating to the Forge should do as well.Fixing this will require multiple approaches:* Updating the puppet module face to insure 'puppet module build' creates a tarball without permissions inherited (all files 0644, all directories 0755, all uid/gids 0/0)* Updating the Forge so it will at least check tarballs for source permissions more restrictive than 0644 and report this back to the module's owner.* Updating documentation on this issue, and how to resolve it* Updating r10k to enforce consistent permissions on deployment of modules from any source.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You
Jira (PUP-1974) Theme: Sensitive Data in Catalogs
Title: Message Title Kevin Reeuwijk commented on PUP-1974 Re: Theme: Sensitive Data in Catalogs A relatively easy fix would be to have the agent store the catalog file in encrypted form on disk, using a key that only the agent knows (i.e. built into the agent itself). The agent could then decrypt the catalog file into memory during runs, never extracting the contents in clear text on disk. Is this is feasible as an agent-only fix? It wouldn't require any change in the puppet master code and would buy us time to work on the bigger challenge. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
