Jira (PUP-9644) Improve documentation around sensitive data in puppet
Title: Message Title William Hurt commented on PUP-9644 Re: Improve documentation around sensitive data in puppet Hi, I just want to +1 getting this prioritized for release somewhere with examples from DOCUMET-634 and from Gene's blog post. I am myself trying to figure out how to properly right a module with the Sensitive type in a way that is easy for end users to utilize. In my searching around for how to do this properly it looks to me like our documentation on the Sensitive type is still very very light, and frankly that ticket above and Gene's blog post are the only things I've found so far that the least bit helpful. 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.304741.1555347266000.61510.1603388820030%40Atlassian.JIRA.
Jira (PUP-10721) http_instance cannot ignore cert verification
Title: Message Title
William Hurt updated an issue
Puppet / PUP-10721
http_instance cannot ignore cert verification
Change By:
William Hurt
*Puppet Version: 6.17.0* *Puppet Server Version: 2019.8.0.37* *OS Name/Version: Ubuntu 18.04*When attempting to use [Puppet::Network::HttpPool.http_instance|https://github.com/puppetlabs/puppet/blob/fe73adb22453824c014d7975e30e4fc882e8bbc2/lib/puppet/network/http_pool.rb#L36] to perform an HTTP request to an HTTPS url, setting the 'verify_peer' parameter false to ignore certificate verification does not work.*Desired Behavior:* This wrapper should be capable of doing HTTPS requests that ignore cert verification. Otherwise it is impossible to use it for doing requests against end points that use self signed certs.*Actual Behavior:*The attempt to ignore cert verification results in an error when the call is invoked. The following call results in the error text below: {code:ruby} use_ssl = truevalidate_cert = falseconn = Puppet::Network::HttpPool.http_instance(uri.host, uri.port, use_ssl, validate_cert)headers = { 'Content-Type' => 'application/json'}conn.post("#{uri.path}?#{uri.query}", body.to_json, headers){code} {noformat} 2020-10-19T21:16:18.987Z WARN [qtp2062408424-41] [c.p.h.c.i.PersistentSyncHttpClient] Error executing http request javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:645) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:464) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:360) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) at org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:281) at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:339) at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:503) at
Jira (PUP-10721) http_instance cannot ignore cert verification
Title: Message Title William Hurt created an issue Puppet / PUP-10721 http_instance cannot ignore cert verification Issue Type: Bug Assignee: Unassigned Created: 2020/10/20 1:14 PM Priority: Normal Reporter: William Hurt Puppet Version: 6.17.0 Puppet Server Version: 2019.8.0.37 OS Name/Version: Ubuntu 18.04 When attempting to use Puppet::Network::HttpPool.http_instance to perform an HTTP request to an HTTPS url, setting the 'verify_peer' parameter false to ignore certificate verification does not work. Desired Behavior: This wrapper should be capable of doing HTTPS requests that ignore cert verification. Otherwise it is impossible to use it for doing requests against end points that use self signed certs. Actual Behavior: The attempt to ignore cert verification results in an error when the call is invoked. The following call results in the error text below: use_ssl = true validate_cert = false conn = Puppet::Network::HttpPool.http_instance(uri.host, uri.port,
Jira (BOLT-1429) Inconsistent behavior in Boltspec::Run.run_command on Windows
Title: Message Title William Hurt commented on BOLT-1429 Re: Inconsistent behavior in Boltspec::Run.run_command on Windows Yasmin Rajabi I think Michael Lombardi is zeroing in on a ruby gem based solution that you might like. His solution would allow multiple powershell commands in the same run utilizing the same PowerShell process that is kept running between commands so that the process only needs to go through startup once per Bolt startup. 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.314131.1561529132000.74891.1566932221023%40Atlassian.JIRA.
Jira (PUP-9961) Execute can fail on Windows if command is marked Sensitive
Title: Message Title
William Hurt created an issue
Puppet / PUP-9961
Execute can fail on Windows if command is marked Sensitive
Issue Type:
Bug
Assignee:
Unassigned
Created:
2019/08/13 12:38 AM
Priority:
Normal
Reporter:
William Hurt
Desired Behavior: Commandline arrays should be treated the same whether the execute method is passed the ':sensitive' option or not. Actual Behavior: In the case statement on lines 165-172 of execution.rb, if the option hash contains the ':sensitive' option, the casting of all array elements to string that occurs on line 168 is not done. The means that later in the execute_windows method when part.include?(' ') is called, there will be an error if one of the array elements is not a string. Examples: This issue was encountered during the course of the PR to chocolatey to redact sensitive commandline calls. The type had to be modified to munge all values to the priority property to string, because it is not uncommon to supply integers to that property, which after supplying the ':sensitive' option to the execute method in the provider suddenly started throwing an error. This error seems likely to only be possible on Windows since the `include?` call seems to part of an effort at quote normalization that doesn't seem to be necessary in the excute_posix method.
Add Comment
Jira (BOLT-1465) Get Bolt Running in Azure Cloudshell
Title: Message Title William Hurt commented on BOLT-1465 Re: Get Bolt Running in Azure Cloudshell I have tested Bolt to work on the version of Ubuntu that runs CloudShell, both with and without PowerShell core. It runs great. Now waiting on Microsoft to either provide me with a production container image I can test privately, or a public build of CloudShell to be available for testing. Once a production environment is available I can do Azure specific testing to see what documentation if any needs to be updated for CloudShell users to properly leverage bolt. Only things that are different that normal Bolt usage need to be documented, and there shouldn't be much. 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.315895.1562767677000.10513.1562767920078%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1465) Get Bolt Running in Azure Cloudshell
Title: Message Title William Hurt created an issue Puppet Task Runner / BOLT-1465 Get Bolt Running in Azure Cloudshell Issue Type: Bug Assignee: William Hurt Components: Azure, CloudShell, bolt Created: 2019/07/10 7:07 AM Labels: bolt azure Cloudshell Priority: Normal Reporter: William Hurt Azure Cloudshell is a browser hosted shell that allows direct access to your cloud estate as though you were browsing in your own filesystem. There were competing products like Ansible already available in Cloudshell by default for all users, but Bolt wasn't. While talking to a program manager at Microsoft we decided that Bolt would be a perfect fit for CloudShell and should be available to all users by default. This ticket is to cover the work of getting Bolt installed by Microsoft, and then updating documentation and working out a support path whereby Microsoft can funnel people that need support to us. Add Comment
Jira (BOLT-1429) Inconsistent behavior in Boltspec::Run.run_command on Windows
Title: Message Title William Hurt commented on BOLT-1429 Re: Inconsistent behavior in Boltspec::Run.run_command on Windows I think I could live with an option like this as long as the powershell command is the default option, with cmd /c configurable as needed for a specific use case. 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.314131.1561529132000.61738.1561560420314%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1429) Inconsistent behavior in Boltspec::Run.run_command on Windows
Title: Message Title
William Hurt updated an issue
Puppet Task Runner / BOLT-1429
Inconsistent behavior in Boltspec::Run.run_command on Windows
Change By:
William Hurt
When the WinRM transport is used with the run_command method, Bolt leverages the WinRM gem and deliberately chooses to create a [PowerShell session on the remote host|https://github.com/puppetlabs/bolt/blob/master/lib/bolt/transport/winrm/connection.rb#L54].Using the local_windows transport to execute commands on the local host however is different. A simple [call to Open3.capture3|https://github.com/puppetlabs/bolt/blob/master/lib/bolt/transport/local_windows.rb#L71] is made.The effect on the end user is that the behavior of commands given to run_command is inconsistent.Litmus for instance exposes a method called ` run_shell ` that ends up leveraging ` run_command ` . Users that want to test their module using Litmus would be forced to detect within their test suite which scenario they are in at run time, local or remote, and if local, wrap their own commands in ` ' powershell.exe -noprofile -command #{ < blah }` >' boilerplate on their own.Instead, since the better default choice has already been made for WinRM transport commands, it seems like it could solve the issue closer to the source if the local transport were made to implement it's own wrapper, so that all consumers of the `run_command` method in Bolt spec, whether they be end users or frameworks, could enjoy consistency in the behavior of their commands.As an example of users already affected see [this PR comment|https://github.com/puppetlabs/puppetlabs-dsc/pull/414#discussion_r297455284] in which we are already faced with this difficulty while converting a module's test suite to Litmus.
Add Comment
Jira (BOLT-1429) Inconsistent behavior in Boltspec::Run.run_command on Windows
Title: Message Title
William Hurt created an issue
Puppet Task Runner / BOLT-1429
Inconsistent behavior in Boltspec::Run.run_command on Windows
Issue Type:
Bug
Assignee:
Unassigned
Components:
bolt, Windows
Created:
2019/06/25 11:05 PM
Labels:
bolt windows
Priority:
Normal
Reporter:
William Hurt
When the WinRM transport is used with the run_command method, Bolt leverages the WinRM gem and deliberately chooses to create a PowerShell session on the remote host. Using the local_windows transport to execute commands on the local host however is different. A simple call to Open3.capture3 is made. The effect on the end user is that the behavior of commands given to run_command is inconsistent. Litmus for instance exposes a method called `run_shell` that ends up leveraging `run_command`. Users that want to test their module using Litmus would be forced to detect within their test suite which scenario they are in at run time, local or remote, and if local, wrap their own commands in `powershell.exe -noprofile -command # {blah} ` boilerplate on their own. Instead, since the better default choice has already been made for WinRM transport commands, it seems like it could solve the issue closer to the source if the local transport were made to implement it's own wrapper, so that all consumers of the `run_command` method in Bolt spec, whether they be end users or frameworks, could enjoy consistency in the behavior of their commands. As an example of users already affected see this PR comment in which we are already faced with this difficulty while converting a module's test suite to Litmus.
Jira (PUP-9789) Constants assigned twice emit warning during Litmus use on Windows.
Title: Message Title
William Hurt updated an issue
Puppet / PUP-9789
Constants assigned twice emit warning during Litmus use on Windows.
Change By:
William Hurt
Summary:
{brief summary of issue} Constants assigned twice emit warning during Litmus use 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.313352.1561054057000.3.1561054140611%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9789) Constants assigned twice emit warning during Litmus use on Windows.
Title: Message Title
William Hurt updated an issue
Puppet / PUP-9789
Constants assigned twice emit warning during Litmus use on Windows.
Change By:
William Hurt
When running acceptance tests via Litmus, the Puppet::Util::Windows::APITypes::FFI module from lib/puppet/util/windows/api_types.rb is loaded via the puppet gem.Unfortunately this module always gets loaded twice and a warning is returned to the commandline:{noformat}C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/puppet-6.4.2-x64-mingw32/lib/puppet/util/windows/api_types.rb:6: warning: already initialized constant FFI::WIN32_FALSE C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/pdk-1.10.0/lib/pdk/util/windows/api_types.rb:6: warning: previous definition of WIN32_FALSE was here C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/puppet-6.4.2-x64-mingw32/lib/puppet/util/windows/api_types.rb:9: warning: already initialized constant FFI::ERROR_SUCCESS C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/pdk-1.10.0/lib/pdk/util/windows/api_types.rb:9: warning: previous definition of ERROR_SUCCESS was here{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9789) {brief summary of issue}
Title: Message Title
William Hurt created an issue
Puppet / PUP-9789
{brief summary of issue}
Issue Type:
Bug
Assignee:
William Hurt
Components:
Windows
Created:
2019/06/20 11:07 AM
Labels:
windows litmus
Priority:
Normal
Reporter:
William Hurt
When running acceptance tests via Litmus, the Puppet::Util::Windows::APITypes::FFI module from lib/puppet/util/windows/api_types.rb is loaded via the puppet gem. Unfortunately this module always gets loaded twice and a warning is returned to the commandline:
C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/puppet-6.4.2-x64-mingw32/lib/puppet/util/windows/api_types.rb:6: warning: already initialized constant FFI::WIN32_FALSE C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/pdk-1.10.0/lib/pdk/util/windows/api_types.rb:6: warning: previous definition of WIN32_FALSE was here C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/puppet-6.4.2-x64-mingw32/lib/puppet/util/windows/api_types.rb:9: warning: already initialized constant FFI::ERROR_SUCCESS C:/src/puppetlabs-java_ks/.bundle/gems/ruby/2.5.0/gems/pdk-1.10.0/lib/pdk/util/windows/api_types.rb:9: warning: previous definition of ERROR_SUCCESS was here
Jira (BOLT-1117) Powershell task helper library
Title: Message Title William Hurt commented on BOLT-1117 Re: Powershell task helper library I'm hoping to take over work on https://tickets.puppetlabs.com/browse/PDK-603 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.295235.1549498793000.4487.1557852420603%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1176) Tasks run on Windows via PCP do not resolve all executable paths correctly
Title: Message Title William Hurt created an issue Puppet Task Runner / BOLT-1176 Tasks run on Windows via PCP do not resolve all executable paths correctly Issue Type: Bug Assignee: Unassigned Components: bolt, Windows Created: 2019/03/12 12:16 PM Labels: windows powershell bolt tasks Priority: Normal Reporter: William Hurt When a PowerShell task is run on a Windows machine, there are differences in how it resolves paths to some executable files between runs via WinRM and PCP. When running a task that executes the following PowerShell snippet the results are as follows. Notice the path to puppet.bat resolves all the way down to the bat file: (Get-Command puppet) | Select-object * (Get-Command whoami) | Select-object * whoami The result via WinRM:
Jira (BOLT-1128) Correctly accept JSON strings in PS CLI
Title: Message Title William Hurt created an issue Puppet Task Runner / BOLT-1128 Correctly accept JSON strings in PS CLI Issue Type: Improvement Assignee: Unassigned Components: powershell, bolt, Windows Created: 2019/02/13 2:36 PM Labels: windows bolt powershell Priority: Normal Reporter: William Hurt Currently, when a json string is given to bolt as a parameter value in a PowerShell commandline command, the string needs a special escaped formatting for the json to be interpreted correctly by the time the arguments get into Ruby. This ticket will track the work done to the PowerShell module wrapper around the Bolt command to do that escaping for the use, so they don't have to do it on their own. Add Comment
Jira (BOLT-1075) command : commands fail if in a remote session to Windows
Title: Message Title William Hurt commented on BOLT-1075 Re: command : commands fail if in a remote session to Windows That seems fair. I'll be happy when the improvements to Windows console infrastructure start landing, but I'm fine with that conclusion for now. 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-1075) command : commands fail if in a remote session to Windows
Title: Message Title William Hurt commented on BOLT-1075 Re: command : commands fail if in a remote session to Windows You could make an argument that the workaround is the use bolts native ability to run these command remotely and not try to remote into a machine and run it 'locally' I guess. I do wonder if this will just magically work properly though if someone tried this in a domain environment where you don't need --no-ssl and --password and --user, which is how 99% of Windows users would do this anyway. 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-1075) command : commands fail if in a remote session to Windows
Title: Message Title William Hurt commented on BOLT-1075 Re: command : commands fail if in a remote session to Windows It's not clear to me how either of those would be getting dragged into this, but maybe just because I don't know enough about how bolt is working under the hood here. 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-1075) command : commands fail if in a remote session to Windows
Title: Message Title William Hurt commented on BOLT-1075 Re: command : commands fail if in a remote session to Windows Ok, I see the work around. If I provide the password in the commandline call then it works. The issue seems to be that if you are in a remote session to the computer, the prompt to enter a password doesn't work if you leave the password blank. If you are in a local session the prompt to enter the password works as expected. 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-1075) command : commands fail if in a remote session to Windows
Title: Message Title William Hurt updated an issue Puppet Task Runner / BOLT-1075 command : commands fail if in a remote session to Windows Change By: William Hurt Attachment: bolt_BadFileDescriptor_error.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 (BOLT-1075) command : commands fail if in a remote session to Windows
Title: Message Title William Hurt created an issue Puppet Task Runner / BOLT-1075 command : commands fail if in a remote session to Windows Issue Type: Bug Assignee: Unassigned Attachments: bolt_BadFileDescriptor_error.PNG Components: bolt, Windows Created: 2019/01/08 1:08 PM Labels: windows bolt Priority: Normal Reporter: William Hurt Bolt Version 1.8.1 If you are remoted into a Windows machine and attempt to run a command, the command may fail with an `Bad file descriptor` error. This was discovered during the Getting Started with Puppet training class. Desired Behavior: The command should execute normally. Actual Behavior: A bad file descriptor error is encountered. Add Comment
Jira (PUP-8695) Service resource on Windows should handle dependent services.
Title: Message Title William Hurt created an issue Puppet / PUP-8695 Service resource on Windows should handle dependent services. Issue Type: Improvement Assignee: Unassigned Created: 2018/05/03 10:31 AM Labels: windows service Priority: Normal Reporter: William Hurt Desired Behavior: When a manifest specifies ensure => stopped ** on a service in Windows that has dependent services, the service resource should be capable of stopping the dependent services to ensure that the requested service can be stopped. Actual Behavior: Currently the service resource does not understand dependent services. If a running service has dependent services that are still running, the stop command will fail. Add Comment
Jira (BOLT-509) service: Windows Dependent Services
Title: Message Title William Hurt updated an issue Puppet Task Runner / BOLT-509 service: Windows Dependent Services Change By: William Hurt Acceptance Criteria: A stop or a restart task will be able to: * Recursively find services that are dependent on the service you want to stop. * Stop the dependent services in the correct order * Keep track of any services that were stopped that also have a startup type of manual, and the order in which they were stopped * Stop or call restart on the primary serviceFor restart tasks only: * The task should then call start on any services with a manual startup type, there shut down by the currently running task. It should not restart all dependent services, only those that were earlier shut down by this task run and that will not automatically restart themselves as needed.The task should take a parameter to allow the user to explicitly state whether they want dependent services to be restarted in this fashion, or simply fail. The default should be to fail to stop the service and return to the user enough information to reason about what which services will be stopped and restarted if they choose to use that parameter and restart the dependent services. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (BOLT-509) service: Windows Dependent Services
Title: Message Title William Hurt updated an issue Puppet Task Runner / BOLT-509 service: Windows Dependent Services Change By: William Hurt Acceptance Criteria: A stop or a restart task will be able to: * Recursively find services that are dependent on the service you want to stop. * Stop the dependent services in the correct order * Keep track of any services that were stopped that also have a startup type of manual, and the order in which they were stopped * Stop or call restart on the primary serviceFor restart tasks only: * The task should then call start on any services with a manual startup type, there shut down by the currently running task. It should not restart all dependent services, only those that were earlier shut down by this task run and that will not automatically restart themselves as needed.The task should take a parameter to allow the user to explicitly state whether they want dependent services to be restarted in this fashion, or simply fail. The default should be to fail to start stop the service and return to the user enough information to reason about what services will be stopped and restarted if they choose to use that parameter and restart the dependent services. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (BOLT-509) service: Windows Dependent Services
Title: Message Title William Hurt created an issue Puppet Task Runner / BOLT-509 service: Windows Dependent Services Issue Type: Improvement Assignee: Unassigned Components: service, Windows Created: 2018/05/02 9:32 AM Labels: windows service Priority: Normal Reporter: William Hurt The puppetlabs-service module is not aware of dependent services. This creates a problem restarting services if those services have dependent services that can prevent the service you want to restart from properly stopping. The dependent services must be stopped individually first, and then restarted again, if their startup type is manual. Services who startup type is automatic will start again on their own as needed. Add Comment
