Forge Home

Modules

Resources

PuppetEcosystemPuppet CommunityUpdates

winsw

WINSW Module. Service Wrapper for any process.
Project URLRSS FeedReport issues

8,568 downloads

7,921 latest version

4.6 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 1.1.1 (latest)
  • 1.1.0
  • 1.0.1
  • 1.0.0
released Dec 7th 2016
This version is compatible with:

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'kenmaglio-winsw', '1.1.1'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add kenmaglio-winsw
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install kenmaglio-winsw --version 1.1.1

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download
Tags: service, powershell, wrapper, winsq

Documentation

kenmaglio/winsw — version 1.1.1 Dec 7th 2016

winsw

Table of Contents

  1. Important
  2. Description
  3. Setup - The basics of getting started with winsw
  4. Usage - Configuration options and additional functionality
  5. Reference - An under-the-hood peek at what the module is doing and how
  6. Limitations - OS compatibility, etc.
  7. Development - Guide for contributing to the module

Important

If you change the $service_id value, after you have installed the service, and you do not ensure abscent first, you will cause errors. The reason is because the code which tried to uninstall, will already have been effected.

Tested on Windows 10 and Windows Server 2012 R2. There shouldn't be any reason this wouldn't work on

Description

This module encapsulates functionality of the WinSW service application wrapper. The development of that project is accredited: https://github.com/kohsuke/winsw

This module attempts to allow any executable with any arguments to be wrapped in a Windows Service. This will require files to be placed on the system in a managed path: EXE, XML, EXE.Config

Derived Types:

  • install
  • service

Install will create the folders in $install_path, drop the files in that folder named $serviceid[.exe|.xml]. Then after those are successfull, the defined type will install the service into the Service Manager.

Service will ensure the service is running.

Beginning with winsw

By default, classifying a node with this class will not get you very far. It will test that the module will work and will run an instance of powershell.exe as a service.

You can take two approaches:

  1. Use the Defined Types under Usage in your own module. They will automatically be created once you add this module ot your puppet file.
    1. You can build your own class that manages multiple services this way, if you so choose.
  2. You can classify a node with the winsw class, and use hiera to override the local variables.

Usage

Usage Pattern for Installing and Configuring Title = name of executable / service

Optional Parameters

Usage Pattern for Uninstalling

Additional Configuration Parameters

To Specify Service Account to run service as

To Run Interactively (not service account cannot be used - only local system)

Reference

The module includes embedded the winsw executable file, and provides a template for the configuration XML. It attepts to create whatever directories you need specified by $install_path Then drops the needed files in that path as $service_name(.exe|.xml)

Utilizing exec's against powershell this module will then manage the behavior flow of winsw commands.

Known Side-Effects

On initial install, the output will show not only the Exec[install_serviceid], but also the Exec[rebuild_service_serviceid]. This is expected as the config xml file is placed, which fires the notify on Exec[rebuild_service_serviceid]. This notify is needed if a config xml file change happens. The service must be stopped, uninstalled, installed and started to take effect.

Limitations

Limitations for current release are really more around parameters which the native WinSW executable can take, which have not been implemented here yet. Right now only the basics to get an executable running, with arguments and environment variables are possible.

More will be added in later revisions.

If you need one specifically please open an issue here on github, and I will try to add that functionality quickly for you.

See: https://github.com/kohsuke/winsw

Development

Please fork and submit pull requests

To setup local environment:

You can include --noop if you don't want to apply, however service actions will fail as it won't actually install.

If you run an elevated command prompt, you can navigate to the service executable directory. Then you can use these to test states of your service and the module. (note MyService is your servie name)