Re: [Puppet Users] Re: How to control who can add/update permissions in sudoers
Problem is that if you don't have a way of limiting where sudo entries can be made, someone can create a new module and grant themselves full sudo rights there for a large number of systems. When in a large enterprise such as ours, there are modules that are created and maintained by teams outside of the main teams that maintain the bulk of the puppet code. I think one possibility we are looking in to is using Teamcity (could also be done with Jenkins) to check that sudo calls aren't made outside of our protected sudo module. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5198fce0-fb84-42fe-bc8e-b6c2b48141d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] How to control who can add/update permissions in sudoers
Hi all, We're currently on PE 3.8.4. We need to be able to manage sudoers permissions with Puppet, but control things so sudoers permissions can only be granted within a specific module. So permissions could be included via 'include foo::bar' from anywhere, but the actual sudoers permissions used by the include could only be set within the specific module that has access tightly controlled. The goal is to prevent someone from injecting a new sudoers rule in to a module/manifest outside of our control. Any ideas? Thanks, Alex -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/38c300e1-9b21-499f-9eb6-6f3347042a28%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Using Puppet to roll out Windows Updates
You could use Puppet to manage WSUS though using stuff like PoshWSUS https://poshwsus.codeplex.com/ On Wednesday, June 11, 2014 11:55:51 AM UTC-7, Brian Mathis wrote: Why not use WSUS? This is what it's made for, it's already part of Windows, and can be easily managed from the WSUS console. Once you're operating in a Windows world, your life will be far better by doing things the Windows Way instead of resisting it. Sounds like a case of: *if the only tool you have is a hammer, to treat everything as if it were a nail* Incidentally, you typically wouldn't use Puppet to handle OS updates either (apt-get upgrade, yum update), which is the same thing, so it's not even a case of a Windows-specific thing. That's not to say that Puppet couldn't be abused into doing it. ❧ Brian Mathis @orev On Wed, Jun 11, 2014 at 12:35 PM, Pskov Shurik pskov...@gmail.com javascript: wrote: Hello everyone, We have recently started using Puppet to do initial system prep on new servers, such as Apache, Java installs, hosts file updates etc. However, we are now exploring the possibility of extending Puppet to manage Windows Updates. Er... has anyone done it? The requirements are simple: give Puppet a list of KB items to download and it would go and deploy these on whatever servers Puppet Agent is running on. We are happy for servers to go download a copy of patches, so we won't be using Puppet's central repository of installers (since Windows update installers are different depending on OS and architecture). I found a PowerHell script here - http://www.flobee.net/programmatically-run-windows-update-as-part-of-a-broader-patch-and-reboot-process/ - that could probably be, somehow, integrated into Puppet but if there's an easier way or modules that do it already, then I would appreciate a pointer. Thanks Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/87d8f0d8-8c47-4236-843a-5b5f1aa5d1b9%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/87d8f0d8-8c47-4236-843a-5b5f1aa5d1b9%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/aa6c8314-4d2e-4b83-9a0d-080f14bbd5b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
I'm sorry, I misspoke, I should have said that for us Puppet (PE actually) has been a moving target in a number of ways. For instance, we started out heavily using the PE dashboard to define what classes specific nodes would get and related variables, pretty quickly realized that that wasn't very scalable or repeatable and found hiera and environments. Puppet does a decent job of explaining environments, but their documentation in regards to integrating with git and gitolite is inadequate, particularly considering that they strongly recommend going down that path. Oh and while you are researching how to make dynamic environments work, you invariably run into R10k which sounds really awesome, but then you wonder how do you use it? Dynamic environments are great, extremely useful, but centrally managing what nodes are in what environment wasn't possible until we discovered the console_env module, which unfortunately isn't working for us after we upgraded to PE 3.2 (and to make a point about how the product is a moving target, they are currently working on a new way of assigning roles to systems). Hiera is also great as it's much faster to work with than the dashboard, but it's a lot easier to make mistakes with hiera. Also, for many situations, you need a hiera yaml file for individual nodes (like when you want a group of systems to use a specific class). So now there's the roles and profiles pattern, which Puppet recommends using along with hiera, but they don't provide good documentation at all on how to use both together. Plus if you pay attention to R.I. Pienaar (and you definitely should, in my opinion), you see that he's proposed a new pattern where you use hiera data within modules, but getting that to work requires using one of the modules that aren't yet in a finished state... I've talked to people who don't think that Puppet has handled the way they've added features and patterns and deprecated other features and patterns, but we haven't personally run in to that. All in all, I love the product, don't get me wrong, and maybe it looks pretty stable when you're at the guru level and figuring out new stuff is fairly easy, but for me, it's just me and a coworker trying to mature our linux and puppet infrastructure, processes and workflows. Neither of us are developers, so are learning that side of things as best as we can while we learn Puppet, git, hiera, Geppetto (which is the bee's knees, just be super careful when you try to merge two significantly different branches together using it), beaker, rspec, ruby and so on. I'm always questioning our choice in tools because that's how you stay ahead in this game and when I go looking for why people are using Salt Stack and Ansible instead of Puppet or Chef, the number one reason I've seen is complexity of the code needed to do something. Having said that, now that I've figured out a number of things and can pretty much do anything I want with Puppet, albeit crudely (you can see my kvm/webvirtmgr module as evidence of this), I don't see a reason to switch, but I can certainly understand why some people may look at the DevOps space and gravitate towards Salt Stack and Ansible over Puppet. Thanks, Alex On Wednesday, May 7, 2014 1:18:49 AM UTC-7, Felix.Frank wrote: On 05/07/2014 12:52 AM, Ramin K wrote: I find it best not to change my workflow or methodology until it makes sense on my system regardless of what the community or even Puppet Labs has said. Ramin, I could hardly agree more. Even your ignored practices resemble my own personal choices very closely (those perhaps come rather natural to old schoolers). If I understood Alex right though, he also feels that the apparent flux might be hindering broader acceptance of Puppet. If that is indeed the case, we have a problem that we should talk about. (Note that apparent stability is more important than the technicalities.) However, it has been my feeling that general adoption is not one of Puppet's problems. On the contrary, Puppet users usually form the largest crowd in any kind of forum concerned with the configuration management problem. The user base keeps growing and the community is literally buzzing with activity. Alex, are there concrete issues that you have faced concerning the ease of adoption? Thanks, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f7a80605-ed1e-4e45-a5c0-188d58767339%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
And this is aside from the significant resistance we've been getting from our traditional Windows admins over using Puppet, which is a problem that Puppet definitely can't solve. Their partnership with Microsoft is a very good thing, in my opinion though. Oh, and Chocolatey. :D --Alex On Wednesday, May 7, 2014 10:04:23 AM UTC-7, Alex Scoble wrote: I'm sorry, I misspoke, I should have said that for us Puppet (PE actually) has been a moving target in a number of ways. For instance, we started out heavily using the PE dashboard to define what classes specific nodes would get and related variables, pretty quickly realized that that wasn't very scalable or repeatable and found hiera and environments. Puppet does a decent job of explaining environments, but their documentation in regards to integrating with git and gitolite is inadequate, particularly considering that they strongly recommend going down that path. Oh and while you are researching how to make dynamic environments work, you invariably run into R10k which sounds really awesome, but then you wonder how do you use it? Dynamic environments are great, extremely useful, but centrally managing what nodes are in what environment wasn't possible until we discovered the console_env module, which unfortunately isn't working for us after we upgraded to PE 3.2 (and to make a point about how the product is a moving target, they are currently working on a new way of assigning roles to systems). Hiera is also great as it's much faster to work with than the dashboard, but it's a lot easier to make mistakes with hiera. Also, for many situations, you need a hiera yaml file for individual nodes (like when you want a group of systems to use a specific class). So now there's the roles and profiles pattern, which Puppet recommends using along with hiera, but they don't provide good documentation at all on how to use both together. Plus if you pay attention to R.I. Pienaar (and you definitely should, in my opinion), you see that he's proposed a new pattern where you use hiera data within modules, but getting that to work requires using one of the modules that aren't yet in a finished state... I've talked to people who don't think that Puppet has handled the way they've added features and patterns and deprecated other features and patterns, but we haven't personally run in to that. All in all, I love the product, don't get me wrong, and maybe it looks pretty stable when you're at the guru level and figuring out new stuff is fairly easy, but for me, it's just me and a coworker trying to mature our linux and puppet infrastructure, processes and workflows. Neither of us are developers, so are learning that side of things as best as we can while we learn Puppet, git, hiera, Geppetto (which is the bee's knees, just be super careful when you try to merge two significantly different branches together using it), beaker, rspec, ruby and so on. I'm always questioning our choice in tools because that's how you stay ahead in this game and when I go looking for why people are using Salt Stack and Ansible instead of Puppet or Chef, the number one reason I've seen is complexity of the code needed to do something. Having said that, now that I've figured out a number of things and can pretty much do anything I want with Puppet, albeit crudely (you can see my kvm/webvirtmgr module as evidence of this), I don't see a reason to switch, but I can certainly understand why some people may look at the DevOps space and gravitate towards Salt Stack and Ansible over Puppet. Thanks, Alex On Wednesday, May 7, 2014 1:18:49 AM UTC-7, Felix.Frank wrote: On 05/07/2014 12:52 AM, Ramin K wrote: I find it best not to change my workflow or methodology until it makes sense on my system regardless of what the community or even Puppet Labs has said. Ramin, I could hardly agree more. Even your ignored practices resemble my own personal choices very closely (those perhaps come rather natural to old schoolers). If I understood Alex right though, he also feels that the apparent flux might be hindering broader acceptance of Puppet. If that is indeed the case, we have a problem that we should talk about. (Note that apparent stability is more important than the technicalities.) However, it has been my feeling that general adoption is not one of Puppet's problems. On the contrary, Puppet users usually form the largest crowd in any kind of forum concerned with the configuration management problem. The user base keeps growing and the community is literally buzzing with activity. Alex, are there concrete issues that you have faced concerning the ease of adoption? Thanks, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email
[Puppet Users] Puppet module to install and configure libvirt on hosts and webvirtmgr on a separate server
Hi All, I got this fully working yesterday on CentOS 6.5 and uploaded it to github today: https://github.com/ITBlogger/puppet-kvm It's very crude, doesn't have any parameter validation or testing and requires hiera as written, but you may find it useful. At some point it would be interesting to create a custom type to do all of this, but I'm just not there yet. I ended up going this route because I couldn't get the Carla Souza based libvirt modules to work. They seem to be too far out of date at this point. None of them set up webvirtmgr for you either. Anyhow, use it, add to it, edit it, fork it, or do whatever you want with it. If you print it out, would also make for good kindling for a fire, or perhaps once shredded, good to use for the bottom of a hamster cage. Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/13823d0d-fb11-4854-a847-c96dd2f3525e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
If you are trying to follow Puppet Labs recommended best practices, it's definitely a moving target. On Mon, May 5, 2014 at 5:37 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 04/30/2014 04:28 PM, Alex Scoble wrote: I sometimes wonder how the moving target that is the Puppet DSL slows adoption of the product. Well, I don't know what part of the discussion led you to the conclusion of the Puppet DSL being a moving target, but I can confidently state that it is just not true. Yes, the language is seeing constant additions. This is inherently a good thing, because those strive to ever make the user's life easier. Such changes are usually opt-in, you don't have to use things you don't need. Sure, users face recurring issues that get iterated time and again on the list, because solving them is a less than trivial design problem. When those can eventually be solved, the offending parts may be taken out of the language (see Dynamic Scoping), but never without an appropriate deprecation phase. The dev team goes to great lengths to ensure that your manifest will not just break. As for the future parser, that is just an elegant way to allow people to preview the Puppet 4 language additions before its release (yes, Puppet 4 *will* have an enhanced DSL - I would argue against the view that turning a new page for a major release makes you a moving target). I feel compelled to add - the future parser is a preview system. It is *not* something you should enable on a production master for a realistic field test. Production grade for this parser will be reached in Puppet 4. Regards, Felix -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/QNZyd4ipB0U/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/536785FA.5030203%40alumni.tu-berlin.de . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAETmVfTTaC8zOauVdPKpQ3tiDHpuO6fVjNKmoKET6UXxb%2BpkLg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
Hi John, Thanks for the info. By the way, I started using the inherit pattern with params because of the myriad of Splunk modules out there that do it, including this one from Puppet Labs https://github.com/puppetlabs/puppetlabs-splunk I understand why the pattern is used, it makes it a bit easier to deal with variables, particularly with hiera. I also understand what you are saying. This is the sort of thing that can drive one nuts, heh. It would be nice if there was only one way to do things and the one way was also the right way, but such nirvana is hard to find. Thanks, Alex On Wed, Apr 30, 2014 at 7:15 AM, jcbollinger john.bollin...@stjude.orgwrote: On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote: Hi John, Thanks so much for your feedback. It's extremely useful for me at this stage of my education in the Puppet DSL. Here is the Puppet Users group thread where R.I. Pienaar said that he felt that using create_resources() was bad: https://groups.google. com/forum/?fromgroups#!searchin/puppet-users/create_ resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ For the record, then, R.I. said I dont tend to use create_resources as I consider it about as bad as eval() :) . I hardly find that an emphatic and categorical condemnation. In fact, I think that lines up relatively well with my own position on the matter, expressed earlier in this thread. Responses to comments: 2. As far as I can see, I'm using class inheritance solely to make sure that class parameters are available to the main and sub classes. Maybe you are seeing that I'm using inheritance where it's not yet strictly needed? I'll have to look more closely at my code and fix any instances of inheritance where it's unnecessary. Thanks. I think I was looking primarily at class kvm::virtnet. It is not parameterized itself and it does not contain any resource parameter overrides, so it cannot have any need to inherit from class kvm. Moreover, class kvm is parameterized, so *nobody* should inherit from it. It looks like you may be inheriting simply to avoid prefixing class kvm's variables with 'kvm::' where you reference them, but that's poor form even when you do use inheritance. If you are concerned about a possibility that class kvm::virtnet will be evaluated before class kvm, so that the references to kvm's variables are not resolved correctly, then 'include' class kvm instead of inheriting from it. But that's dangerous and nearly pointless. It is dangerous because if class kvm is declared via a parameterized-style declaration, and class kvm::virtnet really is evaluated first, then catalog compilation will fail -- as it would also do under the same circumstances with classes as you present. It is nearly pointless because if you can rely on class kvm being evaluated first so that catalog compilation succeeds, then class kvm::virtnet doesn't need to inherit, include, or do anything else along those lines to work properly. The caveat is that if class kvm is declared via 'include' or (I think) hiera_include(), and class kvm::virtnet is also independently declared, then it is possible for class kvm::virtnet to be evaluated first without the catalog compiler crashing later. One possible approach to that problem is basically just to say don't do that. If class kvm::virtnet is intended only for internal use by the module, as appears may be the case, then document that clearly and be done with it. None of this is an issue with respect to class kvm::virtnet being declared by class kvm, by the way; if that's the only declaration of class kvm::virtnet then class kvm is certain to be evaluated first. John -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/QNZyd4ipB0U/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/35a23857-cc2c-445e-adb0-aa8ce404e760%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/35a23857-cc2c-445e-adb0-aa8ce404e760%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAETmVfTQ-SNAksDYGpDEbZs_7wA0ka--z_%2Bc6v49fc5qHZwSaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
Thanks, R.I.Pienaar, I sometimes wonder how the moving target that is the Puppet DSL slows adoption of the product. I'll keep an eye on the future parser. Hopefully, it's in PE soon. Of course, then I'll need to wait until someone creates a useful module that shows how to use the pattern. I'm not quite smart enough (or knowledgeable enough yet) to create a new pattern on my own. Thanks, Alex On Wed, Apr 30, 2014 at 7:19 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - From: jcbollinger john.bollin...@stjude.org To: puppet-users@googlegroups.com Sent: Wednesday, April 30, 2014 3:15:03 PM Subject: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote: Hi John, Thanks so much for your feedback. It's extremely useful for me at this stage of my education in the Puppet DSL. Here is the Puppet Users group thread where R.I. Pienaar said that he felt that using create_resources() was bad: https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/create_resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ For the record, then, R.I. said I dont tend to use create_resources as I consider it about as bad as eval() :) . I hardly find that an emphatic and categorical condemnation. In fact, I think that lines up relatively well with my own position on the matter, expressed earlier in this thread. And I still think that, unfortunately there are often few other options. Today you should just suck it up and use the future parser and loop the data though, it seems to be speedy enough and relatively stable, syntax has been locked down etc. I've not followed this thread too closely but I'd hope the f.parser iterating your hashes/arrays should do all you need. If not it's probably worth highlighting those. ie. the closer to reality the f.parser becomes the less you should be using create_resources. -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/QNZyd4ipB0U/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1444896807.322.1398867543907.JavaMail.zimbra%40devco.net . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAETmVfRzC-Wd6vOzohynFj125X3Lp8b-L1p45J0yfTQsnCkCZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: variable scoping and templates
As far as I know, the only reason you would use params.pp is if you have
sane defaults you want to pass to variables. When you do, you use:
class test inherits test::params {
}
for your init.pp. You don't use an include statement as far as I know.
However, because you aren't defining sane defaults, you don't need the
params.pp.
Instead just make your test/manifests/init.pp look like:
class test {
$p1 = hiera('param1')
$p2 = hiera('param2')
file { 'testfile' :
path = /tmp/testfile,
content = template(test/testfile.erb),
}
}
Hope that helps.
--Alex
On Wednesday, April 30, 2014 11:31:03 AM UTC-7, drs wrote:
I am new to puppet and am trying to figure out variable scoping. I have a
test module that I am using for this and it looks like this:
manifiests/init.pp:
class test {
include test::params
file { 'testfile' :
path = /tmp/testfile,
content = template(test/testfile.erb),
}
}
manifests/params.pp:
class test::params {
$p1 = hiera('param1')
$p2 = hiera('param2')
}
templates/testfile.erb:
this is the first parameter: %= @p1 %
this is the second parameter: %= @p2 %
global.yaml:
---
param1: this is the first one
param2: this is the second one
Based on what I am seeing in the ProPuppet book (the discussion of the
puppet module in Chap. 2, pp69-70), this should work. However, the values
are not being inserted in the template. In order to get them in, I have to
add something like this to the init.pp manifest:
$a = $::test::params::p1
$b = $::test::params::p2
and reference @a and @b in the template.
So the question is: Am I missing something or is there an error in the
ProPuppet example?
If I need to add the $a = …. and $b=… lines to the init.pp, what, if any
is the advantage to having a params.pp manifest. I could just put the
hiera() calls in init.pp.
thanks for your patience.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/935d68a3-64cb-4f51-8fe4-a6282f4260dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: variable scoping and templates
By the way, if you are using Puppet 3.0.0 or newer you shouldn't need the
hiera() function at all.
Just call out your variables like so:
class test (
$a,
$b,
) {
file { 'testfile' :
path = /tmp/testfile,
content = template(test/testfile.erb),
}
}
In your hiera yaml it would look like (assuming you've set up your site.pp
to allow for calling classes within hiera):
---
classes:
- test
test::a:'foo'
test::b:'bar'
Hope this helps,
Alex
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/44799bde-64bb-44af-a6f8-772307f0151c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: variable scoping and templates
Heh, John, I said shouldn't need, not shouldn't use. Thanks, Alex On Wed, Apr 30, 2014 at 3:12 PM, jcbollinger john.bollin...@stjude.orgwrote: On Wednesday, April 30, 2014 3:02:14 PM UTC-5, Alex Scoble wrote: By the way, if you are using Puppet 3.0.0 or newer you shouldn't need the hiera() function at all. Not so fast. Automatic data binding does remove any *need* for writing explicit hiera() calls (provided you are willing to structure your hiera keys in a suitable way), but the implication that you in fact *shouldn't*use explicit hiera() calls is not nearly so well established. Also, if you want the special hierarchy-transcending behavior of hiera_hash() or hiera_array() (which, admittedly, are not hiera() itself) then you can only get it via the appropriate function calls. John -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/jZGsQ97oljs/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/caf5ac4a-23c2-4ad1-9b94-17d9bb30c0e4%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/caf5ac4a-23c2-4ad1-9b94-17d9bb30c0e4%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAETmVfSy_7SpD7QwdHY-USuqMxL2%2BmMObpu%3DggRGfxPBYQdzyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
Hi John, Thanks so much for your feedback. It's extremely useful for me at this stage of my education in the Puppet DSL. Here is the Puppet Users group thread where R.I. Pienaar said that he felt that using create_resources() was bad: https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/create_resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ Responses to comments: 1. That makes perfect sense. I'll do that from now on. Thanks. 2. As far as I can see, I'm using class inheritance solely to make sure that class parameters are available to the main and sub classes. Maybe you are seeing that I'm using inheritance where it's not yet strictly needed? I'll have to look more closely at my code and fix any instances of inheritance where it's unnecessary. Thanks. 3. You are right. I'm using the wrong kind of 'undef' here. 4. Yep, I'll have to look at the parameters and clean this up as well. Thanks much! Alex On Tuesday, April 29, 2014 7:10:36 AM UTC-7, jcbollinger wrote: On Monday, April 28, 2014 2:34:43 PM UTC-5, Alex Scoble wrote: Hi All, I'm working on a module that builds KVM/libvirt hosts and populates them with predefined VMs. So far I have the module to where it can create any number of virtual nets, storage pools and volumes using virsh, but it isn't pretty. I've read on various threads here that create_resources is not a good function to use. This was stated quite emphatically by R.I. Pienaar and others. If anyone has been vocal (here) about Puppet functions not to use then it's me, and create_resources() is not one I rant about. As a general rule I do prefer expressing configuration in DSL where that's feasible, and you can, in fact, do the job of create_resources() almost entirely with ordinary Puppet DSL (you need to add only stdlib's keys() function). Nevertheless, I'm not persuaded that going to substantial effort and length to avoid create_resources() is necessarily a win. On the other hand, I have come out rather strongly against the ensure_resource() function. Were you perhaps thinking of that? Already I've run into the situation where it's hard to control order in which two separate create_resources functions are run and I've seen some kludges to fix it, but I'm looking for a better way and hoping that it doesn't involve the use of custom types because that's currently more than I want to deal with. Indeed, one of the issues that does exist with create_resources() is that you cannot express resource references in Hiera data (though I have seen one recent report that claims otherwise). When part of the point of using that function in the first place is that you don't want to have to know exactly which resources you are actually declaring, that can present a challenge. It is, nevertheless, a challenge that can be worked around. In some cases, the workaround is a mechanism, such as collector chaining, that you might reasonably have used anyway. It would be super helpful if anyone could point me to a puppet module on github that presents me with a better pattern to use with the hiera data. [...] Any other help or criticisms are also welcome. That looks pretty clean to me already. It does appear that maybe you want to express relationships between your Kvm::Virtpool and Kvm::Virtvol instances, but Garrett appears already to have gotten you pointed in a useful direction with that (collector chaining). If you want responses to particular commentary about the create_resources() function then it would be helpful to provide a pointer to that commentary. R.I. is a pretty smart guy, and he has thought a lot about how Puppet can and should use data, so I'm not remotely going to try to respond to anything he may have said on the topic without actually reading it for myself Additional, minor comments about your code: 1. For any but the most simple Execs, I recommend using descriptive resource titles, and expressing the commands themselves via Exec's 'command' property. It is much, much easier that way to understand their purpose, especially in log output. 2. There are only two reasons for using class inheritance: to make a variable of the inherited class reliably available for use as a class parameter default, and to enable overriding properties of a resource declared by the inherited class. The latter is the original purpose, and the former is merely a side effect, but the former is by far the more common reason for class inheritance these days. In all other cases, an ordinary class declaration (include 'foo') can and should be used instead, if indeed anything of the sort is needed at all. Avoid class inheritance where it is unneeded. Especially avoid inheriting from a parameterized class. 3. Your class kvm has the strung 'undef' as the defined default value for a bunch
[Puppet Users] Looking for a better way to use hiera hashes than create_resources
Hi All,
I'm working on a module that builds KVM/libvirt hosts and populates them
with predefined VMs.
So far I have the module to where it can create any number of virtual nets,
storage pools and volumes using virsh, but it isn't pretty.
I've read on various threads here that create_resources is not a good
function to use. This was stated quite emphatically by R.I. Pienaar and
others.
Already I've run into the situation where it's hard to control order in
which two separate create_resources functions are run and I've seen some
kludges to fix it, but I'm looking for a better way and hoping that it
doesn't involve the use of custom types because that's currently more than
I want to deal with.
Here's what I have and hopefully someone can help me do this in a cleaner
way. Sorry that it's not in Github as I'm not ready to put it there yet.
*This is an example of the hiera data that I'm working with:*
kvm::servertype: 'kvm'
kvm::virtnet_name: 'br0'
kvm::virtnet_forwardmode: 'bridge'
kvm::virtbridge_name: 'br0'
kvm::virtnet_macaddress: '52:54:00:1F:95:6C'
kvm::virtpool_hash:
default:
virtpool_size: '429496729601'
iso-images:
virtpool_target: '/var/lib/libvirt/iso-images'
virtpool_format: 'iso'
kvm::virtvol_hash:
dtlrazorts1.img:
volcapacity: '80G'
volformat: 'qcow2'
dtlrepots1.img:
volcapacity: '80G'
volformat: 'qcow2'
dtlwebvirtmants1.img:
volcapacity: '60G'
volformat: 'qcow2'
*My init.pp*
class kvm (
$servertype = $kvm::params::servertype,
$virtnet_name= 'undef',
$virtnet_forwardmode = 'undef',
$virtbridge_name = 'undef',
$virtnet_macaddress = 'undef',
$virtpool_hash = 'undef',
$virtvol_hash= 'undef',
) inherits kvm::params {
include kvm::fw
if ($servertype == 'kvm') {
file { '/var/opt/lib/pe-puppet/temp':
ensure = directory,
owner = 'pe-puppet',
group = 'pe-puppet',
}
package { ['libvirt',
'python-virtinst',
'qemu-kvm',
'qemu-kvm-tools',
'bridge-utils',
'virt-manager',
'libguestfs-tools',]:
ensure = present,
}
service { 'libvirtd':
ensure = running,
enable = true,
hasstatus = true,
hasrestart = true,
require= Package['libvirt'],
}
if $virtpool_hash {
create_resources('kvm::virtpool', $virtpool_hash)
}
include kvm::virtnet
if $virtvol_hash {
create_resources('kvm::virtvol', $virtvol_hash)
}
}
if $servertype == 'kvmwebmgr' {
include kvm::kvmwebmgr
}
}
*The virtpool.pp file:*
define kvm::virtpool (
$virtpool= $name,
$virtpool_size = undef,
$virtpool_target = '/var/lib/libvirt/images',
$virtpool_type = 'dir',
$virtpool_format = 'raw',
) {
file { ${virtpool_target}:
ensure = directory,
} -
exec { virsh pool-define-as ${name} --target ${virtpool_target} --type
${virtpool_type} --source-format ${virtpool_format} virsh pool-autostart
${name} virsh pool-start ${name}:
path= '/usr/bin',
unless = virsh pool-list | /bin/grep ${name},
#refreshonly = true,
}
}
*The virtnet.pp file:*
class kvm::virtnet inherits kvm {
file {
/var/opt/lib/pe-puppet/temp/${hostname}_virtnet_${virtnet_name}.xml:
ensure = file,
content = template('kvm/virtnet.xml.erb'),
owner = 'pe-puppet',
group = 'pe-puppet',
} -
exec { 'virsh net-destroy default virsh net-undefine default':
path = '/usr/bin',
onlyif = 'virsh net-list | /bin/grep default',
} -
exec { virsh net-define
/var/opt/lib/pe-puppet/temp/${hostname}_virtnet_${virtnet_name}.xml
virsh net-autostart ${virtnet_name} virsh net-start ${virtnet_name}:
path = '/usr/bin',
unless = virsh net-list | /bin/grep ${virtnet_name},
}
}
*The virtvol.pp file:*
define kvm::virtvol (
$virtvol = $name,
$pool= 'default',
$volcapacity = '60G',
$volformat = 'qcow2',
) {
exec { virsh vol-create-as ${pool} ${name} ${volcapacity} --format
${volformat}:
path = '/usr/bin',
unless = virsh vol-list ${name} | /bin/grep ${name},
onlyif = virsh pool-list ${pool} | /bin/grep ${pool},
}
}
*The virtnet.xml.erb:*
network
name%= @virtnet_name %/name
forward mode='%= @virtnet_forwardmode %' /
bridge name='%= @virtbridge_name %'/
mac address='%= @virtnet_macaddress %'/
/network
-
end files
-
It would be super helpful if anyone could point me to a puppet module on
github that presents me with a better pattern to use with the hiera data.
Any other help or criticisms are also welcome.
Thanks,
Alex
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To
[Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
By the way, if it's not clear, my ultimate goal is to automate everything
so that bare metal servers pxe boot to a razor server, get their CentOS
install ISO and kickstart from razor, get installed, boot up, get their
network interfaces and logical volumes set up, get all the necessary
libvirt packages installed and configured, all the necessary bits required
to get VMs up and running (storage pools, virtual volumes, virtual
networks), VMs get spun up, they connect to razor and get their OSes
installed and everything configured through Puppet.
And the only thing I have to do is turn on the bare metal servers and sign
the puppet certs, although I will likely set the Puppet server to autosign
those as well so everything is automated. This way we can have a set of lab
systems that can be brought up and torn down as quickly as possible.
On Monday, April 28, 2014 12:34:43 PM UTC-7, Alex Scoble wrote:
Hi All,
I'm working on a module that builds KVM/libvirt hosts and populates them
with predefined VMs.
So far I have the module to where it can create any number of virtual
nets, storage pools and volumes using virsh, but it isn't pretty.
I've read on various threads here that create_resources is not a good
function to use. This was stated quite emphatically by R.I. Pienaar and
others.
Already I've run into the situation where it's hard to control order in
which two separate create_resources functions are run and I've seen some
kludges to fix it, but I'm looking for a better way and hoping that it
doesn't involve the use of custom types because that's currently more than
I want to deal with.
Here's what I have and hopefully someone can help me do this in a cleaner
way. Sorry that it's not in Github as I'm not ready to put it there yet.
*This is an example of the hiera data that I'm working with:*
kvm::servertype: 'kvm'
kvm::virtnet_name: 'br0'
kvm::virtnet_forwardmode: 'bridge'
kvm::virtbridge_name: 'br0'
kvm::virtnet_macaddress: '52:54:00:1F:95:6C'
kvm::virtpool_hash:
default:
virtpool_size: '429496729601'
iso-images:
virtpool_target: '/var/lib/libvirt/iso-images'
virtpool_format: 'iso'
kvm::virtvol_hash:
dtlrazorts1.img:
volcapacity: '80G'
volformat: 'qcow2'
dtlrepots1.img:
volcapacity: '80G'
volformat: 'qcow2'
dtlwebvirtmants1.img:
volcapacity: '60G'
volformat: 'qcow2'
*My init.pp*
class kvm (
$servertype = $kvm::params::servertype,
$virtnet_name= 'undef',
$virtnet_forwardmode = 'undef',
$virtbridge_name = 'undef',
$virtnet_macaddress = 'undef',
$virtpool_hash = 'undef',
$virtvol_hash= 'undef',
) inherits kvm::params {
include kvm::fw
if ($servertype == 'kvm') {
file { '/var/opt/lib/pe-puppet/temp':
ensure = directory,
owner = 'pe-puppet',
group = 'pe-puppet',
}
package { ['libvirt',
'python-virtinst',
'qemu-kvm',
'qemu-kvm-tools',
'bridge-utils',
'virt-manager',
'libguestfs-tools',]:
ensure = present,
}
service { 'libvirtd':
ensure = running,
enable = true,
hasstatus = true,
hasrestart = true,
require= Package['libvirt'],
}
if $virtpool_hash {
create_resources('kvm::virtpool', $virtpool_hash)
}
include kvm::virtnet
if $virtvol_hash {
create_resources('kvm::virtvol', $virtvol_hash)
}
}
if $servertype == 'kvmwebmgr' {
include kvm::kvmwebmgr
}
}
*The virtpool.pp file:*
define kvm::virtpool (
$virtpool= $name,
$virtpool_size = undef,
$virtpool_target = '/var/lib/libvirt/images',
$virtpool_type = 'dir',
$virtpool_format = 'raw',
) {
file { ${virtpool_target}:
ensure = directory,
} -
exec { virsh pool-define-as ${name} --target ${virtpool_target} --type
${virtpool_type} --source-format ${virtpool_format} virsh pool-autostart
${name} virsh pool-start ${name}:
path= '/usr/bin',
unless = virsh pool-list | /bin/grep ${name},
#refreshonly = true,
}
}
*The virtnet.pp file:*
class kvm::virtnet inherits kvm {
file {
/var/opt/lib/pe-puppet/temp/${hostname}_virtnet_${virtnet_name}.xml:
ensure = file,
content = template('kvm/virtnet.xml.erb'),
owner = 'pe-puppet',
group = 'pe-puppet',
} -
exec { 'virsh net-destroy default virsh net-undefine default':
path = '/usr/bin',
onlyif = 'virsh net-list | /bin/grep default',
} -
exec { virsh net-define
/var/opt/lib/pe-puppet/temp/${hostname}_virtnet_${virtnet_name}.xml
virsh net-autostart ${virtnet_name} virsh net-start ${virtnet_name}:
path = '/usr/bin',
unless = virsh net-list | /bin/grep ${virtnet_name},
}
}
*The virtvol.pp file
Re: [Puppet Users] Looking for a better way to use hiera hashes than create_resources
Hi Garrett, Thanks for the response. The module you posted does indeed help as it shows how to deal with hashes of hiera data without using the create_resources() function. Thanks, Alex Hi, The create_resources() function allows you to have a data driven design. This gives you the ability to specify arbitrary data in Hiera and decouple data from modules. It means you can change the data without the code. I would argue that any define in your module should have a corresponding create_resources() function, so that it can be accessed through data in Hiera. As for ordering, your defines should probably take care of that, though you can use collections with chaining to help, such as Virt::Foo || - Virt::Bar || When you are using create_resources(), I recommend also specifying an option to use hiera_hash() to collect your hashes. This does a deep hash merge and will return values from all levels of the hierarchy. My types module[1] is an example of this that lets you define file, mount, and cron resources as hashes. [1] - https://github.com/ghoneycutt/puppet-module-types Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/34d1eb41-71ee-4a5d-9258-49d3477dde13%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Looking for a better way to use hiera hashes than create_resources
I think I get it now. The types module is actually a wrapper for tying hiera hash data to the three built in types, but this pattern could also be used with a defined type perhaps? Thanks, Alex On Monday, April 28, 2014 1:05:55 PM UTC-7, Alex Scoble wrote: Hi Garrett, Thanks for the response. The module you posted does indeed help as it shows how to deal with hashes of hiera data without using the create_resources() function. Thanks, Alex Hi, The create_resources() function allows you to have a data driven design. This gives you the ability to specify arbitrary data in Hiera and decouple data from modules. It means you can change the data without the code. I would argue that any define in your module should have a corresponding create_resources() function, so that it can be accessed through data in Hiera. As for ordering, your defines should probably take care of that, though you can use collections with chaining to help, such as Virt::Foo || - Virt::Bar || When you are using create_resources(), I recommend also specifying an option to use hiera_hash() to collect your hashes. This does a deep hash merge and will return values from all levels of the hierarchy. My types module[1] is an example of this that lets you define file, mount, and cron resources as hashes. [1] - https://github.com/ghoneycutt/puppet-module-types Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/debd6399-3c00-423d-b57f-52c3d26a1d3b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Looking for a better way to use hiera hashes than create_resources
Sorry, this is what happens when I'm too tired. I see all the pieces now. The types module is using create_resources() as well as the hiera_hash() function. I'll read the collectors documentation again. Any idea why R.I. Pienaar thinks that it's a bad idea to use the create_resources() function? Thanks, Alex On Monday, April 28, 2014 1:19:50 PM UTC-7, Alex Scoble wrote: I think I get it now. The types module is actually a wrapper for tying hiera hash data to the three built in types, but this pattern could also be used with a defined type perhaps? Thanks, Alex On Monday, April 28, 2014 1:05:55 PM UTC-7, Alex Scoble wrote: Hi Garrett, Thanks for the response. The module you posted does indeed help as it shows how to deal with hashes of hiera data without using the create_resources() function. Thanks, Alex Hi, The create_resources() function allows you to have a data driven design. This gives you the ability to specify arbitrary data in Hiera and decouple data from modules. It means you can change the data without the code. I would argue that any define in your module should have a corresponding create_resources() function, so that it can be accessed through data in Hiera. As for ordering, your defines should probably take care of that, though you can use collections with chaining to help, such as Virt::Foo || - Virt::Bar || When you are using create_resources(), I recommend also specifying an option to use hiera_hash() to collect your hashes. This does a deep hash merge and will return values from all levels of the hierarchy. My types module[1] is an example of this that lets you define file, mount, and cron resources as hashes. [1] - https://github.com/ghoneycutt/puppet-module-types Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/eca95701-2e41-4c9c-b861-9e3e9a602622%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Using Puppet to automate management of KVM/libvirt VMs?
For instance, there's Carla Souza's module https://github.com/carlasouza/puppet-virt but it only handles provisioning VMs. It doesn't deal with end to end bare metal to running VMs configuration. I'm currently planning on doing a bunch using erb xml files, virsh and hierafied parameters to fill in the gaps, but that seems a bit ugly and primitive. On Tuesday, April 22, 2014 10:43:35 AM UTC-7, Alex Scoble wrote: Hi All, Is anyone here using Puppet to automate management (creation, spinup and provisioning) of VMs on KVM/libvirt hosts? If so, how are you doing it? Are you using a particular module on GitHub? Seems like there was a bunch of development done in this space in 2011 and then it just stopped. Curious to know how people are dealing with this. Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4e797888-6705-428a-b0a6-84689e694008%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Using Puppet to automate management of KVM/libvirt VMs?
Hi All, Is anyone here using Puppet to automate management (creation, spinup and provisioning) of VMs on KVM/libvirt hosts? If so, how are you doing it? Are you using a particular module on GitHub? Seems like there was a bunch of development done in this space in 2011 and then it just stopped. Curious to know how people are dealing with this. Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2f1480f1-3901-48fc-8193-3bd37e7f3512%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Books and resources for Test Driven Development for Puppet?
This seems to be the sort of thing that I'm looking for http://vstone.eu/puppet-modules-in-jenkins/ a good nuts and bolts walk through on using Jenkins to do Puppet syntax and lint checking. On Monday, March 24, 2014 10:24:35 AM UTC-7, Alex Scoble wrote: Hi All, Was wondering if anyone knew of any good books or resources for learning Test Driven Development of Puppet including puppet-rspec, beaker and Jenkins. Yes, I know that beaker is more for acceptance testing than unit testing, but I still see it as part of the testing tool chain that Puppet pros should ultimately know how to use. I'm looking for resources that really start with the basics for each subject and then help people ramp up to more advanced usage. Yes, I know there's this http://puppetlabs.com/blog/test-driven-development-with-puppet and some other blog posts, but they don't really start basic enough or go deep enough. What I'm looking for are resources that help me build our testing tool chain and also show how to use the tool chain once it's built. Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20a9a6a8-3e5a-4cb8-8cb2-3b6cfd400124%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Books and resources for Test Driven Development for Puppet?
It's kind of annoying that there's a TDD for Chef book from O'Reilly, but not one for Puppet. There's definitely a need for it, in my opinion. On Monday, March 24, 2014 10:24:35 AM UTC-7, Alex Scoble wrote: Hi All, Was wondering if anyone knew of any good books or resources for learning Test Driven Development of Puppet including puppet-rspec, beaker and Jenkins. Yes, I know that beaker is more for acceptance testing than unit testing, but I still see it as part of the testing tool chain that Puppet pros should ultimately know how to use. I'm looking for resources that really start with the basics for each subject and then help people ramp up to more advanced usage. Yes, I know there's this http://puppetlabs.com/blog/test-driven-development-with-puppet and some other blog posts, but they don't really start basic enough or go deep enough. What I'm looking for are resources that help me build our testing tool chain and also show how to use the tool chain once it's built. Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4e311142-b45c-45b2-a991-1d2e5447a5fd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Books and resources for Test Driven Development for Puppet?
Hi All, Was wondering if anyone knew of any good books or resources for learning Test Driven Development of Puppet including puppet-rspec, beaker and Jenkins. Yes, I know that beaker is more for acceptance testing than unit testing, but I still see it as part of the testing tool chain that Puppet pros should ultimately know how to use. I'm looking for resources that really start with the basics for each subject and then help people ramp up to more advanced usage. Yes, I know there's this http://puppetlabs.com/blog/test-driven-development-with-puppet and some other blog posts, but they don't really start basic enough or go deep enough. What I'm looking for are resources that help me build our testing tool chain and also show how to use the tool chain once it's built. Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b1fd7384-dbb8-49d4-b85f-a39602f1b06a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] How to group systems using Puppet and hiera?
Hi All, We are currently transitioning from using the Puppet Enterprise (PE) ENC to using hiera. Howevver, one piece of functionality that we lack with hiera is the ability to group systems together based on function. We can only currently group the systems based on available facts and are currently using environment, osfamily and domain in our hierarchy, however it would be extremely useful to also have a group or role category in our hiera hierarchy. As I see it we have a few options and hopefully, people here can add better options that they are using. The first is to use groups within the PE ENC which can apparently be used as a variable within the hiera hierarchy. This would be an easy solution, but not a very scalable one as putting systems into groups using the PE console is very slow and I haven't seen a documented way to manipulate the PE console data using a command line tool. Second is to create a custom fact named group, but this requires that each system has a yaml file dropped in the correct place and I don't see a good way to automate creation of these files using PE, which would make it scalable. One way to do it would be to create a hiera yaml for each system with group parameter set, but the whole point of this exercise is to avoid creating hiera yamls for each system in our environment. I don't see having 1000+ hiera yamls as very scalable or manageable. Third, of course, is to just manage this with individual hiera yamls for each system where classes required for that system's functions, but can't be defined higher up in the hierarchy, would be called out, but as I said before, this option isn't very scalable or manageable. If you are using Puppet and hiera, how are you managing groups of systems (web servers, Nessus servers, mail servers, etc.)? Thanks, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/234ab5f3-bb1e-43a8-b365-bd110e5052da%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppetlabs-dhcp - Failed to parse template dhcp/dhcp.pool.erb, undefined method each
When I change it to an array it injects a comma into the range and DHCP
pukes.
On Thursday, January 24, 2013 3:20:46 AM UTC-8, Peter wrote:
Not sure if it is the reason but making the change seems to fix it. Just
incase anyone else comes across this in the future.
The init.pp file calling the Pool's template (
https://github.com/puppetlabs/puppetlabs-dhcp/blob/master/tests/init.pp)
is passing a string not an array hence the variable not having an each
method (see below for extract)
dhcp::pool{ 'example.com':
network = '10.1.1.0',
mask= '255.255.255.0',
range = *'10.1.1.100 10.1.1.200'*,
gateway = '10.1.1.1',
}
By changing the underlined and bolded part to ['10.1.1.100', '10.1.1.200']
fixed the error ... go figure. Not sure some ruby setting on my end is not
tweaked right or these things get through the test harness?
Peter.
On Thursday, 24 January 2013 09:55:57 UTC+11, Peter wrote:
Hi List,
After installing the puppetlabs-dhcp module and trying to run the
tests/init.pp file I receive and error see below for sequence:
puppet module install zleslie/dhcp
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
âââ zleslie-dhcp (v1.1.0)
(**Needed to install the concat dependacy for the Puppetlabs-dhcp module.
Raised a github issue (#17) to include the dependency in the module**)
puppet module install ripienaar/concat
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
âââ ripienaar-concat (v0.2.0)
puppet apply /etc/puppet/modules/dhcp/tests/init.pp --verbose
Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/pe_version.rb
Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/root_home.rb
Info: Loading facts in
/etc/puppet/modules/stdlib/lib/facter/puppet_vardir.rb
Info: Loading facts in
/etc/puppet/modules/stdlib/lib/facter/facter_dot_d.rb
Info: Loading facts in
/etc/puppet/modules/concat/lib/facter/concat_basedir.rb
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera
defaults
Error: Failed to parse template dhcp/dhcpd.pool.erb:
Filepath: /etc/puppet/modules/dhcp/templates/dhcpd.pool.erb
Line: 7
Detail: undefined method `each' for 10.1.1.100 10.1.1.200:String
at /etc/puppet/modules/dhcp/manifests/pool.pp:15 on node
creator.mgnt.local
Error: Failed to parse template dhcp/dhcpd.pool.erb:
Filepath: /etc/puppet/modules/dhcp/templates/dhcpd.pool.erb
Line: 7
Detail: undefined method `each' for 10.1.1.100 10.1.1.200:String
at /etc/puppet/modules/dhcp/manifests/pool.pp:15 on node
creator.mgnt.local
My question is what could be causing this? I assume that this is
something to do with Puppet's DSL?
Thanks,
Peter
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/42592cc9-c180-48e6-976f-f70c705cc3e4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppetlabs-dhcp - Failed to parse template dhcp/dhcp.pool.erb, undefined method each
Nevermind. I think the problem was that I was splitting it up into two
members of an array with a comma as opposed to just keeping it one long
string. So yeah, this fix worked.
Thanks,
Alex
On Wednesday, November 20, 2013 12:24:03 PM UTC-8, Alex Scoble wrote:
When I change it to an array it injects a comma into the range and DHCP
pukes.
On Thursday, January 24, 2013 3:20:46 AM UTC-8, Peter wrote:
Not sure if it is the reason but making the change seems to fix it. Just
incase anyone else comes across this in the future.
The init.pp file calling the Pool's template (
https://github.com/puppetlabs/puppetlabs-dhcp/blob/master/tests/init.pp)
is passing a string not an array hence the variable not having an each
method (see below for extract)
dhcp::pool{ 'example.com':
network = '10.1.1.0',
mask= '255.255.255.0',
range = *'10.1.1.100 10.1.1.200'*,
gateway = '10.1.1.1',
}
By changing the underlined and bolded part to ['10.1.1.100',
'10.1.1.200'] fixed the error ... go figure. Not sure some ruby setting on
my end is not tweaked right or these things get through the test harness?
Peter.
On Thursday, 24 January 2013 09:55:57 UTC+11, Peter wrote:
Hi List,
After installing the puppetlabs-dhcp module and trying to run the
tests/init.pp file I receive and error see below for sequence:
puppet module install zleslie/dhcp
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
âââ zleslie-dhcp (v1.1.0)
(**Needed to install the concat dependacy for the Puppetlabs-dhcp
module. Raised a github issue (#17) to include the dependency in the
module**)
puppet module install ripienaar/concat
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
âââ ripienaar-concat (v0.2.0)
puppet apply /etc/puppet/modules/dhcp/tests/init.pp --verbose
Info: Loading facts in
/etc/puppet/modules/stdlib/lib/facter/pe_version.rb
Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/root_home.rb
Info: Loading facts in
/etc/puppet/modules/stdlib/lib/facter/puppet_vardir.rb
Info: Loading facts in
/etc/puppet/modules/stdlib/lib/facter/facter_dot_d.rb
Info: Loading facts in
/etc/puppet/modules/concat/lib/facter/concat_basedir.rb
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera
defaults
Error: Failed to parse template dhcp/dhcpd.pool.erb:
Filepath: /etc/puppet/modules/dhcp/templates/dhcpd.pool.erb
Line: 7
Detail: undefined method `each' for 10.1.1.100 10.1.1.200:String
at /etc/puppet/modules/dhcp/manifests/pool.pp:15 on node
creator.mgnt.local
Error: Failed to parse template dhcp/dhcpd.pool.erb:
Filepath: /etc/puppet/modules/dhcp/templates/dhcpd.pool.erb
Line: 7
Detail: undefined method `each' for 10.1.1.100 10.1.1.200:String
at /etc/puppet/modules/dhcp/manifests/pool.pp:15 on node
creator.mgnt.local
My question is what could be causing this? I assume that this is
something to do with Puppet's DSL?
Thanks,
Peter
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1359ff59-460d-4d1c-8148-998eea162cbd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Anyone currently using Puppet environments, gitolite and the Puppet post-receive hook?
Hi All, I'm trying to use gitolite to control who has access to our puppet code in git and running into problems with the Puppet Labs semi-official post-receive hook https://github.com/adrienthebo/puppet-git-hooks/blob/master/post-receive/dynamic-environments I have gitolite working to where I can do all of the usual git commands on my repos, but the post-receive hook isn't working. I get the following errors when doing a push: remote: /usr/lib/ruby/1.8/fileutils.rb:1231:in `chown': Operation not permitted - /etc/puppetlabs/puppet/environments/hieratest (Errno::EPERM) remote: from /usr/lib/ruby/1.8/fileutils.rb:1231:in `chown' remote: from /usr/lib/ruby/1.8/fileutils.rb:967:in `chown_R' remote: from /usr/lib/ruby/1.8/fileutils.rb:1331:in `traverse' remote: from /usr/lib/ruby/1.8/fileutils.rb:965:in `chown_R' remote: from /usr/lib/ruby/1.8/fileutils.rb:964:in `each' remote: from /usr/lib/ruby/1.8/fileutils.rb:964:in `chown_R' remote: from hooks/post-receive:95 remote: from hooks/post-receive:39:in `each_line' remote: from hooks/post-receive:39 Does anyone have any ideas on how I can get the post-receive hook to work? Otherwise we won't be able to use gitolite and that would be a shame. Regards, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d7b299c2-2838-44a6-bf4a-b53bb22a3c47%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Anyone currently using Puppet environments, gitolite and the Puppet post-receive hook?
My current solution is to have the post-receive hook put the pushed branch to /var/staging/environments and then have a cron job run every minute or so that rsyncs all of the environments (except for production, which will have to be synced manually) to /etc/puppetlabs/puppet/environments and manage the permissions (chown, chmod) with rsync as well. It would be nicer to be able to do the rsync whenever a git push is done, but the mechanics of that are more complicated and a project for a later date. Any thoughts? --Alex On Tuesday, October 29, 2013 12:40:11 PM UTC-7, Alex Scoble wrote: Hi All, I'm trying to use gitolite to control who has access to our puppet code in git and running into problems with the Puppet Labs semi-official post-receive hook https://github.com/adrienthebo/puppet-git-hooks/blob/master/post-receive/dynamic-environments I have gitolite working to where I can do all of the usual git commands on my repos, but the post-receive hook isn't working. I get the following errors when doing a push: remote: /usr/lib/ruby/1.8/fileutils.rb:1231:in `chown': Operation not permitted - /etc/puppetlabs/puppet/environments/hieratest (Errno::EPERM) remote: from /usr/lib/ruby/1.8/fileutils.rb:1231:in `chown' remote: from /usr/lib/ruby/1.8/fileutils.rb:967:in `chown_R' remote: from /usr/lib/ruby/1.8/fileutils.rb:1331:in `traverse' remote: from /usr/lib/ruby/1.8/fileutils.rb:965:in `chown_R' remote: from /usr/lib/ruby/1.8/fileutils.rb:964:in `each' remote: from /usr/lib/ruby/1.8/fileutils.rb:964:in `chown_R' remote: from hooks/post-receive:95 remote: from hooks/post-receive:39:in `each_line' remote: from hooks/post-receive:39 Does anyone have any ideas on how I can get the post-receive hook to work? Otherwise we won't be able to use gitolite and that would be a shame. Regards, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7d6470ad-c1cb-4676-af32-9376039e0a5e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Building another Puppet module for Splunk
By the way, I forgot to give thanks to the Puppet SE Team and to dhogland for their work on similar Splunk modules. I definitely integrated a lot of the work that they did into my module. Thanks, Alex On Tuesday, October 15, 2013 2:21:45 PM UTC-7, Alex Scoble wrote: Hi All, I've been working on yet another Puppet module to deploy and manage Splunk. Yep, I know that there are already many out there, but none do what I need and also work the way we work and also have control of the various conf files built in. It's still a work in progress and isn't fully documented, but it is working for systems running RHEL 6. I also plan to get it working and featurefull for Windows systems as well. I'm sure that Debian support wouldn't be too hard either, but I'll leave that to others to do if they so choose. This is also my first github project, coincidentally. You can find it here: https://github.com/ITBlogger/puppet-module-splunkmgr I've tried to follow Puppet's style guide as much as possible and have used Puppet Labs' own NTP module as a style reference as well. Sorry that the manifests related to managing the conf files (particularly the Splunk App for *nix one) aren't all that easy to read, but the module is managing a lot of stanzas in the conf files. A few things you should know to use the module: It requires - This https://github.com/ITBlogger/puppet-splunk_conf/tree/patch-1 branch of cwooley's splunk_conf module which uses augeas to manage the conf file stanzas. I'm waiting for him to merge in my pull request, but until then you'll need to use my branch. This is because I changed his module to decouple stanza names from resource titles. This allows you to modify stanzas in two different conf files if needed. I originally did this so that Splunk and Splunk Universal Forwarder could be on the same system, but found this to be unnecessary in Splunk 6, but still liked the ability to name resource titles differently from stanza names. - The puppetlabs/firewall module - Puppet 3.0 or higher - All packages be served up by a private repo server - this could easily be changed to suit your needs, but this is how we work. We avoid putting installers and packages within Puppet modules and leverage Puppet's package management and software installation providers It is written to take advantage of hiera, but use of hiera isn't strictly necessary, although the documentation is written with hiera in mind using yaml as the backend. After using hiera for a few months, I can't imagine a better way to manage nodes. As we are PE customers, we never used node classifier manifests and instead used the dashboard to manage nodes and hiera is way better than that. I also like it better than node classifier manifests as those put configuration data into your Puppet modules and I'm definitely a believer in keeping data and config management modules separate. Any input or constructive criticism you have would be much appreciated. Regards, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Building another Puppet module for Splunk
Hi All, I've been working on yet another Puppet module to deploy and manage Splunk. Yep, I know that there are already many out there, but none do what I need and also work the way we work and also have control of the various conf files built in. It's still a work in progress and isn't fully documented, but it is working for systems running RHEL 6. I also plan to get it working and featurefull for Windows systems as well. I'm sure that Debian support wouldn't be too hard either, but I'll leave that to others to do if they so choose. This is also my first github project, coincidentally. You can find it here: https://github.com/ITBlogger/puppet-module-splunkmgr I've tried to follow Puppet's style guide as much as possible and have used Puppet Labs' own NTP module as a style reference as well. Sorry that the manifests related to managing the conf files (particularly the Splunk App for *nix one) aren't all that easy to read, but the module is managing a lot of stanzas in the conf files. A few things you should know to use the module: It requires - This https://github.com/ITBlogger/puppet-splunk_conf/tree/patch-1 branch of cwooley's splunk_conf module which uses augeas to manage the conf file stanzas. I'm waiting for him to merge in my pull request, but until then you'll need to use my branch. This is because I changed his module to decouple stanza names from resource titles. This allows you to modify stanzas in two different conf files if needed. I originally did this so that Splunk and Splunk Universal Forwarder could be on the same system, but found this to be unnecessary in Splunk 6, but still liked the ability to name resource titles differently from stanza names. - The puppetlabs/firewall module - Puppet 3.0 or higher - All packages be served up by a private repo server - this could easily be changed to suit your needs, but this is how we work. We avoid putting installers and packages within Puppet modules and leverage Puppet's package management and software installation providers It is written to take advantage of hiera, but use of hiera isn't strictly necessary, although the documentation is written with hiera in mind using yaml as the backend. After using hiera for a few months, I can't imagine a better way to manage nodes. As we are PE customers, we never used node classifier manifests and instead used the dashboard to manage nodes and hiera is way better than that. I also like it better than node classifier manifests as those put configuration data into your Puppet modules and I'm definitely a believer in keeping data and config management modules separate. Any input or constructive criticism you have would be much appreciated. Regards, Alex -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending on
the structure above. I want each sudoers definition to be in it's own file
in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not using
'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs, hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: What's your hiera tree look like?
I couldn't get hiera integrated with PE 3.0.1 to work with nested
hierarchies, so this is what my hierarchy looks like:
:hierarchy:
- defaults
- %{clientcert}
- %{domain}
- %{osfamily}
- %{environment}
- global
Regards,
Alex
On Tuesday, March 19, 2013 2:30:16 PM UTC-7, Larry Fast wrote:
My Hiera tree is turning into a chaotic mess. I'm guessing that my tree
structure is one problem source. So I'm wondering how other real users have
setup hiera. Here are the core problems that are giving me headaches.
# I need to version control my modules separately but hiera data is
monolithic. If I need to change anything anywhere, I need to release a new
version of the whole tree.
# I can't easily review the final output from hiera within puppet because
the traversal is dependent on facts. I need to feed the facts into Hiera
before I get anything meaningful.
# Can't easily compare the config of two different servers. (really the
same as the previous)
Here's my Hiera tree. I'm very interested to know how others deal with
these issues. Does Puppet Enterprise include Hiera mgmt tools?
- %{environment}/%{project}/%{server_env}/%{module_name}
- %{environment}/%{project}/%{server_env}/common
- %{environment}/%{project}/%{role_name}-role/%{module_name}
- %{environment}/%{project}/%{role_name}-role/common
- %{environment}/%{project}/%{module_name}
- %{environment}/%{location}/%{module_name}
- %{environment}/%{module_name}
- %{environment}/common
NOTES:
Each Environment is a copy of our git repo and includes the hiera tree.
Project, Server_env, Role_name Location are custom facts
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Yeah, I'll have to try again after upgrading to PE 3.1 which was just
released.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested directory
works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending
on the structure above. I want each sudoers definition to be in it's own
file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Dumb question...have you tried loading the data into a hiera array since
that's apparently what it's looking for?
Another dumb question...what's the pipe (|) for in your yaml data?
Unfortunately, the hiera documentation on the Puppet site is a bit thin and
I don't see that in the examples.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested directory
works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending
on the structure above. I want each sudoers definition to be in it's own
file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Great thanks...still learning.
On Tue, Oct 15, 2013 at 7:53 PM, David Patterson
pattersondav...@gmail.comwrote:
Yes to the array. I get this error when I try:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
As for the pipe, it preserves newlines:
http://en.wikipedia.org/wiki/YAML#Newlines_preserved
On Tuesday, October 15, 2013 7:38:50 PM UTC-7, Alex Scoble wrote:
Dumb question...have you tried loading the data into a hiera array since
that's apparently what it's looking for?
Another dumb question...what's the pipe (|) for in your yaml data?
Unfortunately, the hiera documentation on the Puppet site is a bit thin and
I don't see that in the examples.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested
directory works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at
least let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that,
so there may be some differences with that and the version of hiera that
you are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::**clientcert}
- datacenter/app/role/%{::**server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/
depending on the structure above. I want each sudoers definition to be in
it's own file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::**sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::**sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::**sudo_configs,
flatten(hiera_debug_array('**sudoers')))
}
define sudo_crap::sudo_configs($**filename, $contents) {
file {/tmp/etc/sudoers.d/$**filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully
with some code examples :) I've been banging my head on this for the
better part of 2 weeks :)
Thanks!
David
--
You received this message because you are subscribed to a topic in the
Google Groups Puppet Users group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/puppet-users/ZQjzAife5-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
