[Puppet Users] First anniversary of the module team
The 1st anniversary of the module team! Hello from the module team here at Puppet Labs! I’m starting this email with a lie because I’m not sure exactly when our first anniversary really is, but I started on the 1st of July and the team had only just gotten started, so that’s as good a date as any. For those readers who are unaware, the module team at Puppet Labs exists primarily to implement the supported modules initiative. For anyone that missed the announcement last year, the goal of supported modules is to help you more easily discover amazing modules and offer support for those modules to Puppet Enterprise customers. Over the last year we’ve been laying the foundations to make this sustainable (and making it up as we go along). In order to support modules across the diverse set of platforms PE runs on, we’ve had to experiment with and learn how to test modules in a sustainable, scalable way, and over the last year we’ve been trying to accomplish that. Members of the team Before we talk about what we’ve been doing over the last year, I thought it would be nice to briefly talk about who is in the team, our backgrounds, and where you can get hold of us. I’ll list everyone in the order they joined the team to make life easy for me. Hunter Haugen Hunter was the very first member of the team and many of you know him as “hunner” on IRC. Previously a member of the Professional Services team, Hunter spent his time traveling and visiting customers all over the world. His background, like mine, is mostly UNIX systems administration. He’s responsible for the huge refactoring of the apache module a while back, and is all over the popular puppetlabs modules we hope you’re all using. Ashley Penney This one is me. I’m “ashp” on IRC and hopefully I know many of you. I’ve been a Puppet user since the start of 2008, when I spent most of my time harassing Luke on IRC over “bugs” I found that turned out to be fundamental design decisions. I’ve been in operations for ~12 years, and this is the only job I’ve ever had where nobody will wake me up at 0300 to let me know everything has crashed and the world is on fire. It’s pretty awesome. Chris Hoge Anyone here who has used the openstack modules can thank Chris for putting in a ton of work to make them awesome. Just before I took this job, I tried to use the puppetlabs openstack modules and after a week I threw up my hands and gave up as nothing worked. Now they actually work and are awesome. Progress! Chris primarily focuses on openstack, but he sometimes has to wrestle modules that are dependencies into shape (like mongodb!). You can find him as “hogepodge” on IRC. Travis Fields Travis joined to help the module team build out and build up awesome modules specifically for Windows. The rest of us are Linux users, so we often just threw up our hands and said “I can’t fix that!” when modules had issues on Windows. Since joining the team, he’s taken over the reboot and registry modules, fixed vcsrepo to work on windows, taken on the new acl module, as well as fixed a number of issues throughout our tooling to make sure Windows is a true first class platform for modules instead of something we hide under the bed from. Travis goes by “cyberious” on IRC. Morgan Haskel Morgan previously worked with Onyxpoint (a long time Puppet community member!) on Puppet modules. Battle-scarred from forcing complex modules into behaving properly, she joined Puppet Labs to help us write amazing supported modules. She’s brought some adult supervision to the team and ensures we’re on a regular cadence for module releases. You can ask her questions about Hadoop (she’ll love it, I promise) on IRC as “_morgan”. AJ Johnson The almost-newest member of the team is our boss; he's in charge of ensuring we’re all pointing in the right direction and focused on actually building things the community benefits from. He escaped from IBM to come wrangle the team into a semblance of order and make sure we’re on track to deliver supported modules! Colleen Murphy The actual-newest member of the team comes to us for the summer as an intern from PSU (that’s the portland one, not the Pennsylvania one). She’s a Linux sysadmin, Puppet user, and developer, and she is already helping us tackle a project we’ve been putting off for months. You can find her on IRC as “crinkle”. If you’re igalic or blkperl then I preemptively ban you from asking her for PR merges! :) Other People This is already longer than an Oscar acceptance speech, so I want to wrap up by just saying that we have a bunch of other fantastic people that help us keep this show on the road. Lauren Rother helps ensure modules have documentation that makes sense, Heidi Pio shouts at us when we don’t close JIRA tickets, Justin Stoller makes the CI environment work, John Duarte shakes his head at our attempts at risk assessments and testing plans, Ryan Coleman helps us figure out what we’re even meant to be building
[Puppet Users] Module team update: 2013-09-24 - 2013-12-12
://forge.puppetlabs.com/puppetlabs/apache/0.10.0
http://forge.puppetlabs.com/puppetlabs/vswitch/0.2.0
So you know, just a little bit of work.
#Other stuff
I rewrote the yumrepo{} type/provider in upstream Puppet but it's still in
a PR. It should make developing providers (it didn't have one before)
significantly easier for the community.
We're still just a team of 3, so I'm afraid this is all we were able to get
done, but we'll continue working on bringing you great modules and working
on improving the testing of these modules so we can keep making releases
that don't blow up in your face. :)
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
Join us at PuppetConf 2014, September 23-24 in San Francisco
--
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/CAC9eg%2BkdpuWMcxegPa4%3DNySO%2BibN1sJpOyfRqvr8JHWyKjV%3DuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Added $::osfamily=Solaris support for the puppetlabs/ntp module
If you make this a PR it would be easier to review. The major problems I see is that you removed AIX and Gentoo support (I also like to stick it to those Gentoo users, but they might get a little upset..). You also added the 'restrict' keyword back in to restrict lines but we automatically prepend that in the template. If you make a PR against NTP I can help you review and iterate on it there however, as I can make comments inline. :) On Thu, Nov 21, 2013 at 2:24 PM, Richard Feltstykket zorgofal...@gmail.comwrote: Hi, I've added preliminary support for $::osfamily=Solaris on the puppetlabs/ntp module to the below branch on github. It works for me on OpenIndiana Hipster. This is really my first use of github and contributing to the puppetforge in general, so can someone tell me if I've done anything wrong? I'm going to go snag my puppet training book and make sure I've done the tests right, and then I'll commit those to this branch as well. https://github.com/ramassa/puppetlabs-ntp/tree/feature/master/solaris_support Thanks, Richard -- 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/c1e2389f-2881-4b59-91b0-5ee3072b26cb%40googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. -- Ashley Penney ashley.pen...@puppetlabs.com Module Engineer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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/CAC9eg%2BmUwQvgsdmngx3r%2BaF5cOBc%3DECb%2BHxH8ij_ku0%2Bj%3Ducrw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet module list error: Error: No source module metadata provided for mcollective
Hi! I'm afraid this was mostly my fault, we released a version of mcollective without some needed metadata and recently changes made this more problematic than it used to be. I've uploaded a new release so you should be able to fix this with: puppet module uninstall puppetlabs-mcollective puppet module install puppetlabs-mcollective If the uninstall step doesn't work, just rm -rf /etc/puppetlabs/puppet/modules/mcollective altogether to force the issue. After this is done you should have v1.1.3 and things should work better! On Wednesday, November 13, 2013 3:45:49 PM UTC-5, Puppet Muppet wrote: Hi, I'm new to Puppet and having some trouble running the following commands on my Puppet Server. #puppet module list or #puppet module install puppetlabs/apt I get the following error. Notice: Preparing to install into /etc/puppetlabs/puppet/modules ... Error: No source module metadata provided for mcollective Error: Try 'puppet help module install' for usage The version I am running is Puppet v3.3.1 (Puppet Enterprise 3.1.0) Would you be able to point me in the right direction please. Many thanks! PM -- 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/56073e65-a2cb-4a18-82e1-7abf643f52d2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Module team update: 2013-09-04 - 2013-09-23
I am terrible at getting these out on schedule.
Another busy month with a whole bunch of stuff going on, internally and
externally. The main highlights of the month are the recently rewritten
puppetlabs-mysql and puppetlabs-postgresql modules. Both have had huge
overhauls internally and are now (hopefully) vastly more useful for end
users.
*What did you guys do to my databases?*
*
*
I'm going to selfishly talk about puppetlabs-mysql first as I'm about to
refactor in my changes today. Over the last month I've done two large
things for the MySQL module.
First, I've written replacement types and providers for the venerable mysql
providers that have been floating around for Puppet modules for years now.
(First provider I ever modified for internal use, in the distant past)
These replacements are called mysql_grant, mysql_user, and mysql_database
and hopefully represent a reasonable set of improvements. The major thing
I wanted was to allow them to work with puppet resource so that from the
cli you can do:
# puppet resource mysql_user blah@host ensure=absent and have things work.
This was mostly for selfish reasons as I can never remember the syntax to
add users.
Second, I've refactored the module substantially. Previously we relied on
enormous numbers of parameters in an attempt to manage /etc/.my.cnf and we
constantly received pull requests to add new parameters. The new module
blows all this away and allows you to do:
mysql::globals {
override_options = { 'mysqld' = 'max_connections' = '256' }
}
You can feed it any my.cnf options you want and they will magically appear.
It has some downsides in that we can't validate what you put into my.cnf
by allowing you to set any keys, but there's a few thousand possible
entries to my.cnf and it's not realistic for us to handle them all.
I'm thinking long term we'll pull certain key values out into parameters
like before and just merge those into the hash used to write out .my.cnf.
*And postgresql?*
*
*
Ken Barber completely rewrote this to be much more flexible than before and
to use a type/provider to build up the configuration, allowing you to just
drop in configuration resources easily. I won't talk as much about this
here as I don't have a full a picture of it as I do for mysql but it's in
the master branch of puppetlabs-postgresql right now and available for
testing.
*What modules did you release since the last update?*
*
*
http://forge.puppetlabs.com/puppetlabs/ntp/2.0.1
http://forge.puppetlabs.com/puppetlabs/apache/0.9.0
http://forge.puppetlabs.com/puppetlabs/postgresql/2.5.0
http://forge.puppetlabs.com/puppetlabs/pe_upgrade/2.0.0
http://forge.puppetlabs.com/puppetlabs/git/0.0.3
http://forge.puppetlabs.com/puppetlabs/firewall/0.4.2
http://forge.puppetlabs.com/puppetlabs/apt/1.3.0
And some from other teams worth mentioning:
http://forge.puppetlabs.com/puppetlabs/reboot - a type/provider to schedule
reboots (windows only for now)
http://forge.puppetlabs.com/puppetlabs/registry/0.1.2
http://forge.puppetlabs.com/puppetlabs/java_ks/1.2.0
*What else are you guys up to?*
*
*
Lots of little things! I've been working on documentation, understanding
data-in-modules, testing (updating the vcsrepo spec tests from rspec1 to
rspec2). Hunter's working on a huge amount of stuff from beaker
(acceptance testing) to scaling guides to more work on the apache module.
I'm sure I've missed a bunch of stuff we're doing but as always swing by
#puppet and shout at ashp (or hunter) if you want anything module related
or just want to throw us your worst I can't figure out how to.. problems.
Thanks,
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
--
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] Need help starting with puppet
If you haven't already done this you should head over to http://apt.puppetlabs.com/ after the vagrant instance boots and grab the appropriate http://apt.puppetlabs.com/puppetlabs-release-precise.debpackage first so that you're using our packages rather than the default Ubuntu ones. Hopefully if you use those you should get a better result! On Fri, Sep 6, 2013 at 10:29 PM, audrey.lee.is...@gmail.com wrote: hello world. I found the learning puppet site so I thought that would be a good place to start. I downloaded the vm. I was able to import it into virtualbox. But then it hung during bootup. So I used vagrant to vagrant up a clean precise64 box. I did apt-get install puppet apt-get got me this: vagrant@precise64:~$ vagrant@precise64:~$ puppet --version 2.7.11 vagrant@precise64:~$ vagrant@precise64:~$ which puppet /usr/bin/puppet vagrant@precise64:~$ vagrant@precise64:~$ aptitude search puppet p etherpuppet p etherpuppet:i386 p mcollective-plugins-puppetca p mcollective-plugins-puppetd p mcollective-plugins-puppetral i puppet i A puppet-common p puppet-el p puppet-lint p puppet-testsuite p puppetmaster p puppetmaster-common p puppetmaster-passenger p vim-puppet vagrant@precise64:~$ vagrant@precise64:~$ Then I tried the first command in learning puppet: puppet resource service I saw a screen full of warnings like this 1: warning: Service network-interface-container found in both debian and upstart; skipping the upstart version Then I saw an error at the end: Could not run: Execution of '/sbin/status wait-for-state' returned 1: status: Unknown parameter: WAITER I tried a reboot to see if that helped. Reboot did not help. I'm looking for clues on how to get puppet up in a clean ubuntu 12.04 virtual box. If I need to steer clear of Vagrant to make puppet work, that is a non-starter for us. We had planned to do a lot of mixing of Vagrant and puppet. -- 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. -- Ashley Penney ashley.pen...@puppetlabs.com Module Engineer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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] Module team update: 2013-08-09 - 2013-09-03
Going forward I'm going to aim for this twice a month as weekly is too frequent and I forget to write them every week. This update is dedicated to blkperl who keeps me writing them by reminding me every time I forget. It's been a busy month and with Puppetconf falling in the middle of the month progress has been a bit all over the place. Our focus this month has been on connecting with the community, discussing module standards, testing, and all the stuff around the edges of modules. One piece of solid work that's come out of this is the Beginners Guide to Modules, the very beginning piece of our drive towards having a coherent set of module documentation that covers everything from how a beginner should lay out a module to best practices for types/providers, all the way to testing frameworks. Obviously this is a new thing for us so you'll have to help us to help you by giving us awesome feedback on how to improve the guide and what information you would most like to see Puppetlabs standardize and define next. The guide is at http://links.puppetlabs.com/bgtm and we'll be working to clean it up, move it to our real documentation site and get space built for us to write more. I've already done some more work towards an Advanced guide and towards some blog posts to showcase existing modules (like stdlib) and other techniques to help you improve modules. RELEASES: Not as many releases this month, we're sort of focused on other areas and groundwork to make this easier going forward: http://forge.puppetlabs.com/puppetlabs/nodejs/0.4.0 http://forge.puppetlabs.com/puppetlabs/firewall/0.4.1 http://forge.puppetlabs.com/puppetlabs/concat/1.0.0 http://forge.puppetlabs.com/puppetlabs/gcc/0.1.0 http://forge.puppetlabs.com/puppetlabs/rabbitmq/3.0.0 http://forge.puppetlabs.com/puppetlabs/ntp/2.0.0 From other groups: http://forge.puppetlabs.com/puppetlabs/puppetdb/1.6.0 http://forge.puppetlabs.com/puppetlabs/gce_compute/0.1.0 - from google! WORK IN PROGRESS Hunter has been working on puppetlabs-apache, merging in endless PRs and helping to improve that module even more. Alongside that he's working on beaker, the previously named puppet-acceptance framework. We're looking to adopt it for testing modules but we're in the middle of learning about it and figuring out how to best adopt it so it's easy for community members to get going with. The earlier part of the month was taken up with Puppetconf prep for his talk (which I heard was awesome and enjoyed by all!) He also made https://github.com/hunner/roles_and_profiles as part of this, so check that out. Ken (honorary member of the module team this week!) has completely refactored puppetlabs-postgresql and has a massive pull request in completely overhauling the module. It looks fantastic and will be vastly easier to work with and ensure that we don't have weird dependency issues going forward. Ashley (me) has been in the weeds in the MySQL module for a while now. I've written some new types: mysql_user, mysql_db, mysql_grant to replace the existing ones that had a number of issues that were making working with this module difficult. The new ones can all be called with puppet resource allowing you to manipulate mysql via puppet without having to use manifests. They all have various improvements and will underlie the refactoring work that I plan to do in the MySQL module in the next few weeks. Puppetconf made it very clear to me that the community cares deeply about the MySQL module but many people fork it off due to the difficulty with adding your own configuration params, installation sources, and general ability to tweak the module without difficulty. One of the reasons I've been working on the providers and types is to make sure I have fresh pain in my mind before I start writing some beginner provider/types documentation for the module team. MySQL has proven to be an absolute nightmare to write these types for so I'm full of pain points to touch on to make sure the rest of you have an easier time in the future. -- Ashley Penney ashley.pen...@puppetlabs.com Module Engineer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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] pupplet-labs/firewall module errors
On Thu, Aug 29, 2013 at 12:57 AM, Amol Kedar ajke...@gmail.com wrote: i see this error on the daemon.log of the agent machine Aug 28 17:11:07 dev2-db puppet-agent[5154]: (/Stage[main]//Node[dev2-db]/Resources[firewall]) Failed to generate additional resources using 'generate': Invalid address from IPAddr.new: !Aug 28 17:11:08 dev2-db puppet-agent[5154]: Could not prefetch firewall provider 'iptables': Invalid address from IPAddr.new: !Aug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[000 accept all icmp]) Could not evaluate: Invalid address from IPAddr.new: ! Aug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[001 accept all to lo interface]) Dependency Firewall[000 accept all icmp] has failures: trueAug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[001 accept all to lo interface]) Skipping because of failed dependencies Aug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[002 accept related established rules]) Dependency Firewall[000 accept all icmp] has failures: trueAug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[002 accept related established rules]) Skipping because of failed dependencies Aug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[999 drop all]) Dependency Firewall[000 accept all icmp] has failures: trueAug 28 17:11:08 dev2-db puppet-agent[5154]: (/Firewall[999 drop all]) Skipping because of failed dependenciesAug 28 17:11:08 dev2-db puppet-agent[5154]: Finished catalog run in 1.19 seconds if anyone has any prior experience with this, please let me know I haven't seen this before but - can you show me a full iptables from an existing client, a full ifconfig, and maybe even the result of: $ irb irb(main):002:0 require 'ipaddr' = true irb(main):003:0 IPAddr.new = #IPAddr: IPv6::::::::/::::::: That's what I get for a plain call to IPAddr.new, I'm wondering what you're getting. -- Ashley Penney ashley.pen...@puppetlabs.com Module Engineer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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] params pattern when writing modules
As one of the two new maintainers of all Puppetlabs modules I can tell you for sure that our intent is to make sure everything in init.pp inherits out of params.pp instead of declaring them directly in the main class, and if you're kind enough and can throw a github issue up for any cases you notice where that's not true we can fix them. I never liked the params.pp pattern myself but there's no great solution to where do I store all my weird logic to make the rest of my classes simple. We're standardizing on keeping all params defined in params.pp and inheriting that in init.pp so that they can be overridden. I can't claim it's the best pattern, but we're at least going to strive for consistency. (For background, each puppetlabs module was written by a different person with their own views on this stuff and we had no unifying style guide or guidelines to work from. We're working on fixing these, but it takes time and we don't want to barge in rewriting everything and upsetting current users). On Tue, Aug 13, 2013 at 5:32 PM, Ellison Marks gty...@gmail.com wrote: So, I've been looking into the params pattern for writing modules, ie. having a params.pp file that init.pp inherits from as a place to use custom logic to set variables, and it seems very useful. I do have one question that I'm hoping someone can answer. If, for example, I look at an example42 module, everything is in params.pp. On the other hand, looking at, say, puppetlabs modules, there's some mixing, with the case statements determining variable contents living in params.pp, but with straightforward string and boolean values stored between params.pp and the argument list in init.pp, with seemingly little logic dictating what goes where. Basically, what's people thoughts on the value of having every single variable defined in params.pp, vs only the complex, logicky ones, and also, in the case that I'm being dense, can someone explain the logic behind the puppetlabs modules. -- 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. -- 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] Module team update: 2013-07-20 - 2013-08-09
So uh, as you can see from the subject there's been a little bit of a gap between the last email and this one. I got super sick and forgot to put it together, so you have my apologies if you were paying attention! Over the last two weeks we've continued to focus on the backlog of PRs as well as working on a number of things internally related to testing. I won't bore you with the details but we've been having conversations around different testing frameworks, improvements to rspec-system provisioning, how to automatically test multi-node setups, just all sorts of stuff related to how can we help you guys test modules better?. This is chewing up a lot of internal time as we start working out what we're doing! Over the last 2 weeks we've released a bunch of modules and in no special order they are: http://forge.puppetlabs.com/puppetlabs/ntp/2.0.0-rc1 http://forge.puppetlabs.com/puppetlabs/vswitch/0.1.1 http://forge.puppetlabs.com/puppetlabs/rabbitmq/3.0.0-rc2 http://forge.puppetlabs.com/puppetlabs/java/1.0.1 http://forge.puppetlabs.com/puppetlabs/postgresql/2.4.1 http://forge.puppetlabs.com/puppetlabs/nodejs/0.3.0 http://forge.puppetlabs.com/puppetlabs/passenger/0.1.0 http://forge.puppetlabs.com/puppetlabs/xinetd/1.2.0 http://forge.puppetlabs.com/puppetlabs/apache/0.8.1 http://forge.puppetlabs.com/puppetlabs/pe_upgrade/1.0.0 The openstack Puppet modules have also had a bunch of releases: http://forge.puppetlabs.com/puppetlabs/cinder/2.1.0 http://forge.puppetlabs.com/puppetlabs/horizon/2.1.0 http://forge.puppetlabs.com/puppetlabs/nova/2.1.0 http://forge.puppetlabs.com/puppetlabs/glance/2.1.0 http://forge.puppetlabs.com/puppetlabs/keystone/2.1.0 http://forge.puppetlabs.com/puppetlabs/openstack/2.1.0 http://forge.puppetlabs.com/puppetlabs/quantum/2.1.1 A quiet two weeks! I've also been working (slowly) on prototypes for the new data in modules feature that was merged into puppet master. The short story for that for people unaware of the feature is hiera 2.. in your modules!. It adds a huge amount of flexibility and clever features and I'm doing my best to understand how it all hangs together so we can help put together guides for everyone else. We have some other projects on the go I don't want to announce yet, but you can rest assured we are busy trying to make module writing a pleasure for everyone. As always you can contact ashp@ and hunner@ on #puppet with any concerns, questions, wild rants about what jerks we are, and so forth. Have a good weekend, readers! -- 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] Checking for the existence of a file
You cannot use ruby code in Puppet directly, which is why this isn't
working for you.
To do this you would need to write a Puppet Function as documented at
http://docs.puppetlabs.com/guides/custom_functions.html. This would then
let you do something like:
if exists('/file') {
Functions always run on the master, not the agent, so this would then test
for the file on the master.
On Wed, Aug 7, 2013 at 1:20 PM, Ted Fiedler fiedl...@gmail.com wrote:
I would like to check for the existence of a template file and if that
template exists, use it otherwise move on. The file would obviously need to
exist on the Puppet server, not the client. Here is my code.
$filetest =
File.exists?(/etc/puppetlabs/puppet/modules/samba/templates/$hostname.erb)
if $filetest == true {
file { '/etc/samba/smb.conf':
notify = Service[smb, winbind],
replace = 'no',
path = '/etc/samba/smb.conf',
ensure = file,
content = template(samba/smb.erb,
samba/${hostname}.erb),
require = Package[samba],
}
} else {
file { '/etc/samba/smb.conf':
notify = Service[smb, winbind],
replace = 'no',
path = '/etc/samba/smb.conf',
ensure = file,
content = template(samba/smb.erb),
require = Package[samba],
}
}
I keep getting the error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Syntax error at '.'; expected '}' at
/etc/puppetlabs/puppet/modules/samba/manifests/init.pp:34 on node
when I run the following test, it seems to work fine, but if I modify my
code above within puppet to use this, it fails also...
# cat test.rb
$test =
File.exists?(/etc/puppetlabs/puppet/modules/samba/templates/file.erb)
print $test
# ruby test.rb
true
Any ideas?
A million thanks in advance
Ted
--
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.
--
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] Benefits of retrofitting Puppet to a legacy fleet
On Fri, Aug 2, 2013 at 4:26 AM, Alex Harvey alexharv...@gmail.com wrote: Hi all, I am going to have a meeting to sell the idea of retrofitting Puppet to a fleet of already-built legacy Unix systems to a skeptical management (as opposed to only using it to build new linux systems, where I don't need to sell the idea). Here, legacy Unix means AIX, Solaris, HP-UX, and various versions of Linux. Much of the work is already done as far as deployment to these platforms is concerned, so the difficulty of compiling Ruby, etc, on Platform X version Y doesn't need to be considered. I see the following benefits: 1) Having facter on every computer in the company is good. 2) Having MCollective replace your for loops everywhere is good. 3) Being able to standardise configuration of some simple services, e.g. NTP, root's profile, etc., is better than not having standardised these services. 4) Any services that you can migrate into Puppet become visible in Puppet manifests, which is always better than documentation in a Wiki, which may or may not be up to date. Being more ambitious, I am thinking that with MCollective, it might be possible to use Puppet to install patches etc. on legacy systems. Maybe even possible, with a lot of effort, to fully automate the patching of everything, and have the change management system automatically updated as well. Any/all ideas/criticisms are appreciated. I have one week to write the proposal. All of those points seem reasonable to me! If it wasn't for HP-UX I would suggest Phttp://docs.puppetlabs.com/pe/latest/install_system_requirements.htmluppet Enterprise as they have pre-compiled everything for AIX, Solaris, and so on. They might be able to package up for HP-UX if the number of nodes is big enough. :) At a previous job I used mcollective for patch management and sort of change control, so these things are definitely possible. We had a modified package agent that could take various options to generate reports in different ways (mostly CSV, we weren't fancy) and could then be used to do rolling patch upgrades across various clusters. For change management we were more focused on tying specific git commits to triggered puppet runs so that we could verify that X change made it out to all the machines, so what you're looking to do sounds completely reasonable. I found when writing proposals for Puppet that focusing on point 4 in your above list was by far the most persuasive. A service fully converted to Puppet is by definition documented and repeatable and in a large corporation that's probably more important than any other point you can raise in favor of puppet. The number of times I've had to deal with a critical failure of an undocumented and unknown system or find a way to migrate an old setup to a new operating system with no information.. Good luck! -- 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] puppetlabs-ntp: templates merge, and new features
Hey guys, https://github.com/puppetlabs/puppetlabs-ntp/pull/80 adds some fairly significant changes and so I wanted to put it up for review early before going any further. The big change is that it gets rid of the distro specific templates in favor of one more sophisticated template we can start adding options to and increasing the flexibility of. To that end it adds a bunch of params to handle ntp keys - is there anyone on the list using ntp keys? If so does this feature make sense to you? Do you want more? less? different things? We add preferred_servers for dalen. Hopefully this is what he wanted! We add driftfile as a param in case you like to store it in non-standard places. :) Anyway, hopefully you guys can tear this apart and find all the flaws and suggest missing features. I would appreciate any reviews of the new template especially as now is the time to find gaps and flaws in it! Thanks, -- 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] Module team update: 2013-07-15 - 2013-07-19
My apologizes to all the readers for not getting this out on Friday. It was 100F in my basement and it felt like I was melting, I completely forgot in my rush to escape the house and survive until today. Three weeks into working on modules and we're making steady progress. Things have slowed down a little from my side as I work against the rabbitmq module and with the community to try and make some firm decisions on design patterns, but hunner has flown ahead and kept our contributions moving. As a result we made the following releases last week: http://forge.puppetlabs.com/puppetlabs/apache/0.8.0 - mostly bugfixes. http://forge.puppetlabs.com/puppetlabs/ruby/0.0.2 - development work http://forge.puppetlabs.com/puppetlabs/mysql/0.9.0 - backup features, bugfixes http://forge.puppetlabs.com/puppetlabs/postgresql/2.4.0 - features We also moved two modules into our namespace (we're working on the transition for these, we've never done this formally before): http://forge.puppetlabs.com/puppetlabs/inifile/1.0.0 http://forge.puppetlabs.com/puppetlabs/pe_upgrade/1.0.0 And nothing to do with us, but while checking releases I found that puppetdb was updated last week: http://forge.puppetlabs.com/puppetlabs/puppetdb/1.5.0 Of all the above work I'd say postgresql is the most important set of changes as hunner merged in and wrote some new features so these add some significant capabilities to this module. Thanks everyone if you hung in and read all of this, I hope your week is full of temperate weather and productive puppeting. -- 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: Module team update: 2013-07-07 - 2013-07-12
On Sat, Jul 13, 2013 at 6:16 AM, Alessandro Franceschi a...@lab42.it wrote: I insist on the question since I've not had answers previously: Any hope the redesign of the PuppetLabs modules will consider the suggested standards discussed here: https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md ? I know you're finding the lack of answer from us frustrating and I can promise we're not trying to ignore it or trivialize the issue. From our perspective it's just the two of us and we're just trying to find our feet and handle the enormous PR backlog and get the modules into some kind of shape. I'm not against any of those parameter names and I'll accept PRs to deprecate all the existing names and replace them with alternatives but it's just a big chunk of work that we haven't been able to schedule yet. So from my personal point of view I am trying to use those parameter names as much as possible, as well as that general class outline, in the context of transforming existing modules where I can't just start over. We haven't reached the point where we're doing much from scratch so these kinds of design things haven't come up as we're trying to find ways to work within what we got! So there's a totally unofficial answer, but I think hunner is generally on the same page as me. We see the need for a standardized list of parameter names/layout that is recommended, and we're in favor of moving towards it. Alessandro, here's a proposal that might help - https://github.com/puppetlabs/puppet/pull/1718 is a PR about improving the skeleton that module generate creates. It would be awesome to see if we can get electrical and you to work together to put together a skeleton that a/ reflects the class layout in that doc (probably just install,config,service and init as a skeleton) as well as a STANDARDS.md or GUIDELINES.md document that includes all those parameters. That way the information would be right there whenever a user creates a module. It would go a huge way towards getting these adopted I think if you integrated that document directly into the module skeleton. It would make it easy for busy people like me juggling modules to constantly refer to the document as I'd have copies of it all over the place. :) -- 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] puppetlabs-ntp template discussion
On Sat, Jul 13, 2013 at 7:15 AM, Erik Dalén erik.gustav.da...@gmail.comwrote: I've been missing a way to set which server(s) should be preferred. We generally include all our NTP servers in the config but prefer the one that is in the same site as the node in question. So for a machine in site1 it would look like: server ntp.site1.example.com prefer server ntp.site2.example.com server ntp.site3.example.com I'll take a look at this but I have a sneaky suspicion if you just pass in servers = [ 'ntp.site1.example.com prefer', 'ntp.site2.example.com' ] it should magically do the right thing. On monday I'll find that out and make it do the right thing if not. I guess what you're saying is it's a pain to modify the list per site? In that case we can always add a prefer = 'blah' and have that append to the site you pick if that works. I think what I'm saying is here is tell me the API you'd like most for that and we'll do it. :) Thanks, -- 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] Module team update: 2013-07-07 - 2013-07-12
Hello! Now that we're two weeks in it's time for another update on what's been going on in the module team. We focused on puppetlabs-ntp and puppetlabs-firewall as our two primary modules, but also merged in fixes to passenger, rabbitmq, mysql, apt, and apache. As a result of this work we've released: http://forge.puppetlabs.com/puppetlabs/apache/0.7.0 http://forge.puppetlabs.com/puppetlabs/ntp/1.0.0 http://forge.puppetlabs.com/puppetlabs/firewall/0.4.0 Of these three the apache release is by far the largest. The module was basically rewritten between the older version and this and most users have been using it from git for a while. This is a huge change so I would recommend anyone on 0.6.0 to test carefully before unleashing it in production. The NTP module was also completely rewritten (but is tiny in comparison). There's some work left to do in this to unify the templates but I wanted to get a release out the door today and work on the unification for 2.0.0. The firewall changes are smaller but the regular mix of features and bugfixes. In addition to all these module releases Hunter released http://rubygems.org/gems/rspec-system-serverspec, which is a bridge between the serverspec matchers and rspec-system. I made https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/71 which is an in progress refactor of the installation part of the rabbitmq module. I want to continue overhauling this module completely until it sparkles. Please take a poke in there and comment if you're a rabbitmq user. Thanks, -- 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: puppetlabs-ntp template discussion
On Thu, Jul 11, 2013 at 10:41 AM, jcbollinger john.bollin...@stjude.orgwrote: Currently, users have the alternative of specifying their own custom template instead of one of those packaged with the module. If the proposed change would remove that option, then it would be a significant step backward. If, however, the question is merely whether it would be important to me for the module by default to apply an NTP config file that is as similar as possible to my distro's stock file, then no, that is not an issue at all. John We definitely won't remove that feature - I'm going to try really hard not to remove any current features of any modules during our work to improve them. Nothing is more frustrating than having some feature you rely on torn out underneath you. I was just talking in terms of having a single stock template we use as the default and then allowing people to pass in their distribution specific one if they need it. I replied to this mail but I want to thank everyone replying for keeping the conversation going. I'll look at making sure it's possible to run ntp out of cron (I don't know if we'll include it in the module but you can set $manage_service to false (or service_ensure = stopped) to run it out of cron. I'll also dig in and look at the driftfile and make sure we manage that properly too! Thanks everyone, -- 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] puppetlabs-ntp template discussion
On Thu, Jul 11, 2013 at 3:49 PM, Matthew Burgess matthew.2.burg...@gmail.com wrote: On 11 July 2013 20:28, Dan White y...@comcast.net wrote: Excellent. I will see what I can do to contribute a run-it-by-cron option to the module, since I already do that. As far as the large time differences, there are multiple references out there to a line at the top of ntp.conf as follows: tinker panic 0 That line's actually *required* on VM guests (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 - search for 'NTP Recommendations' ). The templates could use updating to guard it with '% if @panic == false || @is_virtual == true -%' instead of just the single @panic check that they currently have . Or does it perhaps need to be a little more complex so that a warning can be spat out if the conflicting options of @panic == true and @is_virtual == true are set for a particular guest? In the new code we set panic based on $is_virtual by default, so it sets panic to false for virtual and true for physical. That way we get the right behavior out of the box and physical people can override it too. I figured that was preferable to having more logic in the templates. I suppose it depends on if there is the potential of a use case where people on virtual machines are simply not allowed to tolerate large skews either, I'd hate to railroad them by forcing the issue. -- 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] puppetlabs-ntp template discussion
Hi guys, As I mentioned in a previous email I've refactored ntp and released a 1.0.0 release candidate. There's one outstanding flaw remaining that's bothering me and I wanted to solicit opinions on the list. We currently maintain a template per distribution that is close to the stock distribution provided ntp configuration. This leads to massive sprawl and means adding a distribution means yet another template. Would users of the ntp module mind if we unified this all into a single template? Obviously we'd have to pick one as the best base template and move over to using it and deal with the fact that your ntp configuration would significantly change. Obviously we'd still be using your custom servers in the template so that bit wouldn't change. We could expand the restrict option to let you pass in more customized options here. What else would people like to be able to tune, change, tinker, trigger, whack, or modify in terms of parameters? If you have a really complex ntp setup then I want to hear from you! The more complex and awkward the better so that we can be sure our module meets your needs. If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! Thanks, -- 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] puppetlabs-ntp 1.0.0-rc1
On Wed, Jul 10, 2013 at 5:14 AM, Matthias Saou matth...@saou.eu wrote:
It looks really nice and clean! I would personally only have a few very
minor nitpicks :
* Shouldn't the placeholder files/README.markdown be removed?
* Space between class name and parenthesis inconsistency :
class foo(... vs. class foo (...
* In the templates, this comment should use single quotes :
# Managed by puppet class { ntp: servers = [ ... ] }
* In the el template, this variable isn't in the current scope :
% if @is_virtual == false -%
Add a new params variable for it, similar to $panic?
* For real RHEL, the ntp server hostnames used will be centos
instead of the original rhel ones. I'm not sure this is worth
trying to fix, though.
Great work on cleaning up the module!
Good eye! I've opened
https://github.com/puppetlabs/puppetlabs-ntp/pull/68for these fixes.
I just switched over to scope.lookupvar('::is_virtual')
for that single use rather than make it a parameter as it's coming out of
the box via facter.
If anyone knows the official rhel ntp servers then let me know and I'll
distinguish between rhel/centos if anyone cares. Honestly we'd be better
off just defining a pool from pool.ntp.org as the standard set used
everywhere and let people override them rather than carry this list around.
It's less likely to drift out of date. I started another email about
unifying the templates so if anyone wants to discuss pools, lets take it
there.
--
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] puppetlabs-ntp 1.0.0-rc1
Hi, Over the last few days I've spent some time refactoring the puppetlabs-ntp module to be a little bit more modern in style and not to be one giant class. As a result I've released a release candidate and I wanted to give users of the module a headsup to take a look at the differences and possibly go as far as testing out the new version. For the most significant change we're deprecating autoupdate in favor of just setting package_ensure to whatever you'd like it to be. Some other parameters have been reorganized and tweaked to align better with resource_ensure style naming. http://forge.puppetlabs.com/puppetlabs/ntp/1.0.0-rc1 or github is where you can grab the latest if you're willing to test it. If you have any feedback regarding the general design of the module this is an excellent place to hash it out as we'll be out to improve other modules with time. Thanks, -- 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] Fwd: [Module team] Much ado about modules
On Mon, Jul 8, 2013 at 11:12 AM, Alessandro Franceschi a...@lab42.it wrote: On Saturday, July 6, 2013 1:30:15 AM UTC+2, Nan Liu wrote: On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney ashley...@puppetlabs.comwrote: Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it. I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand. This was our first week working full-time on Modules, and I spent a good chunk of time this week filling in paperwork, meeting people I've only seen on IRC, and trying to get up to speed with internal systems and tools. This slowed us down a little. Hi! I'm glad to hear this is prioritized. We focused specifically on puppetlabs-mysql and puppetlabs-apt this week to try and get the PR/issue count under control. To give you an idea of the progress we've made: puppetlabs-mysql: Closed/merged 20 PRs. puppetlabs-apt: Closed/merged 18 PRs. We're going to continue iterating over different modules each week to deal with the enormous backlog of PRs and issues and keep bashing these into shape until we're caught up with all the community submissions. We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward. As a result of this week's work we have released: http://forge.puppetlabs.com/**puppetlabs/apt/1.2.0http://forge.puppetlabs.com/puppetlabs/apt/1.2.0 http://forge.puppetlabs.com/**puppetlabs/mysql/0.8.0http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0 Would it be possible for the module team to review Alessandro's The handy grail of modules standards thread and set a variable name standard moving forward? It doesn't even need to be quite as comprehensive, but some basic standard to start. We use quite a few modules as upstream, and would love to see some consistency even if it means breaking changes. Thanks again, and look forward to the great things coming out of the module team. Nan +1 of course. We all say some naming standards are needed and we still continue to make our modules in our ways. For the sanity of Puppet modules ecosystem let's do something about it. This is definitely something we want to do and need to do. I've been a little hesitant to wade down into the whole these are the specific parameter names we want to use and building out a huge set of guidelines, but I do have a straightforward question for the list along these lines: We're refactoring the ntp module to try and be a little bit of a better design rather than one giant class. We've been having some discussions in the PR about the right way to name the following options: manage_service ensure_package package_enable I was leaning towards: ensure_package enable_package ensure_service. But it's been proposed that: service_ensure package_enable Makes better sense in terms of being able to scan for things. Does anyone reading this have strong preferences either way? Now is the time for us to slowly start renaming parameters across the modules as we work on bringing in PRs, so speak up now. :) -- 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] Fwd: [Module team] Much ado about modules
Hello! Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it. I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand. This was our first week working full-time on Modules, and I spent a good chunk of time this week filling in paperwork, meeting people I've only seen on IRC, and trying to get up to speed with internal systems and tools. This slowed us down a little. We focused specifically on puppetlabs-mysql and puppetlabs-apt this week to try and get the PR/issue count under control. To give you an idea of the progress we've made: puppetlabs-mysql: Closed/merged 20 PRs. puppetlabs-apt: Closed/merged 18 PRs. We're going to continue iterating over different modules each week to deal with the enormous backlog of PRs and issues and keep bashing these into shape until we're caught up with all the community submissions. We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward. As a result of this week's work we have released: http://forge.puppetlabs.com/puppetlabs/apt/1.2.0 http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0 Thanks, -- 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-inventing the Wheel (again?)
On Thu, Jun 20, 2013 at 4:20 PM, Eric Aiken ericai...@gmail.com wrote: I'm new to puppet and working my way through the documentation. I'm struggling with the puppet labs module repo. I've toyed with numerous automation and configuration methodologies over the decades. Perhaps I'm seeing puppet wrong, Compared with CFEngine there is a a lot I like, but I'm not sure why I'm still having to re-invent the wheel for a linux server distribution. What I mean is, why at this point in the linux lifecycle, there are not standard modules for the 10,50 or 100 things that an admin must change to deploy a linux server in prod or dev Even though puppetlabs has a modules repo, if you look for some basic modules: sudoer, resolv.conf, ifcfg, there a numerous instances of modules by users. Each with their own idiosyncrasies. Why do admins have to keep re-inventing the wheel for each iteration of Config Mgmt and Monitoring tools. Has anyone created a repo of puppet modules for a given linux distro. In my case CentOS. Seems there should be (at this point) /etc/puppet/modules/CentOSx, that includes all the necessary modules/manifest etc. that only need to be tweaked for local settings or deleted for lack of need. According to the documentation and books i'm working through, i'll need to download and modify module by module 10's to 100+ modules/manifests/.pp files for a basic CentOS server running a java app. Not counting the effort necessary for best practices of parametrize classes. What am I missing here? I've had a number of jobs now that all used Linux and all did sort of the same things and yet in almost every case the configuration of the systems ended up radically different. In some cases this was due to security requirements, or legacy issues, or personal tastes amongst the people involved in how to best setup things. In some cases we just used init scripts, in others we wanted to integrate monit to restart services automatically, in some we needed to do weird pam stuff to log console keystrokes. What I'm driving at here is that there's just so many different things you can do with things as simple as sudoers that everyone reinvents the wheel for their specific circumstance. The trouble with generic modules that are flexible enough to handle all use cases is that they become complex! I've written a sudoers module that relied heavily on augeas to parse and do all kinds of sudoers stuff to enable really complex sudoer magic. At the very next job we pushed out a single sudoers file to all servers. In a situation like that do you really want all the complexity of a module that includes functions, maybe providers, defines, all kinds of stuff that is difficult to maintain yourself when you can write a couple of quick classes that do exactly what you want? :) Thanks, -- 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] Unknown function validate_bool when trying puppet labs apache class
On Sun, Jun 2, 2013 at 9:21 PM, Francisco Reyes franci...@natserv.netwrote: Is there a way to list all the available modules? Or basically anything in the git repository should be able to be installed that way? Well, your best bet is actually to flip over from using git to the forge. http://forge.puppetlabs.com/ is the url and this is where 'puppet module install x' goes to look. Here the modules are versioned so you're (generally) getting known good versions of modules that are tested together. If you had a blank setup and used puppet module install puppetlabs-apache it would automatically check for dependencies and fetch all of those as well. You can find a ton of other modules on here too. Sometimes I install them from the forge and sometimes I google those modules and find them on git and go right to the source, depending on when they were last released. (Sometimes people add them to forge and forget to ever update them). -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Unknown function validate_bool when trying puppet labs apache class
If you take a look in Modulefile in the root of the module you can see the other dependencies. You're going to need 'stdlib' and probably 'concat' as well. You can install them with either 'puppet module install puppetlabs-stdlib' type commands or just grab them from git also. On Sun, Jun 2, 2013 at 6:34 PM, Francisco Reyes franci...@natserv.netwrote: New to puppet. I am trying to use the Apache class from puppet labs found here: https://github.com/puppetlabs/puppetlabs-apache When it runs agent --test on my test environment I get: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unknown function validate_bool at /etc/puppet/modules/apache/manifests/init.pp:43 on node slave Running on Ubuntu 12.04 with puppet 2.7.11-1ubuntu2.2 installed from the default Ubuntu repository . Looking in the files from the class I see calls to the function validate_bool, but don't see it defined. If there some base/pre-requisite class that I needed? Don't see any mention in the readme file. Also, these classes from puppetlabs github, is there a way to tell what version they would work with? -- 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?hl=en. 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Packages for Ubuntu 13.04 Raring
I think they already are? If you grab http://apt.puppetlabs.com/puppetlabs-release-raring.deb and install that you should be able to get all the latest packages for raring. On Thu, May 30, 2013 at 7:22 PM, Vlad v...@vladgh.com wrote: When packages for Ubuntu 13.04 Raring going to be released? -- 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?hl=en. 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] PuppetDB
You definitely still need postgres! If you grab http://forge.puppetlabs.com/puppetlabs/puppetdb instead of installing it manually, it will help you get postgres and all the other dependencies you need installed. On Fri, May 24, 2013 at 5:33 PM, Worker Bee beeworke...@gmail.com wrote: Hi Everyone; I am sorry to be a pest but, I am very confused here. I just installed the latest PuppetDB from the repo packages. However, it does not appear that postgres is installed. I am really lost here... is postgres no longer required? Thanks! Bee -- 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?hl=en. 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Using puppet to install puppet modules
On Wed, May 15, 2013 at 10:48 AM, Nikola Petrov nikol...@gmail.com wrote:
I can second that. Not sure why puppetlabs decided to invent yet another
package system with it's own problems and metadata definition and
updates specifics
While I'm not disagreeing that this is a pain, I think part of the
difficulty with using system packages is they tend to assume you have one
set of files going into one place. How do you easily package up a module
when you want it to go into:
/etc/puppet/environments/production/x
/etc/puppet/environments/dev/x
Keeping in mind everyone has a different number of environments they want
modules in. I think that definitely makes things complex for OS level
packaging. Having said that, package{} really should grow a puppetmodule
provider to make some of this easier. :)
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] example42 puppet-squid
On Mon, May 13, 2013 at 5:21 PM, Jim Miller stl...@gmail.com wrote:
I am using example42s squid module
https://github.com/example42/puppet-modules/tree/master/squid, and trying
to define certain user variable at the puppet/manifest/nodes.pp level
This is the first module of their's I've tried, I've read over their
documentation and FAQ and for the life of me I can not figure this out. To
me their examples are VERY HIGH level and I'm _really_ new to puppet. I'm
sure I'm missing something fundamental but I'm just not seeing it. I've
also installed example42s 'common' module which is needed to make the type
of changes I'm talking about.
The following works fine:
node 'xio99cdetest1.mygroup.com' {
include squid
}
AND
node 'xio99cdetest1.mygroup.com' {
class { 'squid':
squid_port = '3030',
}
}
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Invalid parameter squid_port at /etc/puppet/manifests/nodes.pp:94 on node
xio99cdejump01.centric.com
If you load up the init.pp from this module you'll notice that after the
class squid declaration there's no parameters listed for the class. This
is because this is a old style module at this point and is just setting
variables directly in params.pp. You would be best off looking for a
better squid module while you get up to speed on Puppet.
The best I could find for you is
https://github.com/dezwart/puppet-squid currently,
if you look in the init.pp in there as a counter example to the example42
one you'll quickly see how the parameters belong directly to the class. In
this case he doesn't have squid_port as a parameter, so it won't be usable
without modifications for you, but it's a better example of the kind of
structure a squid module should contain.
If this is all horrible for you and you're not able to make any headway let
me know and I can give you some help to modify one of these modules to make
the port a parameter.
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Foreman and Puppet managing templates question
Foreman does replace nodes.pp. It acts as an 'ENC', the external node classifier. We'd need more details on what you're doing with templates in Puppet and nodes.pp to really answer this question. Are you thinking in terms of how you'd put variables into nodes directly with Foreman? There's space in the host page in Foreman for adding variables, under Parameters if you want to add them directly. A better approach to this is to look into Hiera, where you build a hierarchal data store that relies on various facts to provide the appropriate contents to variables to then consume in erb templates. Ideally you'd find ways to not have node specific information, but if you did need it you'd add $::fqdn to your hiera hierarchy and then add nodename.yaml files for each node where you listed out all the variables. This has the big benefit of remaining version controlled, unlike parameter entries in Foreman. As I said earlier, if you give some use cases we can probably explain this all a little better to you. Thanks, On Tue, May 7, 2013 at 9:53 AM, timo stockford...@gmail.com wrote: Hi, I have just started to use Foreman 1.1. I have been using Puppet for a while and have some custom modules and ones that have been dragged down from git etc. I am using nodes.pp in Puppet to assign classes and template entries to hosts. So is Foreman meant to eliminate my need for a nodes.pp? How do I manage my erb templates in Puppet without a nodes.pp? Thanks, -- 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?hl=en. 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Can anyone recommend a module with a resource managing a block of lines in a file?
On Sat, May 4, 2013 at 7:25 PM, Schofield dbschofi...@gmail.com wrote: I'm hoping a commonly used module that provides a resource for managing multiple contiguous lines in a file already exists and someone can point me to it. I want something like the file_line type in the puppet labs stdlib module but have it check multiple lines instead of just one. This feels like it would be a natural fit to be modeled in augeas (unless I misunderstand your requirements), which is designed for exactly this kind of line by line control of files. For an example you can look at https://forge.puppetlabs.com/domcleal/augeasproviders for some providers Dominic has written. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] New to hiera
On Sat, May 4, 2013 at 9:50 PM, Josh j...@endries.org wrote: I'm not yet sold on heira; so far it seems to just shift complexity outside of the classes and add a little more in the process, with hierarchies and stuff, and now I have data in multiple places... I still need case statements to handle different OSes and stuff. Eh, we'll see. Maybe I just haven't read something that explains the benefits well yet. You should check out https://puppetlabs.com/blog/hiera-for-pouncers-and-stalkers/ as it's a great guide to the benefits of hiera. You really don't need case statements if you use heira, because you can make a hiera structure based on a fact like $::osfamily and then have: osfamily/Redhat.yaml osfamily/Debian.yaml This gives you the benefit that if you drop in a new .yaml file supporting a new distribution you only have to drop it into heira, and not modify multiple manifests. The article I linked probably does a better job of explaining it, but the goal is to remove all the data from your manifests leaving just variables behind, and then hiera fills in all the blanks. It takes some getting used to but I think you'll find it leads to better, cleaner, manifests in the long run. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Help me with a local Linux account management module
On Fri, Apr 26, 2013 at 4:08 PM, David Reagan jer...@gmail.com wrote:
I'm pretty much brand new to Puppet. I've read the tutorials on puppet
labs, and most of Pro Puppet. But there's still a lot I don't get. So I
figured I'd learn by doing.
My current goal is to write a user account wrapper. It would only be for
local Linux accounts only, only on Ubuntu for now.
I'm not just using the user type because I want to manage ssh authorized
keys as well.
I did find https://github.com/dcsobral/puppet-users, and a few others.
But I'm not fond of the use of csv files, and it seems like a simple enough
module to learn with.
Wrapping user and ssh_authorized_key is simple, just pass in the
information. But I do have a couple questions I couldn't find answers to in
the docs, here, or Google.
*Questions*:
- What happens when a group listed in the user type does not exist on
the server?
Generally speaking you shouldn't let that happen! The user resource will
fail because it wants the group to exist first. Create a group{} resource
and in the user{} resource add something like require = Group['users'], or
whatever, so that this doesn't happen.
-
- How do I figure out what hash to use for the password when creating
a new user?
There's several ways to handle this. Generally the way it's done is via a
custom function that executes on the puppetmaster and injects the results
of that run into the catalog for the client. This way you can use a hash
generator. Something like
https://github.com/kwilczynski/puppet-functions/blob/master/lib/puppet/parser/functions/random_password.rb
- Do I just copy the hash directly into the password property? No need
to tell puppet what kind of hash it is?
It basically takes the contents of password and shovels it into the
appropriate /etc/shadow column.
- ssh_authorized_key: name has to be unique. So how do I add a key to
more than one user?
You'd want to structure this as a kind of custom_user{} define that was
able to take keys as a parameter and those can be an array or hash of
info. This way you're basically listing all the keys per user rather than
trying to assign keys to multiple users.
Because you'll have custom_user{ 'blah': } you'll be able to refer to the
blah as $name in the define and then you can make your ssh_authorized_key
names like:
ssh_authorized_key { ${name}-key: } so that they have unique names, I'll
leave the rest of this up to your imagination as you'd need a unique -key
bit per key you pass in. That's one reason I suggested the keys param be a
hash, so that you can have a name and then value and use that to build up
the name cleanly.
- I'd like to simply pass in an array of links(?) to pub key files to
my wrapper instead of the actual ssh key. How would I tell Puppet to split
the contents at the spaces so I can get the key, type, and name properties
out of it?
This stuff is tricky with the language as it stands. The way I've solved
this (and seen others solve this) in the past is that rather than trying to
pass in arrays you build a hash in hiera for your users and then pass the
entire hash to create_resources('mycustomusersdefine', hashname) to have it
create a call to the define for each element of the hash. If you google
create_resources you should find some examples.
Future plans would be to manage shell configuration as well. But for now,
all I need is what I've described above.
Oh, when implementing this, does making a
/etc/puppet/manifests/accounts/username.pp file per user, then including
that file on the nodes that need that user, raise any bad idea flags for
you?
It does, but only because even at this early stage you should start
thinking is this how to do a task, or the data the task needs? if it's
data you should be thinking of 'hiera' and how you can use that to seperate
your data from your manifests.
Good luck!
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] CFP: UCMS '13 (San Jose - June 24)
Hi all, I made the mistake of agreeing to help organize a conference and so now I'm circling the user groups of all the majorconfiguration management tools with my cap in hand begging for talks. It's going to be in San Jose as part of a week of USENIX conferences and we're looking for interesting uses of conf mgmt or anything else cool to talk about. You can find more information at: https://www.usenix.org/conference/ucms13/call-for-participation I personally would love to hear from anyone who has an awesome infrastructure testing setup or interesting testing setup and so if that's you then I beg you to consider presenting a talk. I think it's something that the Puppet community skimps on very often and would be great to get the word out that testing is useful! Thanks, -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Want to work in cutting-edge education in Cambridge, MA?
Hello! I'm not a recruiter, manager, or otherwise non-technical person spamming the users list in order to harvest email addresses. I'm one of the 'devop engineers' at EdX, a MIT/Harvard/Everyone else non-profit organization aimed at reinventing online education. We're the non-profit version of Udacity/Coursera basically. We're currently a team of three, with two members of the team having a strong programming/dev background and me, the black sheep of the team with a primarily ops background. We're looking for people who would feel comfortable jumping directly into a hodge podge environment based in AWS running a mostly Django stack with Puppet driving the conf mgmt behind the scenes. Must be comfortable with ongoing endless arguments about the Right Way to do everything from provisioning to deployment and must be willing to wade in feet first into the eternal vim vs emacs argument. We're a very tight knit self organizing team with minimal direction from above other than requirements from the developers building the stuff we run. You'll have a direct and visible affect on the environment here and help us shape it to be world class (hopefully!). We have free lunches and a relaxed (but horribly busy still as we're like a startup) environment. I've been here since September or so and I absolutely love it here. I love coming to work and I love being able to directly design the infrastructure and build things without endless meetings and delays and politics. :) As you can tell, I don't write a lot of job advertisements but if you'd be potentially interested in working with us please drop me a line at apen...@edx.org with your resume or catch 'ashp' in #puppet. The only real restriction we have is that we're looking for local people rather than remote workers due to the nature of our collaboration. Oh and we're a 'kind of agile team, I guess', with retros and planning and trello boards and all that kind of thing so we hope you're cool with that too. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] How does facter get ipaddress?
On Sun, Dec 30, 2012 at 12:08 PM, Mandla Mbuli lm.mb...@gmail.com wrote: Hi I am running a version 'facterversion = 2.0.0-rc4' do you know if this uses /sbin/ip? does it adapt for ArchLinux which uses puts it in /usr/sbin/ip (judgin from `which ip`) `facter ipaddress` and `facter fqdn` don't work for me. I don't know how to troubleshoot. I just started really reading/playing about puppet today. I also tried the latest version available from rubygems and it still can't find the ipadress or fqdn. What could be the possible problems? The pull request hasn't been merged so I believe it still only uses ifconfig. You'll have to either find a way to install that on arch or try and manually merge the pull request in I'm afraid! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How does facter get ipaddress?
On Fri, Nov 30, 2012 at 6:59 AM, Bret Wortman b...@thewortmans.org wrote: Aha! The problem is that ifconfig doesn't return anything containing inet addr: in Fedora 17. The output looks like this: eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.2.13 netmask 255.255.255.0 broadcast 192.168.2.255 inet6 fe80::d6be:d9ff:fe92:1df5 prefixlen 64 scopeid 0x20link inet6 2001:470:1d:429:d6be:d9ff:fe92:1df5 prefixlen 64 scopeid 0x0global ether d4:be:d9:92:1d:f5 txqueuelen 1000 (Ethernet) RX packets 15939189 bytes 11636881674 (10.8 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14236195 bytes 2245276793 (2.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 19 So it falls through to host `hostname`, which isn't available because I need Puppet to configure freeipa-client for me, which it struggles to do. So I guess I have to hardcode the DNS server into my kickstart and then let puppet take care of the resolv.conf after that. I have no idea if it cleanly merges but if you're feeling brave you could grab https://github.com/puppetlabs/facter/pull/267 and see if that magically does the right thing for F17. It uses /sbin/ip in preference to ifconfig, so it should work a lot better. I couldn't get it merged so it's just sat and gotten a little stale but hopefully does 99% of what you need still if you can merge it for testing. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Technical Reviewers Needed
I am definitely interested in this. I've years of experience with Puppet and have worked on mentoring junior team members so I've seen a lot of the beginner problems close up. I'm happy to review anything you throw my way. I have been toying with the idea of writing a Puppet book for months now, glad someone beat me to it! On Mon, Nov 26, 2012 at 7:32 AM, joan...@packtpub.com joan...@packtpub.comwrote: I am searching for a number of technical reviewers for a Puppet Beginner's Guide that is currently in production. You need to have good technical knowledge, and be able to spare a few hours every couple of weeks to review the chapters. Please get in touch if you're interested! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 3.0 rspec and custom resources
Jeff, During those failing rspecs I have (the stdlib functions) I also see anchor failures so they are probably related to the same bug as this email! On Fri, Oct 26, 2012 at 6:33 PM, Jeff McCune j...@puppetlabs.com wrote: Hrmmm. Is there a small rspec example you could post that reproduces this issue? I'd love to try and reproduce it since there's definitely a possibility that a change between Puppet 2.7 and 3.0 is responsible for this issue. -Jeff On Fri, Oct 26, 2012 at 8:01 AM, Nathan Huff nathan.ri.h...@gmail.com wrote: I am trying to figure out if I am missing something simple here. After upgrading to puppet 3.0 running puppet-rspec tests that use custom resources from modules in the fixtures directory are failing. I have a module that uses the anchor type and with 2.7.19 it works fine. After upgrading to 3.0 all of the tests are failing with Puppet::Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type anchor at /home/nrhuff/repos/puppet-os/spec/fixtures/modules/os/manifests/init.pp:2 on node enyo.localhost The debug output is Debug: importing '/home/nrhuff/repos/puppet-os/spec/fixtures/manifests/site.pp' in environment production Debug: importing '/home/nrhuff/repos/puppet-os/spec/fixtures/modules/stdlib/manifests/init.pp' in environment production Debug: Automatically imported stdlib from stdlib into production Debug: importing '/home/nrhuff/repos/puppet-os/spec/fixtures/modules/stdlib/manifests/stages.pp' in environment production Debug: Automatically imported stdlib::stages from stdlib/stages into production Debug: importing '/home/nrhuff/repos/puppet-os/spec/fixtures/modules/os/manifests/init.pp' in environment production Debug: Automatically imported os from os into production Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type anchor at /home/nrhuff/repos/puppet-os/spec/fixtures/modules/os/manifests/init.pp:2 on node enyo.localhost /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/resource.rb:218:in `initialize' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/resource.rb:120:in `initialize' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:44:in `new' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:44:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/util/errors.rb:35:in `exceptwrap' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:43:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:42:in `collect' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:42:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/module.rb:283:in `collect' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/branch.rb:16:in `each' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/branch.rb:15:in `each' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:25:in `collect' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/resource.rb:25:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast.rb:62:in `safeevaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/astarray.rb:25:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/astarray.rb:20:in `each' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/astarray.rb:20:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast.rb:62:in `safeevaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/resource/type.rb:136:in `evaluate_code' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/resource.rb:81:in `evaluate' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/compiler.rb :165:in `evaluate_classes' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/compiler.rb:150:in `each' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/compiler.rb:150:in `evaluate_classes' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/functions/include.rb:11:in `real_function_include' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/functions.rb:63:in `send' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/functions.rb:63:in `function_include' /home/nrhuff/.rvm/gems/ruby-1.8.7-p358/gems/puppet-3.0.1/lib/puppet/parser/ast/function.rb:31:in `send'
Re: [Puppet Users] in-module data with hiera
This is -exactly- what I've wanted in my modules since I heard of
Hiera and I am strongly supporting this proposal. I'll be
experimenting with your gem. I can't give this enough support as this
is what I wanted since Hiera began. It'll make supporting multiple
distros/operating systems much easier for modules on the forge.
On Sun, Sep 30, 2012 at 5:37 AM, R.I.Pienaar r...@devco.net wrote:
hello,
Till now hiera-puppet was the only way I know that allowed hiera data to
be loaded from inside a module.
The problem with this was that it was still subject to the site specific
hierarchy which means a module author had a pretty hard time to store
his data in a proper way in his module thus perpetuating the use of the
params classes pattern.
Now that Puppet 3 is out and it's gem extensible I can finally try some
ideas I had but put off implementing because it was too hard to install
and distribute these extensions.
I propose extending the module layout with a data/ directory that can go
into each module and in this data directory would live a hiera config
file (optionally) and module specific data:
your_module
├── data
│ ├── hiera.json
│ └── osfamily
│ ├── Debian.json
│ └── RedHat.json
└── manifests
└── init.pp
Here the data/hiera.json is optional and specifies a hierarchy that the
module author chooses and is unique to the specific backend.
The default contents would be this is the file is absent:
{hierarchy: [osfamily/%{osfamily}, common]}
But a module author can pick anything there, should even be able to rely
on facts that is shipped with the module in its lib dir since that'll
get pluginsynced out before compile time:
Now given the data files for Redhat:
{apache::package : httpd}
...and Debian:
{apache::package : apache2}
And your main hiera site config being something like:
:backends: - json
- module_json
You should be able to just write module code like this:
class apache($package=apache) {
package{$package: ensure = present}
}
If no data is specified in the site hiera backends then this will use
the in-module hierarchy and data and just do the right thing on RedHat
and Debian systems but as always the site can still override the data
using hard coding, site specific data, ENCs etc.
So the important thing here is the module author has control over the
hierarchy that gets used when the data in his module gets loaded. The
site can has its own hierarchy policy but this backend will only use
the hierarchy that is recorded in the module by its author.
If you want to play with this idea on your Puppet 3 install just do 'gem
install hiera-module-json'
So I am looking for feedback from the community on this pattern, will it
solve the problem of author-supplied module data better than we have
today? I've heard this problem brought up quite a lot so keen to hear
feedback.
I'd imagine eventually a backend like this might be a hard-coded backend
shipped with puppet and always there as the lowest priority backend
below any that the site might specify in their site wide hiera config so
everyone can rely on this being there and with the new lookup helpers
this should also be backward compatible - old Puppets or ones who
specifically disable the hiera indirector will just not have data and
will need to supply it some other way.
---
R.I.Pienaar
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Help me name a class in the new puppetdb module!
I kind of feel like the reason you're having a problem naming this is that it doesn't really belong in the puppetdb class but in the puppet module that sets up the server. :) That's how I did this, I have a puppetdb module that purely sets up puppetdb and then puppet::server::puppetdb to handle that other stuff. Failing that I guess I nominate the name puppetdb::puppetmaster despite the ugliness! On Fri, Sep 14, 2012 at 7:03 PM, Chris Price ch...@puppetlabs.com wrote: Anyone interested in helping me name a class in the forthcoming puppetdb module? There are 2 major parts to the module... the part that sets up puppetdb itself, and the part that sets up the puppet master to talk to puppetdb. I'm brainstorming names for the latter... a class that you would apply on your puppet master machine to tell it how to find and use puppetdb. Any suggestions? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Where to execute script to add server to Zabbix monitoring system?
You might be able to use generate() for this - it runs the command on the puppetmaster and returns the result to the client. Should be easy enough to use safely! On Tue, Sep 11, 2012 at 7:28 PM, JeremyCampbell jeremycampbel...@gmail.com wrote: I've written a script which adds a new server to our Zabbix monitoring system using their api. This script contains the api username and password so I wouldn't want it sitting on the puppet clients. I assume to execute it on the puppetmaster side I need to configure the script as a custom function? And to avoid the script from contacting the Zabbix server every run, it could write the host name to a file which it checks beforehand. Would that be the way to go or are there any better approaches? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zpww3ilJjlMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Append string to list items.
You could give inline_template() from stdlib a try instead. You could do:
$nodes = ['gfs01' ,'gfs02', 'gfs03', 'gfs04]
$brick_store = /var/bricks
$new = inline_template('nodes.each {|n| etc etc etc')
I'm not 100% sure it'll work in this case but I've done other similar
evil things with inline_template.
On Mon, Aug 27, 2012 at 4:06 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
Trevor,
Thanks. I'm getting 'bad target Array' with:
define glusterfs::volume_create ( $brick_store, $nodes, $replicas='1',
$transport='tcp' ) {
.
$n2 = regsubst ($nodes, '$', :$brick_store) # Bad target array here.
notice (bricks = $n2)
}
On entering the define, $nodes = ['gfs01.us1.xxx.com',
'gfs02.us1.xxx.com'] and $brick_store=/var/bricks
Doug.
On Mon, Aug 27, 2012 at 12:44 PM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
Try using regsubst:
http://docs.puppetlabs.com/references/stable/function.html#regsubst
On Mon, Aug 27, 2012 at 3:03 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
I have an array:
$nodes = ['gfs01' ,'gfs02', 'gfs03', 'gfs04]
and a string variable:
$brick_store = /var/bricks
How can I append /var/bricks to each item in the array? Lack of a
looping construct makes this challenging in puppet.
Such that:
brick_array = ['gfs01:/var/bricks', 'gfs02:/var/bricks', ... ]
I also need to come up with a way to append a further sequence of
incrementing brick numbers to the items as well.
Doug
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Automate Agent Runs
http://docs.puppetlabs.com/guides/rest_api.html You have to enable the REST api on clients if you want to talk to them that way (as it's disabled by default) but this will probably get you where you need to go. Failing that you could use something like mcollective and make a mini-REST api to push requests to it. That would make it easy to request mcollective go find the machine in question and instruct it to check-in. Thanks, On Mon, Aug 20, 2012 at 2:54 PM, Mike Carr mcar...@gmail.com wrote: We are building a system that has a front end for a user to request a host, the use can select what they want on the host. Our application will build/apply the correct profiles, we would then like to trigger the agent to check-in. Our app is current written in Groovy so a REST API would be great. Is this possible? The server app will most likely not sit on the same sever as Puppet. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/haP7D_d7EJAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Job Listing - Linux Admin in Boulder, CO
More than that I think we should have a rule that if you want to post a job listing you have to provide some kind of details about it! On Fri, Aug 17, 2012 at 12:15 PM, Dan White y...@comcast.net wrote: Is full time telecommuting an available option ? “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Original Message - From: Guy Matz guym...@gmail.com To: puppet-users@googlegroups.com Sent: Friday, August 17, 2012 11:36:52 AM Subject: [Puppet Users] Job Listing - Linux Admin in Boulder, CO Anyone interested? Thanks, Guy guymatz at gmail -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Help with puppet variables
Hi, Good news! You sound like someone who would benefit greatly from Hiera. Hiera is part of Puppet 3 (you have to do a little bit more work with Puppet 2.7) and provides a way of providing different bits of data, via variables, for different hosts. If you take a look at http://puppetlabs.com/blog/first-look-installing-and-using-hiera/ this should cover a good introduction to setting up and integrating hiera into your environment. We use Hiera ourselves to do things like set 'base' variables that apply by default unless your host overrides them, which should hopefully be similar enough to what you want to do. Good luck! Thanks, On Wed, Aug 8, 2012 at 3:34 PM, thiago thsa...@gmail.com wrote: Hi, I'm a beginner on Puppet and i have one priority on my configuration. I have a lot of hosts and each one need different variables. Is it possible to configure a specific environment of these variables for each host? -- Thiago Silveira Alexandre LPI I Certified -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] a complete solution for puppet
I have heard from various other puppet users of Open Puppet installations of tens of thousands of nodes (at least last I heard, there's probably people with more) so it definitely scales that high. Generally they've had to restrict themselves on some features or sometimes use Puppet in slightly strange ways to improve scaling, but people are definitely doing it today. The flash you get from PE just makes things easier. Most of us started with a fairly small Puppet trial and over time developed modules to build up an entire puppet infrastructure. I have a fairly (badly) written module that installs puppetmasters, sets up repos, hiera, databases, everything needed to fully deploy a relatively scalable Puppet infrastructure. I think there's a lot of us out there, maybe a few of us should get together, share what we have, and try to build a combined module that people can use to help bootstrap and scale. On Wed, Jul 25, 2012 at 7:34 PM, Stuart Cracraft smcracr...@me.com wrote: Hey, Chris: so that begs the question, do you think you have some secret or are just happier with fewer flashy gui's, more install/deployment scripts, and so forth. In other words, do you think the scaling of Open Puppet is adequate to scale much larger without the flash? Or, is there something fundamentally holding back Open Puppet from handling thousands, tens of thousands, or hundreds of thousands of nodes, in your opinion? Cheers, Stuart On Wednesday, July 25, 2012 2:52:00 PM UTC-7, Christopher Wood wrote: On Wed, Jul 25, 2012 at 02:20:17PM -0700, Hai Tao wrote: I see. so it is on purpose to make it not easy to use so the enterprise can be sold? :) There are different skill levels at different tasks in the enterprise space, and it is legitimate that some organizations are better off with a prefabbed installer for a configuration management system. I've created a puppet installation of reasonable complexity without puppet enterprise, but that is possibly just me: $ cd files/puppet/svn/prod/trunk $ ls manifests/nodes | wc -l 43 $ find modules -name *pp | wc -l 174 That's not to say I don't salivate a bit at the thought of Puppet Enterprise, but my budget of $0 doesn't help there. Or perhaps a career-long $0 budget has helped, in that I'm more used to building from components instead of buying the package. People who are more used to buying than building may be better off with a different situation than mine. On Wed, Jul 25, 2012 at 2:02 PM, Christopher Wood christopher_w...@pobox.com wrote: Sounds like you should be talking to your managers about buying Puppet Enterprise. On Wed, Jul 25, 2012 at 02:00:37PM -0700, Hai Tao wrote: Hi, I notice that many components of puppet do not scale well and are not intended for large environment. For example, stored config and inventory service. In order to scale, we need to use puppetDB, right? Another example is the webrick, and which should be replaced by a decent web server such as apache. All these need a lot of new installation of pieces of software and configurations. My question is why the designer of puppet did not consider this and integrate everything into a complete solution at the beginning, rather than having us have to reconfigure everything by hand. Who will use puppet if he has only 50 nodes? -- Hai Tao -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Hai Tao -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/MW0Ok3Eent8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. --
Re: [Puppet Users] puppetmasterd continuously consuming high CPU, with many interrupts
It might be totally unrelated but check for ksoftirqd and see if it's running with high CPU. The leap second the other day caused all my puppetmasters to spike up to 100% CPU and other people had similar problems. I notice your server has 271 days uptime so it might not be the cause but it's worth trying to either set the date with date -s or reboot the machine to see if it clears it up. On Mon, Jul 2, 2012 at 2:42 PM, Robin Lee Powell rlpow...@digitalkingdom.org wrote: So, I have a server at home that has four VMs running inside it. All are managed via puppet. The physical host runs puppetmasterd. I don't recall noticing this before, but puppetmasterd has decided to be kind of crazy. Here's the physical host with no puppetmasterd running: top - 11:36:15 up 271 days, 15:16, 1 user, load average: 5.68, 5.50, 6.45 Tasks: 129 total, 1 running, 128 sleeping, 0 stopped, 0 zombie Cpu(s): 3.6%us, 1.8%sy, 0.0%ni, 80.4%id, 14.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8128776k total, 6991020k used, 1137756k free, 408756k buffers Swap: 8388604k total, 552356k used, 7836248k free, 185220k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 10296 qemu 20 0 2366m 1.5g 8884 S 6.2 19.6 6:37.65 qemu-kvm 17334 qemu 20 0 2788m 1.7g 544 S 2.7 22.3 4576:25 qemu-kvm 9904 qemu 20 0 2358m 581m 8820 S 0.9 7.3 3:55.78 qemu-kvm 1 root 20 0 46880 8076 1372 S 0.0 0.1 0:27.00 systemd 2 root 20 0 000 S 0.0 0.0 0:10.48 kthreadd 3 root 20 0 000 S 0.0 0.0 322:04.84 ksoftirqd/0 6 root RT 0 000 S 0.0 0.0 0:00.00 migration/0 7 root RT 0 000 S 0.0 0.0 0:11.57 watchdog/0 8 root RT 0 000 S 0.0 0.0 0:00.00 migration/1 10 root 20 0 000 S 0.0 0.0 551:03.31 ksoftirqd/1 And here it is with puppetmasterd running: top - 11:25:07 up 271 days, 15:05, 1 user, load average: 12.59, 8.68, 7.05 Tasks: 131 total, 3 running, 128 sleeping, 0 stopped, 0 zombie Cpu(s): 15.2%us, 36.4%sy, 0.0%ni, 6.6%id, 39.7%wa, 0.0%hi, 2.0%si, 0.0%st Mem: 8128776k total, 6830276k used, 1298500k free, 381356k buffers Swap: 8388604k total, 555328k used, 7833276k free, 180096k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 10660 puppet20 0 214m 107m 4040 S 61.9 1.3 8:46.81 puppetmasterd 3 root 20 0 000 S 21.4 0.0 320:38.54 ksoftirqd/0 10 root 20 0 000 R 20.2 0.0 549:30.88 ksoftirqd/1 10296 qemu 20 0 2470m 1.4g S 13.1 18.1 4:23.70 qemu-kvm 17334 qemu 20 0 2788m 1.7g 540 S 8.3 22.0 4574:54 qemu-kvm 9904 qemu 20 0 2422m 572m 8820 S 3.6 7.2 3:07.15 qemu-kvm 24980 qemu 20 0 1824m 1.4g 612 S 3.6 18.3 15046:11 qemu-kvm 12209 rlpowell 20 0 15256 1228 908 R 1.2 0.0 0:00.04 top 1 root 20 0 46880 7992 1356 S 0.0 0.1 0:26.97 systemd 2 root 20 0 000 S 0.0 0.0 0:10.48 kthreadd The high CPU use by puppetmasterd is bad enough, but what makes me be all like wait, what? is the ksoftirqd usage. Puppet master version is 2.16. This is *without* a client running; there's no traffic on 8140 according to tcpdump, and there's nothing happening in the log. http://users.digitalkingdom.org/~rlpowell/media/public/puppetmasterd_strace.txt has strace output; it's pretty boring, but there are a few select and rt_sigprocmask calls near the bottom. I'm totally stumped here. Any ideas? -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. .i ko na cpedu lo nu stidi vau loi jbopre .i danfu lu na go'i li'u .e lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni li'u -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Is this possible with Hiera - Puppet Module Development and using Hiera
On Fri, Jun 22, 2012 at 7:02 PM, Peter pe...@ifoley.id.au wrote: Thanks for taking the time to reply. Yes hiera provides support for module developers ... however I would argue that it is limited for example, the hiera-puppet plugin is *hard-coded* to only look for values in the module manifest directory for a file called data.pp. This does allow for a very low threshold for module developers to start implementing hiera in their modules (rename their existing params.pp files). I believe by extending the hiera-puppet plugin for module developers to follow a similar convention as hiera for module users would make certain things easier for module developers. By providing the ability to signal the hiera-puppet plugin (using a module-hiera.yaml file (for lack of a better name)) a module developer could reduce complexity and use the DRY principle to setup sane defaults (either in a defaults.pp or in a defaults.yaml file) and than use layer on top specific settings for Operating systems or even Hardware Types (as examples). Sorry I don't have time right now to provide something in depth but a brief example would be setting up ISCSI, the module I currently have has a complex params.pp file for detecting particular setups. As a module developer I am interested in setting up a hierarchy such that from most specific to least specific: * Hardware_platform * Operating System * Defaults By defining this in the module-hiera.yaml file it makes it very easy for me to signal to the module user what settings override which. I am not suggesting taking any control from module users, and to be explicit user settings (if set) would override the module variable. Hopefully I have done a better job of explaining what I am thinking. Thanks, Peter. If I understand your idea correctly then I too would like to see this. We would be able to use a hierarchy within the module (when sharing on the forge) to provide various defaults without having to do a bunch of selectors on $operatingsystem etc and make it easier for someone to start providing overrides from their own hiera data. Right now to provide defaults that differ for an operating system you would have to do a bunch of logic in params.pp that the person would want to strip out and replace with a call to hiera anyway. By allowing us to create params.pp as a series of hiera calls in the first place it'll reduce the amount of modifications (hopefully to zero) when taking a module off the forge. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Conditional with variable from facter
The :: refer to scope, in this case it's saying variables at the very top
scope of what puppet knows about. This is because you can have:
$::operatingsystem
$module::class::operatingsystem
And it's not sure which one you mean. By adding the :: you're making sure
it knows to check the fact and not something you might have set in a
specific class.
On Wed, Jun 20, 2012 at 4:22 PM, Jakov Sosic jso...@srce.hr wrote:
On 06/18/2012 03:25 PM, Jakov Sosic wrote:
Hi.
I have the following facts available:
# facter | grep oper
operatingsystem = CentOS
operatingsystemrelease = 6.2
Now, if I wish to use conditionals on these facts, I have to do it like
this:
case $operatingsystem {}
case $::operatingsystemrelease {}
I'm puzzled as to why can't I just use $operatingsystemrelease, and what
do these two semicolons mean?
Any ideas?! :) Anyone?!?!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Boston (well, Cambridge) puppetcamp on friday!
As this came up in #puppet today (and nobody seemed to know about it) I thought I'd spam the list to mention that there's a Puppetcamp in Cambridge, MA, this friday. The details are at http://puppetcampboston.eventbrite.com/ for anyone that didn't know about this and can wrangle a day off work to come along. Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
On Fri, Jun 15, 2012 at 8:36 PM, Jo Rhett jrh...@netconsonance.com wrote: I've looked at the code. It requires changing the triggers to have attributes, which is honestly a fairly trivial change and likely backwards compatible with anything today, too. Look at Puppet::Relationship.match? () -- it's accepts the idea of event types, but only has triggers for :ALL_EVENTS or :NONE. That or else could be replaced with specific event types being passed quite easily. Then each object would have to be modified to accept a revised syntax in the situation (optional) where only specific types are desired. It really doesn't appear to be a large change. I think the path forward at this point is probably to put together a rough patch that does what you're looking for. In my experience the puppetlabs guys are very helpful about answering questions and helping improve patches once a pull request/issue has been raised. I'd be shocked if they didn't at least give you some solid feedback on getting this included. Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
On Thu, Jun 14, 2012 at 11:20 AM, jcbollinger john.bollin...@stjude.orgwrote: If finer grained event-handling behavior is desired, then it should be implemented as a general-purpose facility instead of as a one-off special case. For instance, it is conceivable that a future version of Puppet would allow for some kind of filter to be installed on notification and subscription relationships, to control which events are passed through based on which resource properties changed. I don't imagine that could happen before v3.1, however, if then. Like most other posters so far I think that this would be such a fundamental change that it should come in a major version if anything. I wouldn't be opposed to the idea of being able to filter on parameters when doing a subscribe/notify, maybe a filter meta-parameter along the line of filter = ['source', 'owner' ], but like most people I feel this adds a lot of complexity for very little gain. I would prefer to simply schedule the puppet run that changes the mode and causes a service restart to occur out of hours and take the restart downtime. I feel it keeps things simple to retain the existing concept of notify. Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
On Fri, Jun 15, 2012 at 2:41 PM, Jo Rhett jrh...@netconsonance.com wrote: But your main argument is: but like most people I feel this adds a lot of complexity for very little gain. It's an odd phenomena, in that this wouldn't affect anyone not using the filter at all, but because they don't see a need for it they will object to someone else having the functionality. I figure I should clarify a little bit. Unless my understanding of Puppet internals is way off it would be quite a lot of work to add the filter as it stands. A lot of code would have to change internally to make it capable of filtering on parameters. By complexity I meant code wise, not puppet manifest/syntax wise. I just meant that it would take a lot of development to get it working consistently and properly as a metaparam throughout the codebase. It would be nice to hear from someone at puppetlabs just how difficult this would be to add based on the 3.0 codebase. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Looking for a path into the innards of the Puppet Firewall Module @ The Forge
I recently submitted a pull request for a fairly basic feature. I started out by editing spec/fixtures/iptables/conversion_hash.rb and spec/unit/puppet/type/firewall_spec.rb to add in tests for what I wanted then worked backwards from there by copying existing code, modifying it a bit and running until the tests passed. I recommend it as a way of getting started! Failing that if you visit irc.freenode.net/#puppet I'm in there as ashp and can attempt to answer specific questions about it. I'll be the first to admit I have -no- idea what I'm doing but I stumbled through enough to add something so I might be able to help you go in the same direction. On Mon, May 21, 2012 at 4:25 PM, Dan White y...@comcast.net wrote: For a few reasons: There is a missing bit of functionality that is important to me. I know WHAT I want to fox, but I do not know HOW. Also, if I am understanding how this module operates, I have ideas for other modules that use the same base methods. So, I am looking for either the folks that wrote this module or someone who can help me understand it enough for me to make some enhancements to it myself. Please help me help the Puppet community ! Thanks. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Newbie question: what to start from?
I'm not associated with this site in any way but you might want to look at http://www.example42.com/ and https://github.com/example42, they have a lot of examples and existing modules you could look through to get a feel for how Puppet is put together. On Fri, May 18, 2012 at 2:01 PM, Anatoliy Lisovskiy wavebo...@gmail.comwrote: Thanks anyway. ;) When we started using cfengine long time ago cookbooks _with_examples_ were available, it was very convenient. Anatoliy On Thu, May 17, 2012 at 2:56 PM, Andy Taylor andytaylo...@gmail.comwrote: Welcome :) I started here: http://docs.puppetlabs.com/learning/ Lots of good material. On May 17, 10:24 pm, Anatoliy Lisovskiy (Wavebourn) wavebo...@gmail.com wrote: Hello fellow community members! I just joined you in order to find an information about how to start using Puppet... Currently we use cfengine for our legacy system containing several OS platforms, including physical and virtual servers. For fresh new hardware and OS versions we decided to go with Puppet due to it's growing popularity (wow, 4082 members of this group only!). I've installed it on a Linux KVM guest, it is up and running. What's next, what would you recommend me to do now, in order to avoid common errors causing messy configuration? Do we have some kind of FAQ? Sincerely, Anatoliy -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 3.0 and Hiera
On Fri, May 4, 2012 at 5:05 AM, R.I.Pienaar r...@devco.net wrote:
I think the plan was that there would be a priority order as below:
- someone wrote in a manifest: class{foo: something = something}
- an ENC supplied the values for something on the class foo
- someone did include foo or class{foo: } this would consult hiera
- if hiera does not have an answer it would default to default
This gives people with more complex needs than those matched by hiera
the ability to use ENCs and get exactly the data model they desire as
well as people who do not want any magical data lookup for some class
the ability to hard code values.
And at the same time it lets module authors provide out of the box
defaults that work without placing a load on module users where they
might have to read every class and set hiera values for every argument
before they can use a class if all they wanted was the default out of
the box behaviour.
Does this sound sane?
I can't speak for anyone else but this sounds fantastic to me. I've already
ran into this problem where I want a bunch of defaults to be used unless
they need to specifically overwrite them in Hiera and I don't always want
to add those into Hiera (because of the lack of namespacing it can get
messy). All of the changes mentioned so far will be of very big benefit
and really improve things. :)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables
This was a long email! The answer to your problems is definitely something
like
Hiera. You make a common.yaml that has all your defaults and then you can
overwrite these based on any fact you like, when building the hierarchy.
You can
make a hierarchy like:
fqdn
environment
common.yaml
Then you could make
environment/staging.yaml
fqdn/server1.yaml
And override any of the defaults in common.yaml with more specific
values. You even
just set something like php_errors: true in staging.yaml and then in the
template have
some kind of % if php_errors % log with errors % end % etc kind of
code. Hiera
is definitely the solution to what you're trying to do, it lets you extract
all that magic
out of the manifests and keep them clean and then rely on looking for the
most specific
match when traversing down the hierarchy.
On Tue, Apr 24, 2012 at 9:19 AM, Calimero calimero...@evolutive.org wrote:
Hi,
I worked with puppet ( 0.25) back in 2008/2009. We were able to
deploy 200 servers from scratch and manage them. It worked fine.
I'm now with a new customer and I'm pushing Puppet (and I'm also back
to puppet on a side project).
We're considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts. I'm
upgrading myself to Puppet 2.6's new concepts and features.
Anyway consider this for the sake of argument:
- node server1.hostingcompanyAlpha.com
-- hosted on a dedicated server at provider Alpha
-- production
- node server2.hostingcompanyBeta.net
-- hosted on a dedicated server at provider Beta
-- production
- node staging.myprivatenetwork.priv
-- hosted on my customer's private network
-- staging/QA
- node dev.myprivatenetwork.priv
-- hosted on my customer's private network
-- development server
Those four nodes must host the same elements:
- Apache HTTPD with multiple VHosts
- PHP
- Extra software ...
There are a few differences between nodes:
- Servers don't have the same capabilities (CPU/Mem/bandwidth): we
need to tweak Apache's MaxClients settings on a per-host basis
- We need to tweak PHP : displaying errors on 'staging' and 'dev' but
hiding them on server1/server2 (ie: setting 'display_errors' to 'on'
or 'off' in php.ini)
- On development and staging/testing servers we need to change some of
the VHosts definitions: add extra serverAliases, etc ...
- server1, server2 and staging/dev must use different DNS servers (/
etc/resolv.conf) and RPM Mirrors (yumrepo{ })
I've read the following blog post:
http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
Back with puppet 0.25, we'd use global variables (not even node
inheritance).
manifest/sites.pp had something like:
$envname = 'prod'
$envstr = ''
$dns_servers = [ '10.0.0.42', '10.10.1.42' ]
import classes/*.pp
node 'server1.hostingcompanyAlpha.com' {
$httpd_maxclients = 300
$yum_base = http://mirrors.hostingcompanyAlpha.com/ftp.centos.org/
$dns_servers = [ '1.2.3.4', '1.2.4.4' ] # Hosting Co.'s resolvers
include mywebserver
}
node 'server2.hostingcompanyBeta.net' {
$httpd_maxclients = 200
$yum_base = http://repo.hostingcompanyBeta.net/centos/;
$dns_servers = [ '8.8.8.8.8' , '8.8.4.4' ]
include mywebserver
}
node 'staging.myprivatenetwork.priv' {
$httpd_maxclients = 50
$php_display_errors = 'on'
$envname = 'staging'
$envstr = 'stag'
include mywebserver
}
node 'dev.myprivatenetwork.priv' {
$httpd_maxclients = 20
$php_error_reporting = E_ALL
$php_display_errors = 'on'
$envname = 'dev'
$envstr = 'dev'
include mywebserver
}
manifests/classes/mywebserver.pp would contain somethine like this:
import php
import httpd
class mywebserver {
include centos # which would in turn include modules 'yum' and
'resolv'
include httpd
include php
include php::apc
define httpd::vhost { 'mysite' :
servername = www.mysite.com,
documentroot= /var/www/html/mysite.com,
}
}
modules/httpd/manifests/init.pp had:
# defaults
$httpd_maxclients = 150
$httpd_...
class httpd {
file { /etc/httpd/conf/httpd.conf :
content = template(httpd/httpd.conf.default.erb); #
which would
then use $httpd_maxclients
}
}
We also had a httpd::vhost($ip = *, $port = 80, $servername,
$documentroot, ...) define which would write VHosts files based on the
following template:
VirtualHost %= ip %:%= port%
ServerName %= servername %
% if envstr != '' -%
ServerAlias %= envstr %%= servername %
% end -%
% if envname != 'prod' -%
php_admin_value display_errors on
% end -%
...
/VirtualHost
modules/yum/manifests/init.pp had:
# defaults
$yum_base = http://myrepo.myprivatenetwork.priv/centos;
class yum {
yumrep { os :
baseurl = ${yum_base}/RPMS.os,
Re: [Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables
It checks every layer of the hierarchy, so it would look for: fqdn/server1.yaml environment/staging.yaml common.yaml But the important thing to know is it's looking for an actual variable. If you had defined selinux: disabled in common.yaml and nowhere else then it would always reach that file and pull in that value. Just because environment/staging.yaml matches the state of the machine doesn't mean it'll stop processing at that point - it'll check every file in the hierarchy it matches, in order, until it finds an entry for the variable you are looking up. (In a manifest you do $var = hiera(variablename)). On Tue, Apr 24, 2012 at 11:55 AM, Calimero calimero...@evolutive.orgwrote: That's the part I don't really get so far, as I haven't fiddled with Hiera yet. How would Hiera search through the hierarchy ? Try: fqdn/server1.yml == not found Try: environment/staging.yml == not found Fetch from common.yml Or: Try server1/staging.yml == not found Fetch from common.yml ie: is it recursive or it a list of fallbacks ? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How can i make a 'file' resource depend on package installation?
To make this work you need to have:
file { '/etc/foo':
ensure = present,
require = Package['SomePackage'],
}
as well as:
package { 'SomePackage':
ensure = present,
}
The require always has to have something in Puppet to match to. By saying
ensure = present you're just telling puppet hey if this package is
installed then don't worry, otherwise install the latest version you can
find through the package manager. As long as you have both pieces you
should be in good shape!
On Mon, Apr 23, 2012 at 5:27 AM, geog tomer...@gmail.com wrote:
thanks for clarifying that out! i'll give it a few more shots for some
reason did not work for me.
On Apr 23, 12:21 pm, R.I.Pienaar r...@devco.net wrote:
- Original Message -
From: geog tomer...@gmail.com
To: Puppet Users puppet-users@googlegroups.com
Sent: Monday, April 23, 2012 10:11:30 AM
Subject: [Puppet Users] How can i make a 'file' resource depend on
package installation?
basically i want to add to my file resource a requirements on a pre-
installed package and if its not installed should be first installed.
file {
require = Package[SomePackage]
}
I understand require is not supported in file resource is there any
other solution to have this dependency?
Require is whats called a meta paramater - it's supported on all
resource types
including File. Same for subscribe, notify and a few others
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] Creating a system module path (starting with Telly)
I've noticed that nobody else has replied to this but as one of the more vocal people in the original discussion I'd like to state that I love the idea of a vendor and site module path and think this is an ideal way to move these things out of the core. This proposal is much less scary than the previous conversations and at this point is actually a pretty big improvement over the current situation. So, +1 from this guy! On Mon, Apr 23, 2012 at 5:03 PM, Michael Stahnke stah...@puppetlabs.comwrote: There was some discussion and concern about moving the Nagios types/providers out of the core area of Puppet for Telly. We made a mistake of talking about a point solution to a problem rather than the vision on where we’d like it to go, and why. We’ve attempted to outline this a bit more so you can hopefully have a better understanding of our ideas. As always, feel free to comment and voice concerns. This isn’t set in stone and at this point is a proposal. == The Problem == Bundling types and providers into the core of Puppet has a few problems. The most important problem is that it ties releases of the types or providers to releases of core Puppet. That is a pretty slow moving (for stability) system, and it is also a system where most of the investment goes into supporting new releases rather than improving older releases. We want to keep our core stable, while allowing the community platform experts, distro maintainers and other users to enhance the experience with certain aspects of Puppet without having to wait for the next major release. The secondary problem is that it plays favourites - some platform types are in core, others are not. Some monitoring systems, or disk management systems are in core, others are not. That doesn't reflect the real importance of those types, or that some are more special or more stable than others - just happenstance of time. On the other hand, having Puppet work out of the box is awesome. You should be able to install Puppet and immediately get started, managing your platform and generally doing awesome things. Puppet with no types, and no providers, is not awesome. It can't do anything - and install twenty things, then ... is not a good introductory experience. == Proposed Solution == We want to take some of the great lessons from other platforms - Perl, Python, and Ruby - and apply them to this problem: We are proposing to pull more types and providers out of Puppet, so they get the benefit of an independent release cycle, and the advantages of full forge integration. We also propose to have a system module path: a set of modules that ship with core Puppet, taken from the forge, and available by default at install time. They will ensure that Puppet is still awesome out of the box - but that you can list modules and their versions, and can update freely. We also plan a vendor module path, and a site module path. Other platforms have shown the value of this: when distributions package Puppet, they might want more or different modules to support their systems better. Allowing them to drop into the vendor module path and operate in the same way as our system modules makes it easy to use normal modules in an awesome way. Finally, the site module path allows for easy deployment of modules through other packaging systems like yum and apt, internally to companies and sites that want a different path for versioning modules. They separate the mutable path used by the local tool and the managed path for self-packaged modules. This seems to offer the best of both worlds: we can take full advantage of the strengths of modules, but without giving up the awesomeness of Puppet that does great things out of the box. -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types moving into Module
This is kind of an argument against moving these things out of the core in the first place in my opinion. The fact that you can now have multiple versions of the nagios provider is just worse than having a single copy. Before at least I could update to 2.7.x and be assured all my providers were at the same version, now I have to deal with all the module updates (which only grows as time goes on) and constantly deal with checking them into git, managing them, testing them with various versions of the client. I get why you're doing this but as an end user this is just causing me more work and making me do more testing and a lot more management. At least before I could rely on having a broad set of core resources. Now we're going in the opposite direction. Maybe I'm just a grouchy old sysadmin but now I can't just rely on yum.puppetlabs.com to provide my resources and that means time out of my day to update them and push them into git. In the workflow we've instigated at work I cannot just throw in an update and push it - I have to create branches, run tests, open tickets. With things provided by puppet's core I just have to get approval to update the client in one easy push. Maybe I'll just make /etc/puppet/modules/ for modules imported directly from the forge (and unedited in any way) and instigate easier rules around updating these. Sorry if this turned into a bit of a GET OFF MY LAWN post. On Mon, Apr 16, 2012 at 8:45 PM, Michael Stahnke stah...@puppetlabs.comwrote: On Mon, Apr 16, 2012 at 11:36 AM, Todd Zullinger t...@pobox.com wrote: Michael Stahnke wrote: For the next major Puppet version, code-named Telly, we have some changes coming. This is the first in a series of emails around these changes and may require some input from the community. For Telly, the nagios types will be moved into a module. This allows them to be iterated on in isolation from the rest of Puppet's core release cycle and process. In the future we have plans to move several other types into modules that can be individually maintained, improved, tested and used. The module for Nagios will be available on the Forge. The upgrade path is the thing we need some feedback about. The basic steps to upgrade would be to setup a Telly master, and then install the Nagios module via the Puppet Module Tool, which ships integrated with 2.7.13+ and Telly. Is it possible to package these modules for distros? In the past, we've had a few requests to do this for third-party modules but we didn't do this because there wasn't really any standard for it. With puppet module tool being integrated now, perhaps that's something that can be reconsidered. I'm thinking that for folks using rpm, they'd rather see an update that pulls in the same fucntionality as they had before. And even for new installs, I'd personally prefer to install these things via rpm. If I wanted to use a secondary package management system, I could use gems or eggs or CPAN, but I don't. ;) Todd, welcome and I feel your pain. Trust me, I pushed every way I could to use native packages as our module deliver mechanism. However we have some odd requirements that make things not work as well with RPM (or deb, or gems). Basically we need a mechanism to allow multiple versions installed into separate environments (paths on disk). That sort of ruled out traditional packaging systems, without doing some installation and symlink-selection magic. Even then, there were some issues. Something like pm2rpm and pm2deb is very likely something we'll need to make the lives of Puppet Users happy. It should be fairly simple and we'll want to be sure that the default module path is something that is FHS compliant. We'll also want to work with Jordan and see if we can get packaging Puppet Modules (in this format) as an option with FPM. I think FPM already does some Puppet Module stuff, so it may not need any real updates. Mike I think it's good to split out these things, as it would allow us to properly add a nagios dep to the hypothetical puppet-module-nagios package. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ I am free of all prejudice. I hate everyone equally. -- W. C. Fields -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to
Re: [Puppet Users] Supported Ruby Versions for Telly
You might have the best luck going the route of Well, my puppetmaster needs RHEL6 and that's the only way it's supported because then you get 1.8.7 from an official source. I completely sympathise with your situation, having been in it before. Your understanding is right to the best of my knowledge, I wouldn't try and run the master on 1.8.5, but clients should work with the stock RHEL5 Ruby. On Sun, Apr 15, 2012 at 11:29 AM, Dan White y...@comcast.net wrote: I would have no problem trying either one of these, but the PHB-objections I face are that these do not come from Red Hat or a reliable source. They might trust them if they came from PuppetLabs' repository, but even that is no guarantee. They are inconsistently paranoid about what they will permit into their production environment. They had kittens when I initially pulled Cobbler and Puppet from EPEL, while they build replacements for some packages from source and install from the source build rather than with an RPM. Please tell me if I understand the versioning requirements: I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master. The clients/agents can use ruby 1.8.5 for now. Is that accurate ? On Apr 15, 2012, at 12:03 AM, Craig White wrote: enterprise ruby (1.8.7 only) http://www.rubyenterpriseedition.com/download.html Craig On Apr 15, 2012, at 12:55 AM, Gary Larizza wrote: Have you checked out the packages that Karanbir Singh has created? They work fairly well -- http://centos.karan.org/el5/ruby187/ On Sat, Apr 14, 2012 at 8:53 PM, Dan White y...@comcast.net wrote: Great to hear this, but I am now looking for a reliable way to get Ruby 1.8.7 or 1.9.3 onto a RHEL-5 system. The environment I am working still has RHEL 3 and 4 machines running, and I would not hold my breath waiting for transition to RHEL 6 (which does have ruby 1.8.7 in it) One more thing: When I say reliable, it has to be able to convince a non-technical PHB type. Suggestions ? On Apr 13, 2012, at 2:59 PM, Michael Stahnke wrote: Puppet Labs is happy to announce full support for Ruby 1.9.3 will be part of the next major release of Puppet, codenamed Telly. Ruby 1.8.7 and 1.9.3 are considered the primary supported Ruby versions, on all platforms including Unix, Linux, Windows, and MacOS-X. Ruby 1.8.5 is also supported, on the agent only. The Puppet 2.7 series featured initial support for the Ruby 1.9 series, and we are happy to see that work completed and brought forward to full production support in the forthcoming release. Other Ruby versions including 1.8.6, 1.9.1, and 1.9.2 are not officially supported. Ruby implementations other than the MRI series are not officially supported. We will accept patches that fix issues on other (non MRI) Ruby systems. 1.9.3 was selected due to its inclusion in Fedora 17 (Beefy Miracle) and Ubuntu Precise Pangolin. Previews of Telly should be available in May. If you'd like to see some of the changes happening today, you are also welcome to run Puppet's master branch. If you have questions or concerns, feel free to respond here. Mike Stahnke Community Manager -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Why latest stable Debian Squeeze package is 2.6.2-5+squeeze4 please ?
You can try the Debian packages at http://apt.puppetlabs.com/ to see if the Squeeze ones are more up to date (they will be, I think!) On Thu, Apr 5, 2012 at 7:19 AM, Christophe L cl.subscript...@gmail.comwrote: Hello, I have installed puppet on debian-squeeze using aptitude / apt-get but I got the version 2.6.2 of Puppet. After some research, I have found that the last stable debian package version is puppet (2.6.2-5+squeeze4) [security] http://packages.debian.org/squeeze/puppet and that 2.7.12-3 is considered as unstable http://packages.qa.debian.org/p/puppet.html But on the puppet documentation, it is written that The latest stable release is 2.7.12 The latest maintenance release is 2.6.14 Could you explain me the reason why the latest stable release of puppet is considered as unstable on debian squeeze please ? Is there a way to install puppet 2.7.12 on debian squeeze and what are the risks if I do so please ? Thanks in advance for your answers Best regards, Christophe -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] stdlib/range issue
I needed this just yesterday, actually, for NFS mounts.
$PO_0_9 = prefix(range(0,9),'/PO_0')
$PO_10_31 = prefix(range(10,31),'/PO_')
$PO_32_76 = prefix(range(32,76),'/PO_')
nfs::po_mounts_50{ $PO_0_9:
options = 'soft,bg,tcp',
}
nfs::po_mounts_50{ $PO_10_31:
options = 'soft,bg,tcp',
}
nfs::po_mounts_55{ $PO_32_76:
options = 'soft,bg,tcp',
}
I know how ugly this is, but I had to split the range in two just to get
the leading 0.
On Thu, Mar 29, 2012 at 11:57 AM, Gary Larizza g...@puppetlabs.com wrote:
On Thu, Mar 29, 2012 at 8:48 AM, Pablo Fernandez
pablo.fernan...@cscs.chwrote:
Dear stdlib'ers...
I have just discovered the wonders of the parser functions, and got
impressed with the tens of functions that come with stdlib. First things
first... good work!!! Thanks!!
And now the issue. It seems like the writer of the range() function did
not think about ranges with more than one digit that need leading zeros in
the first items, like 01..99, when you usually want to have 01, 02, and
so on. Ruby allows you to do (01..99) and that will do the right thing,
but the range() function provided with stdlib does some type conversion
(detects if it's a number, and changes the type to integer) which converts
01 to 1 breaking this possibility.
Hey Pablo,
Just a question - do you have a NEED for it to be [01...99] with the
leading zero? If I understand correctly, the end result is the same, as
the range function will cast 01 to 1 and not BREAK because you pass it 01 -
correct? Maybe I'm missing why you would need to use 01 explicitly?
I tried to submit a bug report, but I just can list the open ones, can't
make one myself. Is this intentional? How do I properly address this
request?
No problem. We've turned off Github Issues because we use our central
Redmine server for bug tracking --
http://projects.puppetlabs.com/projects/modules/issues Please feel free
to file any module tickets here!
So, I tried to change that myself, but no matter what I do to the
range.rb file, the changes are not picked up by the node. Do I have to do
something to force a reload of the file? This runs in the server, right?
What I did then was to create a range_custom() which is a copy of the
former, but without the type conversion. I tried that and it works like a
charm.
Thanks!
Pablo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@**
googlegroups.com puppet-users%2bunsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/**
group/puppet-users?hl=enhttp://groups.google.com/group/puppet-users?hl=en
.
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] mcollective plugin question
You might want to look into the puppetral plugin to mcollective. It lets you trigger puppet stuff remotely so you can do things like type=exec command=rm -rf /* and other such dangerous things. I tried it recently and the important action of do has vanished (so there's an open ticket on that) but it should do what you need! On Tue, Feb 21, 2012 at 10:46 AM, Kenneth Lo k...@paydiant.com wrote: We've been using mcollective primarily for coordinate service restart across nodes as well as facts-finding, which are all well and good. One thing we would like to utilize this tool is to create an arbitrary shell command plugins/services so our master can really act as a command center. I spoke with a couple folks and know that this is just as a matter of writing the plugin itself, but I'm wondering if folks here already have a solution for it or if you have any pointers we can check. :) Thx in advance. --KL This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Anyone seeing odd agent behaviour with 2.7.10?
I'm having the same thing, I use puppetd -tv all the time and now it's trying to delete a .pid at the end: err: Could not remove PID file /var/run/puppet/agent.pid It's super annoying but not fatal I suppose. I stopped the daemon from running and tried running puppetd again but it still gave the same error. On Thu, Jan 26, 2012 at 8:14 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - Is the puppet agent daemon running when you run the agent by hand? Ah! thats it, I'll take a look -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Cross-module (package) dependencies
I don't have a solution but I do want to chime in and state that modules
that
exist just to collect together virtual resources is a horrible thing.
We're just
talking about working around the way Puppet works right now rather than
defining what the end solution should be.
I would be happiest with some kind of thing that can handle multiple
versions
of the same resource and work out a way to apply them as one entry. Like
others suggested something that can merge all the unique attributes together
for one entry. After all, if they've been included on the host all of
those attributes
should apply so I can't see a dangerous downside to this.
It has to be better than trying to organize things so you only use a
resource
once and having all kinds of tricks and complicated workarounds. I don't
want
my modules to have to rely on some weird generic module full of virtual
resources
just to use a package without clashing into a module written by a coworker.
I
think modules should be capable, if possible, of standing alone, and this
is ruining
that basic concept.
On Wed, Jan 25, 2012 at 12:12 PM, Dan Bode d...@puppetlabs.com wrote:
On Tue, Jan 24, 2012 at 1:28 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Hi,
there was a discussion in the can we deprecate defined() in Telly
thread about how we can even begin to design Forge modules without it.
A recurring problem is that multiple modules rely on certain packages,
and there is no good model (yet) to unite their resource declarations.
Therefore it's a common (although imho disgusting) workaround to do
things like
if !defined(Package[foo]) { package { foo: ensure = installed } }
On 01/20/2012 11:34 PM, Cody wrote:
Defining all somewhat common packages in a central location becomes
unrealistic when you no longer control the code that is in every
module you use. If you obtain five modules from the forge and they
all require a specific package and so all define that package your not
going to convince, nor is it a good design to require everyone to move
the package definitions from that collection of modules. They need to
function as a collection out of the box.
Agreed. How can this be accomplished?
Perhaps there needs to be some kind of Forge common module that by
policy can only ever declare virtual resources (packages are a prominent
Until there is a way to distinguish between collection of regular versus
virtual resources, I hope that we don't do anything that advocates the
usage of virtual resources.
The problem is that collections (like below) meant to
establish multiple dependencies unfortunately have the side effect of
realizing virtual resources.
Class['apt'] - Package| |
example).
A user who wishes to retain the capability of using modules from the
Forge would be required to install this common module, and replace their
own resource declarations with realizations of the common resources.
For this to work, it's definitely a plus that you can override
attributes in collections:
Package| title == apache2: | { ensure = 2.2.12 }
...although that does bear some caveats. Does this still work in recent
versions?
If we can take this for granted, all Forge modules can adhere to that
same standard.
This is a rough sketch of how things might possibly work, and surely has
lots of wrinkles of its own. Still, I'm quite sure we need a proper way
to rid ourselves of the horror that is the parse order dependent check
for defined resources ;-)
Cheers,
Felix
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
This is a fantastic reply and I appreciate the work you put into it. I
have just one
question. As it stands functions can only apply to partial catalogs and
not to the
full catalog. Is this a fundamental design decision that cannot be
changed? Perhaps
it would be interesting to speculate on what could be done if you had the
ability to
use the entire catalog when fully parsed.
While writing that paragraph I guess I can see how that wouldn't work,
you'd always
have to evaluate anything that required those functions at the end of the
catalog and
if they had dependencies that would be impossible.
I still dislike the third module refactoring. I think it removes a lot of
power of self-
contained modules and makes things significantly uglier and more difficult
when
combining modules from multiple sources. I wish it could be solved in a
better
way within Puppet and I believe it could be with (perhaps optional) merging
of
identical resources.
But hey, I'm not the guy who has to implement this so I can appreciate that
there
are probably all kinds of design reasons this doesn't work.
All I know is that telling users If you download 5 modules from puppet
forge
make sure you go through them all, extract any duplicating resources into
random modules that exist purely to allow you to realize packages instead
leads
to a really bad user experience.
On Wed, Jan 25, 2012 at 3:17 PM, Jeff McCune j...@puppetlabs.com wrote:
On Thu, Jan 19, 2012 at 9:18 AM, Nigel Kersten ni...@puppetlabs.com
wrote:
I'm looking for strong opinions on whether we should or shouldn't
deprecate
the defined() function for Telly, the next major Puppet release this
year.
jcbollinger put it quite well in another thread:
Use of the defined function introduces a parse-order dependency, and
the
additional work you need to do to ensure that that dependency is always
fulfilled overcomes any simplicity advantage that might otherwise exist.
I'm coming into this thread a bit late so I'm going to take the
strategy of replying to the OP and pasting a lot of the major comments
about the related issues into this reply and then addressing those
directly, inline.
The TL;DR version is that I strongly believe defined() is an
anti-pattern and should be removed from Puppet core.
For those who would still like to have it available I think it should
be added to the stdlib module as two new functions: already_defined()
and already_declared(). The already_ prefix is to clearly communicate
these are parser-order dependent functions and they _do not_ operate
on the final catalog itself.
Finally, for those who want 100% backwards compatibility, we publish a
new module in addition to, and compatible with, stdlib that provides
the existing behavior of defined().
And now for the longer version of why I have this strong opinion:
Throughout the replies in this thread, many people are using defined()
to test of a resource or class has been added to the catalog and if
not, add a resource with the same type and title to the catalog. I'm
going to call this the if not defined then declare anti-pattern.
I'll explain why it's an anti-pattern at the conclusion. I hope
showing the pattern to be an anti-pattern will be sufficient to show
the pattern should be avoided when publishing modules.
Nick Fagerlund said:
Defined() doesn't suck! It's a 100% reliable way to check what classes
and defined types are available to the autoloader.
This is an accidental feature and orthogonal to the intent of defined.
There's also not much evidence that the Puppet community is
leveraging defined() in this manner. Finally, we should implement a
first-class and supported function to provide this feature in a clear
way. is_available() perhaps.
Ashley Penney said:
if ! defined(Mysql_user [${user}@${host}]) { mysql_user {
${user}@${host}:
... } }
This is the if not defined then declare anti-pattern.
Felix Frank said:
If your master processes this before the *other* declaration of that
mysql_user{}, you're back to square one and get errors about multiple
resource declaration.
This is part of why if not defined then declare is an ant-pattern.
Nan Liu said:
We should at least differentiate defined vs. declared
Yes, certainly. We also need to keep in mind that a function can only
operate on a partial catalog. A function can never operate on a
complete catalog. Therefore, we need to think of these as defined
_yet_ and declared _yet_ with respect to parse order.
My proposal here is to add already_defined() and already_declared() to
stdlib. The names are only an example, I don't really care what
they're called so long as their names take into account the fact that
a function can only operate on a partially compiled catalog.
Dan Bode said:
* static resources in a defined resource type (avoids having to use
classes
to store all static dependencies)
This looks like the anti-pattern, but is not IFF
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
Nigel,
Just so we understand the requirements of this - what would it take to make
a function that
is usable in way that a few of us have mentioned - something that lets us
say If a class
is included in this host, then X. It seems like this would be desirable
functionality and so
far everything I've heard has been a clumsy workaround for this base kind
of functionality.
What I don't understand is why defined creates a parse order dependency and
why it's not
able to search through the entire catalog to see if the class is defined.
This is totally my
lack of understanding of the code shining through but what stops this being
possible?
Is it just the case that you don't want to rely on a class in the future
has hasn't yet been
processed because it might fail and therefore, for the purposes of puppet,
not be defined?
On Mon, Jan 23, 2012 at 7:57 PM, Nigel Kersten ni...@puppetlabs.com wrote:
On Mon, Jan 23, 2012 at 5:15 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Hi,
On 01/20/2012 11:34 PM, Cody wrote:
Defining all somewhat common packages in a central location becomes
unrealistic when you no longer control the code that is in every
module you use. If you obtain five modules from the forge and they
all require a specific package and so all define that package your not
going to convince, nor is it a good design to require everyone to move
the package definitions from that collection of modules. They need to
function as a collection out of the box.
Agreed. How can this be accomplished?
Felix, could you take this to a new thread please? I'd really like to keep
this one focused on the topic at hand if possible :)
Perhaps there needs to be some kind of Forge common module that by
policy can only ever declare virtual resources (packages are a prominent
example).
A user who wishes to retain the capability of using modules from the
Forge would be required to install this common module, and replace their
own resource declarations with realizations of the common resources.
For this to work, it's definitely a plus that you can override
attributes in collections:
Package| title == apache2: | { ensure = 2.2.12 }
...although that does bear some caveats. Does this still work in recent
versions?
If we can take this for granted, all Forge modules can adhere to that
same standard.
Yes, it's quite a hassle.
No, I didn't think this through very thoroughly ;-)
Just another pair of cents.
Cheers,
Felix
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Nigel Kersten
Product Manager, Puppet Labs
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
What would you recommend as an alternative way to handle these cases? I
suppose the mysql lib could be extended to be able to check for users (not
easily, but it could be done), but what about in the second case where I
want to check for various roles being set as classes and then use those to
decide the configuration of foreman. Volcane said that setting variables
in the other classes and checking for those isn't going to cut it either.
What's a good pattern for this?
On Fri, Jan 20, 2012 at 3:39 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
But this is begging for trouble:
On 01/19/2012 09:22 PM, Ashley Penney wrote:
An example:
if ! defined(Mysql_user [${user}@${host}]) {
mysql_user { ${user}@${host}:
password_hash = mysql_password($password),
require = File[/root/.my.cnf],
}
}
If your master processes this before the *other* declaration of that
mysql_user{}, you're back to square one and get errors about multiple
resource declaration.
I can see only pain down this road.
Nick's example on the other hand is quite enticing, I think. We want to
keep that (and include it in some Best Practices ;-)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] any cobbler management modules out there?
While this isn't what you want to hear, exactly, there's a bootstrapping tool that works fantastic with Puppet at http://www.theforeman.org/ - it's probably why you don't see many cobbler modules. People like me who used cobbler when starting out with Puppet migrated off to Foreman with time. On Fri, Jan 20, 2012 at 12:25 PM, Nick oinksoc...@letterboxes.org wrote: On 20/01/12 13:57, Dan White wrote: I am running Cobbler and Puppet together and I am not sure that a Puppet Module is appropriate for more than just the base settings. Cobbler manages all its internal info. To get Puppet to manage it would, IMO, either involve hacking Cobbler or wrapping Cobbler command line calls in Puppet exec resources. Yes - I had imagined the latter. Sounds messy to me. Yes again. But then that's nothing new in this field. I keep both Cobbler and Puppet in a Subversion repository. I used this as a model to start from: http://consultancy.edvoncken.net/index.php/HOWTO_Set_up_a_Subversion_repository_for_provisioning and modified things to fit my environment. Interesting; although there's a big blank there when it gets to Puppet. If you want to preserve the contents of Cobbler, just back up /var/lib/cobbler/config/ Everything is in the JSON files. I keep Puppet in Git. However, it is not documented and wasn't obvious to me that you can version control the entirety of Cobbler and not tread on its toes. However, if you are doing that, obviously it is possible, and this seems a good way to sidestep the problem. For now, anyway. I'll see if I can shoehorn the cobbler directories into my puppet repository somewhere, perhaps under modules/cobbler/files... Then the Puppet bit would just need to deploy that. (Ignoring SCM tracking, which won't play nicely with a scheme like this, by default.) Actually since I'm currently using a masterless Puppet config and checking the source out everywhere, deployment would just be a matter of symlinking. However, this is only able to cut and paste a working cobbler system, right? So far as I can see, I can't use it to drive things from Puppet. What I was hoping might be possible is to have one manifest defining a node's parameters, and use external references within it (or a masterless equivalent along the lines of [1]) to import these into Cobbler. Thanks, Nick 1. http://current.workingdirectory.net/posts/2011/puppet-without-masters/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
I use defined every so often so I would be sad if it was removed, it's
handy for certain things of things:
common/foreman_proxy/manifests/params.pp: if
defined(Class['puppet::server::ca']) {
common/foreman_proxy/manifests/params.pp: } elsif
defined(Class['puppet::server']) {
common/foreman_proxy/manifests/params.pp: if
defined(Class['foreman_proxy::role::build']) {
common/mysql/manifests/rights.pp:if ! defined(Mysql_user
[${user}@${host}])
{
An example:
if ! defined(Mysql_user [${user}@${host}]) {
mysql_user { ${user}@${host}:
password_hash = mysql_password($password),
require = File[/root/.my.cnf],
}
}
In my foreman_proxy stuff:
# puppetca settings
if defined(Class['puppet::server::ca']) {
$puppetca = true
$autosign_location = /etc/puppet/autosign.conf
$puppetca_cmd = /usr/sbin/puppetca
$puppet_group = puppet
# puppetrun settings
$puppetrun = true
$puppetrun_cmd = /usr/sbin/puppetrun
} elsif defined(Class['puppet::server']) {
# puppetrun settings
$puppetca = false
$puppetrun = true
$puppetrun_cmd = /usr/sbin/puppetrun
} else {
$puppetca = false
$puppetrun = false
}
I'm sure there are other ways to do it but this seems elegant and makes
sense at times. I could set variables in those other classes and then
check for them I suppose but what is the harm in doing things this way? I
don't see why defined() couldn't be implemented properly rather than being
removed.
On Thu, Jan 19, 2012 at 3:17 PM, Nick Fagerlund
nick.fagerl...@puppetlabs.com wrote:
On Jan 19, 11:01 am, R.I.Pienaar r...@devco.net wrote:
- Original Message -
Defined() doesn't suck! It's a 100% reliable way to check what
classes and defined types are available to the autoloader. I challenge
anyone
to find me an example of this usage that fails.
can you give an example of this use case pls?
Well... that's something I realized after I posted that, is I'm not
sure if anyone WANTS a reliable way to test the autoloader. (Obviously
people do want a way to check for resource instances, which is why
defined() keeps getting used for that...)
But anyway! Say you make a module for a network service and you want
it to be able to manage its own firewall rule. You know of a defined
type for firewall rules, and you're using it, but you want your module
to be portable and you know of good reasons why someone wouldn't be
using your iptables module.
So, you can conditionally declare the rule if the defined type is
available to the autoloader, and otherwise you don't attempt to manage
the firewall and expect that the user has read the documentation and
will make a hole for the service themselves.
if defined(firewall::iptables::rule) {
firewall::iptables::rule {'mysql_server':
...etc. etc.
}
}
See? It's just a way to peek around at what the user has installed.
Which... maybe implies that it should be renamed to installed().
Dunno.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Installing Oracle
Oh nice! I'm going to look into this - I hadn't spotted this. My solution was rather basic and once the RPM was installed and the various /etc/ stuff done I was just starting up oracle and then telling the developers to: sudo su - oracle sqlplus database/password @some script the dbas gave us @another script To configure everything. I was planning on figuring out how to feed scripts into sqlplus without doing it by hand so I could automate this, but I hadn't got that far because honestly everything about Oracle makes me want to punch my own face over and over. On Sun, Nov 20, 2011 at 6:05 AM, Kristof Willaert kristof.willa...@gmail.com wrote: Hi, [snip] Thanks. One question though. I'm not much of an Oracle expert, and I guess this is more of an Oracle question, than a puppet one, but what did you do to configure Oracle on the command line once it was installed? Oracle actually provides some stuff exactly for this. There is a way to clone an existing oracle install to get up and running on a different machine just by copying over the binaries and running a script called clone.pl to differentiate the new machine/install from the original one. I am planning to use it like this: install the first oracle and prepare it for cloning (see below for instructions), package it in an RPM so I can easily use puppet to get it in place on a new machine and then either write an exec, a custom type/provider to deal with the clone.pl stuff, or just let the DBA's handle it. Information on the cloning stuff: * http://docs.oracle.com/cd/B19306_01/em.102/b16227/oui7_cloning.htm * http://docs.oracle.com/cd/B28359_01/em.111/b31207/oui6_cloning.htm One of the advantages here, is that this is a supported way of customizing. Just my 2c. Kind regards, kristof -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Installing Oracle
This is not what you want to hear but I ended up installing oracle with the
installer and then using fpm to bundle the entire thing into (two,
because it's too goddamn big) rpms. I had no luck doing the installer via
Puppet so I just cheated.
On Sat, Nov 19, 2011 at 1:11 PM, Douglas Garstang
doug.garst...@gmail.comwrote:
That's what I am already using.
On Fri, Nov 18, 2011 at 6:33 PM, Mohamed Lrhazi lrh...@gmail.com wrote:
Maybe you need something like this:
http://www.oracle-base.com/articles/misc/OuiSilentInstallations.php
On Fri, Nov 18, 2011 at 9:23 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
This is pretty ugly.
I'm using puppet to install Oracle, ie an exec{} wrapped around:
/u01/oracle_extract/linux.x64_11gR2_database/database/runInstaller
-silent -responseFile /etc/oracle_response.rsp
The problem is that the damn installer backgrounds itself and returns
control to the shell. I tried putting the above command in a script,
followed by a wait command, but that didn't help. Has anyone got any
ideas how I can automate the installation of Oracle with puppet?
I need to know when the install is finished, because there's
additional commands that need to be run by root, as advised by the
installer, when it's complete.
Doug.
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Devops/Puppet job in downtown Boston
Hi, We're looking (well, my boss is looking) to expand our operations team in Boston and we're specifically looking for people with a passion for automation. Ideally the candidate we're looking for would be developer minded, with the ability to write custom tools or customize existing products (Write patches for Puppet! Submit patches to Puppetlabs, make my job easier!) yet with an understanding of the unique challenges that go into ops. I'm not the hiring guy so I can't speak on any kind of money specifics and I believe we are looking for local people able to commute to downtown Boston (or at least relocate themselves to make that happen.) The company is a security focused organization (https://www.perimeterusa.com/) and we do lots of managed security type stuff. The Boston office is primarily where all ongoing and new development occurs now. I can't give too much detail at this point and I'm not even sure what kinds of details people would need, but so far working here seems pretty good and I moved on from a cushy university position to take this role. We're very determined to reinvent operations here and to bring in the kind of cool automation that everyone on this list likes working on, from auto scaling fancy cloud stuff to decent deployment systems. If this seems like the kind of thing you might be interested in just send me your resume and I will send them all over to my boss before he goes out to recruiters and starts doing things the hard way! Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Sudden failure with storeconfigs in 2.7.4
This was definitely the bug, I should have emailed an update after we figured out the cause! On Sat, Oct 1, 2011 at 2:49 PM, Daniel Pittman dan...@puppetlabs.comwrote: On Sat, Oct 1, 2011 at 08:29, Nigel Kersten ni...@puppetlabs.com wrote: On Fri, Sep 30, 2011 at 9:31 AM, Ashley Penney apen...@gmail.com wrote: I export a @@host for each box (for horrible reasons) and do various things with that including building a /etc/hosts on each server. Sometime today after upgrading to 2.7.4 I realized that all my exported entries are failing and are being stripped from the /etc/hosts which is causing me significant issues. Has anyone else seen any kind of problems with storeconfigs? I'm going to put together a bug report for it but I thought I'd see if anyone else had seen anything weird since the release. Are you using postgres ? I saw some chatter that there was a postgres bug we introduced I think? That sounds exactly like the PostgreSQL bug, which was missed because of case insensitivity in comparisons for other DBMS'. The attached patch should fix that, but the 2.7.5 security release should also contain it. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Sudden failure with storeconfigs in 2.7.4
Hi, I export a @@host for each box (for horrible reasons) and do various things with that including building a /etc/hosts on each server. Sometime today after upgrading to 2.7.4 I realized that all my exported entries are failing and are being stripped from the /etc/hosts which is causing me significant issues. Has anyone else seen any kind of problems with storeconfigs? I'm going to put together a bug report for it but I thought I'd see if anyone else had seen anything weird since the release. Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Community Package Repos for Puppet Labs products
I just wanted to take a minute to thank you for working on these packages. Having first class packages like this available is absolutely vital and it's both helped me internally bring up Puppet faster as well as helped me advocate the product to several other people lately by being able to point them to a puppetlabs provided location to get everything. It's very much appreciated and a thankless job and I hope you'll stick with it! On Wed, Sep 28, 2011 at 4:37 PM, Michael Stahnke stah...@puppetlabs.comwrote: On Wed, Sep 28, 2011 at 7:59 AM, Steve Snodgrass phe...@gmail.com wrote: So I've just started testing these repos and I ran into problems. First, many of the EL6 RPMs are not signed, so they fail to install with my standard yum config. In the EL6 products repo, for example, only 3 of 12 RPMs are signed. The other issue is that the new puppet dashboard 1.2.1 package is not present at all. Thanks. I've fixed this. Thanks for filing the tickets. Mike -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Deployment of applications
This looks fascinating and I'm absolutely going to do some experimentation
with it this week as a way to do some of the awkward deploys that exist. I
love the idea. As a recent 2.7 upgrader I look forward to seeing the faces
version you talk about. I guess today I'll finally get mcollective rolled
out in advance of testing with Puppi. Thanks!
(As for the rest of this thread Volcane convinced me that I was being stupid
and my approach to the problem was wrong and to put the build logic in
Jenkins and keep the deploy logic to package{}.
On Mon, Sep 19, 2011 at 5:01 PM, Alessandro Franceschi a...@lab42.it wrote:
You might be interested in Puppi, which is a Puppet module and a bash
command that i've written exactly for this reason.
Code: https://github.com/example42/puppi
More info: http://www.example42.com (now terribly slow) or
http://puppetlabs.com/blog/deploying-applications-and-bringing-puppet-information-to-the-cli-with-puppi/
It mixes the possibility of defining inside puppet manifests what you
need to make a deploy with a simple command that is actually used to
launch the deploy (by hand, via cron, via mcollective or triggered by
whatever tool).
The deploy procedure (commands to execute) can be totally customized,
but there are some ready examples to deploy from a Nexus repository,
or deploy directly wars, tarballs, zip archives and so on.
In few words, in order to be able to issue a command like:
puppi deploy supersite
you write Puppet code like this:
puppi::project::war { supersite:
source = http://repo.example42.com/deploy/prod/
supersite.war,
deploy_root = /store/tomcat/myapp/webapps,
report_email = sysadm...@example42.com,
}
but you can have more complex arguments like:
puppi::project::maven { supersite:
source = http://nexus.example42.com/nexus/content/
repositories/releases/it/example42/supersite/,
deploy_root = /usr/local/tomcat/supersite/webapps,
config_suffix= cfg,
config_root = /srv/htdocs/supersite,
document_suffix = css,
document_root= /srv/htdocs/supersite,
firewall_src_ip = $site ? {
dr = 192.168.101.1/30,
main= 192.168.1.1/30,
},
backup_retention = 3,
init_script = tomcat,
report_email = sysadm...@example42.com,
enable = true,
}
And, if you need it, there's the mcollective agent and relevant mc-
puppi command.
Hope it might help,
al
On Sep 13, 9:53 pm, Ashley Penney apen...@gmail.com wrote:
I know this has come up on the list numerous times before but I
thought it would be a good time to see if the state of the art has
advanced for this kind of thing. I wanted to know how people are
handling higher level deployment of applications - things that have to
be done repeatedly but not all the time. An example of this is
checking an application out of svn, building it, creating a package
and then moving it off to a repo. Or even just building/installing
locally for developers.
It never seems to fit well into Puppet for me and I end up with crazy
complicated manifests to deal with this kind of thing. I recently
moved these jobs into Rundeck (www.rundeck.org) which works pretty
well but doesn't really leverage any of the stuff I have within
Foreman/Puppet. I've seen suggestions to use mcollective but this
doesn't easily integrate our existing scripts (written in many
languages) or processes and would require me to force a lot of
developers to work differently. I could just have classes that
trigger scripts only when some condition is met (like /.buildapp
files) or something along those lines but nothing seems elegant.
What I'm trying to find out is what other people did to handle this?
I want something I can build up over time and slowly migrate legacy
apps and processes into without having to do a massive up front
development. It should also be relatively simple and not require me
to code anything as anyone on the list who knows me can tell you that
I am absolutely awful at coding.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Deployment of applications
I know this has come up on the list numerous times before but I thought it would be a good time to see if the state of the art has advanced for this kind of thing. I wanted to know how people are handling higher level deployment of applications - things that have to be done repeatedly but not all the time. An example of this is checking an application out of svn, building it, creating a package and then moving it off to a repo. Or even just building/installing locally for developers. It never seems to fit well into Puppet for me and I end up with crazy complicated manifests to deal with this kind of thing. I recently moved these jobs into Rundeck (www.rundeck.org) which works pretty well but doesn't really leverage any of the stuff I have within Foreman/Puppet. I've seen suggestions to use mcollective but this doesn't easily integrate our existing scripts (written in many languages) or processes and would require me to force a lot of developers to work differently. I could just have classes that trigger scripts only when some condition is met (like /.buildapp files) or something along those lines but nothing seems elegant. What I'm trying to find out is what other people did to handle this? I want something I can build up over time and slowly migrate legacy apps and processes into without having to do a massive up front development. It should also be relatively simple and not require me to code anything as anyone on the list who knows me can tell you that I am absolutely awful at coding. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Deployment of applications
The kind of thing I was thinking of was selecting where to run jobs by puppet class, or even requiring that certain classes are assigned to certain nodes (requiring a pre-req class before you actually send over a job to build). In my mind I envisioned extensions to something like Foreman where you can get a list of jobs that are valid for each node by clicking the node (in a job you could apply constraints like only boxes with mysql::server and 4G of ram). Another example of the kinds of terrible stuff I engineer when left to my own devices is I wrote a job in rundeck that at the end wrote a .pp to /tmp/ and called it so that I could use templates in Puppet to build the configuration file to distribute. Basically a lot of the time I just need a way to trigger one time puppet manifests with a gui of some kind I can give to developers. I could very easily just spit a few scripts onto the boxes and call those for the build, I just want a way to enable/disable the jobs. I can't think of any other good way to say do a one time run of project::build_core on the following matching nodes: x, y, z. I am really just using rundeck for the equivalent of that. Other things I would think of using this for is handling deploying a bunch of servers where server 1 has to be fully provisioned before 2 and on 2 at least one service has to be up before 3 can do its thing. It's something that's still a hassle to do well within Puppet. On Tue, Sep 13, 2011 at 4:07 PM, Brian Gupta brian.gu...@brandorr.comwrote: If you want something simple and don't need a GUI, many folks are using either Capistrano (Ruby) or the very similar Fabric (Python) for deployment. You can populate hostlists via Foreman queries. That said, I am not sure what sort of integration with Puppet/Foreman you are looking for. Cheers, Brian On Tue, Sep 13, 2011 at 3:53 PM, Ashley Penney apen...@gmail.com wrote: I know this has come up on the list numerous times before but I thought it would be a good time to see if the state of the art has advanced for this kind of thing. I wanted to know how people are handling higher level deployment of applications - things that have to be done repeatedly but not all the time. An example of this is checking an application out of svn, building it, creating a package and then moving it off to a repo. Or even just building/installing locally for developers. It never seems to fit well into Puppet for me and I end up with crazy complicated manifests to deal with this kind of thing. I recently moved these jobs into Rundeck (www.rundeck.org) which works pretty well but doesn't really leverage any of the stuff I have within Foreman/Puppet. I've seen suggestions to use mcollective but this doesn't easily integrate our existing scripts (written in many languages) or processes and would require me to force a lot of developers to work differently. I could just have classes that trigger scripts only when some condition is met (like /.buildapp files) or something along those lines but nothing seems elegant. What I'm trying to find out is what other people did to handle this? I want something I can build up over time and slowly migrate legacy apps and processes into without having to do a massive up front development. It should also be relatively simple and not require me to code anything as anyone on the list who knows me can tell you that I am absolutely awful at coding. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- http://aws.amazon.com/solutions/solution-providers/brandorr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] ANNOUNCE: Puppet 2.6.9rc1 is available
I'm just writing in support of this - this is the first time I've actually
READ the changelog because it's a mess normally.
On Wed, Jun 15, 2011 at 4:11 AM, R.I.Pienaar r...@devco.net wrote:
I have a feature request for your announce mails :)
git log doesnt make a changelog, it makes a developer orientated
log of events in a git repository.
This information isnt aimed at users. A proper changelog highlighting
changes would be a really good improvement. Even just stripping out the
noise that your particular usage patterns (not doing ff merges) cause
will already help. Additionally there's a lot of commits thats just
spam - add a test, move a file etc - this only helps hiding the important
entries.
Below is a edit taking your 66 line changelog down to a usable 25 lines
by removing all the purely testing related lines, the merge lines and maint
lines.
I think this is already a huge improvement. Changelogs are what users use
to determine the suitability of a upgrade so we should write them with that
in mind.
98ba407 (#7127) Stop puppet if a prerun command fails
6996e0b Do not needlessly create multiple reports when creating a
transaction
caca469 (#4416) Ensure types are providified after reloading
413b136 (#4416) Always remove old provider before recreating it
98f58ce (#2128) Add WARNING for node_name_{fact,value} descriptions
d9b5c1a (#2128) In-line docs for node_name_{fact,value}
3f0dbb5 (#650) Allow symlinks for configuration directories
1c70f0c (#2128) Add support for setting node name based on a fact
c629958 (#2128) Get facts before retrieving catalog
cd4fe14 (#2128) Add the ability to specify a node name
8ebec1e (#7193) Fix path issues with acceptance tests that call old shell
tests
16b2311 (#6885) puppet agent fingerprint requires --verbose to return a
value.
75e2764 (#5318) Always notice changes to manifests when compiling.
8b76be3 (#3836) External nodes should only capture stdout
90eb937 (#7139) Accept '/' as a valid path in filesets
729336e (#6845) Mount writes incorrect vfstab entries
16cf1ac (#6442) Be able to start agents --listen without namespaceauth.conf
0352402 (#3420) Nagios name attribute does not output correctly
f656818 (#4487) When setting environment on a host, ensure it is a string.
c306db2 (#6487) Add some testing for OS X version support in
DirectoryService provider
0008b63 (#6487) Directoryservice provider will fail in future OS releases
9a5bf6e Fixed #7166 - Replaced deprecated stomp send method with
publish
656eff8 (#4655) Allow stage to be set using a default class parameter
7f658e6 vim: Initial ftplugin and indent support
ccbe9f3 Fixed #6681 - Remove --force-yes option from aptitude is used
- Original Message -
CHANGELOG:
2.6.9rc1
c6909a6 Merge branch '2.6.x' into 2.6rc
fc530ac Merge branch 'ticket/2.6.x/7506' into 2.6.x
db1a392 (#7506) Organize READMEs; specify supported Ruby versions in
README.md
4fb7cfe Merge branch 'ticket/2.6.x/6418' into 2.6.x
381fa40 (#6418) Make test 64118 more portable
f8c1132 Merge branch
'ticket/2.6.x/7127-prerun-command-failures-dont-stop-puppet' into
2.6.x
98ba407 (#7127) Stop puppet if a prerun command fails
6996e0b Do not needlessly create multiple reports when creating a
transaction
01c1142 Merge branch 'ticket/2.6.x/4416' into 2.6.x
caca469 (#4416) Ensure types are providified after reloading
413b136 (#4416) Always remove old provider before recreating it
d866ce1 Cleanup indentation, comment, and unused code
b1a506c Merge branch 'ticket/2.6.x/2128_docstrings' into 2.6.x
98f58ce (#2128) Add WARNING for node_name_{fact,value} descriptions
1cd848c (#2128) Whitespace only reflow commit
d9b5c1a (#2128) In-line docs for node_name_{fact,value}
e62734c Merge branch 'ticket/2.6.x/650' into 2.6.x
3f0dbb5 (#650) Allow symlinks for configuration directories
c260cf1 Fix acceptance tests not managing their masters
3d09ca8 Merge branch 'ticket/2.6.x/2128' into 2.6.x
1c70f0c (#2128) Add support for setting node name based on a fact
c629958 (#2128) Get facts before retrieving catalog
cd4fe14 (#2128) Add the ability to specify a node name
8ebec1e (#7193) Fix path issues with acceptance tests that call old
shell tests
9660f5e Merge branch
'ticket/2.6.x/6885-puppet-agent-fingerprint-requires---verbose-to-return-a-value'
into 2.6.x
16b2311 (#6885) puppet agent fingerprint requires --verbose to return
a value.
a00fd25 maint: Refactor specs in preparation for making node name
more flexible
805b287 Merge branch 'bug/2.6.x/5318-minimal-fix' into 2.6.x
75e2764 (#5318) Always notice changes to manifests when compiling.
6a00289 Merge branch 'ticket/2.6.x/7681' into 2.6.x
4a5e99d (#7681) Add an acceptance test for resource refs with array
variables
d7ce922 Merge branch 'test/2.6.x/4123' into 2.6.x
646919e (4123) Fix test for 4123/4 on old egrep in cent4
cbc123c Merge branch '2.6.next' into 2.6.x
25eab1a
[Puppet Users] Mysql user removal problems
Hi,
I'm using duritong's puppet module and I've run into a bizarre issue after
migrating to it that I cannot resolve and I thought I'd take it to the list
in the hope someone can help.
The error I get from a run is:
info: Retrieving plugin
info: Loading facts in dell
info: Loading facts in apache-ports
info: Loading facts in mysql
info: Loading facts in location
info: Loading facts in convera
info: Loading facts in dell
info: Loading facts in apache-portsinfo: Loading facts in mysql
info: Loading facts in location
info: Loading facts in convera
info: Caching catalog for hlstestidm1.law.harvard.edu
err: Could not run Puppet configuration client: Invalid parameter defaults
at
/etc/puppet/modules/development/mysql/manifests/server/account_security.pp:12
That file is:
class mysql::server::account_security {
# some installations have some default users which are not required.
# We remove them here. You can subclass this class to overwrite this
behavior.
#mysql_user{ [ root@${fqdn}, root@127.0.0.1, @${fqdn},
@localhost, @% ]:
#ensure = absent,
# require = Service['mysqld'],
#}
mysql_user { root@${fqdn}:
ensure = absent,
require = Service['mysqld'],
}
}
I think the issue is something to do with mysql_user not allowing ensure to
be used, but the error message doesn't really help. Running puppetd -tvd
didn't add any extra information to help me nail this down.
For reference the mysql_user type is:
--
# This has to be a separate type to enable collecting
Puppet::Type.newtype(:mysql_user) do
@doc = Manage a database user.
ensurable
newparam(:name) do
desc The name of the user. This uses the 'username@hostname' form.
validate do |value|
if value.split('@').first.size 16
raise ArgumentError,
MySQL usernames are limited to a maximum of 16 characters
else
super
end
end
end
newproperty(:password_hash) do
desc The password hash of the user. Use mysql_password() for creating
such a hash.
end
end
---
and the provider for mysql_user:
require 'puppet/provider/package'
Puppet::Type.type(:mysql_user).provide(:mysql,
# T'is funny business, this code is quite generic
:parent = Puppet::Provider::Package) do
desc Use mysql as database.
commands :mysql = '/usr/bin/mysql'
commands :mysqladmin = '/usr/bin/mysqladmin'
# retrieve the current set of mysql users
def self.instances
users = []
cmd = #{command(:mysql)} mysql -NBe 'select concat(user,
\@\, host), password from user'
execpipe(cmd) do |process|
process.each do |line|
users new( query_line_to_hash(line) )
end
end
return users
end
def self.query_line_to_hash(line)
fields = line.chomp.split(/\t/)
{
:name = fields[0],
:password_hash = fields[1],
:ensure = :present
}
end
def mysql_flush
mysqladmin flush-privileges
end
def query
result = {}
cmd = #{command(:mysql)} -NBe 'select concat(user, \@\,
host), password from user where concat(user, \@\, host) = \%s\' %
@resource[:name]
execpipe(cmd) do |process|
process.each do |line|
unless result.empty?
raise Puppet::Error,
Got multiple results for
user '%s' % @resource[:name]
end
result = query_line_to_hash(line)
end
end
result
end
def create
mysql mysql, -e, create user '%s' identified by
PASSWORD '%s' % [ @resource[:name].sub(@, '@'),
@resource.should(:password_hash) ]
mysql_flush
end
def destroy
mysql mysql, -e, drop user '%s' %
@resource[:name].sub(@, '@')
mysql_flush
end
def exists?
not mysql(mysql, -NBe, select '1' from user where
CONCAT(user, '@', host) = '%s' % @resource[:name]).empty?
end
def password_hash
@property_hash[:password_hash]
end
def password_hash=(string)
mysql mysql, -e, SET PASSWORD FOR '%s' = '%s' % [
@resource[:name].sub(@, '@'), string ]
mysql_flush
end
end
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
Re: [Puppet Users] Install bin file through puppet
Aren't these normally self-contained archives with a script? You would need
to write an exec{} statement that wget's the .bin, runs it with whatever
arguments are required for installing, and then cleans up the archive
afterwards. If you add in a creates = to the location of the install you
can ensure this only occurs once.
On Wed, Feb 23, 2011 at 3:05 PM, Steve some1youk...@gmail.com wrote:
puppet newbie trying to install bin file through puppet. How would I
go about it?
class java {
package {java_package:
provider = bin, --this did not work
# source = puppet:///application/jdk-6u23-linux-x64-rpm.bin,
source = http://10.31.31.1/jdk-6u23-linux-x64-rpm.bin;,
ensure = installed
}
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Problem with module
Hi,
I'm having a problem with a module that works on my production servers, but
is giving me grief when ran from scratch. When I run the client I get:
[root@hlsdevcms1 puppet]# puppetd -tv
info: Retrieving plugin
info: Loading facts in apache-ports
info: Loading facts in location
info: Loading facts in dell
info: Loading facts in convera
info: Loading facts in apache-ports
info: Loading facts in location
info: Loading facts in dell
info: Loading facts in convera
info: Caching catalog for hlsdevcms1.law.harvard.edu
err: Could not run Puppet configuration client: Could not find user rhythmyx
I have tried everything I can think of to add more and more require =
statements into the two .pp's that comprise the module but it refuses to
find the user. I have run puppetmasterd in debug mode and the client in
debug mode to no avail, neither gives me any more information on why this
would fail. I've checked in the local yaml on the client and the rhythmyx
stuff appears in there, including the comment statement in the user{}, so
it's definitely in the catalog.
The init.pp (apologises for what a mess this is, but I've been messing with
it trying to get it working):
##
## Install rhythmyx.
##
class rhythmyx {
include rhythmyx::install
if defined(Class[splunk4::client]) {
concat::fragment{splunk4-rx:
target =
/opt/splunk/etc/system/local/inputs.conf,
content =
[monitor:///opt/rhythmyx/Rhythmyx/.../*.log]\ndisabled = false\nsourcetype
= rhythmyx\nindex = rhythmyx\n_blacklist = rx_lib.*\\.log\n,
}
}
##
## Users/Groups
##
user { rhythmyx:
ensure = present,
uid = 5000,
gid = 5000,
comment = rhythmyx user,
home = /opt/rhythmyx,
shell = '/bin/bash',
managehome = true,
require = Group['rhythmyx'],
}
group { rhythmyx:
ensure = present,
gid = 5000,
}
service { RhythmyxD:
ensure = running,
hasrestart = false,
hasstatus = false,
pattern = RhythmyxServer.exe,
start = /opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon start
/opt/rhythmyx/Rhythmyx/,
stop = /opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon stop
/opt/rhythmyx/Rhythmyx sleep 45,
require = Exec[rx-permissions-rhythmyx],
}
##
## Crons
##
file {
/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationFullEdition.sh:
ensure = present,
source =
puppet:///modules/rhythmyx/hls_ScheduledPublicationFullEdition.sh,
owner = rhythmyx,
group = rhythmyx,
mode = 755,
require = [ User[rhythmyx], Group[rhythmyx] ],
}
file {
/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationIncrementalEdition.sh:
ensure = present,
source =
puppet:///modules/rhythmyx/hls_ScheduledPublicationIncrementalEdition.sh,
owner = rhythmyx,
group = rhythmyx,
mode = 755,
require = [ User[rhythmyx], Group[rhythmyx] ],
}
##
## Backups
##
tidy {
/opt/rhythmyx/Rhythmyx/AppServer/server/rx/deploy/publogs.war:
age = '90d',
matches = '*.log',
recurse = 'true',
}
tidy { /tmp/rxtemp.rhythmyx:
age = '2d',
matches = '*.tmp',
recurse = 'true',
}
cron { Rhythmyx restart:
command = /etc/init.d/RhythmyxD restart,
ensure = present,
user= root,
minute = 00,
hour= 03,
weekday = 3,
}
}
The install.pp:
##
## Install rhythmyx
##
class rhythmyx::install {
$url = extlookup(url)
$rxsqlserver = extlookup(rxsqlserver)
#package { 'compat-libgcc-296': ensure = present }
#package { 'compat-libstdc++-296': ensure = present }
#package { 'compat-glibc': ensure = present }
File { owner = rhythmyx, group = rhythmyx, mode = 755, require =
User[rhythmyx], }
file { /opt/rhythmyx/:
ensure = directory,
require = [ User[rhythmyx], Group[rhythmyx] ],
}
exec { rx-permissions-rhythmyx:
command = chown -R rhythmyx:rhythmyx /opt/rhythmyx,
cwd = /opt/,
require = [ File['/opt/rhythmyx'], User['rhythmyx'] ],
}
file { /etc/init.d/RhythmyxD:
ensure = present,
source = puppet:///modules/rhythmyx/RhythmyxD,
owner = root,
group = root,
}
##
## ALL OF
Re: [Puppet Users] Problem with module
I am running 2.6 and can do this if needed. What would the parent class be
in this example, the 'rhythmyx' class that the user{} entry is in? This is
just included from foreman so I'm not sure there really is a parent as
such. I have a user class for actual people that I could use if I had to.
Still, this seems crazy. If there is a reference to a user in resources it
should check the rest of the yaml to see if that user is being created and
create it without erroring. I might file this via the enterprise support
because I think this is a bug, but I'm interested in other opinions before I
do so.
Thanks,
On Tue, Feb 22, 2011 at 3:10 PM, Denmat tu2bg...@gmail.com wrote:
Hi
The way I've got around this is to realize the user in the parent class or
to create a 'user' class and put in a
{ class name: stage = pre}
to guarantee it is created first.
That's using stages in 2.6 though. Not sure what you're running.
Den
On 23/02/2011, at 2:42, Ashley Penney apen...@gmail.com wrote:
Hi,
I'm having a problem with a module that works on my production servers, but
is giving me grief when ran from scratch. When I run the client I get:
[root@hlsdevcms1 puppet]# puppetd -tv
info: Retrieving plugin
info: Loading facts in apache-ports
info: Loading facts in location
info: Loading facts in dell
info: Loading facts in convera
info: Loading facts in apache-ports
info: Loading facts in location
info: Loading facts in dell
info: Loading facts in convera
info: Caching catalog for http://hlsdevcms1.law.harvard.edu
hlsdevcms1.law.harvard.edu
err: Could not run Puppet configuration client: Could not find user
rhythmyx
I have tried everything I can think of to add more and more require =
statements into the two .pp's that comprise the module but it refuses to
find the user. I have run puppetmasterd in debug mode and the client in
debug mode to no avail, neither gives me any more information on why this
would fail. I've checked in the local yaml on the client and the rhythmyx
stuff appears in there, including the comment statement in the user{}, so
it's definitely in the catalog.
The init.pp (apologises for what a mess this is, but I've been messing with
it trying to get it working):
##
## Install rhythmyx.
##
class rhythmyx {
include rhythmyx::install
if defined(Class[splunk4::client]) {
concat::fragment{splunk4-rx:
target =
/opt/splunk/etc/system/local/inputs.conf,
content =
[monitor:///opt/rhythmyx/Rhythmyx/.../*.log]\ndisabled = false\nsourcetype
= rhythmyx\nindex = rhythmyx\n_blacklist = rx_lib.*\\.log\n,
}
}
##
## Users/Groups
##
user { rhythmyx:
ensure = present,
uid = 5000,
gid = 5000,
comment = rhythmyx user,
home = /opt/rhythmyx,
shell = '/bin/bash',
managehome = true,
require = Group['rhythmyx'],
}
group { rhythmyx:
ensure = present,
gid = 5000,
}
service { RhythmyxD:
ensure = running,
hasrestart = false,
hasstatus = false,
pattern = RhythmyxServer.exe,
start = /opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon start
/opt/rhythmyx/Rhythmyx/,
stop = /opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon stop
/opt/rhythmyx/Rhythmyx sleep 45,
require = Exec[rx-permissions-rhythmyx],
}
##
## Crons
##
file {
/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationFullEdition.sh:
ensure = present,
source =
puppet:///modules/rhythmyx/hls_ScheduledPublicationFullEdition.sh,
owner = rhythmyx,
group = rhythmyx,
mode = 755,
require = [ User[rhythmyx], Group[rhythmyx] ],
}
file {
/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationIncrementalEdition.sh:
ensure = present,
source =
puppet:///modules/rhythmyx/hls_ScheduledPublicationIncrementalEdition.sh,
owner = rhythmyx,
group = rhythmyx,
mode = 755,
require = [ User[rhythmyx], Group[rhythmyx] ],
}
##
## Backups
##
tidy {
/opt/rhythmyx/Rhythmyx/AppServer/server/rx/deploy/publogs.war:
age = '90d',
matches = '*.log',
recurse = 'true',
}
tidy { /tmp/rxtemp.rhythmyx:
age = '2d',
matches = '*.tmp',
recurse = 'true',
}
cron { Rhythmyx restart:
command = /etc/init.d
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
Because I like to live dangerously I upgraded to 2.6.5 and it seems like this has resolved the CPU problem completely for me. On Tue, Feb 1, 2011 at 3:17 PM, Udo Waechter udo.waech...@uni-osnabrueck.de wrote: On 01.02.2011, at 18:14, Brice Figureau wrote: On Tue, 2011-02-01 at 10:30 -0500, Ashley Penney wrote: This is the crux of the situation for me too - Puppetlabs blame it on a Ruby bug that hasn't been resolved with RHEL6 (in my situation) but this wasn't an issue until .3 for me too. I feel that fact that many of us have this problem since upgrading means it can be fixed within Puppet, rather than Ruby, because it was fine before. Do you mean puppet 2.6.2 wasn't exhibiting this problem? Yes for me. --udo. -- :: udo waechter - r...@zoide.net :: N 52º16'30.5 E 8º3'10.1 :: genuine input for your ears: http://auriculabovinari.de :: your eyes: http://ezag.zoide.net :: your brain: http://zoide.net -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
I just upgraded the master, I was too lazy to do the nodes yet. On Mon, Feb 7, 2011 at 1:56 PM, Brice Figureau brice-pup...@daysofwonder.com wrote: On 07/02/11 17:23, Ashley Penney wrote: Because I like to live dangerously I upgraded to 2.6.5 and it seems like this has resolved the CPU problem completely for me. Did you upgrade the master or the master and all the nodes? I had a discussion about this issue with Nigel during the week-end, and he said something really interesting I didn't thought about: it might be possible that the reports generated by 2.6.3 were larger than what they were in previous versions. It is then possible that the CPU time taken to unserialize and process those larger reports is the root cause of the high CPU usage. That'd be great if one of the people having the problem could disable reports to see if that's the culprit. And if this is the case, we should at least log how long it takes to process a report on the master. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
This is the crux of the situation for me too - Puppetlabs blame it on a Ruby bug that hasn't been resolved with RHEL6 (in my situation) but this wasn't an issue until .3 for me too. I feel that fact that many of us have this problem since upgrading means it can be fixed within Puppet, rather than Ruby, because it was fine before. On Tue, Feb 1, 2011 at 5:31 AM, Waechter Udo udo.waech...@uni-osnabrueck.de wrote: Hi, On 31.01.2011, at 22:50, John Warburton wrote: On 1 February 2011 08:43, Brice Figureau brice-pup...@daysofwonder.com wrote: On 31/01/11 19:11, Udo Waechter wrote: Do you use storeconfigs? Speaking of resource hogs, do you run the puppet labs dashboard on the same host? I had a similar setup (on crusty old Sun kit mind), and found a big performance hit in writing the reports by the client to the puppet master and then those reports to the dashboard. Everything calmed down once I moved the dashboard to another host Yes I do, but I always did Even if this is not a good idea, performance was acceptable until 2.6.3 Something must have changed there. --udo. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
Yes, it didn't happen with the earlier versions of 2.6. On Tue, Feb 1, 2011 at 12:14 PM, Brice Figureau brice-pup...@daysofwonder.com wrote: On Tue, 2011-02-01 at 10:30 -0500, Ashley Penney wrote: This is the crux of the situation for me too - Puppetlabs blame it on a Ruby bug that hasn't been resolved with RHEL6 (in my situation) but this wasn't an issue until .3 for me too. I feel that fact that many of us have this problem since upgrading means it can be fixed within Puppet, rather than Ruby, because it was fine before. Do you mean puppet 2.6.2 wasn't exhibiting this problem? -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Do we need a new name for --test?
If we don't want --manual you could go with --watch as that's really what I'm doing - watching puppet run. :) On Mon, Jan 24, 2011 at 1:24 PM, Stefan Schulte stefan.schu...@taunusstein.net wrote: On Mon, Jan 24, 2011 at 01:19:35PM +0100, Felix Frank wrote: On 01/24/2011 11:38 AM, Carles Amigó wrote: +1 El 24/01/2011 9:13, Daniel Pittman escribió: On Sun, Jan 23, 2011 at 23:36, Stig Sandbeck Mathisens...@fnord.no wrote: Jesse Reynoldsjessedreyno...@gmail.com writes: --manual Seconded (or, fourthed?) Also, I'll outright *refuse* to install a software that contains a --no-noop switch (just abominable, Stefan ;-) Just for the record: --no-noop is a valid switch. I have noop=true in my puppet.conf (together with onetime=true and daemonize=false) and my normal puppet invocation is »puppet agent -v«. If I want puppet to change stuff I run with »puppet agent -v --no-noop«. Yes it looks ugly but it works fine ;-) -Stefan -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppetmaster 100%cpu usage on 2.6 (not on 0.24)
As a datapoint, I experience this problem on RHEL6: ruby-1.8.7.299-4.el6.x86_64 Gems: passenger (3.0.0) rack (1.2.1) rack-mount (0.6.13) rack-test (0.5.6) rails (3.0.3) On Fri, Dec 17, 2010 at 11:27 AM, Leonid Batizhevsky the.leo...@gmail.comwrote: Ruby or puppet? I start use from 0.25.x (from epel repo and not long) and 1.8.5 ruby. Then I update to 2.6.0 and I saw memory problems. I start to google and found: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Red_Hat_Centos The 1.8.5 branch of Ruby shipped will RHEL5 can exhibit memory leaks. And upgrade to ruby enterprise 1.8.7 and It solve my problems! Leonid S. Batizhevsky On Fri, Dec 17, 2010 at 03:03, Nigel Kersten ni...@puppetlabs.com wrote: For the sake of the archives, what version did you upgrade *from* Leonid ? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
This issue is definitely a problem. I have a support ticket in with Puppet Labs about the same thing. My CPU remains at 100% almost constantly and it slows things down significantly. If you strace it you can see that very little appears to be going on. This is absolutely not normal behavior. Even when I had 1 client checking in I had all cores fully used. On Wed, Dec 15, 2010 at 12:15 PM, Brice Figureau brice-pup...@daysofwonder.com wrote: On Wed, 2010-12-15 at 05:28 -0800, Chris wrote: On Dec 15, 12:42 pm, Brice Figureau brice-pup...@daysofwonder.com wrote: On Tue, 2010-12-14 at 00:24 -0800, Chris wrote: Hi I recently upgraded my puppet masters (and clients) from 0.24.8 to 2.6.4 Previously, my most busy puppet master would hover around about 0.9 load average, after the upgrade, its load hovers around 5 I am running passenger and mysql based stored configs. Checking my running processes, ruby (puppetmasterd) shoots up to 99% cpu load and stays there for a few seconds before dropping again. Often there are 4 of these running simultaneously, pegging each core at 99% cpu. I would say it is perfectly normal. Compiling the catalog is a hard and complex problem and requires CPU. The difference between 0.24.8 and 2.6 (or 0.25 for what matters) is that some performance issues have been fixed. Those issues made the master be more I/O bound under 0.24, but now mostly CPU bound in later versions. If we were talking about only cpu usage, I would agree with you. But in this case, the load average of the machine has gone up over 5x. And as high load average indicates processes not getting enough runtime, in this case it is an indication to me that 2.6 is performing worse than 0.24 (previously, on average, all processes got enough runtime and did not have to wait for system resources, now processes are sitting in the run queue, waiting to get a chance to run) Load is not necessarily an indication of an issue. It can also mean some tasks are waiting for I/O not only CPU. The only real issue under load is if service time is beyond an admissible value, otherwise you can't say it's bad or not. If you see some hosts reporting timeouts, then it's an indication that service time is not good :) BTW, do you run your mysql storedconfig instance on the same server? You can activate thin_storeconfigs to reduce the load on the mysql db. I don't really get what is the issue about using 100% of CPU? Thats not the issue, just an indication of what is causing it You're paying about the same price when your CPU is used and when it's idle, so that shouldn't make a difference :) Generally true, but this is a on VM which is also running some of my radius and proxy instances, amongst others. If that's an issue, reduce the concurrency of your setup (run less compilation in parallel, implement splay time, etc...). splay has been enabled since 0.24 My apache maxclients is set to 15 to limit concurrency. I think this is too many except if you have 8 cores. As Trevor said in another e-mail in this thread, 2PM/Core is the best. Now it all depends on your number of nodes and sleeptime. I suggest you use ext/puppet-load to find your setup real concurrency. -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
Just to reply to this - like I said earlier I can get this problem with 1 node checking in against puppetmaster. All the puppetmasterd processes use maximum CPU. It's not a scaling issue considering serving one node is certainly not going to max out a newish physical server. On Wed, Dec 15, 2010 at 4:45 PM, Brice Figureau brice-pup...@daysofwonder.com wrote: Just some math (which might be totally wrong), to give an idea of how I think we can compute our optimal scaling case: So with 250 nodes and a sleep time of 30 minutes, we need to overcome 250 compiles in every 30 minute time spans. If we assume a concurrency of 2 and all nodes evenly spaced (in time), that means we must compile 125 nodes in 30 minutes. If each compilation takes about 10s, then that means it'll take 1250s, which means 20 minutes so you have some room for growth :) Now during those 20min your 2 master processes will consume 100% CPU. Since we're consuming the the CPU for only 66% of the 30 minute span, you'll globally consume 66% of all your CPU available... Hope that helps, [1]: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Introspection -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Initial data population
On Tue, Nov 23, 2010 at 6:41 PM, Daniel Pittman dan...@rimspace.net wrote:
Ashley Penney apen...@gmail.com writes:
As an example of the kind of thing we're talking about we use a product
called Sonatype Nexus that relies on a bunch of on disk data in
/srv/sonatype-nexus/. When installing the system for the first time (for
example, when the file{} containing the .war triggers) we would like it
to
automatically put down a copy of /srv/sonatype-nexus/. We obviously
don't
want this drifting out of sync with the production data which is where
the
issue is. How do other people handle this?
Package those data files yourself, if necessary including logic in the
package
to ensure that you don't overwrite valuable local changes. Then use puppet
to
ensure that package is either 'installed' or 'latest'.
I suppose this is possible, but awkward. An example of another application
is this horrible Java CMS that we use that writes numerous XML files of
random names all over the place during operation. There's cache
directories, it constantly rewrites various bits of configuration xml files,
it spews logs all over. Packaging something like that up in a way that is
functional is almost impossible. When we want to reinstall/clone that
server we just copy the entire directory and then run Puppet to change a few
key XML files. Something like that is difficult to package, and the files
that you would package change frequently due to patches and internal
development on top of the CMS.
Our options seem to be:
* Nightly/hourly backups of production data to some location where Puppet
can rsync/wget/shovel it out when needed.
* Some kind of process that real-time syncs directories to nfs storage.
* Erroring if the data is missing in some fashion when Puppet runs and
relying on
sysadmins to put it in place.
...or making it available as a puppet file server, and using puppet to put
it
in place.
In our experience that is almost unusable, speedwise.
We've talked through the options but they all have fairly significant
drawbacks. My personal favorite solution would be some kind of daemon
that
syncs data constantly and is capable of intelligently syncing the data
back
to the node if it goes missing. It could be potentially error prone but
it
represents the least bad choice.
You could potentially just use:
file { /example:
source = 'puppet:///module/example', replace = false
}
That will only put the file in place if it doesn't already exist.
Hmm, I always forget about replace = false. I wonder if it has the same
awful speed penalties. I think my issue with this is still the hassle of
constantly syncing the changing files back into Puppet. That's why I was
looking for some kind of semi or fully automated syncing mechanism for
something like this. It's mostly Java apps that are especially bad for
this. Most open source software sticks data into a database or at least a
single easily dealt with directory. Java explodes all over the place like
some kind of evil virus.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Initial data population
On Tue, Nov 23, 2010 at 2:30 PM, Patrick kc7...@gmail.com wrote: 1) So are the Puppet clients (Nexus servers) supposed to be modifying the data in /srv/sonatype-nexus like a database or is it used read-only like a file server? They modify data in that directory. I explained further in another email but we have several Java apps that do similar things, constantly changing/adding xml files and all kinds of logs and other stuff for running. 2) If you change the master copy of the data, can you wipe the data and recopy on each client or do you need to merge in changes? I think in most cases it would require a remerge. Generally speaking I'm only dealing with a single client using this data at a time so my concerns are more 'if the data is not there completely, automatically reprovision it with a copy as up to date as possible' rather than changing things. If there are specific file configuration files I need to change within the data then I handle that within Puppet like any other application. 3) How big is the biggest file in the data? What's the total size? Hmm, I'm not logged in to check at the moment but generally we're talking a maximum of 4G of data for one of these applications, and some closer to 1G. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Initial data population
Hi,
We've been having some internal discussions about the best way to handle
certain cases and I thought I'd turn to the list to solicit opinions on how
other people have solved this issue (or don't, as the case may be). The
issue is that we would like our modules to, where possible, check for the
existence of certain on disk data when installing a service for the first
time and retrieve it from somewhere if it's not available.
As an example of the kind of thing we're talking about we use a product
called Sonatype Nexus that relies on a bunch of on disk data in
/srv/sonatype-nexus/. When installing the system for the first time (for
example, when the file{} containing the .war triggers) we would like it to
automatically put down a copy of /srv/sonatype-nexus/. We obviously don't
want this drifting out of sync with the production data which is where the
issue is. How do other people handle this?
Our options seem to be:
* Nightly/hourly backups of production data to some location where Puppet
can rsync/wget/shovel it out when needed.
* Some kind of process that real-time syncs directories to nfs storage.
* Erroring if the data is missing in some fashion when Puppet runs and
relying on sysadmins to put it in place.
We've talked through the options but they all have fairly significant
drawbacks. My personal favorite solution would be some kind of daemon that
syncs data constantly and is capable of intelligently syncing the data back
to the node if it goes missing. It could be potentially error prone but it
represents the least bad choice. That combined with regular backups would
seem ideal but I can't find anything out there that does this without
significant work/investment. I debated just rsyncing every 15 minutes but
that's not great either.
Thanks,
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
