sugar(1) is a simple remote servers management tool, written in POSIX sh(1), slightly more complex/complete than drist or apply, still much simpler than slack.

And, as it aims to solve a different problem space, orders of magnitude simpler than Ansible, Salt, Chef, Puppet, etc..

Its main purpose is to provide a thin layer of abstraction, just thick enough to automate typical UNIX servers manual administration.

Introduction

sugar(1) mostly tries to solve how to automate manual (mostly UNIX) (mostly remote) server administration. It does so by providing a thin abstraction layer, uniforming commands and files storage.

More complex problems, such as providing uniform layers to manage distinct OSs idiosyncrasies aren’t directly solved: users can still, depending on their need, solve more or less completely that problem by thickening the abstraction layer. We’ll show a few simple examples of such additional layers.

Note sugar(1) is written in POSIX sh(1), so are the auxiliary and samples scripts we provide, but this is not enforced.

The governing principle is about rsync(1)-ing a local directory containing scripts and data to a remote location. The scripts, strongly recommended to be made idempotent, can be conveniently run over ssh(1) on remote locations, and potentially wrapped between locally executed hooks. Such hooks allow to prepare data before syncing, or to check that a setup has been performed as expected.

Convenience scripts are provided to help share data/code between multiple machines with similar setup, or to automatically create commands as linear sequences of other commands.

An exercise in design

Most often, servers are inherently complex, as they must provide a certain variety of services, through a certain variety of software. That complexity is increased when having to manage a fleet of servers, even more so when external constraints, such as a forced based OS, come into play.

As for software, a critical skill to gracefully handle such a terrible amount of complexity is the ability to organize things, and to make sure that the chosen organization doesn’t actually increase the complexity. Still, note that this extra-complexity can be valuable for a wide enough problem space.

Ansible, Chef or Salt all provide some kind of meta-operating system to help users tame the complexity. They also aim at solving a wide problem space, and have been doing so for a while, thus the existence of complete/mature abstractions.

As such, this provides guidelines for features implementation, and tools to solve issues such as unifying OSs discrepancies (e.g. user management).

Smaller players such as drist, apply or sugar, instead follow a bottom-up approach: they offer a few simple, basic elements that can be combined to solve an user-specific problem space.

In the case of sugar(1), this makes the code rather small, simple, sharp. Which means, easy to fully audit yet sometimes subtle to use. A meta-OS provides some construction lines, while simpler tools provide something closer to a white canvas.

C is a razor-sharp tool, with which one can create an elegant and efficient program or a bloody mess.

– Brian Kernighan, The Practice of Programming

Note: This holds true for simple software overall, think, Turing Machines, C, LISP (at its core), UNIX Pipes, Plan9, Go, etc.

Note: Despite this apparent “freedom”, patterns usually emerge from daily use, often oblivious even to their creators at first. Furthermore, adding features need and can be carefully weight, as their orthogonality with existing ones can and should be carefully taken into account. A salient, public example for both points, is the addition of generics to Go:

Although generics have clear use cases, fitting them cleanly into a language like Go is a difficult task. One of the first (flawed) attempts to add generics to Go dates back all the way to 2010. There have been several others over the last decade.

– Ian Lance Taylor, A Proposal for Adding Generics to Go, 2021-01-12

Generics will be one of our focuses for 2022. The initial release in Go 1.18 is only the beginning. We need to spend time using generics and learning what works and what doesn’t, so that we can write best practices and decide what should be added to the standard library and other libraries. We expect that Go 1.19 (expected in August 2022) and later releases will further refine the design and implementation of generics as well as integrating them further into the overall Go experience.

– Russ Cox, Twelve Years of Go, 2021-11-10

Comments

By email, at mathieu.bivert chez: