sabayon
Version information
This version is compatible with:
- Puppet Enterprise 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2016.4.x
- Puppet >= 4.10.0 < 7.0.0
Tasks:
- cleanup
- enman_repo
- update
Start using this module
Add this module to your Puppetfile:
mod 'optiz0r-sabayon', '0.7.1'
Learn more about managing modules with a PuppetfileDocumentation
Sabayon
Table of Contents
- Description
- Setup - The basics of getting started with sabayon
- 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
Description
This module extends puppet with support for the Sabayon Linux distribution.
It adds support for:
- The Entropy package manager
- Managing
Sabayon Community Repository (SCR)
definitions usingenman
- Enabling and disabling entropy repositories
- Entropy package masks and unmasks
- Splitdebug installs for packages
- Using systemd as the default service provider
Setup
What the sabayon module affects
operatingsystem
fact: This module overrides the operatingsystem fact toSabayon
on Sabayon systems.Service
provider: This module overrides the default provider forservice
resources to force use ofsystemd
Package
provider: This module overrides the default provider forpackage
resources to force use ofentropy
Prerequisites
sys-apps/lsb-release
is required for the operatingsystem fact to work
Beginning with sabayon
The types and providers within this module can be used without any special
setup, as long as the required packages are already installed. To let this
module take care of installing the required packages, simply include the
sabayon
class.
class { 'sabayon': }
Usage
Installing packages using entropy
This module sets the entropy
provider to be the default for Sabayon,
so no special configuration is required.
The provider supports package names in both the fully-qualified format, e.g.
package { 'net-misc/openssh':
ensure => installed,
}
Or the more verbose format:
package { 'ssh-server':
ensure => installed,
category => 'net-misc',
name => 'openssh',
}
The category specification is optional as long as the package name is unique.
For example you could install pip
as that's (currently) unique, but you could
not install 'mysql' since there's no way to disambiguate between
virtual/mysql
and dev-db/mysql
.
Managing enman repositories
Install an available SCR repository using enman. The title is taken to be the
repository name by default, and must be available via enman. Use an ensure
value of present
to install the repo, and absent
to remove it.
Repositories recorded in enman-db can be
added by name. Local repositories can be added via URL. When using an URL, the
name
property must match the name of the repo defined at the URL, to prevent
puppet trying to re-add the repo on every run.
enman_repo { 'community':
ensure => present,
}
enman_repo { 'myrepo':
ensure => present,
url => 'https://example.com/myrepo',
}
Enabling and disabling entropy repositories
Installed repositories (whether system or SCR repositories) can be enabled and
disabled using the entropy_repo
type.
To enable a repository, use:
entropy_repo { 'sabayon-limbo':
enabled => 'true',
}
To disable a repository (only if present), use:
if 'sabayon-limbo' in $facts['entropy_repos'] {
entropy_repo { 'sabayon-limbo':
enabled => 'false',
}
}
This type cannot currently install or remove repositories, only control the enabled state of existing repositories. The repository being managed must already exist on the system.
Masking packages
Entropy is very flexible in how to specify which packages can be masked, and supports some or all of the following in the atom specification.
All of these parameters are optional, but at least one must be specified
package
(either fully qualified or unqualified package name)operator
(<
,<=
,=
,>=
,>
. applied to version)version
slot
use
tag
repo
The entropy_mask
type also takes the following optional parameters:
target
(The path to the mask file, defaults to/etc/entropy/packages/package.mask
)
Examples
To mask all packages within the community
repository by default
and later unmask specific packages, you could use something like:
entropy_mask { 'mask-community-by-default':
repo => 'community',
}
Alternatively, you could mask newer versions of a package
entropy_mask { 'mask-postgresql-9.5+':
package => 'app-shells/bash',
operator => '>=',
version => '9.5',
}
Or mask a package with an undesirable set of use flags, e.g. to ensure any installed version of openssh supports ldap, mask all versions of openssh which don't include ldap support with:
entropy_mask { 'openssh-without-ldap-support':
package => 'net-misc/openssh',
use => '-ldap',
}
The entropy_mask
type directly writes to the mask file, rather than using the
equo mask
command line. This is so that entries can be removed again when
using ensure => absent
, something which equo
doesn't yet provide support
for. All entries managed by puppet include the # Puppet Name: namevar
trailing comment. Puppet will completely ignore the existence of other entries
in this file, which means you could manually manage other entries in the file
if you wished, although this is not recommended since puppet would not be able
to remove unmanaged entries if you later decide you want them to be managed.
Unmasking packages
Unmasking packages works identically to masking packages, except using the
entropy_unmask
resource. All the same parameters are supported.
Unmasks take precedence over masks, so assuming
in the example above you have masked everything in the community
repository
you could enable installing a particular package from that repository again
using:
entropy_unmask { 'sublime':
package => 'app-editors/sublime-text',
}
The same caveats about managing the unmask file apply as with entropy_mask
above.
Enabling splitdebug for packages
Entropy splits debug information for packages into separate objects which are
installed at the same time as the package only if splitdebug is enabled
globally, or for specific packages listed in the package.splitdebug
file.
This type behaves similarly to masks/unmasks and manages entries in the
splitdebug file to define packages for which debug information should be
installed. All the same parameters are supported as with entropy_mask
.
entropy_splitdebug { 'kernel':
package => 'sys-kernel/linux-sabayon',
}
The same caveats about managint the splitdebug file apply as with the
entropy_mask
type above.
Enabling splitdebug masks for packages
This type inverts the entropy_splitdebug
behaviour, and prevents splitdebug
from being installed for matching packages even when otherwise enabled by an
entropy_splitdebug
entry. Masks take precedence, and anything matched by an
entropy_splitdebug_mask
entry will never have debug information installed.
All the same parameters are supported as with entropy_mask
.
entropy_splitdebug_mask { 'kernel-4.8':
package => 'sys-kernel/linux-sabayon',
slot => '4.8',
}
The same caveats about managint the splitdebug file apply as with the
entropy_mask
type above.
Managing package keywords
The entropy_keywords
type allows managing entries in the package.keywords
file, which can set missing keywords on packages. A typical example is when
installing a 9999
version package straight from source control which hasn't
been marked as supported on any platform.
Parameters:
keyword
: The package keyword to apply. Defaults to the OS architecutre, e.g.amd64
if not specified, but other typical values might be~amd64
,-*
or**
.package
: Name of the package, maybe qualified or unqualified.operator
: (<
,<=
,=
,>=
,>
, applied to version)version
: Restrict the keyword to a specifc version or range of versionsrepo
: Restrict the keyword to packages from a specific repo
At least one of package
or repo
must be specified.
entropy_keywords { 'sublime-live':
package => 'app-text/sublime-text',
version => '9999',
keyword => '**',
}
For more info on package keywords, see https://wiki.gentoo.org/wiki/KEYWORDS
Reference
Classes
::sabayon
class to install required packages to support included types
Types
enman_repo
: Manages SCR repositories using enmanentropy_repo
: Enables/Disables repositoriesentropy_mask
: Manages entropy package masksentropy_unmask
: Manages entropy package unmasksentropy_splitdebug
Manages entropy package debug informationentropy_splitdebug_mask
Manages entropy package debug information masks
Facts
entropy_repos
Provides a structured fact identifying the entropy repos present on the system including their enabled/disabled state, and whether they are enman or entropy repositories.
Example (in yaml format for readability):
---
sabayonlinux.org:
repo_type: "entropy"
enabled: "true"
sabayon-limbo:
repo_type: "entropy"
enabled: "false"
community:
repo_type: "enman"
enabled: "true"
locale
Identifies the system-wide default locale, as set by eselect
.
This is used internally by the entropy package provider to run equo
commands
using the correct locale.
operatingsystem
Overrides the detection of the operating system on Sabayon systems to Sabayon
.
Tasks
This module includes tasks for ad-hoc use with Puppet Bolt or Choria.
cleanup
This task executes equo cleanup
command on the target nodes, which frees up
disk space used by cached package downloads. It does not accept any parameters,
and does not support running noop mode.
update
This task executes equo update
command to update repository defintions on the
target nodes. It accepts an optional repo
paramter which limtis the updates to
a single repo. If omitted, all repos defined on the target node are updated.
enman_repo
This task manages enman_repo
resources and can list available/installed repos,
remove installed repos, or add available repos via either name or URL.
Limitations
This module is actively used by the developer against current Sabayon versions. Due to the rolling release nature of Sabayon, the module is provided as-is and cannot be guaranteed to always be in a working state. Updates are provided on a best-efforts basis.
Development
Pull requests welcome!
Contributors
What are tasks?
Modules can contain tasks that take action outside of a desired state managed by Puppet. It’s perfect for troubleshooting or deploying one-off changes, distributing scripts to run across your infrastructure, or automating changes that need to happen in a particular order as part of an application deployment.
Tasks in this module release
cleanup
Run `equo cleanup` on target nodes to free up disk space used by downloaded packages
2020-10-03 Release 0.7.1
- Fixes automatic deployment to forge
2020-10-03 Release 0.7.0
- Adds support for adding third party enman repo via URL
- Adds
sabayon::enman_repo
task for managing enman repositories via Bolt/Choria - Add documentation for
sabayon::update
task
2-10-12-08 Release 0.6.1
- Improve parsing of package versions with respect to PMS v7 spec
2019-05-10 Release 0.6.0
- Adds
cleanup
task - Convert module to using PDK
2018-10-14 Release 0.5.0
- Update package install error handling for compatbility with puppet 6
- Add support for
pre_pre
package versions - Update build-time gems
2017-03-13 Release 0.4.0
- Replace operatingsystem.rb native fact with executable fact to workaround https://tickets.puppetlabs.com/browse/FACT-1528 (ace13)
2016-10-16 Release 0.3.0
- Add
entropy_repo
type to enable/disable repositories - Add
entropy_repos
fact
2016-10-13 Release 0.2.0
- Add
locale
fact - Remove obsolete
has_entropy
fact - Improve
entropy
package provider to set locale envvar directly and not shell out to a distributed script to set locale.
2016-10-13 Release 0.1.2
- Improved package regexes for valdiation and parsing (now following the Gentoo EAPI6 PMS document to ensure correctness)
- Removed validation for required parameters in
entropy_*
types
2016-10-13 Release 0.1.0
- Added support for additional types:
entropy_splitdebug
entropy_splitdebug_mask
entropy_keywords
- Added spec tests for most types and providers
2016-10-10 Release 0.0.2
- First forge release
Copyright (c) 2016 Ben Roberts Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.