9 ms·

Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ

169 points by jonasvp 14y ago

jonasvp 14y ago
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.
specto 14y ago
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.
boothead 14y ago
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.)
maheart 14y ago
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 :)
lvh 14y ago
Salt 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#L281 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 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. I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.
- Orva 14y ago
  > I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS. Yup, ZeroMQ doesn't support TLS.
  - jacques_chester 14y ago
    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.
    - Nrsolis 14y ago
      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.
      - lucian1900 14y ago
        Then it should not be used anywhere else. Since it is, it really should have TLS support.
- kbutler 14y ago
  http://docs.saltstack.org/en/latest/topics/index.html 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 are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic. """
  - lvh 14y ago
    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.)
dantheta 14y ago
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.
- jacques_chester 14y ago
  I complained about cfengine's syntax in a blog post a while ago[1]; someone mentioned that a patch for YAML-based cfengine manifests had been proposed. I haven't seen anything since, but then ... well I don't follow the cfengine news too closely. It largely seems to be that a lot of these systems take their directives as nestable key-value pairs, so I think YAML is a good fit. Amusingly, the first link someone posted on my blog post was to Salt. I didn't dig too deep at the time as it appeared to be more at the REF end of the spectrum to me. [1] http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
- ciupicri 14y ago
  If you want YAML, check out ansible ( http://ansible.cc/ http://ansible.cc/ )
- vsh426 14y ago
  ansible has very readable concise YAML syntax[1]. Plus, no bootstrapping required (its optional, haven't tried it though) and works off ssh by default (also has a 0mq mode). [1] https://github.com/ansible/ansible/tree/devel/examples/playbooks https://github.com/ansible/ansible/tree/devel/examples/playb...
mhd 14y ago
Just when I narrowed my options down to ansible and chef… This seems to be more in line with chef/puppet, with a dedicated daemon on the client.
- crdoconnor 14y ago
  It's more similar to ansible than puppet. Both are python based and use zeromq. All four are declarative and AFAIK, all four have a dedicated daemon on the client.
  - mpdehaan2 14y ago
    I would rather not get into "X is better than Y", but this is not quite accurate. I'm not saying that's a bad thing, but I see a distilled Puppet syntax there, where Ansible (http://ansible.cc http://ansible.cc) is more about modeling both resource states and ordered processes across machines. Ansible actually uses SSH by default but there's a 0mq accelerator if you want to use it. We don't just execute individual SSH commands, modules are remote resources that model idempotent state -- but don't stay resident. The 0mq accelerator came later. There's also a pull mode, and a local mode in Ansible. Using SSH is nice because you don't have the additional PKI, and all that comes with having to maintain that. (No needs of accurate NTP and DNS either, and working with Kerberized SSH and using your OS credentials is possible). Need to do non-root things? You can do things (if you have permissions) entirely as non-root. Furthermore, Ansible does not have a dedicated daemon on the client. It's daemonless, and consumes no resources when not running. When running with 0mq, the daemon is ephemeral, stopping after a set period of time, to not consume resources. It also requires no bootstrapping, so if you have blank cloud images with nothing on them, or brownfield systems in the field, you can just start managing them immediately. cloud-init and so on are great for this, all cloud tools can inject keys. For this reason (no agents), it's starting to look very appealing on embedded devices and network hardware as well. While implemented in Python you can write modules in any language. Finally, Ansible's core focus is around making multi-tier orchestration easy (somewhat of a niche case), so that leads it to look a lot different at the language/resource level. But if you have just one tier, you can use it too. It's frequently used to deal with rolling updates involving N-tier applications with monitoring servers and load balancers all in play, though you can definitely use Ansible just for classical config management. I think part of the reason Salt may look similar to Ansible is Salt is clearly inspired by Func, especially the minion/overlord terminology, globbing, minion-to-minion, etc, and I was one of the original authors of Func at Red Hat. We were toying around with a message bus Func at the time and decided not to do it. So, yeah, lots of tools in this space. In Ruby config land, there's also Sprinkle, Rexify, etc! So many options!
jvehent 14y ago
Is there a search functionality, similar to what Chef::Search provides ?
ciupicri 14y ago
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]. [1] http://ansible.cc/ http://ansible.cc/ [2] http://ansible.cc/docs/gettingstarted.html#requirements http://ansible.cc/docs/gettingstarted.html#requirements
- stevekemp 14y ago
  And my own tool, this time in Perl, which is thoroughly documented here: http://www.steve.org.uk/Software/slaughter/guide/ http://www.steve.org.uk/Software/slaughter/guide/
- X-Istence 14y ago
  There is also Fabric [1] to allow management of remote servers using Python scripts. [1] http://docs.fabfile.org/en/1.5/ http://docs.fabfile.org/en/1.5/
  - mercurial 14y ago
    Fabric is a deployment tool, which makes it useful in many cases where something like Salt would be overkill, but is definitely not in the same category.
  - lukes386 14y ago
    Also cuisine[0], a more fully featured configuration management tools built on top of Fabric's lower level functions. [0]: https://github.com/sebastien/cuisine https://github.com/sebastien/cuisine
- buster 14y ago
  And it can also use zeromq ;)
- vsh426 14y ago
  I like its syntax too, its simple to understand and model[1]. [1]https://github.com/ansible/ansible/tree/devel/examples/playbooks https://github.com/ansible/ansible/tree/devel/examples/playb...
indymike 14y ago
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.
fsniper 14y ago
Salt is a promising tool for configuration management and remote execution. 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. I believe there may be many more to come. 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.
reactor 14y ago
Also there is cdist (http://www.nico.schottelius.org/software/cdist/ http://www.nico.schottelius.org/software/cdist/) not so popular but interesting.
- pekk 14y ago
  It seems that cdist recipes must be written as shell scripts.
  - telmich 14y ago
    That is absolutely right - and thus your sysadmins do not need to learn a new language / DSL. cdist is mostly about being simple
3am 14y ago
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.
- mpdehaan2 14y ago
  Yeah, I was one of the Func authors. That minion/overlord terminology, globbing, delegation, minion-to-minion, etc, are ideas clearly from there. I think mCollective was the first to take our Func-on-AMQP ideas and implement them, actually, though Salt was probably the first to try to stick a CM layer on the top of a Func-based-system, like I was planning but hadn't got around to ("Remote Rocket Surgery" was the placeholder codename for that on top of Func). As far as Func->Ansible goes, Seth Vidal (another one of the original authors) also does a lot of commits and wrote our yum module -- and is now using it for Fedora Infrastructure. I wouldn't really recommend anyone look at Func anymore -- it's fading just a little bit (taken over by Steve Salesvan, also ex Red Hat), but it's still in use at places like Tumblr, which is a pretty large setup. Still, it was fun to do. We sort of did multiprocessing before multiprocessing.py :) Adoption is going pretty well at the moment and it has been fun to watch. Several setups in the couple thousand of node ranges, lots around Big Data applications.
dcgibbons 14y ago
Why?
bascule 14y ago
Salt is using its own homebrew transport encryption protocol instead of TLS (which, among other things, serializes everything as JSON o_O): https://salt.readthedocs.org/en/latest/topics/specs/salt_auth_proto_abs.html https://salt.readthedocs.org/en/latest/topics/specs/salt_aut... Why are they doing this? Good question!
- jhawk28 14y ago
  ZeroMQ does not provide transport level encryption. By performing the encryption at the message level, it lets Salt publish the messages to everyone that is subscribed, but then only the minions that can decrypt the data actually run the code.
  - bascule 14y ago
    And what's the threat model for this protocol, exactly? How many cryptographers have actually studied it? Encrypted transport protocols are notoriously hard to get correct... just look at how many times TLS, SSH, and IPsec have been compromised. Their abstract mentions little about the algorithms they're actually using. For example, they mention "RSA authentication" but not what authenticated encryption mode they're using (looking at the code, it's encrypt-then-HMAC. At least their MAC comparison function looks constant time-ish) I don't think the people who created this have any business designing an encrypted transport protocol.
- X-Istence 14y ago
  Please do explain how you expect pub/sub to work with TLS when the pub/sub part of the protocol doesn't speak TLS, only "data" ... and data is flowing only one way.
cookiecaper 14y ago
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.
23david 14y ago
I don't really consider salt as an alternative to puppet/chef. 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. 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. Just don't use capistrano... :-)
- lobster_johnson 14y ago
  > It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code. I disagree. If anything, Ruby is closer to Bash (in a good way, mind you) whereas Python's various syntax choices (white-space sensitivity, parens for function calls, some things only available as imported modules, etc.) makes it more different. Consider bash: if [ `which foo` == "/usr/bin/foo" ]; then do_stuff fi compared to Ruby: if `which foo`.strip == "/usr/bin/foo" do_stuff end compared to Python: import os if os.popen("which foo").read().strip() == "/usr/bin/foo": do_stuff() Also, I would be careful about making generalizations without the data to back it up. "Many sysadmins & devops prefer..." is what Wikipedia editors would call weasel words. I have only anecdotal evidence myself; I personally used to be a Python guy but now prefer Ruby; and some time ago my company hired a sysadmin/devops guy who came from Python, but grew to prefer Ruby once he started to learn it while working for us. Considering that both Puppet and Chef are written in (almost entirely) Ruby, I would say that the sysadmin/devops field is currently leaning more strongly toward Ruby than Python. Although I'm sure bash dominates both. Don't get me wrong, in terms of productivity and so forth, Python and Ruby are entirely on an equal footing.
baijum 14y ago
Salt development community is more active than Puppet, see this comparison: https://gist.github.com/baijum/4545747 https://gist.github.com/baijum/4545747

169 points by jonasvp 14y ago

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.

specto 14y ago

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.

boothead 14y ago

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.)

maheart 14y ago

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 :)

lvh 14y ago

Salt 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#L281 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 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. I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.

Orva 14y ago
> I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS. Yup, ZeroMQ doesn't support TLS.
- jacques_chester 14y ago
  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.
  - Nrsolis 14y ago
    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.
    - lucian1900 14y ago
      Then it should not be used anywhere else. Since it is, it really should have TLS support.
kbutler 14y ago
http://docs.saltstack.org/en/latest/topics/index.html 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 are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic. """
- lvh 14y ago
  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.)

dantheta 14y ago

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.

jacques_chester 14y ago
I complained about cfengine's syntax in a blog post a while ago[1]; someone mentioned that a patch for YAML-based cfengine manifests had been proposed. I haven't seen anything since, but then ... well I don't follow the cfengine news too closely. It largely seems to be that a lot of these systems take their directives as nestable key-value pairs, so I think YAML is a good fit. Amusingly, the first link someone posted on my blog post was to Salt. I didn't dig too deep at the time as it appeared to be more at the REF end of the spectrum to me. [1] http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
ciupicri 14y ago
If you want YAML, check out ansible ( http://ansible.cc/ http://ansible.cc/ )
vsh426 14y ago
ansible has very readable concise YAML syntax[1]. Plus, no bootstrapping required (its optional, haven't tried it though) and works off ssh by default (also has a 0mq mode). [1] https://github.com/ansible/ansible/tree/devel/examples/playbooks https://github.com/ansible/ansible/tree/devel/examples/playb...

mhd 14y ago

Just when I narrowed my options down to ansible and chef… This seems to be more in line with chef/puppet, with a dedicated daemon on the client.

crdoconnor 14y ago
It's more similar to ansible than puppet. Both are python based and use zeromq. All four are declarative and AFAIK, all four have a dedicated daemon on the client.
- mpdehaan2 14y ago
  I would rather not get into "X is better than Y", but this is not quite accurate. I'm not saying that's a bad thing, but I see a distilled Puppet syntax there, where Ansible (http://ansible.cc http://ansible.cc) is more about modeling both resource states and ordered processes across machines. Ansible actually uses SSH by default but there's a 0mq accelerator if you want to use it. We don't just execute individual SSH commands, modules are remote resources that model idempotent state -- but don't stay resident. The 0mq accelerator came later. There's also a pull mode, and a local mode in Ansible. Using SSH is nice because you don't have the additional PKI, and all that comes with having to maintain that. (No needs of accurate NTP and DNS either, and working with Kerberized SSH and using your OS credentials is possible). Need to do non-root things? You can do things (if you have permissions) entirely as non-root. Furthermore, Ansible does not have a dedicated daemon on the client. It's daemonless, and consumes no resources when not running. When running with 0mq, the daemon is ephemeral, stopping after a set period of time, to not consume resources. It also requires no bootstrapping, so if you have blank cloud images with nothing on them, or brownfield systems in the field, you can just start managing them immediately. cloud-init and so on are great for this, all cloud tools can inject keys. For this reason (no agents), it's starting to look very appealing on embedded devices and network hardware as well. While implemented in Python you can write modules in any language. Finally, Ansible's core focus is around making multi-tier orchestration easy (somewhat of a niche case), so that leads it to look a lot different at the language/resource level. But if you have just one tier, you can use it too. It's frequently used to deal with rolling updates involving N-tier applications with monitoring servers and load balancers all in play, though you can definitely use Ansible just for classical config management. I think part of the reason Salt may look similar to Ansible is Salt is clearly inspired by Func, especially the minion/overlord terminology, globbing, minion-to-minion, etc, and I was one of the original authors of Func at Red Hat. We were toying around with a message bus Func at the time and decided not to do it. So, yeah, lots of tools in this space. In Ruby config land, there's also Sprinkle, Rexify, etc! So many options!

jvehent 14y ago

Is there a search functionality, similar to what Chef::Search provides ?

ciupicri 14y ago

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]. [1] http://ansible.cc/ http://ansible.cc/ [2] http://ansible.cc/docs/gettingstarted.html#requirements http://ansible.cc/docs/gettingstarted.html#requirements

stevekemp 14y ago
And my own tool, this time in Perl, which is thoroughly documented here: http://www.steve.org.uk/Software/slaughter/guide/ http://www.steve.org.uk/Software/slaughter/guide/
X-Istence 14y ago
There is also Fabric [1] to allow management of remote servers using Python scripts. [1] http://docs.fabfile.org/en/1.5/ http://docs.fabfile.org/en/1.5/
- mercurial 14y ago
  Fabric is a deployment tool, which makes it useful in many cases where something like Salt would be overkill, but is definitely not in the same category.
- lukes386 14y ago
  Also cuisine[0], a more fully featured configuration management tools built on top of Fabric's lower level functions. [0]: https://github.com/sebastien/cuisine https://github.com/sebastien/cuisine
buster 14y ago
And it can also use zeromq ;)
vsh426 14y ago
I like its syntax too, its simple to understand and model[1]. [1]https://github.com/ansible/ansible/tree/devel/examples/playbooks https://github.com/ansible/ansible/tree/devel/examples/playb...

indymike 14y ago

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.

fsniper 14y ago

Salt is a promising tool for configuration management and remote execution. 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. I believe there may be many more to come. 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.

reactor 14y ago

Also there is cdist (http://www.nico.schottelius.org/software/cdist/ http://www.nico.schottelius.org/software/cdist/) not so popular but interesting.

pekk 14y ago
It seems that cdist recipes must be written as shell scripts.
- telmich 14y ago
  That is absolutely right - and thus your sysadmins do not need to learn a new language / DSL. cdist is mostly about being simple

3am 14y ago

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.

mpdehaan2 14y ago
Yeah, I was one of the Func authors. That minion/overlord terminology, globbing, delegation, minion-to-minion, etc, are ideas clearly from there. I think mCollective was the first to take our Func-on-AMQP ideas and implement them, actually, though Salt was probably the first to try to stick a CM layer on the top of a Func-based-system, like I was planning but hadn't got around to ("Remote Rocket Surgery" was the placeholder codename for that on top of Func). As far as Func->Ansible goes, Seth Vidal (another one of the original authors) also does a lot of commits and wrote our yum module -- and is now using it for Fedora Infrastructure. I wouldn't really recommend anyone look at Func anymore -- it's fading just a little bit (taken over by Steve Salesvan, also ex Red Hat), but it's still in use at places like Tumblr, which is a pretty large setup. Still, it was fun to do. We sort of did multiprocessing before multiprocessing.py :) Adoption is going pretty well at the moment and it has been fun to watch. Several setups in the couple thousand of node ranges, lots around Big Data applications.

dcgibbons 14y ago

Why?

bascule 14y ago

Salt is using its own homebrew transport encryption protocol instead of TLS (which, among other things, serializes everything as JSON o_O): https://salt.readthedocs.org/en/latest/topics/specs/salt_auth_proto_abs.html https://salt.readthedocs.org/en/latest/topics/specs/salt_aut... Why are they doing this? Good question!

jhawk28 14y ago
ZeroMQ does not provide transport level encryption. By performing the encryption at the message level, it lets Salt publish the messages to everyone that is subscribed, but then only the minions that can decrypt the data actually run the code.
- bascule 14y ago
  And what's the threat model for this protocol, exactly? How many cryptographers have actually studied it? Encrypted transport protocols are notoriously hard to get correct... just look at how many times TLS, SSH, and IPsec have been compromised. Their abstract mentions little about the algorithms they're actually using. For example, they mention "RSA authentication" but not what authenticated encryption mode they're using (looking at the code, it's encrypt-then-HMAC. At least their MAC comparison function looks constant time-ish) I don't think the people who created this have any business designing an encrypted transport protocol.
X-Istence 14y ago
Please do explain how you expect pub/sub to work with TLS when the pub/sub part of the protocol doesn't speak TLS, only "data" ... and data is flowing only one way.

cookiecaper 14y ago

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.

23david 14y ago

I don't really consider salt as an alternative to puppet/chef. 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. 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. Just don't use capistrano... :-)

lobster_johnson 14y ago
> It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code. I disagree. If anything, Ruby is closer to Bash (in a good way, mind you) whereas Python's various syntax choices (white-space sensitivity, parens for function calls, some things only available as imported modules, etc.) makes it more different. Consider bash: if [ `which foo` == "/usr/bin/foo" ]; then do_stuff fi compared to Ruby: if `which foo`.strip == "/usr/bin/foo" do_stuff end compared to Python: import os if os.popen("which foo").read().strip() == "/usr/bin/foo": do_stuff() Also, I would be careful about making generalizations without the data to back it up. "Many sysadmins & devops prefer..." is what Wikipedia editors would call weasel words. I have only anecdotal evidence myself; I personally used to be a Python guy but now prefer Ruby; and some time ago my company hired a sysadmin/devops guy who came from Python, but grew to prefer Ruby once he started to learn it while working for us. Considering that both Puppet and Chef are written in (almost entirely) Ruby, I would say that the sysadmin/devops field is currently leaning more strongly toward Ruby than Python. Although I'm sure bash dominates both. Don't get me wrong, in terms of productivity and so forth, Python and Ruby are entirely on an equal footing.

baijum 14y ago

Salt development community is more active than Puppet, see this comparison: https://gist.github.com/baijum/4545747 https://gist.github.com/baijum/4545747