Forge Home

Modules

Puppet

Resources

PuppetEcosystemPuppet CommunityUpdates

sssd

Manage sssd at once or incrementally
Project URLRSS FeedReport issues

1,288 downloads

551 latest version

5.0 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

  • 0.1.2 (latest)
  • 0.1.1
  • 0.1.0
released Jul 6th 2022
This version is compatible with:
  • Puppet Enterprise 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x
  • Puppet >= 6.21.0 < 8.0.0
  • , , , ,

Start using this module

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

Add this module to your Puppetfile:

mod 'jcpunk-sssd', '0.1.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add jcpunk-sssd
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install jcpunk-sssd --version 0.1.2

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

Documentation

jcpunk/sssd — version 0.1.2 Jul 6th 2022

sssd

Why this SSSD module, when there are so many others on the forge?

This is a minimalist SSSD module that supports incrementally building the config (via /etc/sssd/conf.d) or setting it all at once.

Table of Contents

  1. Description
  2. Setup - The basics of getting started with sssd
  3. Usage - Configuration options and additional functionality
  4. Limitations - OS compatibility, etc.
  5. Development - Guide for contributing to the module

Description

Manage the SSD package, config, and services. You can manage some or all of these elements. Additionally you can build the SSSD config incrementally via either the $configs parameter or by calling the sssd::config defined type yourself.

Setup

Beginning with sssd

Simply including the class is enough to get the packages and services. If you want any running authentication domains, you'll need to add those. Examples are included in the Usage section.

Usage

The two parameters you probably care most about are $main_config and $configs.

The key thing to remember is if a domain is not listed within

[sssd]
domains=XXXXXXXXXXX

It will not be consulted. So when dropping in overrides make sure to set the domain as you want it.

NOTE: sssd does not merge the config elements. An override from inside /etc/sssd/conf.d/*.conf will REPLACE the entry defined earlier. If you are defining domains somewhat dynamically, you'll need to get that sorted out.

main_config

This is a hash that gets mapped directly into /etc/sssd/sssd.conf (or your $main_config_file)

The "value" entries can be either a String or an Array. In the case of an Array, the content will be automatically joined with a ', ' in your config file. This should let you merge and knockout elements as needed and possibly have cleaner looking formatting.

class { 'sssd':
  main_config => {
    sssd => {
      'setting' => ['value', 'a']
    },
    pam => {
      'setting' => 'value, a'
    },
    nss => {
      'setting' => 'value'
    },
    sudo => {
      'setting' => 'value'
    },
    domain/a => {
      'setting' => 'value'
    },
    domain/b => {
      'setting' => 'value'
    },
  }
}

or in hiera

sssd::main_config:
  sssd:
    setting:
      - value
      - a
  pam:
    setting: 'value, a'
  nss:
    setting: value
  sudo:
    setting: value
  'domain/a':
    setting:value
  'domain/b':
    setting:value

These will produce

[sssd]
setting=value, a
[pam]
setting=value, a
[nss]
setting=value
[sudo]
setting=value
[domain/a]
setting=value
[domain/b]
setting=value

configs

Items in the $configs hash are passed directly into the sssd::config defined type.

Their structure is basically the same as main_config, but with one extra layer of nesting.

sssd::main_config:
  sssd:
    setting:
      - value
      - a
  pam:
    setting: 'value, a'
sssd::configs:
  'override sssd':
    filename: example.conf
    stanzas:
      sssd:
        setting:
          - value
          - b
  override_pam:
    stanzas:
      pam:
        debug: 0

This will produce the $main_config in /etc/sssd/sssd.conf and extra configs in /etc/sssd/conf.d containing the stanzas defined under each title.

# /etc/sssd/sssd.conf
[sssd]
setting=value, a
[pam]
setting=value, a

#/etc/sssd/conf.d/example.conf
[sssd]
setting:value, b

#/etc/sssd/conf.d/50-pam.conf
[pam]
debug=0

Limitations

This module specifically does not manipulate files or services that do not belong to sssd. There are other modules on the forge that can configure pam/authselect and oddjob/login.defs.

If you want to manipulate the sssd startup units, I'd recommend the systemd::dropin features from puppet-systemd

SSSD makes use of inotify to watch some files. The inotify appears to run with all permissions dropped, so non-world accessible files cannot be watched.

Development

Hop on over to the git repo listed in metadata.json