1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
Source: consfigurator
Section: admin
Priority: optional
Maintainer: Sean Whitton <spwhitton@spwhitton.name>
Build-Depends: debhelper-compat (= 13), texinfo, python3-sphinx, sphinx-common
Standards-Version: 4.5.1
Homepage: https://git.spwhitton.name/consfigurator/about/
Vcs-Git: https://git.spwhitton.name/consfigurator
Vcs-Browser: https://git.spwhitton.name/consfigurator
Rules-Requires-Root: no
Package: cl-consfigurator
Architecture: all
Depends: ${misc:Depends}, ${sphinxdoc:Depends}, cl-alexandria, cl-ppcre, cl-interpol
Recommends: sbcl
Description: Lisp declarative configuration management system
Consfigurator is a system for declarative configuration management using
Common Lisp. You can use it to configure hosts as root, deploy services as
unprivileged users, build and deploy containers, and produce disc images.
.
Consfigurator's design gives you a great deal of flexibility about how to
control the hosts you want to configure. Input and output streams attached
to an interactive POSIX sh running on the target host (or in the target
container) is sufficient to use much of Consfigurator's functionality. But
if it is possible to get an implementation of Common Lisp started up on the
host, then Configurator can transparently execute your deployment code over
on the remote side, rather than exchanging information via POSIX sh. This
lets you use the full power of Common Lisp to deploy your configuration.
.
Configurator has convenient abstractions for combining these different ways
to execute your configuration on hosts with different ways of connecting to
them. Connections can be arbitrarily nested.
.
Declarative configuration management systems like Consfigurator and Propellor
share a number of goals with projects like the GNU Guix System and NixOS.
However, tools like Consfigurator and Propellor try to layer the power of
declarative and reproducible configuration on top of traditional,
battle-tested unix system administration infrastructure like apt, dpkg, yum,
and distro package archives, rather than seeking to replace any of those.
Let's get as much as we can out of all that existing distro policy-compliant
work!
|