Chef cookbook sys

Description

The "sys" cookbook helps integrating a (Debian) node into an enterprise computing infrastructure. It configures various services in a single cookbook eg. apt repositories, automount, NTP, IPMI BMCs, postfix, SNMP, aso. But it concentrates on client setup and does not configure the respective central services.

Requirements

• Chef version >= 12
• The chef-vault cookbook

Platforms

The "sys" cookbook development is focussed on Debian GNU/Linux.kitch Debian derivatives as Ubuntu usually work (with minor tweaks).

• Supported flavors:
  • Debian
    • 7 (Wheezy) (with Chef client > 12.0) [deprecated]
    • 8 (Jessie) (with Chef client > 12.0) [deprecated]
    • 9 (Stretch) (with Debian-packaged Chef client 12.14)
    • 10 (Buster) (with Debian-packaged Chef client 13.8)
    • 11 (Bullseye) (with Cinc client <= 18)
  • Ubuntu
    • 18.04 (Bionic) (with Ubuntu-packaged Chef client 12.14)
    • 20.04 (Focal) (with Ubuntu-packaged Chef client 15.8)

The sys cookbook is partially operable and occassionally tested with Debian Testing as well as CentOS7, CentOS Stream 8, Alma Linux 8 and Cumulus Linux.

Usage

The "sys" cookbook can be added to a nodes run-list anytime. By default the cookbook does not deploy or configure anything. The individual recipes are only activated by defining the corresponding attributes.

The sys_* resources can be invoked directly from wrapper cookbooks.

Recipes

• apt – Configure APT in /etc/apt/apt.conf.d/, set APT preferences in /etc/apt/preferences.d, define package repositories in /etc/apt/sources.list.d and manage the APT keyring.
• autofs – Setup automatic mounting of NFS servers in /etc/auto.master.d/. Supports setup to read automounter maps from LDAP.
• banner – Sets a welcome message displayed at login.
• boot – Set Grub boot parameters in /etc/default/grub.
• control (sysctl) – Define kernel variables in /etc/sysctl.d/.
• directory – Provides an attribute interface to the directory resource.
• fuse – Setup FUSE in /etc/fuse.conf.
• hosts – Local /etc/hosts, /etc/hosts.allow, and /etc/hosts.deny configuration.
• krb5 – Use Kerberos to manage credential security (authentication).
• ldap – Connect to a local LDAP account management (authorization) by configuring /etc/ldap/ldap.conf.
• modules – Load kernel modules.
• network – Setup the local network in /etc/network/interfaces.d/.
• nis – Connect to local NIS servers by configuring /etc/yp.conf.
• nsswitch – Manage /etc/nsswitch.conf.
• mail – Forward mails to an mail relay with Postfix.
• pam – Configure the authentication modules in /etc/pam.d/.
• resolv – Adjust /etc/resolve.conf to lookup at your site DNS server.
• route – Configure routeing by attributes.
• serial – Configure /etc/inittab.
• ssh – Configure the SSH daemon and deploy/manage authorized keys.
• ssl – Distribute SSL certs and keys via data bags and chef-vault.
• sudo – Add Sudo privileges to /etc/sudoers.d/.
• time – Connect to site NTP server and set local time zone.
• tmp – Deploy Tmpreaper to clean directories like /tmp/.

Resources

• nftables
• nftables_rule
• sys_x509_certificate
• sys_ca_certificates – Install/remove CA certificates.
• sys_shutdown – Resource to restart and power down the node at a defined time.

Library

The Sys::Secret enables transport of encrypted data between nodes using the private/public key infrastructure of Chef. This functionality is deprecated in favor of chef-vault.

Motivation

Why writing a cookbook like "sys"?

The general philosophy for writing cookbooks is to implement a specific service (e.g. Syslog, SNMP, OpenSSH, NTP) or system component (e.g. PAM, Sudo, Limits) within a single cookbook. For a community cookbook, where it is the goal to be platform independent, as generic as possible and cross-infrastructure sharable, this makes absolute sense. Unfortunately this approach in the most cases leads to a very complex dependency hierarchy with roles including dozens of cookbooks (with specific version) and a deep attributes structure, just to integrate a node into your environment. The "sys" cookbook is basically the opposite approach, implement everything for a basic integration of a node into the site infrastructure within a single cookbook. As soon as a node is integrated by the "sys" cookbook only a very limited number of cookbooks should be required to deploy the service the machine is intended to host.

Focus on the Client-Side

For example the "sys" cookbook is capable to deploy a mail relay configuration in order to enable all machines part of the infrastructure to send mails to an MTA. Get the right package and do minor changes to the configuration. Very easy, a couple of lines of code. This means 99% of all nodes will never see a dedicated cookbook related to mail. In order to deploy an MTA server a Postfix/Sendmail cookbook will be needed, but only on a handful of nodes. This approach is different to almost all Chef cookbooks you will find out there. Server and client deployment is usually within a single cookbook, and this is the right way to implement it (from a single cookbook's perspective). Mostly 90% (if not more) of the code part of a cookbook used to deploy a service is dedicated to the server side. Many services common in bigger computing infrastructures like NIS/LDAP, Mail, DNS, Samba, NFS, etc. have very complex server-side configuration, and logically nearly trivial client side setup. The "sys" cookbook approach removes dependencies to cookbooks including the server deployment.

Minimize Dependencies

Cookbooks like timezone,resolv or ntp consist of a single recipe with a handful of attributes. The "sys" cookbook approach wants to remove dependencies to trivial cookbooks for simplicity. More complex cookbooks for system component configurations like PAM or Sudo have a light-weight implementation in the "sys" cookbook also. Since in big clusters these things tend to be relatively homogeneous for the majority of machines and tend to be more comprehensive on a small number of user-facing nodes.

Design Principles

1. Reduce cookbook dependencies to one for the integration of all nodes into the environment on a site.
2. No changes by default! This means unless attributes are set, no deployment and configuration happens. Lets say the boot configuration which the "sys" cookbook is capable of deploying with attributes in node.sys.boot doesn't match the needs for a specific node, you are still free to use a more general grub cookbook or even a site-grub cookbook.
3. The "sys" cookbook doesn't deploy the server-side of services. It configures a node to use a mail relay, but doesn't install a mail-server.
4. The name of a definition is prefixed with sys_ to prevent name space collision with other cookbooks.
5. Attributes defined with default_unless in the attributes/ directory.

Authors

• Sergey Boldyrev
• Matteo Dessalvi
• Stefan Haller
• Christopher Huhn
• Gabriele Iannetti
• André Kerkhoff
• Dennis Klein
• Ilona Neis
• Bastian Neuburger
• Matthias Pausch
• Victor Penso
• Thomas Roth
• Christian Tacke

Copyright and License

Copyright:: 2012-2022 GSI Helmholtzzentrum fuer Schwerionenforschung GmbH

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.