insserv_override
Version information
This version is compatible with:
- Puppet Enterprise 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
- Puppet >= 3.0.0 < 6.0.0
- , , ,
Start using this module
Add this module to your Puppetfile:
mod 'stm-insserv_override', '0.2.2'
Learn more about managing modules with a PuppetfileDocumentation
insserv_override
Table of Contents
- Overview
- Module Description - What does the module do?
- Setup - The basics of getting started with gai
- Usage - Configuration options and additional functionality
- Reference - An under-the-hood peek at what the module is doing and how
- Limitations - OS compatibility, etc.
- Development - Guide for contributing to the module
Overview
Manage override files for LSB init.d
boot dependencies.
Module description
The init.d
boot process uses a dependency based order to start and stop services. Chapter 20 of the Linux Standard Base Core Specification 3.1 defines the format of a compliant Init Script. The Init Script for a service should include the necessary settings (e.g. the runlevels) to sucessfully start and stop the service. An override mechanism is available to allow local variations without modifying the distributed scripts. This requires the creation of files in the /etc/insserv/overrides
directory. This module provides a way to manage these files in your environment.
Setup
What insserv_override affects
This module create, modifies or removes files in the /etc/insserv/overrides
directory. These files are used to determine what services should run in a given runlevel and the order in which services are started or shut down.
Setup requirements
The insserv_override
module requires the Puppetlabs modules stdlib
version 4.3.x or later.
Beginning with insserv_override
The insserv_override
module includes a defined type of the same name that creates override files in the proper location. It also calls the insserv
executable to activate the new configuration.
You have to declare the type for each configuration you would like to override. See the next section for examples.
Usage
Update the Apache service configuration to only start in runlevel 2
insserv_override { 'apache2':
default_start => [ '2' ],
default_stop => [ '0', '1', '3', '4', '5', '6' ],
}
Update dependencies for Puppet to be started last and terminated first
insserv_override { 'puppet':
required_start => [ '$all' ],
required_stop => [ '$all' ],
}
Remove override for MySQL service
insserv_override { 'mysql':
ensure => absent,
}
Reference
Defines Types
Public Defined Types
insserv_override
: The main type to create or remove an override. Undefined parameters are not included in the override file.
Parameters (all optional)
-
ensure
: Whether the override file should exist or not. This parameter is passed to the File resource. Default: present -
provides
: The names of the boot facilities provided by this script. Defaults to the resource title. Can be an array when more than one facility is provided. -
required_start
: The names of the facilities that must be available before this facility can be started. Can be a string or an array. -
required_stop
: The names of the facilities that must still be available when this facility is stopped. Can be a string or an array. -
should_start
: Facilities which should be available during startup of this facility. Can be a string or an array. -
should_stop
: Facilities which should still be available during shutdown of this facility. Can be a string or an array. -
x_start_before
: Facilities that should be started after the current facility. Can be a string or an array. -
x_stop_after
: Facilities that should be stopped before the current facility. Can be a string or an array. -
default_start
: The runlevels in which the current facility should be started. -
default_stop
: The runlevels in which the current facility should be stopped. -
x_interactive
: Whether to start this script alone during boot so the user can interact with it at the console. This is a boolean parameter. Default: false -
short_description
: A one-line description for the service.
Limitations
This module is only useful on init.d
based systems. Most modern distributions (e.g. Debian-8, Ubuntu-15.04, SLES-12, RedHat-7) are using the systemd
boot process instead of the older init.d
based boot process.
Development
Feel free to send pull requests.
2018-02-04 - Release 0.2.2
Summary
Updated version requirements and include RuboCop tests without functional changes.
2016-04-11 - Release 0.2.1
Summary
The release contains just a metadata update without functional changes.
2016-01-06 - Release 0.2.0
Summary
Some small bugfixes.
Type of parameter x_interactive
has been changed to a boolean.
Changed dependency on stdlib
4.3.x or later.
Features
- Parameter
x_interactive
is a boolean parameter now.
Bugfixes
-
Fix check for valid runlevels to work with older versions of the
stdlib
module. Update dependencies forstdlib
>= 4.3.0 < 5.0.0. -
Fix single user runlevel character code to
S
.
2015-12-10 - Release 0.1.0
Summary
Initial release.
Dependencies
- puppetlabs/stdlib (>= 4.3.0 < 5.0.0)
Copyright (c) 2015, Stefan Möding All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.