Salt development community is more active than Puppet, see this comparison: https://gist.github.com/baijum/4545747
Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ
71–75 of 75 posts
Re: Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ
#72Earlier quoted context omitted.
Thanks! BTW, I'm not sure limited applies. There are several setups with thousands of nodes and users doing some pretty complex multi-tier orchestration magic (N-tier, load balancers, monitoring outage windows, Jenkins, all integrated, etc). And you've got ansible-pull for mega-large scale if you want.
The thread starter meant, AFAICT, that Ansible scales down nicely. If you have 3-4 boxes, maybe 0MQ is overkill, and even running a a Chef client constantly is overkill.
Exactly. Having to install chef and all it's dependencies to install nginx and a few config files in the end feels really wasteful. With ansible, there are zero server-side dependencies.
Re: Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ
#73Earlier quoted context omitted.
http://docs.saltstack.org/en/latest/topics/index.html """ Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption ar…
That explains the feature set, but it doesn't quite explain why it doesn't use TLS; TLS also starts with public key cryptosystems and then generates signing and symmetric encryption keys, oftentimes using precisely the same base algorithms (AES-256 and HMAC-SHA256). (Also, msgpack seems completely orthogonal to this issue.)
It's not really as easy as "use X library". As another commenter mentioned - using stunnel might be better than "rolling your own" based on well tested primitives, but "just using openssl" isn't necessarily a good solution, see eg this recent discussion:
http://lists.randombit.net/pipermail/cryptography/2012-Octob...
Re: Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ
#74Salt starts off with negative marks because they decided to type the letters A-E-S in their codebase: https://github.com/saltstack/salt/blob/develop/salt/crypt.py... 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 highe…
> I would hope the standard for cryptography is higher than "nothing obviously wrong with it" Can you please show me where that was the design decision that selected AES? Or are you just making an assumption that the code was not written by professional cryptographers and extensively peer reviewed? AES-CBC is still a perfectly valid safe choice for implementations today. The most successful attacks against it, are ir…
The point was that they wrote their own crypto on top of (the low level AES). That is a bad idea, especially since TLS has similar properties to their system.
Re: Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ
#75Earlier quoted context omitted.
You know it's weird, I've been noodling with ZeroMQ for about a year now and I just never connected those mental dots myself. Bugger.
It's worth noting that 0MQ was developed as a library for HFT/algorithmic trading applications. In those environments, TLS isn't necessarily a requirement because it's a closed network. If you need TLS so your trading app can talk to the ticker-plant securely, you have bigger problems than you think.
Then it should not be used anywhere else.
Since it is, it really should have TLS support.