Live data from Hacker News

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

linuxjournal.com

51–60 of 75 posts

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

#51

Earlier quoted context omitted.

Can someone who has used both chime in? I've used ansible a bit and like it, but I've never heard of Salt before.

We're using salt and while it's incredible buggy still it's the most impressive system we've used so far. It's faster than anything else because it does not go through the process of signing in through ssh and creating a unix session. That might sound like a boring detail but it opens up many possibilities by doing things like asking all machines for their system time and then doing something with it.

To speed up ssh login time, try adding the following to your ~/.ssh/config:

  Host *
    ControlMaster auto
    ControlPath ~/.ssh/auth/%r@%h:%p
    ControlPersist yes
For me this changes connection times from 1.7 seconds to 0.189 seconds when connecting to a host over the internet.

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

#52
post #6

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

Seems like you're essentially saying that you don't trust it because it's not a peer-reviewed crypto system using TLS. Can you see that it's flawed in its specific implementation?

This is a real community project. If you can see a way to improve something, just open a pull request on github.

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

#53
post #49

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_aut... Why are they doing this? Good question!

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.

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

#54
post #53
post #49

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_aut... Why are they doing this? Good question!

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.

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.

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

#55
post #51

Earlier quoted context omitted.

We're using salt and while it's incredible buggy still it's the most impressive system we've used so far. It's faster than anything else because it does not go through the process of signing in through ssh and creating a unix session. That might sound like a boring detail but it opens up many possibilities by doing things like asking all machines for their system time and then doing something with it.

To speed up ssh login time, try adding the following to your ~/.ssh/config: Host * ControlMaster auto ControlPath ~/.ssh/auth/%r@%h:%p ControlPersist yes For me this changes connection times from 1.7 seconds to 0.189 seconds when connecting to a host over the internet.

What does this do?

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

#56
post #51

Earlier quoted context omitted.

To speed up ssh login time, try adding the following to your ~/.ssh/config: Host * ControlMaster auto ControlPath ~/.ssh/auth/%r@%h:%p ControlPersist yes For me this changes connection times from 1.7 seconds to 0.189 seconds when connecting to a host over the internet.

What does this do?

Maintains a persistent ssh connection to each host once the first is created. Any subsequent ssh commands will be sent over the existing channel, skipping the time-consuming handshake process.

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

#57
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.

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

#58

Earlier quoted context omitted.

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.

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 ) 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, modu…

>In Ruby config land, there's also Sprinkle, Rexify, etc! So many options!

The Rexify (or more precisely Rex) that I'm aware of is written in Perl - http://rexify.org/ | https://github.com/krimdomu/Rex

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

#59

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

There's also cdist which is python and shell-script based - does not even need python on the target machine, only ssh and a posix shell.

check it out: http://www.nico.schottelius.org/software/cdist/

disclaimer: I work with the author, but not actually on the cdist codebase (not enough to brag about, anyway)

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

#60
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... :-)

Post reply on HN