home of the madduck/ blog/
A botnet for configuration management

Following my last rant about configuration management, I've had a closer look at Salt, both for my personal use, as well as for a client who would like to deploy something that is not Puppet.

Salt has some very good ideas, for instance:

But there are also a couple of downsides to Salt:

Those are the big issues. There are many small issues too, but those won't be around for too long as the project is moving along quickly and the community is vibrant. This is surely an important point that speaks for Salt.

However, the above issues seem to hint at design choices that might well turn out to stand in the way later.

Following a day of frustration, I now feel the overpowering urge to write my own configuration management system, because of course I feel that I could do it better than everyone else. Does this sound familiar to you?

Let's just say — hypothetically — that I would, then I'd want to reuse as much existing functionality as possible. For instance, I'd want the entire remote execution framework to be independent from any configuration management implemented on top.

So what does this mean? What would such a remote execution framework need? Here are some thoughts:

Doesn't this sound like a Unix botnet to you? ;)

I could imagine whacking this up with a bit of Python, some shell glue, socat and SSH: the server would have an authorized_keys file with forced commands connecting the client to the server process via sockets.

Or I could imagine using twisted for that.

But I would prefer if something like this already existed. Anyone?

Comments are broken on my blog, and I cannot be bothered to work on them. If you have any input, please write to me. I will (eventually) condense all feedback into a new article.

NP: Mouse on Mars: Parastrophics