The Tiny Configuration Manager

This is a very small configuration management tool for when you need Puppet but for a way smaller deployment.

Full docs are available at https://pythonhosted.org/tinycm/

Installing

The easy global install with global python packages:

$ pip3 install tinycm

In a seperate python environtment

$ virtualenv -p /usr/bin/python3 /usr/local/share/tinycm
$ /usr/local/share/tinycm/bin/pip3 install tinycm
$ ln -s /usr/local/share/tinycm/bin/tinycm /usr/local/bin/tinycm

Configuration format

This tool doesn't use a special DSL for defining your configuration. Just plain old YAML. Configuration manifests are saved as a somename.cm.yml file and importable modules are somemodule.mod.yml. The configuration files cannot contain any executable code but mode complicated definitions can be created as python modules.

host:
  - filter: .*\.office\.example\.com
    constants:
      nameserver1: 10.0.0.1
      nameserver2: 10.0.0.2

global:
  nameserver1: 8.8.8.8
  nameserver2: 8.8.4.4
plugins:
  - vim
---
# Install vim and create a sane basic config in /etc/vim/vimrc.local
vim:
  name: global
  is-global: true
  ensure: exists
---
package:
  name:
    - vim
    - htop
  ensure: installed
---
file:
  name: /etc/resolv.conf
  contents: |
    # managed by TinyCM
    nameserver {nameserver1}
    nameserver {nameserver2}
  type: constant
  interpolate: true

Every definition is a seperate yaml document with a single object in it except the first document. The first document contains some global config for the manifest.

In the global: dictionary you can define constants to be used in various places in the definition. The host: list specifies overrides to the global constants based on a filter regex.

The host: list doesn't define groups of definitions like puppet, even if none of the filters in the host list matches every definition is executed, it is only for overriding constants for specific hosts.

One mayor difference between TinyCM is that is supports duplicate definitions. If two modules contain a definition for package::apache2 then those definitions will be merged in the parsing stage. Every definition type has it's own logic for merging. The package type will merge almost always except when one package has ensure: installed and one has ensure: removed. If one of the definitions is unmergeable then and exception will be thrown and the apply/verify process will stop.

Manifest loading

TinyCM doesn't have any ca-certificate-client-certificate-signing stuff like Puppet for linking an agent with a master server. It can run in standalone mode by specifying a local manifest file (and possibly a module include path). Or can specify an URL for a remote manifest. The module include path can also be on a remote URL so you can store your modules on a central server.

This makes it easy to run TinyCM standalone or with a task runner like ansible.

Starting a job

TinyCM doesn't run as a daemon. You can start it manually or run it automatically through cron.

The only required parameter for running TinyCM is a path to a local or remote manifest file:

$ tinycm http://some.server.somewhere.com/manifests/cool-name.cm.yml

This will download the manifest and verify it (no changes to the server). If any module is specified it will be loaded from http://some.server.somewhere.com/manifests/{module-name}.mod.yml

To actually make changes to your server you need to add the --apply flag:

$ tinycm --apply /path/to/manifest.cm.yml

If you want to specify a specific hostname:

$ tinycm --hostname laptop.domain.com --apply /path/to/manifest.cm.yml