can't authenticate based on IP? what? huh?

[Jo Rhett]

Okay, I totally did see this in the release notes but I read it that you weren't allowing certificates with IP addresses in them, not that you wouldn't allow IP authentication in auth.conf at all.  

Jul 17 14:52:46 sj2-puppet puppet-master[13998]: Authentication based on IP address is deprecated; please use certname-based rules instead

I don't feel that it is reasonable to expect that every puppet customer match up their naming scheme to their IP blocks, nor to want to list every possible naming scheme in their authorization list when an IP bitmask will do the job much more simply.

I don't mind or care about IPs in certificates--I've never seen this, and don't expect to. But disallowing IP-based authentication is going to be very difficult at many sites, and possibly allow things which were never intended. Please reconsider this.

-- 

Jo Rhett

Net Consonance : net philanthropy to improve open source and internet projects.

[Marc Lucke]

So I'm seeing a lot of hype around Ansible. It seems to be a compelling story. I've looked around and found a lot of stories about why you would use it over puppet, but not puppet over ansible. Can anyone relate personal experiences or point to some interesting reading?

[Marc Lucke]

… well there you have it. No advantages. Or nobody cares about this better system. Or nobody knows :)

On 18/07/2012, at 8:54 AM, Marc Lucke wrote:

> So I'm seeing a lot of hype around Ansible. It seems to be a compelling story. I've looked around and found a lot of stories about why you would use it over puppet, but not puppet over ansible. Can anyone relate personal experiences or point to some interesting reading?
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[Brian Gupta]

> On 18/07/2012, at 8:54 AM, Marc Lucke wrote:
>
>> So I'm seeing a lot of hype around Ansible. It seems to be a compelling story. I've looked around and found a lot of stories about why you would use it over puppet, but not puppet over ansible. Can anyone relate personal experiences or point to some interesting reading?

On Fri, Jul 20, 2012 at 8:11 PM, Marc Lucke <ma...@marcsnet.com> wrote:
> … well there you have it. No advantages. Or nobody cares about this better system. Or nobody knows :)
>

Well, I am guessing most of the people on this list haven't heard of
Ansible (until now). (Other than any Orson Scott Card fans.)

Taking a quick look the high level differences are:

1) Userbase/community - Puppet has a much larger userbase and
community. My belief is this is an advantage for puppet.

2) Larger number of modules available for use with puppet.

2) Ansible uses SSH to connect to the managed hosts. Pros and cons
here. Will let others argue which is "better".

3) DSL - Puppet has a Declarative DSL which largely separates the what
from the how. Ansible seems to mix the two in their playbooks. (Much
like Chef, but with Ansible not being Ruby specific.) I prefer a
Declarative DSL, but others may prefer alternate approaches.

4) Python vs Ruby - I feel Ruby is more popular in the Devops
community, and find I like the syntax better, but Python is not
necessarily a bad choice. That said, largely as a puppet user, one
doesn't have to deal with Ruby. (Nor does a Absible user have to deal
with writing Python.) This decision would be more important if you
wanted to contribute to one of the projects in question.

5) GPL vs Apache - DIfferent strokes for different folks. I actually
prefer GPL licensed software, but many prefer the Apache 2 license.

6) Push vs poll. - Ansible pushes configs to hosts where puppet
clients check in to a central server on regular intervals. (My
understanding is that ansible is somehow serverless.)

7) External data - Puppet supports the concept of storing ones data
separately from the code. It appears that ansible does not have a
standard method for doing so.

8) Built in remote command execution. Puppet relies on mcollective for
this feature, which is additional administrative overhead to setup and
maintain. However, on the flip side, I am certain that mcollective is
much more scalable than ansible. (IE: I am not using a tool that uses
ssh to manage 1000s of servers.) I can't say as a blanket statement
which is better.. If all you are managing is 10 nodes, I could see
simplicity of setup being an advantage. If you need to scale obviously
the scalable solution wins. That said, I would probably prefer to use
the scalable tool in small scenarios, so I don't have to learn two
toolchains.

9) Puppet manifests are historically have non-deterministic order
execution, unless dependencies are specifically declared. I think this
is the correct approach as implicit dependency graphs can be
dangerous, and lead to incomplete understanding of one's
configuration. That said, we are all used to scripts that run in
order, so this is definitely a learning curve when folks are new to
puppet.

10) Puppet is available in an Enterprise Edition that you can buy from
a known vendor with a full support contract. This gives many companies
warm and fuzzies. The majority of folks would say this is an advantage
for Puppet, however if one wants to be on the FLOSS bleeding edge, and
you don't have any money for software/support anyway, it might just be
a wash.

All in all I would say that Ansible feels more like a deployment
system with some basic configuration management idioms supported.
(Basically a step from capistrano or fabric towards a full-fledged
cfg-management framework.) I'm also sure I didn't get this all right,
and missed differences, as I have never used Ansible, and quickly
skimmed the docs.

Cheers,
Brian

[Chamberlain, Darren]

* Marc Lucke <marc at marcsnet.com> [2012/07/20 20:11]:
> ...well there you have it. No advantages. Or nobody cares about

> this better system. Or nobody knows :)
>
> On 18/07/2012, at 8:54 AM, Marc Lucke wrote:
> > So I'm seeing a lot of hype around Ansible. It seems to be a
> > compelling story. I've looked around and found a lot of stories
> > about why you would use it over puppet, but not puppet over
> > ansible. Can anyone relate personal experiences or point to
> > some interesting reading?

I've been investigating ansible over the last few weeks and I've
found it to have a lot of interesting things going for it: Ansible
is small, fast, lightweight, and consise, but also young, immature,
and rapidly evolving. Puppet has a vast and interesting ecosystem
around it, with lots of integration points with external tools;
ansible, by virtue of its youth, has none of that -- yet. For
example, if you want to set up a centralized dashboard to manage
your ansible jobs, you need to build it from scratch[*], while with
puppet, you have several mature alternates to choose from or build
upon. There are also numerous examples of puppet manifests and best
practices on the web, countless puppet modules freely available on
puppetforge and github, and many blog posts and presentations from
which to learn puppet, while ansible has basically just the mailing
lists (which is fairly active), the official docs, and a few github
repos of examples, but since ansible is evolving so rapidly these
examples are potentially of limited value. (Michael DeHaan has done
an admirable job of keeping the docs up-to-date, though.)

The speed of ansible's evolution is actually my biggest concern
about it right now; I don't want to get in a situation where my
playbooks (ansible-speak for what puppet calls manifests and what
cfengine calls promises) become outdated and need to be rewritten.
(I have hit this problem with puppet, too, though; I unintentionally
used several features that have been changed or deprecated as puppet
evolved, especially ones involving variable scope.)

Having said that, ansible is already incredibly usable and I haven't
yet found anything that I'm currently doing in puppet that I cannot
do in ansible. I'm using puppet to manage over 400 mixed-OS nodes in
a distributed, masterless environment, and I'm not using the
foreman, mcollective, puppetdb, storeconfigs, or any of those types
of features, so my environment might be fairly atypical.

As for why one should choose puppet over ansible, I think the
deciding factors for most people will be the tool ecosystem, the
developer ecosystem, and your comfort with evolving tools. I am
personally of the opinion that the tools managing your
infrastructure should be as mature and surprise-free as possible,
since any change in those tools could cause all sorts of problems
down the line; with the changes coming in puppet 3.0, I think the
playing field is about level here -- ansible may be young, but
Michael seems to have a very clearly defined end goal for what
ansible will become, and I don't see that changing much. Puppet
obviously has the lead in the tool and developer ecosystem fronts,
by virtue of its maturity (as I mentioned above), so if reporting,
long-term trending, and the like is a hard requirement then ansible
cannot be considered.

[*] I've actually got a very usable ansible dashboard setup using
Jeknins, pulling playbooks and inventory lists from subversion.

--
Darren Chamberlain <dar...@boston.com>

[Nick Lewis]

On Tuesday, July 17, 2012 3:46:21 PM UTC-7, Jo wrote:

Okay, I totally did see this in the release notes but I read it that you weren't allowing certificates with IP addresses in them, not that you wouldn't allow IP authentication in auth.conf at all.  

Jul 17 14:52:46 sj2-puppet puppet-master[13998]: Authentication based on IP address is deprecated; please use certname-based rules instead

I don't feel that it is reasonable to expect that every puppet customer match up their naming scheme to their IP blocks, nor to want to list every possible naming scheme in their authorization list when an IP bitmask will do the job much more simply.

I don't mind or care about IPs in certificates--I've never seen this, and don't expect to. But disallowing IP-based authentication is going to be very difficult at many sites, and possibly allow things which were never intended. Please reconsider this.

This is actually something of a misleading deprecation warning, I'm afraid. The change we plan to make is to distinguish "allow" and "allow_ip", to avoid confusing IPs and certnames. So the change you will need to make is to explicitly use "allow_ip" if you want to do IP-based authentication. However, adding that feature to 2.7.x, though backward compatible, turns out to require a fairly significant rework of some of the auth code, which is a risk we don't feel is appropriate. So the feature won't be in until 3, at which point it will be required.

That means we're in the awkward position of issuing a warning you can't actually fix yet, which is *really* not something we like to do. But it seems better to at least give some alert that you'll need to make a change in the future than to have it suddenly occur without forewarning. So yes, there's definitely a bit of an issue here, but I assure you we don't intend to remove IP-based authentication entirely.

Nick Lewis

[Marc Lucke]

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

Thanks Darren. One thing that struck me about puppet was that it seems like you can easily spend more time managing puppet than managing your machines until you hit some sort of critical mass even if you are more dev than ops. Ansible promises to lower the learning curve and simplify which is pulling some of the team I work in away from puppet because they resent having to write and debug code (if that's what they wanted to do, they'd have just been devs to begin with). The traditional old school stomping grounds of a sysadmin are procedural, predictable, pretty easy to use and relatively bug free which seems to be in stark contrast with puppet; if Ansible solves those problems then it's a compelling story.

Marc

[Nigel Kersten]

As Nick said, this wasn't something we took lightly, but I do believe
we've made the right interim decision.

Jo, can you provide a bit more detail about your specific use case so
we can be sure we're solving it going forward?

[Marc Lucke]

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

Thanks for the input Brian. I have to say I definitely prefer procedural scripts with a predictable run order, but you can accomplish this with stages. I've yet to refactor my own code so that I can deploy an ecosystem of servers in one go rather than a few runs per server. I like your analogy that Ansible looks like a step above fabric & capistrano - that's the impression I got too. But I haven't used it either.

Marc