https://github.com/ema/pets
A configuration management system for Pets, not Cattle
https://github.com/ema/pets
configuration linux
Last synced: about 1 month ago
JSON representation
A configuration management system for Pets, not Cattle
- Host: GitHub
- URL: https://github.com/ema/pets
- Owner: ema
- License: mit
- Created: 2022-10-21T08:22:10.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2023-06-03T11:49:42.000Z (almost 2 years ago)
- Last Synced: 2024-08-01T21:47:00.379Z (10 months ago)
- Topics: configuration, linux
- Language: Go
- Homepage:
- Size: 725 KB
- Stars: 461
- Watchers: 7
- Forks: 9
- Open Issues: 4
-
Metadata Files:
- Readme: README.adoc
- License: LICENSE
Awesome Lists containing this project
- awesome-github-repos - ema/pets - A configuration management system for Pets, not Cattle (Go)
README
= PETS
image:https://github.com/ema/pets/actions/workflows/go.yml/badge.svg[link="https://github.com/ema/pets/actions/workflows/go.yml"]
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)
- Arch Linux (Pacman, yay)
== Summary
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
ema ALL=(ALL:ALL) NOPASSWD:ALL
----
== Usage
Build and install pets with:
----
$ go install github.com/ema/pets@latest
----
The following options are supported:
----
$ pets -h
Usage of ./pets:
-conf-dir string
Pets configuration directory (default "/home/ema/pets")
-debug
Show debugging output
-dry-run
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 https://github.com/ema/pets/tree/master/sample_pet[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.
image::design.png[]
== 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
----
== Examples
=== Firewall
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
----
== Reception
Pets was featured https://news.ycombinator.com/item?id=33414338[on Hacker News]
and https://lobste.rs/s/jc2oru/configuration_management_system_for[on
Lobsters].
The author of Chef started
https://twitter.com/adamhjk/status/1587169750249271296[an interesting Twitter
thread] about Pets too.