There is also Ansible [1] which is written in Python and connects to servers using SSH (combined with sudo if needed). This means you don't need to install anything on the servers you're managing, since most distributions have Python >= 2.4 included. For more details see the requirements page [2].<p>[1] <a href="http://ansible.cc/" rel="nofollow">http://ansible.cc/</a><p>[2] <a href="http://ansible.cc/docs/gettingstarted.html#requirements" rel="nofollow">http://ansible.cc/docs/gettingstarted.html#requirements</a>
Salt starts off with negative marks because they decided to type the letters A-E-S in their codebase: <a href="https://github.com/saltstack/salt/blob/develop/salt/crypt.py#L281" rel="nofollow">https://github.com/saltstack/salt/blob/develop/salt/crypt.py...</a><p>Specifically, they appear to be doing AES-CBC with HMAC-SHA256. There's nothing obviously wrong with it (randomized IVs from os.urandom, both authentication and encryption and with distinct keys...) but I would hope the standard for cryptography is higher than "nothing obviously wrong with it". Specifically, I would hope that the standard for cryptography is somewhere along the lines of using a peer-reviewed cryptosystem that has stood the test of time such as TLS, OpenPGP or even NaCl (given the name, particularly the latter would be pretty good). I'm not saying TLS doesn't have flaws; I'm saying appropriately configured TLS is better than rolling your own crypto.<p>I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.
I don't really consider salt as an alternative to puppet/chef.<p>Although it can do many of the same things as both of them, there are a few important differences. 1) By default, it encourages the use of YAML definitions which makes the codebase more readable/manageable over time. 2) It incorporates a first-class remote execution environment that replaces the need for parallel ssh or ssh almost entirely. 3) It leverages zmq as a data bus, and can easily transfer files or live data over the bus in multiple different topologies. 4) It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code.<p>Ansible shares a lot of similar characteristics, and it's great seeing both projects taking off. Definitely room for more than one system in this area, and everyone benefits from the healthy competition. It's not terribly complicated to have different systems manage different parts of your stack anyhow. You can easily use chef/salt/ansible all at once and use each project to manage different layers of your stack.<p>Just don't use capistrano... :-)
I've been using Salt for about 10 months. It's pretty simple and is exceptionally fast when compared to many alternatives. Also, the code is absolutely clean, easy to read and well commented. We actually use Salt's code when we need an example of how to do python right... especially when you want to make diffs easy.
We've started using Salt for configuration management and it's everything we'd hoped for. It took some time to get our state tree figured out but now it works like a charm.
I've kicked salt's tyres recently and really like it. I think me favourite aspects are being able to use jinja and the fact that everything is all in the same place for the definitions. (As opposed to spread around various json/ruby files in chef for example.)
Salt is using its own homebrew transport encryption protocol instead of TLS (which, among other things, serializes everything as JSON o_O): <a href="https://salt.readthedocs.org/en/latest/topics/specs/salt_auth_proto_abs.html" rel="nofollow">https://salt.readthedocs.org/en/latest/topics/specs/salt_aut...</a><p>Why are they doing this? Good question!
I highly recommend Salt stack. It's a great piece of software: straightforward and gets the job done. After using Puppet, Chef and cfengine, I'm glad there's salt :)
Didn't Salt build upon Func? And didn't the author of Func go on to write Ansible? My experience between Salt, Rundeck, Ansible, and Fabric was that Salt/Rundeck were too heavyweight and that between Ansible and Fabric, Ansible mopped the floor with Fabric. Just my $.02.
So far I have only used salt at home in a lab environment, however it is promising. I especially love that I can dictate my directory structure for configuration by my own standards.
Salt is a promising tool for configuration management and remote execution.<p>But I believe it's still in it's early stages and need to go way much much more. My colleague decided upon using salt instead of chef or puppet. I'm ok with this decision but had too made some tweaks and send bug fixes or features upstream while testing environment.<p>I believe there may be many more to come.<p>Still, it's easy to use, configure and also it's still really nice on the eyes with being python. It's trivial to make fixes to the code base.
I'm currently a reasonably happy puppet user, but I do like the look of Salt. Puppet's configuration DSL always struck me as a little over-wrought (and slightly too inconsistent to remember easily). I would have preferred YAML/XML/ini files.
Met the guys behind Salt recently, and they seem pretty nice and host the local Python meetup. I'd like to try to use it some time, but the docs seem a bit on the impregnable side; while it seems they have decent coverage, there isn't a lot to really glue it all together and from just a quick skim, it seems like it'd be a pain to start from those. They should really invest in some decent "Getting Started"/tutorial blocks and attempt to explain the concepts narratively. I noticed perhaps a bit of this, but as I said, on a quick skim, it seemed quite insufficient.
Also there is cdist (<a href="http://www.nico.schottelius.org/software/cdist/" rel="nofollow">http://www.nico.schottelius.org/software/cdist/</a>) not so popular but interesting.