remote-config

Remote administration scripts for Arch Linux
git clone git://git.danielmoch.com/remote-config.git
Log | Files | Refs

commit 958e7ebefa29789596feb899e7c5a5643a655bb0
parent 694fcb99a27dccabef980eb7fae9a0453c00dc6a
Author: Daniel Moch <daniel@danielmoch.com>
Date:   Mon, 11 Feb 2019 20:54:56 -0500

Add README

Diffstat:
AREADME.rst | 65+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+), 0 deletions(-)

diff --git a/README.rst b/README.rst @@ -0,0 +1,65 @@ +remote-config +------------- + +This project basically started out with the realization that 80 MB of Python +modules in order to remotely manage machines is insane. Beyond that, this is +sort of a weekend project without much structure. That said, I think the idea is +noble and I'd like to see it develop into something more general-purpose. + +The core idea is to bring some structure to the notion of running shell scripts +over SSH. All scripts are written in POSIX shell, and so should work on any +operating system with ``/bin/sh``. + +Invocation +========== + +As it stands today a project is executed via the ``remotecfg`` script, with the +heavy lifting being done by a second script, which is sourced alongside the +project scripts themselves. That second script provides functions to make things +like installing packages and starting services idempotent. It is, however, +currently tied to Arch Linux and Systemd. + +With the above qualifications in mind, executing a project is as easy as running +the command line: + +``remotecfg [-s] remote_host config`` + +With ``remote_host`` being the remote machine to operate on, and ``config`` +being the configuration to apply (see below). The optional ``-s`` flag indicates +the ``remotecfg`` should use ``sudo`` to elevate its privileges to root after +connecting to the remote host. + +Project Structure +================= + +A project is simply a directory containing all of the files, secrets, templates, +and remote scripts ``remotecfg`` can run. There is a directory for each of the +aforementioned types, with each directory containing subdirectories +corresponding to the possible configurations for that project. Everything in the +files directory for a given configuration is copied to the remote machine and +made available to the script in the remote directory. The secrets directory +contains GPG encrypted files that are decrypted and then merged with the files +directory (with the secrets directory taking precedence). The templates +directory contains files that are run through a ``sed`` filter to replaces +strings with secrets. The sed filter applied is specified in the first line of +the file (this is perhaps the first thing in need of improvement). + +Sample project structure:: + + project + |- files + | |- config 1 + | | |- file 1 + | | |- file 2 + | |- config 2 + | | |- file A + | | |- file B + |- remote + | |- config 1 + | |- config 2 + |- secrets + | |- config 1 + | |- config 2 + |- templates + | |- config 1 + | | |- file 3