]> ruderich.org/simon Gitweb - safcm/safcm.git/blob - README.adoc
go fmt
[safcm/safcm.git] / README.adoc
1 = README
2
3 Simple and fast configuration management (safcm) is written in Go and licensed
4 under GPLv3+. It is:
5
6 - *simple*: to use and implement, obvious concepts and less bugs
7 - *fast*: to learn and to use, quickly apply new configurations to your hosts
8 - *configuration management*: sync files, packages, services and run commands
9   on remote hosts
10
11 The goal is that even unexperienced users (with safcm or configuration
12 management in general) should be able to apply configuration with safcm
13 quickly. This means all key concepts of safcm must be easy to grasp and for
14 each task there should be one obvious way.
15
16 It can also be read as "saf(e) configuration management" as it combines
17 simplicity and safety in the following principles:
18
19 - *fail fast*: catch (user) errors as soon as possible; host configuration
20   (including templates) is evaluated locally to prevent partial configuration;
21   errors immediately abort the synchronization
22 - *remote hosts are untrusted*: clear security boundary between local and
23   remote host; data used from remote hosts is marked tainted (detected
24   groups); all output from remote hosts is escaped to prevent terminal
25   injection attacks; each host only receives its own configuration and no data
26   from other hosts
27 - *safety and security*: create files with "write to temporary file", "sync",
28   "rename", "sync directory" for atomicity and durability; guard against
29   symlink and other TOCTOU attacks; extensive test suite
30
31
32 == Overview
33
34 This section describes the general concepts, behavior and terminology of
35 safcm.
36
37 Safcm _synchronizes_ _files_, _packages_, _services_ and _commands_ to remote
38 _hosts_. All hosts are explicitly configured. Hosts can be put into _groups_
39 to apply the same configuration to multiple hosts. The host itself is also
40 considered a group for host-specific configuration. In addition to manual
41 group assignment _detected groups_ assign hosts to groups depending on the
42 output of custom commands on the remote host. The configuration for a group
43 contains the files, packages, services and commands which should be applied to
44 all hosts which are members of this group.
45
46 The configuration of all managed hosts is stored in a directory on the local
47 host. Safcm uses https://yaml.org/[YAML] for all configuration files. Strict
48 type checks prevent potential pitfalls due to the complex YAML syntax. Tasks
49 like copying a file require no explicit configuration.
50
51 Files (regular files and symbolic links) and directories, including
52 permissions, user/group and content are kept in a regular filesystem tree on
53 the local host. Files can use _templates_ for dynamic content depending on the
54 host or its groups. Each path can have _trigger_ commands which are executed
55 when the path itself or any sub-paths are modified during synchronization.
56 Packages are package names of the remote operating system. Services are
57 service names of the remote operating system. Commands are shell commands
58 passed to `/bin/sh`.
59
60 When files with the same path are present in multiple groups of a host, an
61 explicit _group priority_ must be configured to resolve the conflict.
62 Conflicts do not apply to packages and services which are simply merged from
63 all groups. Commands are appended so that the same command can be executed
64 multiple times.
65
66 To sync the configuration to a remote host, the local `safcm` binary connects
67 to it via `ssh`. It then copies a _remote helper_ binary to `/tmp` on the
68 remote host to perform the actual sync later. If the remote helper is already
69 present, has the proper checksum, permissions and user/group then the copying
70 step is skipped. `safcm` then queries the remote host for information,
71 including operating system, architecture and detected groups. With all
72 relevant data collected, it assigns the host to its groups, evaluates the
73 configuration including templates and finally sends the new configuration to
74 the remote helper which then applies it to the remote host.
75
76 The synchronization happens in the following order which cannot be changed:
77
78 . Collect information from remote helper including detected groups
79 . Build configuration for the host and send it to the remote helper
80 . Apply the configuration using the remote helper
81 .. Synchronize files
82 .. Install packages
83 .. Enable/Start services
84 .. Run triggers
85 .. Run commands
86
87 After the synchronization is complete (or on the first error) the applied
88 changes are displayed. Multiple hosts are synchronized in parallel.
89
90
91 == Limitations & Gotchas
92
93 Besides some obvious limitations due to the simplicity of safcm there are a
94 few issues the user should be aware of. Some of these might get fixed in the
95 future, others are due to the design of safcm.
96
97 - Commands are executed with `/bin/sh -c` on the remote host which might leak
98   sensitive information to other users via the command line (unless `/proc` is
99   mounted with `hidepid=`). Store sensitive data in a file and execute or
100   source it as a workaround.
101
102 - Permissions of existing files and directories will be overwritten with the
103   default (root/root, 0644 for files, 0755 for directories) unless manually
104   configured via `permissions.yaml`. This includes important paths like
105   `/root` which often have strict permissions by default, so carefully check
106   the diff output for unwanted changes.
107
108 - The full file content of all files is sent to the remote during
109   synchronization. This makes it impractical to synchronize large files with
110   safcm. Since most configuration files are small this shouldn't be an issue
111   for common scenarios.
112
113 - Quoted strings in the output are quoted using Go's `%q` format string. The
114   result is similar -- but not identical -- to quoted strings in regular shell
115   scripts which can be confusing.
116
117 - Permissions of symlinks are ignored on BSD systems. They are always shown to
118   have `0777` as permissions even though the current umask controls the actual
119   permissions when creating new symlinks. Existing symlinks with different
120   permissions are not updated. Most BSDs ignore the permissions when following
121   symlinks which should reduce the impact of this limitation.
122
123
124 == Requirements
125
126 - to build the `safcm` binary and remote helper:
127   * Go >= 1.16
128   * GNU make
129
130 - local host:
131   * Go support for architecture and operating system, see the "$GOOS and
132     $GOARCH" section in the official
133     https://golang.org/doc/install/source#environment[Go installation guide]
134
135 - *remote hosts*:
136   * Go support for architecture and operating system
137   * Supported operating system:
138     ** GNU/Linux with common commands (`uname`, `id`, `stat`, `sha512sum`,
139        `cat`, `mktemp`, `rm`, `ln`, `chmod`)
140     ** FreeBSD (same commands, but uses `sha512`)
141     ** OpenBSD (same commands, but uses `sha512`)
142   * SSH server
143   * to install packages:
144     ** `apt-get` (Debian or derivative)
145   * to sync services:
146     ** `systemd`
147
148 Adding support for other operating systems (e.g. BSDs) or distributions
149 including package managers (e.g. Arch, Gentoo) is easy. Please send patches.
150
151
152 == Authors
153
154 Written by Simon Ruderich <simon@ruderich.org>.
155
156
157 == License
158
159 This program is licensed under GPL version 3 or later.
160
161 Copyright (C) 2021  Simon Ruderich
162
163 This program is free software: you can redistribute it and/or modify
164 it under the terms of the GNU General Public License as published by
165 the Free Software Foundation, either version 3 of the License, or
166 (at your option) any later version.
167
168 This program is distributed in the hope that it will be useful,
169 but WITHOUT ANY WARRANTY; without even the implied warranty of
170 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
171 GNU General Public License for more details.
172
173 You should have received a copy of the GNU General Public License
174 along with this program.  If not, see <http://www.gnu.org/licenses/>.