A configuration management system for Pets, not Cattle

  • By Emanuele Rocca
  • Last update: Jan 5, 2023
  • Comments: 5



A Configuration Management System for computers that are Pets, not Cattle.

This is for people who need to administer a handful of machines, all fairly different from each other and all Very Important. Those systems are not Cattle! They’re actually a bit more than Pets. They’re almost Family. For example: a laptop, workstation, and that personal tiny server in Sweden. They are all named after something dear.

pets works on Linux systems. The following distro families are supported:

  • Debian-like (APT)

  • RedHat-like (YUM)

  • Alpine (APK)


Pets is the first configuration management system driven by comments embedded in the config files themselves, rather than by a domain-specific language (DSL). For example, say you want to ensure that user "ema" has sudo rights. Create a file with the following contents under $HOME/pets/, run pets as root, done. The file can be called whatever you want. Note that pets will install the sudo package for you if missing.

# pets: destfile=/etc/sudoers.d/ema, owner=root, group=root, mode=0440
# pets: package=sudo
# pets: pre=/usr/sbin/visudo -cf



Build and install pets with:

$ go install github.com/ema/[email protected]

The following options are supported:

$ pets -h
Usage of ./pets:
  -conf-dir string
        Pets configuration directory (default "/home/ema/pets")
        Show debugging output
        Only show changes without applying them

Let’s say you’ve decided to put your configuration files under /etc/pets. The system can then be used with:

# pets -conf-dir /etc/pets

See sample_pet for a basic example of what your /etc/pets can look like. Note that directory structure is arbitrary, you can have as many directories as you want, call them what you want, and so on.

Design overview

The idea behind Pets is that Configuration Management of individual hosts shouldn’t be harder than administering the system by hand. Other configuration management tools typically focus on usage scenarios involving complex relationships between multiple, fairly homogeneous systems: for example, setting up a bunch of application servers behind a load-balancer, or configuring a database and its replicas. For that you need a templating language, some way to store and share information about the various systems, and a way to either push the changes to all hosts or pull them from a central location. All that complexity can discourage from using a configuration management tool to begin with: why bother with Chef syntax and ERB templates if you just need to edit a few files?

Pets instead focuses on the individual, local machine. No need to ssh anywhere, no puppetmaster to configure, nada. It works by reading your regular, static configuration files (say muttrc) with added pets modelines, inspired by the concept of vim modelines. Pets can copy your configuration files to the right place, fix permissions, install packages, and run commands upon file update.

Following from this basic idea, here are the design decisions:

  • Runs locally on a single machine

  • One directory holds the full configuration of the system

  • No variables, no templates, just plain static config files

  • No dependencies between different components (eg: updating file A if and after file B was updated)

  • A single one-shot program reading the configuration directory and applying changes

  • Changes are applied only if basic syntax checks pass

  • Main interaction mechanism inspired by vim modelines

Here’s the initial design document in all its beauty. Ignore the "watcher" part, that was before I settled on a one-shot approach.


Configuration directives

  • destfile — where to install this file. One of either destfile or symlink must be specified.

  • symlink — create a symbolic link to this file, instead of copying it like destfile would.

  • owner — the file owner, passed to chown(1)

  • group — the group this file belongs to, passed to chgrp(1)

  • mode — octal mode for chmod(1)

  • package — which package to install before creating the file. This directive can be specificed more than once to install multiple packages.

  • pre — validation command. This must succeed for the file to be created / updated.

  • post — apply command. Usually something like reloading a service.

Configuration directives are passed as key/value arguments, either on multiple lines or separated by commas.

# pets: package=ssh, pre=/usr/sbin/sshd -t -f

The example above and the one below are equivalent

# pets: package=ssh
# pets: pre=/usr/sbin/sshd -t -f



Say you want to configure the local firewall to drop all incoming traffic except for ssh? Here’s an example that does the following:

  • Installs ferm if missing

  • Validates the configuration with /usr/sbin/ferm -n

  • If the configuration is valid, copies it under /etc/ferm/ferm.conf

  • Reloads the firewall rules with systemctl reload

# pets: destfile=/etc/ferm/ferm.conf, owner=root, group=root, mode=644
# pets: package=ferm
# pets: pre=/usr/sbin/ferm -n
# pets: post=/bin/systemctl reload ferm.service

domain (ip ip6) {
    table filter {
        chain INPUT {
            policy DROP;

            # connection tracking
            mod state state INVALID DROP;
            mod state state (ESTABLISHED RELATED) ACCEPT;

            # allow local packets
            interface lo ACCEPT;

            # respond to ping
            proto icmp ACCEPT;

            # allow SSH connections
            proto tcp dport ssh ACCEPT;

        chain OUTPUT {
            policy ACCEPT;

        chain FORWARD {
            policy DROP;

SSH Server

# pets: destfile=/etc/ssh/sshd_config, owner=root, group=root, mode=0644
# pets: package=ssh
# pets: package=openssh-client-dbgsym
# pets: pre=/usr/sbin/sshd -t -f
# pets: post=/bin/systemctl reload ssh.service
# Warning! This file has been generated by pets(1). Any manual modification
# will be lost.

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

X11Forwarding yes

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes


Pets was featured on Hacker News and on Lobsters.

The author of Chef started an interesting Twitter thread about Pets too.




  • 1

    Fix failing test for alpine

    Hi! This an attempt to fix fling tests for alpine. I made path to coreutls bin configurable that resolved some issues with chmod/chown , however one test still fails, please see - https://ci.sparrowhub.io/report/1781

    18:32:23 :: === RUN   TestIsNotInstalled
    18:32:23 :: 2022/11/15 18:32:23 [ERROR] running /sbin/apk info -qe astroid: 'exit status 1'
    18:32:23 ::     util.go:79: true != false
    18:32:23 :: --- FAIL: TestIsNotInstalled (0.06s)

    And I don't now why, code of package.go should return false, but it seems it returns true:


    	if family == APK {
    		installed := NewCmd([]string{"apk", "info", "-qe", string(pp)})
    		_, _, err := RunCmd(installed)
    		if err != nil {
    			log.Printf("[ERROR] running %s: '%s'\n", installed, err)
    			return false
    		return true
  • 2

    Awesome project


    Originally I wanted to send you an email, but I couldn't find a way of contacting you except twitter (which I don't have/use). Hence, the dirty message in ticket approach.

    The thing is, that I'm currently in the design phase of a tool that has the exact same use-case.

    My plan was to meet up with a good friend in a few days to verify the design. Imagine my astonishment when he sent me your project this morning :D. At this point, I want to say that I really like the name of the project.

    What was most surprising is that you went with a few core design decisions I was keen on using, but really wasn't sure about:

    • In file configuration
    • The one directory per system rule
    • No inter-file dependencies I guess those cannot be too much of a bad idea then.

    From here on, the design starts to differs quite a bit though. I planned to have the configuration for various different systems in the same directory, including a way to have a "base" configuration that's shared for all systems. My plan was also to go with templating (at least for those "base" files), even though I'm not yet sure how to inject variables in a nice way.

    From what I understand, your plan is to keep this project rather minimalistic (which I respect a lot) and stick to your design decisions.

    If that's the case, I'll probably continue building my project as planned :). I just wanted to tell you aren't the only one that's annoyed by the current PC configuration situation :D.

    Best regards,

    Arne Beer

  • 3

    Support for symlinking files

    Great project.

    If files could be symlinked rather then moved itd be great for combining with a dot files git repo or for more easily managing config files without needing to run the command every time you change a file

  • 4

    Usage exmaple?

    I red through the Readme and got some understanding on what it is supposed to do. But I have no clue about how to run it or how my folder structure would look like etc. Some usage example could help

  • 5

    A bit more examples

    Is it possible to add more examples? For example, I would like to see if PETS can replace my Ansible stuff on my home server. I have runbooks for this:

    • Install packages, set config
    • Install docker, put docker-compose files in place
    • Add stuff to crontab
    • Create symlinks to my dotfiles
    • Add samba mounts
    • Install and config ssmtp
    • etc