The "sys" cookbook helps integrating a (Debian) node into a computing site. It configures various services in a single cookbook eg. apt repositories, automount, NTP, IPMI BMCs, postfix, SNMP, aso. But it concentrates on the client side and does not configure the respective central services.
- Chef version >= 10.12
- No dependencies to other cookbooks.
The "sys" cookbook development is focussed on Debian GNU/Linux. Debian derivatives as Ubuntu probably work with minor tweaks but are untested.
- Supported flavors: Debian Wheezy and Jessie and partially Squeeze
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.
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.
- Reduce cookbook dependencies to one for the integration of all nodes into the environment on a site.
- 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.bootdoesn't match the needs for a specific node, you are still free to use a more general
grubcookbook or even a
- 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.
- The name of a definition is prefixed with
sys_to prevent name space collision with other cookbooks.
- Attributes defined with
The "sys" cookbook can be added to a nodes run-list anytime. By default the cookbook doesn't deploy or configures anything. The individual recipes will be automatically applied when the corresponding attributes are defined or the
sys_* resources are called.
- 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.dand manage the APT keyring.
- autofs – Setup automatic mounting of NFS servers in
- banner – Sets a welcome message displayed at login.
- boot – Set Grub boot parameters in
- ca_certificates – Install/remove CA certificates.
- cgroups – Define
/etc/cgconfig.confand load sub-systems.
- directories – Provides an attribute interface to the directory resource.
- fuse – Setup FUSE in
- hosts – Local
- interfaces – Setup the local network in
- krb5 – Use Kerberos to manage credential security (authentication).
- ldap – Connect to a local LDAP account management (authorization) by configuring
- modules – Load kernel modules.
- nis – Connect to local NIS servers by configuring
- nsswitch – Overwrite
- mail – Forward mails to an mail relay with Postfix.
- pam – Configure the authentication modules in
- resolv – Adjust
/etc/resolve.confto lookup at your site DNS server.
- route – Configure routeing by attributes.
- serial – Configure
- shutdown – Resource to restart and power down the node at a defined time.
- ssh – Configure the SSH daemon and deploy/manage authorized keys.
- sudo – Add Sudo privileges to
- sysctl (
sysctl) – Define kernel variables in
- time – Connect to site NTP server and set local time zone.
- tmp – Deploy Tmpreaper to clean directories like
Sys::Secret enables transport of encrypted data between nodes using the private/public key infrastructure of Chef.
Author:: Bastian Neuburger
Author:: Christopher Huhn
Author:: Dennis Klein
Author:: Matthias Pausch
Author:: Victor Penso
Copyright:: 2012-2013, GSI HPC Department
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
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.