Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

Select Status

RSS

O1-systemd (4) Versions 0.1.3

Chef cookbook that installs and configures Systemd units: system components and services managed by the Linux systemd system/service manager.

Policyfile
Berkshelf
Knife
cookbook 'O1-systemd', '~> 0.1.3', :supermarket
cookbook 'O1-systemd', '~> 0.1.3'
knife supermarket install O1-systemd
knife supermarket download O1-systemd
README
Dependencies
Quality 33%

<p><img src="https://siliconangle.com/wp-content/blogs.dir/1/files/2018/02/1486909_635690216474466_54627279_n.png" alt="ansible logo" title="ansible" align="left" height="80" /></p>
<p><img src="https://www.servethehome.com/wp-content/uploads/2017/11/Redhat-logo.jpg" alt="redhat logo" title="redhat" align="right" height="60" /></p>

Chef Cookbook:vertical_traffic_light:Systemd

Cookbook Version
GitHub release (latest by date)
Build Status
License: MIT

Table of Contents
- Supported Platforms
- Requirements
- Role Variables
- Install
- Config
- Dependencies
- Example Playbook
- License
- Author Information

Chef cookbook that installs and configures Systemd units: system components and services managed by the Linux systemd system/service manager.

Supported Platforms:
* Debian
* Redhat(CentOS/Fedora)
* Ubuntu

Requirements

systemd is generally considered the de-facto service management tool for Linux distributions and should be included with most OS installations. While typically not a concern, it may be worth noting that Linux kernel >= 3.13 is required by systemd and Linux kernel >= 4.2 is necessary for unified cgroup hierarchy support.

Reference the systemd README for further details.

Role Variables

Variables are available and organized according to the following software & machine provisioning stages:
* install
* config

Install

The following variables can be customized to control various aspects of installation of individual systemd units. It is assumed that the host has a working version of the systemd package. Available versions based on OS distribution can be found here.

[unit_configs: <config-list-entry>:] path: (default: <string> /etc/systemd/system)
- load path to systemd unit configuration.

In addition to /etc/systemd/system (default), unit configs and associated drop-in ".d" directory overrides for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories.

Files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in. See table below and consult systemd(1) for additional details regarding path load priority.

Load paths when running in **system mode** (--system)

Unit Load File Path Description
/etc/systemd/system Local configuration
/run/systemd/system Runtime units
/usr/local/lib/systemd/system Units installed for local system administration
/usr/lib/systemd/system Units of installed packages

Load paths when running in **user mode** (--user)

Unit Load File Path Description
$XDG_CONFIG_HOME/systemd/user or $HOME/.config/systemd/user User configuration ($XDG_CONFIG_HOME is used if set, ~/.config otherwise)
/etc/systemd/user User units created by the administrator
$XDG_RUNTIME_DIR/systemd/user Runtime units (only used when $XDG_RUNTIME_DIR is set)
/run/systemd/user Runtime units
$dir/systemd/user for each $dir in $XDG_DATA_DIRS Additional locations for installed user units, one for each entry in $XDG_DATA_DIRS
/usr/local/lib/systemd/user User units installed for local system administration
/usr/lib/systemd/user User units installed by the distribution package manager

Example

 {
    "unit_configs": [
      {
        "name": "apache",
        "path": "/run/systemd/system",
        "Service": {
          "ExecStart": "/usr/sbin/httpd",
          "ExecReload": "/usr/sbin/httpd $OPTIONS -k graceful"
        },
        "Install": {
          "WantedBy": "multi-user.target"
        }
      }
    ]
 }

[unit_config: <config-list-entry>:] type: <string> (default: service)
- type of systemd unit to configure. There are currently 11 different unit types, ranging from daemons and the processes they consist of to path modification triggers. Consult systemd(1) for the full list of available units.

Example

 {
    "unit_configs": [
      {
        "name": "apache",
        "type": "socket",
        "Socket": {
          "ListenStream": "0.0.0.0:8080",
          "Accept": "yes"
        },
        "Install": {
          "WantedBy": "sockets.target"
        }
      }
    ]
 }

Config

Configuration of a systemd unit is declared in an ini-style config file. A systemd unit INI config is composed of sections: 2 common amongst all unit types (Unit and Install) and 1 specific to each unit type. These unit configurations can be expressed within the role's unit_config hash variable as lists of dicts containing key-value pairs representing the name, type, load path of the unit and a combination of the aforemented section definitions.

Each configuration section definition provides a dict containing a set of key-value pairs for corresponding section options (e.g. the ExecStart specification for a system or web service [Service] section or the ListenStream option for a web [Socket] section).

[unit_config: <list-entry>:] Unit | <unit-type e.g. Service, Socket, Device or Mount> | Install: <dict> (default: {})
- section definitions for a unit configuration

Any configuration setting/value key-pair supported by the corresponding Systemd unit type specification should be expressible within each unit_config collection and properly rendered within the associated INI config.

The following provides an overview and example configuration of each unit type for reference.

[Service]

Manages daemons and the processes they consist of.

Example

note: # path: /etc/systemd/system, type: service
```json
{
"unit_configs": [
{
"name": "example-service",
"Unit": {
"Description": "Sleepy Service",
},
"Service": {
"ExecStart": "/usr/bin/sleep infinity",
},
"Install": {
"WantedBy": "multi-user.target"
}
}
]
}

**[[Socket](http://man7.org/linux/man-pages/man5/systemd.socket.5.html)]**

Encapsulates local IPC or network sockets in the system.

#### Example

```json
 {
    "unit_configs": [
      {
        "name": "docker",
        "type": "socket",
        "Unit": {
          "Description": "Listens/accepts connection requests at /var/run/docker/sock (implicitly *Requires=* associated docker.service)",
        },
        "Socket": {
          "ListenStream": "/var/run/docker.sock",
          "SocketMode": "0660",
          "SockerUser": "root",
          "SocketGroup": "docker"
        },
        "Install": {
          "WantedBy": "sockets.target"
        }
      }
    ]
 }

[Mount]

Controls mount points in the sytem.

Example

 {
    "unit_configs": [
      {
        "name": "tmp_new",
        "type": "mount",
        "Unit": {
          "Description": "New Temporary Directory (/tmp_new)",
          "Conflicts": "umount.target",
          "Before": "local-fs.target umount.target",
          "After": "swap.target"
        },
        "Mount": {
          "What": "tmpfs",
          "Where": "/tmp_new",
          "Type": "tmpfs",
          "Options": "mode=1777,strictatime,nosuid,nodev:
        }
      }
    ]
 }

[Automount]

Provides automount capabilities for on-demand mounting of file systems as well as parallelized boot-up.

Example

 {
    "unit_configs": [
      {
        "name": "proc-sys-fs-binfmt_misc",
        "type": "automount",
        "Unit": {
          "Description": "Arbitrary Executable File Formats File System Automount Point",
          "Documentation": "https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html",
          "ConditionPathExists": "/proc/sys/fs/binfmt_misc/",
          "ConditionPathIsReadWrite": "/proc/sys/",
        },
        "Automount": {
          "Where": "/proc/sys/fs/binfmt_misc",
        }
      }
    ]
 }

[Device]

Exposes kernel devices and implements device-based activation.

This unit type has no specific options and as such a separate [Device] section does not exist. The common configuration items are configured in the generic [Unit] and [Install] sections. systemd will dynamically create device units for all kernel devices that are marked with the "systemd" udev tag (by default all block and network devices, and a few others). To tag a udev device, use TAG+="systemd in the udev rules file. Also note that device units are named after the /sys and /dev paths they control.

Example

# /usr/lib/udev/rules.d/10-nvidia.rules

SUBSYSTEM=="pci", ATTRS{vendor}=="0x12d2", ATTRS{class}=="0x030000", TAG+="systemd", ENV{SYSTEMD_WANTS}="nvidia-fallback.service"

# Will result in the automatic generation of a nvidia-fallback.device file with appropriate [Unit] and [Install] sections set

[Target]

Provides unit organization capabilities and setting of well-known synchronization points during boot-up.

This unit type has no specific options and as such a separate [Target] section does not exist. The common configuration items are configured in the generic [Unit] and [Install] sections.

Example

 {
    "unit_configs": [
      {
        "name": "graphical",
        "path": "/usr/lib/systemd/system",
        "type": "target",
        "Unit": {
          "Description": "Graphical Interface",
          "Documentation": "man:systemd.special(7)",
          "Requires": "multi-user.target",
          "Wants": "display-manager.service",
          "Conflicts": "rescue.service rescue.target",
          "After": "multi-user.target rescue.servie rescue.target display-manager.service",
          "AllowIsolate": "yes"
        }
      }
    ]
 }

[Timer]

Triggers activation of other units based on timers.

Example

 {
    "unit_configs": [
      {
        "name": "dns-makecache",
        "type": "timer",
        "Timer": {
          "OnBootSec": "10min",
          "OnUnitInactiveSec": "1h",
          "Unit": "dnf-mackecache.service"
        },
        "Install": {
          "WantedBy": "multi-user.target"
        }
      }
    ]
 }

[Swap]

Encapsulates memory swap partitions or files of the operating system.

Example

  # Ensure existence of swap file
  mkdir -p /var/vm
  fallocate -l 1024m /var/vm/swapfile
  chmod 600 /var/vm/swapfile
  mkswap /var/vm/swapfile

 {
    "unit_configs": [
      {
        "name": "var-vm-swap",
        "type": "swap",
        "Unit": {
          "Description": "Turn on swap for /var/vm/swapfile",
        },
        "Swap": {
          "What": "/var/vm/swapfile"
        },
        "Install": {
          "WantedBy": "multi-user.target"
        }
      }
    ]
 }

[Path]

Activates other services when file system objects change or are modified.

Example

 {
    "unit_configs": [
      {
        "name": "repository-code-coverage-analysis-trigger",
        "type": "path",
        "Unit": {
          "Description": "Activate code coverage analysis on modified git repositories",
        },
        "Path": {
          "PathChanged": "/path/to/git/repo",
          "Unit": "code-coverage-analysis.service"
        }
      }
    ]
 }

[Scope]

Manages a set of system or foreign/remote processes.

Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. Unlike service units, scope units manage externally created processes and do not fork off processes on their own. The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.

Example

 {
    "unit_configs": [
      {
        "name": "user-session",
        "type": "scope",
        "Unit": {
          "Description": "Session of user",
          "Wants": "user-runtime-dir@1000.service user@1000.service",
          "After": "systemd-logind.service systemd-user-sessions.service user-runtime-dir@1000.service user@1000.service",
          "RequiresMountsFor": "/home/user"
        },
        "Scope": {
          "SendSIGHUP": "yes",
          "TasksMax": "Infinity"
        }
      }
    ]
 }

[Slice]

Group and manage system processes in a hierarchical tree for resource management purposes.

The name of the slice encodes the location in the tree. The name consists of a dash-separated series of names, which describes the path to the slice from the root slice. By default, service and scope units are placed in system.slice, virtual machines and containers registered with systemd-machined(1) are found in machine.slice and user sessions handled by systemd-logind(1) in user.slice.

See systemd.slice(5) for more details.

Dependencies

None

Example Role definitions

default example (no custom unit configurations specified):
json
{
"systemd": {}
}

service/socket/mount pair:
json
{
"systemd":
{
"unit_configs": [
{
"name": "my-service",
"Unit": {
"After": "network-online.target",
"Wants": "network-online.target",
"Requires": "my-service.socket"
},
"Service": {
"User": "web",
"Group": "web",
"ExecStart": "/usr/local/bin/my_service $ARGS",
"ExecReload": "/bin/kill -s HUP $MAINPID"
},
"Install": {
"WantedBy": "multi-user.target"
}
},
{
"name": "my-service",
"type": "socket",
"Socket": {
"ListenStream": "0.0.0.0:4321",
"Accept": "true"
},
"Install": {
"WantedBy": "sockets.target"
}
},
{
"name": "var-data-my_service",
"type": "mount",
"path": "/run/systemd/system",
"Mount": {
"What": "/dev/nvme0",
"Where": "/var/data/my_service"
},
"Install": {
"WantedBy": "multi-user.target"
}
},
]
}
}

License

MIT

Author Information

This cookbook was created in 2020 by 0xO1.IO.

Dependent cookbooks

This cookbook has no specified dependencies.

Contingent cookbooks

There are no cookbooks that are contingent upon this one.

Collaborator Number Metric
            

0.1.3 failed this metric

Failure: Cookbook has 0 collaborators. A cookbook must have at least 2 collaborators to pass this metric.

Contributing File Metric
            

0.1.3 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a CONTRIBUTING.md file

Foodcritic Metric
            

0.1.3 passed this metric

No Binaries Metric
            

0.1.3 passed this metric

Testing File Metric
            

0.1.3 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a TESTING.md file

Version Tag Metric
            

0.1.3 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must include a tag that matches this cookbook version number