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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
… 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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> 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 <marc@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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
* 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 <darren@boston.com> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nick Lewis
2012-Jul-21 02:01 UTC
[Puppet Users] Re: can''t authenticate based on IP? what? huh?
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> -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet > projects. > > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/DtGsIKqCOTsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 21/07/2012, at 11:41 AM, Chamberlain, Darren wrote:> * 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 <darren@boston.com> > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nigel Kersten
2012-Jul-21 23:48 UTC
Re: [Puppet Users] Re: can''t authenticate based on IP? what? huh?
On Fri, Jul 20, 2012 at 7:01 PM, Nick Lewis <nick@puppetlabs.com> wrote:> 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.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? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 21/07/2012, at 11:20 AM, Brian Gupta wrote:>> 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 <marc@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 > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.