Live data from Hacker News

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

linuxjournal.com

61–70 of 75 posts

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

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

Interesting tip. Thanks!

Note that you might need to create the auth subfolder using `mkdir ~/.ssh/auth`, otherwise it might throw an error on connection: `muxserver_listen bind(): No such file or directory`

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

#62
post #46
post #20

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

It seems that cdist recipes must be written as shell scripts.

That is absolutely right - and thus your sysadmins do not need to learn a new language / DSL. cdist is mostly about being simple

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

#63
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…

> 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 ironically, due to OpenSSL's poor implementation. (http://eprint.iacr.org/2010/594)

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

#64
post #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 leverage…

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

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

#65
post #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 leverage…

Not really the kind of comment HN generally approves, but I felt compelled to share...

> Just don't use capistrano... :-)

At one of my previous start-ups, we used to call it, "crapistrano". That is all!

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

#66
post #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 leverage…

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

I generally agree with your response. My only slight irritation is with how you wrote out the Python code. It looks a bit...uglier? and more verbose than it needs to be, especially compared to the others. This looks better to me:

  from commands import getoutput
  if getoutput('which bash') == '/bin/bash':
      do_stuff()
Although if your goal is to determine if e.g. bash is located in /bin, then I would do:

bash:

  if [ -e '/bin/bash' ];
  then
      do_stuff
  fi
(I don't know Ruby.)

Python:

  import os.path
  if os.path.exists('/bin/bash'):
      do_stuff()
I know I'm just splitting hairs. :)

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

#67
post #66

Earlier quoted context omitted.

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

I generally agree with your response. My only slight irritation is with how you wrote out the Python code. It looks a bit...uglier? and more verbose than it needs to be, especially compared to the others. This looks better to me: from commands import getoutput if getoutput('which bash') == '/bin/bash': do_stuff() Although if your goal is to determine if e.g. bash is located in /bin, then I would do: bash: if [ -e '/b…

The point was definitely not the logic of the examples! Rather to show three core similarities/differences:

* Ruby has bashisms like `foo`; Python requires a function call.

* Ruby has a nesting syntax similar to bash with if/end; Python is whitespace-sensitive.

* Ruby has method calls without parentheses, similar to bash commands, whereas Python requires them.

> Although if your goal is to determine if e.g. bash is located in /bin,

Actually, that was not the goal at all. The goal (which, again, is irrelevant to my point) was to determine if the PATH-resolved executable binary "foo" was in a specific location. Rest assured that I would not use "which" in a real-life app. :-)

(Thanks for commands.getoutput(), my Python is rusty.)

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

#68
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!

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.

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

#69
post #40

Earlier quoted context omitted.

I love Ansible. After having used puppet and chef at the company I work for, everyone was thrilled about how easy and boiler-plate free Ansible is. Chef is great for bigger architectures, but if your goal is to provision a limited set of servers and document it's configuration in a readable format, Ansible is truly fantastic.

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.

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

#70

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

Ansible has various connection modes between the client and the server. SSH is the default, but the stock release also including a "fireball" transport that uses a ZeroMQ daemon to dispatch incoming command requests.
Post reply on HN