SSS2 design ideas

by hobbitalastair

I thought that I would write down the ideas that have been slowly gelling in my head with regard to SSS Mk.2, the replacement for my current syncing system.

The basic requirements for the syncing system, as of now:

  • Lightweight. To run on the Toshiba, preferably less than 6MB of RSS when running, and written in a compiled language to minimise overheads. It also needs to be small to be a manageable project!
  • Provides all of the features of my current system:
    • Installed package management via ‘tasks’ or similar
    • Configuration file management (patches, custom files, and merging with pacnew files)
    • Enabled services management
    • User management. This would be a real improvement over the ‘hacked’ form used in my current meta-package based system.
  • Adds new features:
    • Git based states. This would allow state roll backs, branches for testing, and ‘sane’ state syncing across computers. I’d have to make sure that the number of branches was manageable, though, since merging would be purely manual.
    • No dependence on Pacman. This would hopefully allow me to also roll out a similar system on the other computers I use that I might not have admin rights to, and which aren’t Arch Linux based.
    • Automatic updating over the local network, or as a fall back, from an online git repo. That’s possibly a job for a dedicated daemon, though.
    • Simpler roll out (how?)
    • A simpler way to add new changes?
  • Easy to extend! This would be accomplished by having all of the information on how to change state – recipes to check, enable, or disable states – stored in plaintext files. If I wanted to add a new recipe, for instance, to add udev (or similar) rules, I could easily create a new recipe that did so. Although that particular example would be better served by just creating a new file…

I am aiming to end up with something like bcfg2, but designed to be suited to smaller networks, and written in a lighter language than python. But otherwise, something pretty similar!


I will consider other options, rather than a pure config file based system – one of the strong points of the existing system is that it leveraged existing code. This did lead to some limitations, but I’m trying not to reinvent the wheel…

If I did go down the purely config file based route, the system itself could be split into groups:

  • State parser: Parses the state description files and returns a state object containing information on the target state
  • State database: Holds information on the state at the last update
  • Logger: Interacts with the journal or log system… locally if required
  • Recipe runner: Runs the required recipes
  • State finder: Figures out the current system state using the recipes (how would this work for generic recipes?)
  • State comparer: Compares the current, old, and target states, and returns a ‘diff’
  • State updater: Runs the required recipes to fix the problems shown by the state comparer

Then there is the optional extras:

  • Command line tools: Updater, diff generator, other?
  • State description and recipe syncer, probably git based
  • Mailer interaction?
  • Monitor, for disk space, system health, etc (should really be another project?)
  • Group updater (after testing an update, roll it out?)
  • Group monitoring tools (host X,Y,Z are fine, host W has an issue)

The optional extras should, perhaps, belong to another group…


 

For the parser (both for the recipe and state description files), I either need to write my own or use a pre-existing language. Because I need conditionals, a simple scripting language would really be good, although it is probably over the top for what I am trying to do – conditionals are fairly simple, and lists would be nice, but other control structures are probably OTT!

I was also considering what I wanted to do with regards to config file management, since the current system relies on a shell script that is less than stable.

I did find some additional software that might help:

  • Augeas: Basically, a substantially more complex version of patchman, which is (potentially) better suited to what I want to do. It looks quite similar to the replacement that I had vaguely considered…
  • Lua: A lightweight scripting language. Overly complex for my needs, but better than bash, and with more features than dash, such as arrays.

I’ll evaluate each one and make a choice. Both seem lightweight, with minimal dependencies. However, they may be more complex than I need…

Advertisements