[Puppet Users] Styling parameter and variable types
With the future parser we can now add type annotations to a whole bunch of
things. Usually it's pretty easy, just chuck the type in front of the
variable and you're done. But what if you have multiple variables or class
parameters beneath each other, do we align them, how do we align them, and
what about more complex type definitions?
An example:
class test (
String $param1,
String $param2,
Integer $param3,
Variant[String, Integer] $param4 = 80,
Struct[{ a = Enum[hi, there, everyone], b = Optional[Variant[Enum[yo,
lo], Integer[2]]]}] $param5 = { a = 'hi', },
) {}
So do we style it like so: align based on starting token of required and
option parameters
class test (
String $param1,
String $param2,
Integer $param3,
Variant[String, Integer]
$param4 = 80,
Struct[{ a = Enum[hi, there, everyone], b = Optional[Variant[Enum[yo,
lo], Integer[2]]]}] $param5 = { a = 'hi', },
) {}
Or do we take it one step further and align everything:
class test (
String
$param1,
String
$param2,
Integer
$param3,
Variant[String, Integer]
$param4 = 80,
Struct[{ a = Enum[hi, there, everyone], b = Optional[Variant[Enum[yo,
lo], Integer[2]]]}] $param5 = { a = 'hi', },
) {}
Should we break up complex type definitions:
class test (
String $param1,
String $param2,
Integer $param3,
Variant[String, Integer] $param4 = 80,
Struct[{
a = Enum[hi, there, everyone]
b = Optional[Variant[
Enum[yo, lo],
Integer[2]]]
}] $param5 = { a = 'hi', },
) {}
I like this last one best. It limits the length of the line and by
splitting up the type definition according to the type we're defining (a
hash) it becomes fairly easy for a human to parse. But then, should the
Variant after the Optional be on a new line already or only the arguments
to Variant since that one can take multiples (like in the way you'd break
up an array over multiple lines) etc. etc. etc. I'm still not entirely
happy about all the white spacing between the type and the actual variable
name but I do like the columnar view it creates.
Eventually we'll be able to create/alias our own types which should limit
the amount of crazy before a variable or parameter definition but until
then, what do we do? And once we have the ability to create/alias our own
types, how do we style those?
We don't have to agree on a it must be done exactly this anal way but a
loose consensus about what it could look like would be useful.
--
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/d698039a-6212-4454-a491-bcfaa8a0c360%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Client self-deregistration from PuppetDB
There's no need for CGI magic through the Puppet Master, you can talk to PuppetDB directly. See the PuppetDB API documentation: https://docs.puppetlabs.com/puppetdb/latest/api/commands.html#examples-using-curl On Wednesday, 10 December 2014 13:01:34 UTC+1, Ryan Anderson wrote: You could try a hack like having the system going away call a cgi on the puppet master (via wget) that in-turn does the 'puppet node deactivate' command. -- 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/38d9be77-5007-43c2-8324-e6d73e7041ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: puppetboard unable to reach puppetb
Hi, This doesn't look like a configuration error with regard to Puppetboard but one with regard to Apache. These lines: configuration error: couldn't perform authentication. AuthType not set!: /static/js/lists.js, referer: http://puppetboard.jokefire.com/ aren't generated by Puppetboard, it has no concept of authentication and AuthType is an Apache thing. My bet is the Require all granted line. From what I can gleam from http://httpd.apache.org/docs/current/mod/mod_authz_core.html#require it would require a few more settings, AuthType, AuthName, AuthBasicProvider, AuthUserFile and AuthGroupFile. Until you have authentication set up, replace that Require line with: Order deny,allow Allow from all Let me know if this works for you, -- Daniele Sluijters -- 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/dbf87344-3b72-486d-b67d-737642a12b76%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: puppetboard unable to reach puppetb
Hi, I missed the part where this actually still works but then throws the PuppetDB connection issues. * How did you install Puppetboard, with this module: https://forge.puppetlabs.com/nibalizer/puppetboard? * Are Puppetboard and PuppetDB running on the same machine? * Can you show me your settings.py as documented here: https://github.com/nedap/puppetboard#settings -- Daniele Sluijters -- 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/09357b9c-d898-4a55-b0b8-c82254d52c9a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: puppetboard unable to reach puppetb
Hey,
I think I know what's going on here. You've, dutifully, told Puppetboard
that it needs to validate the server certificate that PuppetDB is
presenting you with (PUPPETDB_SSL_VERIFY) when you setup a connection.
However, I'm betting your OS trust-store does not include a copy of the
Puppet Master CA, the one that handed out PuppetDB's server certificate.
What you need to do is change PUPPETDB_SSL_VERIFY from True to
/var/lib/puppet/ssl/ca/ca.pem (I think that's the path). What also is
slightly weird is that you have defined PUPPETDB_KEY and PUPPETDB_CERT
twice, the latter having it set to None which I'm guessing is what
Puppetboard ends up picking.
However, since your PuppetDB and Puppetboard are hosted on the same machine
you can forgo the whole SSL debacle and use a local, plain connection
instead. Since this traffic will never leave the host people would need to
be logged in to your master to intercept it. Your settings.py then looks
like this:
PUPPETDB_HOST = 'localhost'
PUPPETDB_PORT = 8080
PUPPETDB_TIMEOUT = 60
Once that works for you don't forget to change the LOGLEVEL back to 'info'.
--
Daniele Sluijters
On Thursday, 9 October 2014 09:24:08 UTC-7, bluethundr wrote:
Hi Daniel,
Thanks for getting back to me.
This doesn't look like a configuration error with regard to Puppetboard
but one with regard to Apache. These lines: configuration error:
couldn't perform authentication. AuthType not set!: /static/js/lists.js,
referer: http://puppetboard.jokefire.com/ aren't generated by
Puppetboard, it has no concept of authentication and AuthType is an Apache
thing.
My bet is the Require all granted line. From what I can gleam from
http://httpd.apache.org/docs/current/mod/mod_authz_core.html#require it
would require a few more settings, AuthType, AuthName, AuthBasicProvider,
AuthUserFile and AuthGroupFile.
Until you have authentication set up, replace that Require line with:
Order deny,allow
Allow from all
Ok so I changed my apache config to this:
VirtualHost *:80
ServerName puppetboard.jokefire.com
WSGIDaemonProcess puppetboard user=apache group=apache threads=5
WSGIScriptAlias / /var/www/puppetboard/wsgi.py
ErrorLog /var/log/httpd/puppetboard_error_log
CustomLog /var/log/httpd/puppetboard_access_log combined
Alias /static /usr/lib/python2.6/site-packages/puppetboard/static
Directory /usr/lib/python2.6/site-packages/puppetboard/static
WSGIProcessGroup puppetboard
WSGIApplicationGroup %{GLOBAL}
*Order deny,allow*
*Allow from all*
/Directory
/VirtualHost
I also changed the directory and contents to be readable by apache:
[root@puppet:/etc/httpd/conf.d] #ls -ld
/usr/lib/python2.6/site-packages/puppetboard/static/
drwxr-xr-x. 4 apache apache 4096 Oct 8 12:47
/usr/lib/python2.6/site-packages/puppetboard/static/
I still get the error:
http://puppetboard.jokefire.com/
I missed the part where this actually still works but then throws the
PuppetDB connection issues.
* How did you install Puppetboard, with this module:
https://forge.puppetlabs.com/nibalizer/puppetboard?
I did it via python pip install. I tried using the puppet module
initially. But it threw a bunch of dependency errors on my system. So
rather than try to wrestle with those I decided to to try a pip install
which went ok.
* Are Puppetboard and PuppetDB running on the same machine?
Yes! They are.
* Can you show me your settings.py as documented here:
https://github.com/nedap/puppetboard#settings
Sure! Here you go.
[root@puppet:~] #cat /var/www/puppetboard/settings.py
PUPPETDB_HOST = 'puppet.jokefire.com'
PUPPETDB_PORT = 8081
PUPPETDB_KEY = '/etc/puppetdb/ssl/private.pem'
PUPPETDB_CERT = '/etc/puppetdb/ssl/public.pem'
PUPPETDB_SSL_VERIFY = True
PUPPETDB_KEY = None
PUPPETDB_CERT = None
PUPPETDB_TIMEOUT = 60
DEV_LISTEN_HOST = '127.0.0.1'
DEV_LISTEN_PORT = 5000
UNRESPONSIVE_HOURS = 2
ENABLE_QUERY = True
LOGLEVEL = 'debug'
I also tried the PUPPET_HOST with the IP of the machine, and with 0.0.0.0.
None of that seemed to make any difference!
Thanks again for getting back to me on this.
Tim
On Thu, Oct 9, 2014 at 12:10 PM, Daniele Sluijters daniele@gmail.com
javascript: wrote:
Hi,
I missed the part where this actually still works but then throws the
PuppetDB connection issues.
* How did you install Puppetboard, with this module:
https://forge.puppetlabs.com/nibalizer/puppetboard?
* Are Puppetboard and PuppetDB running on the same machine?
* Can you show me your settings.py as documented here:
https://github.com/nedap/puppetboard#settings
--
Daniele Sluijters
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users...@googlegroups.com javascript
Re: [Puppet Users] Re: Announce: Facter 2.2.0
Hi, I don't mind even changing that stuff in .Z releases but I think .Y is more appropriate indeed. Releasing a new major version of Facter every time a fact is bug fixed seems madness and not something you should get into. As long as the release notes are in order I think most people have come to expect at least some 'breakage' on .Y releases, regardless of wat semver says (that's not anything personal towards Puppet Labs, it happens on a lot of projects). -- Daniele Sluijters -- 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/c57d48fe-0f12-4846-84cc-c6193cfca405%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Announce: Facter 2.2.0
Hey, I agree with the spirit of the fix but the fact that it isn't mentioned anywhere in the release notes is a bit annoying. I personally also consider this a backwards incompatible release, you're changing old behaviour. Albeit for the better, but people depended on that behaviour and no prior warning or deprecation warning was issued. Do also keep in mind that though we can easily fix our own manifests with a regexp match, since the launch of the Forge people have started to use more and more modules maintained by others. Unless the maintainer has already issued an update you're stuck with manually patching an upstream module and carrying that change. Depending on how you deploy your environment this might be difficult to do. -- Daniele Sluijters -- 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/d6e7df73-cf75-478b-ae88-e2475b28b10b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: First anniversary of the module team
Sounds great! 3 and happy birthday (albeit a few days late but feel free to consume more cake). On Wednesday, 25 June 2014 18:53:25 UTC+2, Ashley Penney wrote: 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
Re: [Puppet Users] params.pp/inheritance/defaults/hiera/hiera functions?
- Don't use automatic hiera lookups. This removes the magic and makes it more clear to everyone that the data is coming from hiera. Hold on a sec; if you mean data bindings with 'automatic hiera lookups', most certainly use them. Do not ever hardcode hiera() functions in parameter lookups in your module as you module can now _only_ work with Hiera and not everyone uses or wants to use hiera. Instead let data bindings take care of it so that everyone can benefit from your code, Hiera, ENC or by explicitly passing data in. -- 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/0b5a1a39-ebe1-44dd-a10c-4fc44d340d7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet 3.6.0... and scaling?
The environment caching is already there, use the environment_timeout setting. Mine is set to unlimited and I reload at deploy time by touching tmp/restart.txt. This so far seems to work really well. On Thursday, 22 May 2014 19:26:47 UTC+2, Tristan Smith wrote: Dang. That does look an awful lot like my issue. I am in fact using directory environments (mostly because of the screaming deprecation warnings telling me I was a bad man if I didn't). :/ Shame on me for using a .0 release. On Thursday, May 22, 2014 10:17:24 AM UTC-7, Ellison Marks wrote: Hey, I think I remember another thread that mentioned that there were some performance issues with directory environments. Basically, the next 3.6 release will add a caching option that mostly alleviated the problem for the OP from that thread. https://groups.google.com/forum/#!topic/puppet-users/wzy8NPWauu4 On Thursday, May 22, 2014 9:59:25 AM UTC-7, Tristan Smith wrote: After much hacking to get directory environments settled and the manifest directory in place, I rolled Puppet 3.6 to our puppetmasters last night. One of our puppetmasters has nearabouts 1000 clients, runs passenger under apache 2.2 (ruby 1.8.7, sadly, thanks CentOS), and normally doesn't really notice puppet running - basically peaks out at 20% CPU usage. Under 3.6, even doubling the passenger worker count, it couldn't keep up with the load - I started running out of apache procs due to workers stuck in waiting mode and they were all just hanging waiting for a passenger worker to free up. CPU usage on the system capped out. Strace -c on the passenger workers had them spending 30% of their time in clone() and 60% in wait4(), fwiw. I'm going to be digging to figure out what in hell changed to cause this, but has anyone else experienced a significant change in performance under 3.6? --Triss -- 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/bf6ee783-8570-4b5c-a47a-9b135b01811c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Hiera Performance Testing
Ah, Then I'm afraid you're on your own. The instrumentation framework got added and expanded upon somewhere in the 3.x series, I believe 3.2 was the first to be able to give some useful information and as of 3.5 the API is actually public so that others can build on it. As far as Hiera goes, lookup times depend on a bunch of things. Part of it is the complexity of the hierarchy, the more places it might need to look the longer it will take. If you do a 'normal' hiera call it'll exit on the first match so depending on how quickly it can find a match it'll take a bit longer or not. Then there's the hiera_array and hiera_hash calls which search the whole hierarchy and build up an array or hash of all the returned values which will take longer than a hiera call. If you really want to get an indication I'd say just switch a few modules to hiera and compare compile times. You could also start adding Hiera.debug() calls with time information in Hiera's backend.rb. In all honesty though, I'd suggest you get to upgrading to 3.4+ first. That'll give you a bit of a performance boost and 3.4+ doesn't require Hiera, it just ships with it. It'll also enable a bunch of things that will make your life more pleasant as a module author or maintainer. If you're using opensource modules it's likely they'll shortly start dropping 2.7 support if they haven't already with the coming of Puppet 3.6 and 4.x. -- Daniele Sluijters On Monday, 14 April 2014 19:35:37 UTC+2, David Danzilio wrote: Unfortunately, and I probably should've mentioned this in the OP, we're currently stuck on the 2.7 series. On Monday, April 14, 2014 1:11:36 PM UTC-4, Daniele Sluijters wrote: Hi, I think a good start would be to turn on profiling, aka profiling=true in puppet.conf or puppet agent --profile. The output will show up in the master's logs. -- Daniele Sluijters On Friday, 11 April 2014 22:55:45 UTC+2, David Danzilio wrote: Hi Everybody. I'm trying to come up with a way to understand how Hiera is going to affect compile times on our Puppet masters. We've got just over 100K lines of Puppet code, and thousands of hosts across a few environments. I know there are a lot of variables to this problem, but I'm drawing a blank on a good way to test this. Has anybody run into this? Is there a simple way to do this that I'm just not seeing? Thanks! David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2d3bf99d-6a06-485c-8f6f-c2f7731ce445%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Hiera Performance Testing
Hi, I think a good start would be to turn on profiling, aka profiling=true in puppet.conf or puppet agent --profile. The output will show up in the master's logs. -- Daniele Sluijters On Friday, 11 April 2014 22:55:45 UTC+2, David Danzilio wrote: Hi Everybody. I'm trying to come up with a way to understand how Hiera is going to affect compile times on our Puppet masters. We've got just over 100K lines of Puppet code, and thousands of hosts across a few environments. I know there are a lot of variables to this problem, but I'm drawing a blank on a good way to test this. Has anybody run into this? Is there a simple way to do this that I'm just not seeing? Thanks! David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4a5c072e-3298-4d2c-9e77-ed8abf812cd3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Final Comments on Pro Puppet 2nd Edition
Hi, I'm going to be slightly blunt here. The authors of the book have, repeatedly, ask you to connect with them through different channels and contribute your fixes to the Github repository that was set up. Though I appreciate your review of the book, the way you've handled the situation is not exactly exemplary. I'm also wondering what you're trying to achieve here. I'm sure you realise that most people won't be reading your posts on the mailing lists before buying the book. From reading your comments most of them are not about errors with regard to Puppet but with (perceived) errors in grammar, style or formatting. Only a few are actually about code or command errors and a few about terminology that's used before it's been explained or other issues that could potentially hamper the users understanding. -- Daniele Sluijters On Thursday, 27 March 2014 05:17:40 UTC+1, Jon Forrest wrote: I just posted my list of issues I discovered in Chapters 11 and 12 - the last two chapters of Pro Puppet 2nd Edition. I found a lot of issues with this book. I simply don't understand how these issues escaped the editors. One reason I posted what I did is so that anyone thinking about buying the book will know what to expect. I just hope the technical material about Puppet was higher quality than the editing job that went into this book. Since I'm not a Puppet expert I have no way of judging, so I won't comment. I've posted the complete list of issues on https://www.dropbox.com/s/qmcdgdo4bvq620q/propuppet2.txt Jon Forrest -- 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/65be6841-340e-434e-ad6f-5e2798fae87e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Ideas to allow users only on certain servers
Use virtual users. Instead of declaring your users as 'real', add a @ in front of them. Now they are virtual so they aren't automatically created by Puppet, you need to explicitly realise them, for example based on a tag or group they're a member in. You can do it along the lines of: Users | tag == 'dev' } on a development machine and Users || if you want them all. See: http://docs.puppetlabs.com/puppet/latest/reference/lang_virtual.html http://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html http://docs.puppetlabs.com/guides/virtual_resources.html http://blog.scottlowe.org/2012/11/25/using-puppet-for-account-management/ On Thursday, 13 March 2014 22:52:39 UTC+1, Philippe Conway wrote: So at my organization, we have different departments that should only have access to certain servers. For example: Dev Team: Dev Servers Tech Support: Production Server Admins: All servers How Puppet manages our users now, is once you add the user to the user manifest, it adds them too *all *the servers. I've tried adding an if/else statement as sort of mentioned here: https://groups.google.com/forum/#!topic/puppet-users/EA1LKmaFFJ4 But I learned that wasn't best practice. I've also tried putting users in different classes such as: users::dev users::ts users::admins However that gets a little redundant...Is there another way to do this through Puppet? Or am I better off using something like Active Directory to authenticate and manage groups? Any advice is much appreciated. Thanks! - Philippe -- 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/1d17af54-978b-445f-a97e-a24530608c7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: puppetdb-stencil 0.0.1
Good news everyone,
After about 4hrs of food, beer and code Ewoud Kohl van Wijngaarden (ekohl
on Github) and I are intoxicated to release puppetdb-stencil.
Puppetdb-stencil is designed to render resource types based on a template.
The canonical example of this is the nagios types in Puppet:
$ cd examples python ../puppetdb-stencil.py nagios_host nagios_hostgroup
define host {
host_name node1.example.com
hostgroups +mysql
use mysql
alias MySQL Cluster node node1.example.com
address node1.example.com
}
[..]
define hostgroup {
hostgroup_name mysql
alias MySQL Cluster 1
}
[..]
On a PuppetDB with 600+ machines and 900+ host groups generating the files
for these types takes about 1s in total.
Because of the templating this principle can be applied to any resource
available through PuppetDB as long as a template is created for that type.
Templating is done with the Jinja2 library allowing for inheritance and
many other advanced templating features.
This work has been inspired by the work done by eBay/Marktplaats and Github.
You can find puppetdb-stencil at:
https://github.com/daenney/puppetdb-stencil.
We expect to shortly add:
* packaging and availability through PyPi
* additional configuration switches to fully configure connecting to
PuppetDB
* allow for an arbitrary query to be passed in to the resource request
* allow to specify a file to which the output will be written instead of
stdout
* tests, Travis integration and the works
--
Daniele Sluijters
--
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/bcfd1735-42f5-40ca-8d33-959ebcd8e1cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: introducing puppetboard 0.0.1
Niels: Thank you for the Arch packages, I'll add them to the README's. Jose: I'm not sure what you're getting at, what do you understand as outofsync? Nodes that haven't checked in in a while show up, if that timeframe is too big for you can modify the settings. -- Daniele Sluijters -- 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/1b7c31c2-f073-4390-9d74-addfd8e863ed%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppetboard and ssl
Hey, It should work, Puppetboard is supposed to just pass in the settings to pypuppetdb so unless we really screwed up somewhere that shouldn't be the issue. Can you show me your settings.py file? -- Daniele Sluijters On Saturday, 8 February 2014 23:35:43 UTC+1, Johan De Wit wrote: Hi, Has anyone configured puppetboard to use SSL to connect to the puppetdb server ? puppetboard runs on a dedicated server, puppetdb on my puppetmaster. Using plain http, on 8080, everything works. When i configure puppetboard for https, I get always ERROR:pypuppetdb.api:Could not reach PuppetDB on puppet.koewacht.net:8081 over HTTPS. doing the same with pypuppetdb, in a python shell, it works, as teh apache user, to rule out permission problems. from pypuppetdb import connect db = connect(host='puppet.koewacht.net', port=8081, ssl_key='/etc/puppetboard/pb_priv.pem', ssl_cert='/etc/puppetboard/pb_pub.pem') nodes = db.nodes() for node in nodes: ... print(node) ... fc19.koewacht.net laptopfc18.koewacht.net puppetboard puppet.koewacht.net Just looking to see if it is some setting I oversee, or I have to delve in the code .. Grts Johan -- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP006) _ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile+32 (0)474/42 40 73 BELGIUM http://www.open-future.be _ Next Events: Puppet Fundamentals Training | http://www.open-future.be/puppet-fundamentals-training-4-till-6th-february Puppet Intruction Course | http://www.open-future.be/puppet-introduction-course-7th-february Zabbix Certified Training | http://www.open-future.be/zabbix-certified-training-10-till-12th-february Zabbix for Large Environments Training | http://www.open-future.be/zabbix-large-environments-training-13-till-14th-february Subscribe to our newsletter | http://eepurl.com/BUG8H -- 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/25d1898e-1f95-4645-95cc-5c503e9c6236%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: puppetboard and ssl
Hey Johan,
SSL_VERIFY trips up a few people, I need better docs on that.
When you connect to PuppetDB as a client you need to present two things, a
private key and a public key signed by the Certificate Authority that also
signed the server certificate of PuppetDB. This in all likeliness is your
Puppet CA and it looks like you're passing on those certs correctly.
However, since we're connecting over SSL to PuppetDB, PuppetDB itself also
presents us with a server certificate, again signed by the Puppet CA. This
is what SSL_VERIFY governs, wether we want to verify that the certificate
PuppetDB presents us with is signed by a CA we trust.
When SSL_VERIFY is set to True pypuppetdb/Puppetboard will try to use your
OS truststore, /etc/ssl/ca-certificates usually, to verify that PuppetDB's
server certificate is signed by a CA we know. Since in all likelihood you
haven't added your Puppet CA to this truststore verification will fail and
this is why you get the error.
You have two choices now, set SSL_VERIFY to False and trust that you're
always talking to your actual PuppetDB or copy from the Puppet CA
$vardir/ssl/ca_crt.pem to /etc/puppetboard and set SSL_VERIFY to the path
of ca_crt.pem. In that case the file SSL_VERIFY points to will be used to
verify PuppetDB's server certificate instead of the OS truststore.
I hope this fixes the issue for you.
--
Daniele Sluijters
On Monday, 10 February 2014 20:16:51 UTC+1, Johan De Wit wrote:
Daniele,
It was not the typo. But it seems the ssl_verify=True did the bad thing.
db = connect(host='puppet.koewacht.net
',port='8081',ssl_key='/etc/puppetboard/pb_priv.pem',ssl_cert='/etc/puppetboard/pb_pub.pem',api_version=3,ssl_verify=True,timeout=20)
nodes = db.nodes()
for node in nodes:
... print(node)
...
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.6/site-packages/pypuppetdb/api/v3.py, line 55,
in nodes
nodes = self._query('nodes', path=name, query=query)
File /usr/lib/python2.6/site-packages/pypuppetdb/api/__init__.py, line
266, in _query
timeout=self.timeout)
File /usr/lib/python2.6/site-packages/requests/api.py, line 55, in get
return request('get', url, **kwargs)
File /usr/lib/python2.6/site-packages/requests/api.py, line 44, in
request
return session.request(method=method, url=url, **kwargs)
File /usr/lib/python2.6/site-packages/requests/sessions.py, line 383,
in request
resp = self.send(prep, **send_kwargs)
File /usr/lib/python2.6/site-packages/requests/sessions.py, line 486,
in send
r = adapter.send(request, **kwargs)
File /usr/lib/python2.6/site-packages/requests/adapters.py, line 385,
in send
raise SSLError(e)
requests.exceptions.SSLError: [Errno 1] _ssl.c:492: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
db = connect(host='puppet.koewacht.net
',port='8081',ssl_key='/etc/puppetboard/pb_priv.pem',ssl_cert='/etc/puppetboard/pb_pub.pem',api_version=3,ssl_verify=False,timeout=20)
nodes = db.nodes()
for node in nodes:
... print(node)
...
fc19.koewacht.net
laptopfc18.koewacht.net
puppetboard
puppet.koewacht.net
the working config :
PUPPETDB_HOST = 'puppet.koewacht.net'
PUPPETDB_PORT = 8081
PUPPETDB_SSL_VERIFY = False
PUPPETDB_KEY = '/etc/puppetboard/pb_priv.pem'
PUPPETDB_CERT ='/etc/puppetboard/pb_pub.pem'
PUPPETDB_TIMEOUT = 20
DEV_LISTEN_HOST = '127.0.0.1'
DEV_LISTEN_PORT = 5000
UNRESPONSIVE_HOURS = 2
ENABLE_QUERY = True
LOGLEVEL = 'debug'
Grts
Johan
On 02/10/2014 04:01 PM, Johan De Wit wrote:
Daniele,
I should create an alias pupept=puppet :)
I will test this further this evening, but seems logic the typo did it
(well broke it)
On 02/10/2014 03:48 PM, Johan De Wit wrote:
Hoi Daniele,
/var/www/puppetboard/settings.py
PUPPETDB_HOST = 'puppet.koewacht.net'
PUPPETDB_PORT = 8080
#PUPPETDB_SSL_VERIFY = True
#PUPPETDB_KEY = '/etc/puppetboard/pb_priv.pem'
#PUPPETDB_CERT ='/etc/pupeptboard/pb_pub.pem'
PUPPETDB_TIMEOUT = 20
DEV_LISTEN_HOST = '127.0.0.1'
DEV_LISTEN_PORT = 5000
UNRESPONSIVE_HOURS = 2
ENABLE_QUERY = True
LOGLEVEL = 'info'
ls -l /etc/puppetboard/ssl
[root@centos65 puppetboard]# ls -l /etc/puppetboard/
total 8
-rw-r- 1 apache apache 3247 Feb 8 12:30 pb_priv.pem
-rw-r- 1 apache apache 1895 Feb 8 12:31 pb_pub.pem
I assume the pythin code is executed as apache, as given in the vhost
definition :
VirtualHost *:80
ServerName puppetboard.koewacht.net
WSGIDaemonProcess puppetboard user=apache group=apache threads=5
WSGIScriptAlias / /var/www/puppetboard/wsgi.py
ErrorLog /var/log/httpd/puppetboard.error.log
CustomLog /var/log/httpd/puppetboard.access.log combined
Alias /static /usr/lib/python2.6/site-packages/puppetboard/static
Directory /usr/lib/python2.6/site-packages/puppetboard
WSGIProcessGroup puppetboard
WSGIApplicationGroup
[Puppet Users] Re: Include class if package exists
Hi,
What you're actually running into is that you want the nagios::commandes
class to be executed after the nagios package has been installed.
In that case, use the before metaparameter:
package { 'nagios':
ensure = present,
before = Class['nagios::commandes'],
}
This should fix your ordering and ensure everything works as you expect.
Generally when you run into an issue with Puppet where you want to
conditionally order something al you need are the
require/before/notify/subscribe parameters.
On Monday, 10 February 2014 23:20:06 UTC+1, Pascal Robert wrote:
Hi,
I'm using Puppet for the first time, and for my tests, I'm recreating our
Nagios setup into a Puppet modules. It works at 95%, but I do have a
problem: my module include files but I also need to modify a couple of
Nagios configuration files that comes with the Nagios RPM package. Example:
commandes.pp:
class nagios::commandes {
nagios_command { 'process-service-perfdata':
command_name = 'process-service-perfdata',
ensure = present,
command_line = '/usr/bin/perl /usr/libexec/pnp4nagios/process_perfdata.pl
',
target = '/etc/nagios/objects/commands.cfg',
}
}
init.pp:
class nagios {
include nagios::commandes
package { 'nagios':
ensure = present,
}
package { 'nagios-plugins-all':
ensure = present,
}
package { 'nrpe':
ensure = present,
}
service { 'nagios':
ensure = running,
hasstatus = true,
hasrestart = true,
enable = true,
require = Package[nagios],
}
}
It works fine when Nagios is already installed, but if not, the include of
the class in init.pp is done before the package is installed so it fails.
Error: Puppet::Util::FileType::FileTypeFlat could not write
/etc/nagios/objects/commands.cfg: No such file or directory -
/etc/nagios/objects/commands.cfg
Error:
/Stage[main]/Nagios::Commandes/Nagios_command[process-service-perfdata]:
Could not evaluate: Puppet::Util::FileType::FileTypeFlat could not write
/etc/nagios/objects/commands.cfg: No such file or directory -
/etc/nagios/objects/commands.cfg
If there a way to include the class only if the package is installed?
--
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/5fc5790b-7814-4666-8451-d86693ee6c18%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Using facts that don't exist yet...
Facts get sent at the start to the Puppet master so bringing an interface
online during a Puppet run won't make it available as a Fact during that
run, only on the next run as then the Facts are collected again. Your best
bet is to make it conditional, check for the existence of the Fact and only
if it is set do something.
On Friday, 31 January 2014 09:57:02 UTC+1, Krist van Besien wrote:
Hello,
I run puppet with foreman, and want to do the following:
- Initalize a network interface
- Start a service, bound to that interface.
eg:
#Start an interface for vlan 301 on interface em1
network::if::dynamic { 'em1.301':
ensure = up,
}
#Start an openstack L2 agent
class { 'neutron::agents::ovs':
local_ip = $::ipaddress_em1_301,
enable_tunneling = true,
after = Network::If::Dynamic['em1.301']
}
My problem is that the ::ipaddress_em1_301 fact doesn't exist yet the
moment the catalog gets retreived. So it throws an error. Is there a way
around this?
Krist
--
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/752a43c4-dfd8-476d-8dd0-bd49f03df220%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Choo choo here comes the FOSDEM train
Hi everyone, I've booked at Sogno d’Italia for approx. 30 people. They are expecting us somewhere between 19h00 and 19h20 (that's 7PM for the Americans). I've changed the Eventbrite event to allow tickets up to 35 which means there's about 15 places left if you want to join in. So, if you want food, please register :). See you soon! -- Daniele Sluijters On Thursday, 23 January 2014 11:27:36 UTC+1, Johan De Wit wrote: On 01/23/2014 11:18 AM, Daniele Sluijters wrote: Hi everyone, This is starting to shape up nicely. We've got a group of about twenty people registered now, I'm guessing a few more will join us so I'm thinking we'll end up with about 30 people, which is good. As you all know, the FOSDEM beer party is taking place the night before in Delirium. If you haven't been to Delirium, even if you don't like beer, just go and have a look around. The sheer amount of beer available is mind-blowing. If you're wondering about the local cuisine, the Huffington Post is here to help you: http://www.huffingtonpost.com/2014/01/21/belgian-cuisine-food_n_4617498.html Johan: Do we have an idea yet where we can crash with 20-30 people? Not really, maybe we should send out some scouts, and do a reservation in the neighbourhood ? Previous year, seems the puppeteers took over an italian restaurant :) Sogno D'italia. -- Daniele Sluijters -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3cda1ead-993b-4b9d-9f50-75198552c88e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP006) _ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile+32 (0)474/42 40 73 BELGIUM http://www.open-future.be _ Next Events: Puppet Fundamentals Training | http://www.open-future.be/puppet-fundamentals-training-4-till-6th-february Puppet Intruction Course | http://www.open-future.be/puppet-introduction-course-7th-february Zabbix Certified Training | http://www.open-future.be/zabbix-certified-training-10-till-12th-february Zabbix for Large Environments Training | http://www.open-future.be/zabbix-large-environments-training-13-till-14th-february Subscribe to our newsletter | http://eepurl.com/BUG8H -- 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/8708e021-0490-4632-80f5-76c5db969d49%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Choo choo here comes the FOSDEM train
Hi everyone, This is starting to shape up nicely. We've got a group of about twenty people registered now, I'm guessing a few more will join us so I'm thinking we'll end up with about 30 people, which is good. As you all know, the FOSDEM beer party is taking place the night before in Delirium. If you haven't been to Delirium, even if you don't like beer, just go and have a look around. The sheer amount of beer available is mind-blowing. If you're wondering about the local cuisine, the Huffington Post is here to help you: http://www.huffingtonpost.com/2014/01/21/belgian-cuisine-food_n_4617498.html Johan: Do we have an idea yet where we can crash with 20-30 people? -- Daniele Sluijters -- 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/3cda1ead-993b-4b9d-9f50-75198552c88e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] People transferring from Brussels to Ghent?
Hi everyone, Seems to be shaping up nicely, we've got 10 people registered for now. Would be nice if the group grows a bit more but it's a good start. Johan: Could you ask around a bit about a venue we could crash for food and drinks? It would be nice if it weren't too far from the Solbosch campus. -- Daniele Sluijters On Tuesday, 14 January 2014 17:02:45 UTC+1, Felix.Frank wrote: On 01/14/2014 04:22 PM, Erik Dalén wrote: I'll be there (and at puppet camp amsterdam before and cfgmgmt.eu http://cfgmgmt.eu the days after). Github: https://github.com/dalen/ probably won't be wearing the glasses I have on the picture there :) I won't be at FOSDEM, but will be landing in Brussels Sunday afternoon and board a train to Ghent near the airport some time around 7 p.m. local time. If that coincides with anyone's plans, that would be awesome. Regards, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/934e7b4e-253d-4056-8ea2-ebec84511da5%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppetboard 0.0.3 / pypuppetdb 0.1.0
Hi everyone, It's taken longer than I would have liked but, it's that time of the season again. ## Releases pypuppetdb 0.1.0 is now available on PyPi[1] and updated docs have been posted to Read The Docs[2]. [1]: https://pypi.python.org/pypi/pypuppetdb [2]: http://pypuppetdb.readthedocs.org/en/v0.1.0/ The README and CHANGELOG should provide adequate information on what's changed. It's nothing terribly major except for the SSL settings and behaviour which has been slightly changed and almost complete support for v3. All the endpoints are supported, just not all the features. Of far greater note is the release of Puppetboard 0.0.3. There have been plenty of changes over the past few months. Since a lot of people have been running from source and pulling in changes regularly the changes won't be that obvious but if you were running from a 'release' you're in for a party. I suggest you have a look around the screenshots at available at the Github repository[3]. Up to now it's been a slight pain to install Puppetboard and get it running. As per 0.0.3 Puppetboard is now packaged and available on PyPi, a simple `pip install puppetboard` is all it takes. The README has received extensive updates with regard to how you configure Puppetboard and your webserver. Because for some unknown reason PyPI has decided to not render my README as HTML but in stead serve up the raw ReStructuredText you're better off using the Github[3] repository to browse the README. [3]: https://github.com/nedap/puppetboard ## Future plans I promised native packages for both pypuppetdb and Puppetboard a while ago. Packages for pypuppetdb will hopefully be released in time for FOSDEM for Debian/Ubuntu and likely CentOS. Packages for Puppetboard take a bit more doing as most distributions don't ship the dependencies we require. As noted in pypuppetdb's README, 0.2.x series will drop support for API v3, so PuppetDB prior to 1.5. This is also partially due to internal surgery that needs to happen to nicely support query pagination and a few other long-standing feature requests. Enjoy and as usual you can contact me or join #puppetboard for any help. -- Daniele Sluijters -- 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/a53fc694-c51f-450e-813c-34e5e3f732ea%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Choo choo here comes the FOSDEM train
Hi everyone, It's not exactly a secret that FOSDEM will be taking place during the first weekend of February at the usual location, the ULB Solbosch campus in Brussels. It's also not that big of a secret that a lot of Puppeteers attend especially now that we have a Configuration Management room. However, it usually is a secret who will be there and that more difficult to get in touch with each other because everyone's running about going to interesting talks. Plus, not everyone knows everyone. So I'd like to propose two things: * If you're going to FOSDEM, reply to this e-mail, drop a line with your name, nickname and if you're comfortable with it, a picture so that people might recognise you; * Join the meetup, which will likely involve food and drinks at your own expense. If you're up for it, feel free to register here (or not, doesn't matter but it's nice for in your calendar): https://www.eventbrite.com/e/puppet-community-fosdem-meetup-tickets-5242929744 Now I just have to hope a few people will show up :). -- Daniele Sluijters -- 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/7ee5ab97-3e44-4ed6-b560-2dc09635ea9a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Choo choo here comes the FOSDEM train
Hi, Sounds good. It depends a bit on how big the group gets. If we're a small amount of people it's easier to just figure out something ad-hoc but if the group grows we'll need to think of a venue beforehand at which point having a few local volunteers help out and suggest places would be extremely helpful. Just to avoid any confusion, this is no way an official Puppet Labs events nor am I affiliated with Puppet Labs. This is just a call to socialise from one community member to the rest. -- Daniele Sluijters On Friday, 10 January 2014 22:28:12 UTC+1, Johan De Wit wrote: Hi all, The Belgian Puppet User Group will represent all Puppet User Groups @ the puppet stand @ FOSDEM We hope to see you all passing by the stand and have a nice chat. If we, as the belgian puppet user group can help out with this, feel free to contact me, so i can assign some volunteers :) Grts Johan On 01/10/2014 10:13 PM, Daniele Sluijters wrote: Hi everyone, It's not exactly a secret that FOSDEM will be taking place during the first weekend of February at the usual location, the ULB Solbosch campus in Brussels. It's also not that big of a secret that a lot of Puppeteers attend especially now that we have a Configuration Management room. However, it usually is a secret who will be there and that more difficult to get in touch with each other because everyone's running about going to interesting talks. Plus, not everyone knows everyone. So I'd like to propose two things: * If you're going to FOSDEM, reply to this e-mail, drop a line with your name, nickname and if you're comfortable with it, a picture so that people might recognise you; * Join the meetup, which will likely involve food and drinks at your own expense. If you're up for it, feel free to register here (or not, doesn't matter but it's nice for in your calendar): https://www.eventbrite.com/e/puppet-community-fosdem-meetup-tickets-5242929744 Now I just have to hope a few people will show up :). -- Daniele Sluijters -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7ee5ab97-3e44-4ed6-b560-2dc09635ea9a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP006) _ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile+32 (0)474/42 40 73 BELGIUM http://www.open-future.be _ Next Events: Puppet Fundamentals Training | http://www.open-future.be/puppet-fundamentals-training-4-till-6th-february Puppet Intruction Course | http://www.open-future.be/puppet-introduction-course-7th-february Zabbix Certified Training | http://www.open-future.be/zabbix-certified-training-10-till-12th-february Zabbix for Large Environments Training | http://www.open-future.be/zabbix-large-environments-training-13-till-14th-february Subscribe to our newsletter | http://eepurl.com/BUG8H -- 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/21279e48-e6e2-47aa-a71f-ce3b4c15efe9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs/firewall and fail2ban
Hi, Ah indeed, I misread the puppetlabs-denyhosts module. I had a look at the DenyHosts project but that seems limited to SSH alone. My fail2ban has rules that scan logs of our web servers, mail etc. -- Daniele Sluijters On Wednesday, 30 October 2013 01:39:56 UTC+1, Don Hoffman wrote: On reading your message, I think you are perhaps confusing the static Linux /etc/host.deny mechanism with the DenyHosts project. See http://denyhosts.sourceforg.net Don On Oct 29, 2013, at 5:32 PM, Donald Hoffman don.h...@gmail.comjavascript: wrote: On Oct 29, 2013, at 12:00 PM, Daniele Sluijters daniele@gmail.comjavascript: wrote: Hi, DenyHosts is not an option for me since I can't predict which hosts will be connecting from the outside. Fail2ban solves that issue by looking for odd behaviour instead of asking me to whitelist. Thanks for the suggestion though, -- Daniele Sluijters Hmm. Don’t quite follow. DenyHost works pretty much the same as fail2ban on the detection side. I.e. “looking for odd behavior. See this entry from their FAQ: http://denyhosts.sourceforge.net/faq.html#1_5 The DenyHost daemon monitors /var/log/secure for various signs of unsuccessful attempts to connect (from anywhere). Once a threshold is reached a rule for that IP address is inserted in to /etc/host.deny. Pretty much has the same detection features as Fail2ban. It is only on the filtering side where DenyHosts and Fail2ban really differ. Fail2ban sets up iptables firewall rules while DenyHosts adds entries to hosts.deny for filtering in the app (usually sshd) server daemon. Don -- 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/d03394af-4bf0-4bc0-b250-d3d125a22ab5%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Warning: Local environment: 42A doesn't match server specified node environment production, switching agent to production
Hi, Have you tried --environment=42A? -- Daniele Sluijters On Wednesday, 30 October 2013 09:47:13 UTC+1, AVE1810 wrote: Hi, When I run puppet agent --test --environment 42A, I have the following warning : Warning: Local environment: 42A doesn't match server specified node environment production, switching agent to production. ... The puppet manifest for the environment 42A isn't applied. The puppet version is 3.3.1-1puppetlabs1 on agent and puppetmaster node puppet.conf on the agent node : *[main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates pluginsync = true [agent] server = puppet report = true* --- puppet.conf on the puppetmaster node : *[main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates pluginsync = true [production] modulepath = /etc/puppet/environments/modules/production manifest = /etc/puppet/environments/manifests/production/site.pp [42A] modulepath = /etc/puppet/environments/modules/install/42A manifest = /etc/puppet/environments/manifests/install/site.pp [agent] server = puppet report = true [master] ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY storeconfigs = true storeconfigs_backend = puppetdb reports=log,puppetdb,foreman external_nodes = /etc/puppet/node.rb node_terminus = exec* --- If i comment the last two lines (external_nodes and node_terminus) on the puppetmaster puppet.conf node, The puppet manifest is applied correctly. Anybody has an idea ? 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/879d4d5b-2aa2-4823-9208-ef85476fedee%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] puppetlabs/firewall and fail2ban
Hello, A while back I wanted to switch our home-brewed iptables module to the puppetlabs/firewall module but I couldn't figure out how to tell puppetlabs/firewall to leave the fail2ban chains alone. I was curious if someone had solved the issue and had some examples I can work from? -- Daniele Sluijters -- 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/28d07962-a86c-46ad-9ddb-02e7ae41c348%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs/firewall and fail2ban
Hi, DenyHosts is not an option for me since I can't predict which hosts will be connecting from the outside. Fail2ban solves that issue by looking for odd behaviour instead of asking me to whitelist. Thanks for the suggestion though, -- Daniele Sluijters On Tuesday, 29 October 2013 18:22:04 UTC+1, Don Hoffman wrote: On Oct 29, 2013, at 8:41 AM, Daniele Sluijters daniele@gmail.comjavascript: wrote: Hello, A while back I wanted to switch our home-brewed iptables module to the puppetlabs/firewall module but I couldn't figure out how to tell puppetlabs/firewall to leave the fail2ban chains alone. I was curious if someone had solved the issue and had some examples I can work from? -- Daniele Sluijters -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/28d07962-a86c-46ad-9ddb-02e7ae41c348%40googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. I ran in to this issue also. Never found a scaleable/supportable solution, so switched to DenyHosts instead just to get the deployment going. I used the puppetlabs-denyhosts module.Depending on your application an app-level filter vs a firewall-level filter may be adequate. The latter is possibly more scalable if you are getting massive attacks on your SSH port for example. But if they get so massive that DenyHosts is a significant resource drain you may need to switch to an upstream DDoS-blocking solution anyway, so I decided the app-level filter was sufficient. Don -- 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/28d67b56-fe05-4315-a307-b4a1cf53fa7c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Role-based puppet
Hi,
What you'll need is some way to classify nodes, I do this through Hiera.
Per node I have a yaml file named after the host: hostname.yaml with the
following:
---
roles:
- '::role::somerole'
In manifests/site.pp I only define one node, the default:
node default {
hiera_include('roles', [])
}
Now when hostname checks in it will hit node default and a hiera lookup
will be done for an array named 'roles', which I just defined in the yaml
file. If it's found those roles, which are actually a puppet module, are
included on the host/in the catalog and get applied. If not we return an
empty array so nothing happens, you can also chose not to provide a default
in which case it will error.
As for how to organise roles and profile in Puppet, Craig Dunn has a very
nice post that should get you started:
http://www.craigdunn.org/2012/05/239/
--
Daniele Sluijters
On Friday, 25 October 2013 19:08:39 UTC+2, Steven Jonthen wrote:
Hi guys,
I want realise a role-based puppet-configuration. What I mean is this:
There should be a simple external text-file, which contains hostname/node
-- role association.
Then there should be a class-definition for each role. In this way, I want
to associate a server with different roles.
In this way, Puppet should look for the hostname of the Puppet-Agent in
the external file and see what roles it should have and then
execute the role-classes.
I hope I could explain my problem. The problem is, that I've no idea how
to realise it.
Please help
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Why there is a need for the architecture fact when it is only using hardwaremodel fact?
Hi, It doesn't only use hardwaremodel fact: https://github.com/puppetlabs/facter/blob/master/lib/facter/architecture.rb#L6:L10 # Resolution: # On non-AIX IBM, OpenBSD, Linux and Debian's kfreebsd, use the hardwaremodel fact. # On AIX get the arch value from lsattr -El proc0 -a type # Gentoo and Debian call x86_86 amd64. # Gentoo also calls i386 x86. -- Daniele Sluijters On Thursday, 24 October 2013 16:49:57 UTC+2, beyonddc...@gmail.com wrote: Hi all, hopefully this is a quick question. I would like to know why there is a need for the architecture fact when it is only using hardwaremodel fact? 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] multi-master with single CA, certificate woes
Hey,
I've been battling this all day so I hop some people over here have some
good ideas. I'm trying to set up a multi-master puppet environment with a
single CA.
This is what I've done so far:
* node 1, the CA:
* install puppetmaster
* stop it
* wipe `vardir/ssl`
* configure certname and dns_alt_names
* start it up
* node 2, an actual master that will handle requests but no CA:
* install puppetmaster
* stop it
* wipe `vardir/ssl`
* configure certname, dns_alt_names and ca_server to point to node1, set
ca=false in the [master] block and point server to itself
* do a puppet agent -t
* sign the CSR on node1
* get acknowledgement that node2 grabbed its cert from node1
Now I want to actually make the Puppet master on node2 usable. My Puppet
masters run in Passenger Standalone with an nginx in front of them proxying
the requests on port 8140 to them.
The complete SSL configuration in nginx now looks like this:
ssl on;
ssl_certificatessl/puppetmaster/node2.pem; # this is
`vardir/ssl/certs/node2.pem`
ssl_certificate_key ssl/puppetmaster/node2.key; # this is
`vardir/ssl/private_keys/node2.pem`
ssl_client_certificate ssl/puppetmaster/ca.pem; # this is
`vardir/ssl/certs/ca.pem`
ssl_crlssl/puppetmaster/crl.pem; # this was
copied from the master at `vardir/ssl/crl.pem`
ssl_verify_clienton;#
since we do only master, no CA we can require a client certificate
location / {
[..] bunch of other proxy_set_header directives [..]
proxy_set_headerX-Client-Verify $ssl_client_verify;
proxy_set_headerX-Client-DN $ssl_client_s_dn;
proxy_set_headerX-SSL-Subject $ssl_client_s_dn;
proxy_set_headerX-SSL-Issuer$ssl_client_i_dn;
}
I started the Puppet master and reloaded the nginx for the configuration to
take effect.
First I tried to connect with openssl s_client:
root@node2 # openssl s_client -connect localhost:8140 -cert
/var/lib/puppet/ssl/certs/node2.pem -key
/var/lib/puppet/ssl/private_keys/node2.pem
CONNECTED(0003)
depth=1 CN = Puppet CA: node1
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/CN=node2
i:/CN=Puppet CA: node1
1 s:/CN=Puppet CA: node1
i:/CN=Puppet CA: node1
---
[..]
subject=/CN=node2
issuer=/CN=Puppet CA: node1
---
Acceptable client certificate CA names
/CN=Puppet CA: node1
---
SSL handshake has read 5314 bytes and written 2445 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
[..]
Start Time: 1382622609
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
GET /production/node/node2
Forbidden request: node2l(10.120.12.73) access to /node/node2 [find] at
:115closed
This looks fine, It complains about the self-signed certificate in the
chain but other than that verify return = 0 which as far as I'm aware means
success. Once the handshake is complete I can actually do a GET for that
node but that seems to fail because of something in auth.conf, which is
slightly odd since the authentication succeeded so the ACL shouldn't trip
over it but that's step two (I'm probably forgetting to proxy/set a header).
Now, running `puppet agent -t` however gives me this:
Warning: Unable to fetch my node definition, but the agent run will
continue:
Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate
B: certificate verify failed: [certificate signature failure for /CN=node1]
At this point I'm lost. Ntpd's are running, nodes are within far less than
a second in sync of each other. Certificate is valid from yesterday to
yesterday in 2018 so I doubt that's an issue either. If it were the
`openssl s_client -connect` should have failed too but it's obviously
perfectly happy with it.
What am I missing here? I fear it's staring me in the face but I'm just not
seeing it.
--
Daniele Sluijters
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: multi-master with single CA, certificate woes
Hello,
With a lot of help from Hunter Haugen (Puppetlabs) we managed to figure out
what was wrong and fix it.
The errors always pointed in the direction of SSL issues but I never
managed to figure out why. Turns out this had something to do with the way
I was starting the master to create the CA.
The first issue we found was that ca.pem on node2 wasn't actually matching
ca_crt.pem on node1 which clued us in that something really was wrong
with the way the CA was behaving.
My initial approach of bootstrapping the CA server turned out to be the
issue. I just cleaned the ssl dir, did a `puppet agent -t` followed by a
`puppet cert list`
which would automatically say something about signing the CA and considered
it done. Turns out that's the wrong way to do it. What eventually worked
was wiping vardir/ssl (again) and then starting a Puppet master in the
foreground: `puppet master --no-daemonize -v`. It then actually correctly
bootstrapped
the CA. After that everything started to work. Running `puppet agent -t
--server=node1` (itself) passed and after having requests a cert for node2
and
signed it that too started to work.
I'll shortly document and publish the complete configuration and send a
pull request towards Puppetlabs to clarify a few things in the docs about
how to
achieve all this.
--
Daniele Sluijters
On Thursday, 24 October 2013 15:59:13 UTC+2, Daniele Sluijters wrote:
Hey,
I've been battling this all day so I hop some people over here have some
good ideas. I'm trying to set up a multi-master puppet environment with a
single CA.
This is what I've done so far:
* node 1, the CA:
* install puppetmaster
* stop it
* wipe `vardir/ssl`
* configure certname and dns_alt_names
* start it up
* node 2, an actual master that will handle requests but no CA:
* install puppetmaster
* stop it
* wipe `vardir/ssl`
* configure certname, dns_alt_names and ca_server to point to node1, set
ca=false in the [master] block and point server to itself
* do a puppet agent -t
* sign the CSR on node1
* get acknowledgement that node2 grabbed its cert from node1
Now I want to actually make the Puppet master on node2 usable. My Puppet
masters run in Passenger Standalone with an nginx in front of them proxying
the requests on port 8140 to them.
The complete SSL configuration in nginx now looks like this:
ssl on;
ssl_certificatessl/puppetmaster/node2.pem; # this is
`vardir/ssl/certs/node2.pem`
ssl_certificate_key ssl/puppetmaster/node2.key; # this is
`vardir/ssl/private_keys/node2.pem`
ssl_client_certificate ssl/puppetmaster/ca.pem; # this is
`vardir/ssl/certs/ca.pem`
ssl_crlssl/puppetmaster/crl.pem; # this was
copied from the master at `vardir/ssl/crl.pem`
ssl_verify_clienton;#
since we do only master, no CA we can require a client certificate
location / {
[..] bunch of other proxy_set_header directives [..]
proxy_set_headerX-Client-Verify $ssl_client_verify;
proxy_set_headerX-Client-DN $ssl_client_s_dn;
proxy_set_headerX-SSL-Subject $ssl_client_s_dn;
proxy_set_headerX-SSL-Issuer$ssl_client_i_dn;
}
I started the Puppet master and reloaded the nginx for the configuration
to take effect.
First I tried to connect with openssl s_client:
root@node2 # openssl s_client -connect localhost:8140 -cert
/var/lib/puppet/ssl/certs/node2.pem -key
/var/lib/puppet/ssl/private_keys/node2.pem
CONNECTED(0003)
depth=1 CN = Puppet CA: node1
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/CN=node2
i:/CN=Puppet CA: node1
1 s:/CN=Puppet CA: node1
i:/CN=Puppet CA: node1
---
[..]
subject=/CN=node2
issuer=/CN=Puppet CA: node1
---
Acceptable client certificate CA names
/CN=Puppet CA: node1
---
SSL handshake has read 5314 bytes and written 2445 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
[..]
Start Time: 1382622609
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
GET /production/node/node2
Forbidden request: node2l(10.120.12.73) access to /node/node2 [find] at
:115closed
This looks fine, It complains about the self-signed certificate in the
chain but other than that verify return = 0 which as far as I'm aware means
success. Once the handshake is complete I can actually do a GET for that
node but that seems to fail because of something in auth.conf, which is
slightly odd since the authentication succeeded so the ACL shouldn't trip
over it but that's step two (I'm probably forgetting to proxy
[Puppet Users] Re: SSH Module with multiple conditions
Hey,
Your approach seems fairly solid and should work but two things:
- prefer osfamily over operatingsystem, for example osfamily Redhat =
operatingsystem RedHat|CentOS|Fedora and a few more
- use osfamily to resolve your files. Instead of 'if string this then file
that' just point it to puppet:///modules/ssh/$osfamily/sshd_config
Good luck,
--
Daniele Sluijters
On Thursday, 24 October 2013 22:16:00 UTC+2, John wrote:
I've written and deployed a simple Linux SSH module. But I need to modify
to include support for FreeBSD and AIX. On top of that, I need to include
some conditionals in there that (for example)
if (/etc/file1 contains string abc) ; then
install sshd-config-x ssh-config-x
elsif (/etc/file1 contains string xyz); then
install sshd_config-y ssh_config-y
else install sshd_config-z and ssh_config-z.
So I've got multiple conditions; one for operating systems one for
configurations based on the contents of other files.
Here is my current init.pp I've come up with from the Pro Puppet book. Is
this a good start? Or do I totally need to scrsp this and restart based on
my criteria?
class ssh::params {
case $operatingsystem {
freebsd: {
$ssh_package_name = 'openssh'
$ssh_service_config = '/etc/ssh/sshd_config'
$ssh_service_name = 'sshd'
}
/aix: {
$ssh_package_name = 'openssh-server'
$ssh_service_config = '/etc/ssh/sshd_config'
$ssh_service_name = 'ssh'
}
/(RedHat|CentOS|Fedora)/: {
$ssh_package_name = 'openssh-server'
$ssh_service_config = '/etc/ssh/sshd_config'
$ssh_service_name = 'sshd'
}
}
}
class ssh::install {
package { $ssh::params::package_name:
ensure = installed,
}
}
class ssh::config {
file { /etc/ssh/sshd_config:
ensure = present,
owner = 'root',
group = 'root',
mode = 0600,
source = puppet:///modules/ssh/sshd_config,
require = Class[ssh::install],
notify = Class[ssh::service],
}
file { /etc/ssh/ssh_config:
ensure = present,
owner = 'root',
group = 'root',
mode = 0440,
source = puppet:///modules/ssh/ssh_config,
require = Class[ssh::install],
}
}
class ssh::service {
service { $ssh::params::ssh_service_name:
ensure = running,
hasstatus = true,
hasrestart = true,
enable = true,
require = Class[ssh::config],
}
}
class ssh
{
include ssh::params, ssh::install, ssh::config, ssh::service
}
Here are the configuration files under the file files directory...
[root@puppet ssh]# find files
files
files/default-config-x-sshd.erb
files/default-config-x-ssh.erb
files/default-config-y_sshd_config.erb
files/sshd_config
files/default-config-y_ssh_config.erb
files/ssh_config
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: SSH Module with multiple conditions
Hey,
One other tip, fully qualify everything to avoid weird behaviour in puppet:
- $::osfamily, not $osfamily
- $::ssh::params, not $ssh::params
- include ::ssh::params, not ssh::params
--
Daniele Sluijters
On Thursday, 24 October 2013 22:16:00 UTC+2, John wrote:
I've written and deployed a simple Linux SSH module. But I need to modify
to include support for FreeBSD and AIX. On top of that, I need to include
some conditionals in there that (for example)
if (/etc/file1 contains string abc) ; then
install sshd-config-x ssh-config-x
elsif (/etc/file1 contains string xyz); then
install sshd_config-y ssh_config-y
else install sshd_config-z and ssh_config-z.
So I've got multiple conditions; one for operating systems one for
configurations based on the contents of other files.
Here is my current init.pp I've come up with from the Pro Puppet book. Is
this a good start? Or do I totally need to scrsp this and restart based on
my criteria?
class ssh::params {
case $operatingsystem {
freebsd: {
$ssh_package_name = 'openssh'
$ssh_service_config = '/etc/ssh/sshd_config'
$ssh_service_name = 'sshd'
}
/aix: {
$ssh_package_name = 'openssh-server'
$ssh_service_config = '/etc/ssh/sshd_config'
$ssh_service_name = 'ssh'
}
/(RedHat|CentOS|Fedora)/: {
$ssh_package_name = 'openssh-server'
$ssh_service_config = '/etc/ssh/sshd_config'
$ssh_service_name = 'sshd'
}
}
}
class ssh::install {
package { $ssh::params::package_name:
ensure = installed,
}
}
class ssh::config {
file { /etc/ssh/sshd_config:
ensure = present,
owner = 'root',
group = 'root',
mode = 0600,
source = puppet:///modules/ssh/sshd_config,
require = Class[ssh::install],
notify = Class[ssh::service],
}
file { /etc/ssh/ssh_config:
ensure = present,
owner = 'root',
group = 'root',
mode = 0440,
source = puppet:///modules/ssh/ssh_config,
require = Class[ssh::install],
}
}
class ssh::service {
service { $ssh::params::ssh_service_name:
ensure = running,
hasstatus = true,
hasrestart = true,
enable = true,
require = Class[ssh::config],
}
}
class ssh
{
include ssh::params, ssh::install, ssh::config, ssh::service
}
Here are the configuration files under the file files directory...
[root@puppet ssh]# find files
files
files/default-config-x-sshd.erb
files/default-config-x-ssh.erb
files/default-config-y_sshd_config.erb
files/sshd_config
files/default-config-y_ssh_config.erb
files/ssh_config
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Changes to issue tracking for Puppet projects
Hey Eric, I was curious if you could elaborate a bit more on the choice of JIRA. I'm currently in the exact opposite spot, migrating away from JIRA to Redmine. -- Daniele Sluijters On Thursday, 24 October 2013 22:18:12 UTC+2, Eric Sorenson wrote: We're working on some big changes to our issue-tracking infrastructure. This includes a plan to migrate open issues from Redmine to JIRA for: Puppet, Hiera, Facter, MCollective, PuppetDB, the Forge, and Puppet Enterprise. We're tentatively planning for this change by the end of 2013; I’ll send out communications with specific dates prior to the migration. We’ll actively migrate Redmine bugs that are in-flight for the current releases when the cutover happens. Following the migration date, new bugs must be submitted in JIRA, though Redmine will remain available as a read-only point of reference. There are a few things you need to know: * Everybody needs to create a new account on JIRA, since we can’t migrate passwords from redmine to jira. * If you were watching redmine bugs to track their progress, you will be notified via email with the new location of the bug in JIRA. You'll need to set yourself up to watch the bug in JIRA with your newly-created account. * Some older issues that we think are obsolete will not be migrated, but if we made a mistake and forgot to include your favorite bug, there will be a link on each Redmine issue where you can migrate it with a single click. Please reply to this thread on puppet-users if you have any questions, concerns, or suggestions about the planned migration from Redmine to JIRA. Thanks, —eric0 Eric Sorenson - eric.s...@puppetlabs.com javascript: - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: What Do You Test
Hey, Usually there's about million things that can go wrong but ever since 3.x I've really had no issue whatsoever with upgrading releases. This was quite a bit different from 2.6/2.7 and I think really speaks to the work the QA folks at Puppet Labs are trying to do. That being said, most issues we had actually stemmed from our own code base. Things you know you shouldn't have done but did tend to bite you in the ass when you least expect it. I've been able to avoid any major issues since 3.x by simply having a sane, fairly well tested, code base. Also a good tip, don't patch custom things into Puppet or Hiera etc, that will break, eventually. -- Daniele Sluijters On Monday, 21 October 2013 20:54:13 UTC+2, Kurt Wall wrote: Hi everyone, We are working on enhancing our internal testing so we can improve the overall quality of Puppet releases. For example, I am one of two QA engineers assigned full-time to testing Puppet's FOSS stack. I'm seeking your input and experience to help us identify what we're missing and what we can improve. We have an extensive test suite, but there's always room for more testing and for better testing. When a new version of Puppet is released, what do you try out before you deploy the it in a production setting? What sorts of behaviors do you test before you unleash a new release on unsuspecting machines and users? To express it differently, what has bitten you in the past when deploying a Puppet release? What makes you wary when installing a new release of Puppet? Thanks! Kurt -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet 3.2: add element to array
HI,
It should be possible to do something like this:
$users = [a,b,c]
$users += [d,e]
Or, $users = [[a,b,c] [d,e]] etc.
Perhaps a better question, what is it you're trying to do, exactly, that
you need this?
--
Daniele Sluijters
On Monday, 21 October 2013 20:21:18 UTC+2, Sergey Arlashin wrote:
Hi!
Is it possible to add a new element to an array inside puppet manifest ?
Something like ruby's array.push('new_element') ?
--
Best regards,
Sergey Arlashin
--
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] pypuppetdb 0.0.4 / puppetboard 0.0.2
Hello everyone, It's been way to long since the release but I finally had some time to sort a few things out and release updates to both pypuppetdb and Puppetboard. For those of you who have no idea what this is about: * pypuppetdb is a library to work with the PuppetDB API in Python; * Puppetboard is meant as a replacement to Puppet Dashboard leveraging PuppetDB through pypuppetdb as its datasource. New is PuppetDB 1.5 (API v3) compatibility. None of the new features of API v3 have been implemented yet, that's going to be the goal for the coming weeks but everything that used to be possible with API v2 + Experimental is now available over API v3. Because PuppetDB 1.5 dropped the /experimental endpoints those have been removed from pypuppetdb too, even for older versions of PuppetDB. Puppetboard has gained a metrics tab and facts now have pretty pie-charts as well as an assorted set of small fixes and improvement across the board. Once pypuppetdb has gained support for all the new features in API v3 there are going to be some significant changes to Puppetboard, both in its capabilities and the UI. For those of you who will be at Puppet Camp London in November, I'm hoping I'll be able to show you at least some of that. As usual you can get the code from: * pypuppetdb: https://github.com/nedap/pypuppetdb or `pip install pypuppetdb` * puppetboard: https://github.com/nedap/puppetboard -- Daniele Sluijters -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Announce: PuppetDB 1.5.0 Available
Oh goody this looks awesome. -- Daniele Sluijters On Tuesday, 1 October 2013 01:56:49 UTC+2, Chris Price wrote: PuppetDB 1.5.0 is now available for download! This is a new feature release that contains a few bug-fixes as well. = ## Downloads ## = Available in native package format at: http://yum.puppetlabs.com and http://apt.puppetlabs.com Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ # Documentation (including how to install): http://docs.puppetlabs.com/puppetdb/1.http://docs.puppetlabs.com/puppetdb/1.2 5 # Issues can be filed at: http://projects.puppetlabs.com/projects/puppetdb/issues ## PuppetDB 1.5.0 Release Notes ## Notable features and improvements: * (#21520) Configuration for soft failure when PuppetDB is unavailable This feature adds a new option 'soft_write_failure' to the puppetdb configuration. If enabled the terminus behavior is changed so that if a command or write fails, instead of throwing an exception and causing the agent to stop it will simply log an error to the puppet master log. * New v3 query API New `/v3` URLs are available for all query endpoints. The `reports` and `events` endpoints, which were previously considered `experimental`, have been moved into `/v3`. Most of the other endpoints are 100% backwards-compatible with `/v2`, but now offer additional functionality. There are few minor backwards-incompatible changes, detailed in the comments about individual endpoints below. * Query paging This feature adds a set of new HTTP query parameters that can be used with most of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`, `events`, `reports`, `event-counts`) to allow paging through large result sets over multiple queries. The available HTTP query parameters are: * `limit`: an integer specifying the maximum number of results to return. * `order-by`: a list of fields to sort by, in ascending or descending order. The legal set of fields varies by endpoint; see the documentation for individual endpoints for more info. * `offset`: an integer specifying the first result in the result set that should be returned. This can be used in combination with `limit` and `order-by` to page through a result set over multiple queries. * `include-total`: a boolean flag which, if set, will cause the HTTP response to contain an `X-Records` header indicating the total number of results that are available that match the query. (Mainly useful in combination with `limit`.) * New features available on `events` endpoint * The `events` data now contains `file` and `line` fields. These indicate the location in the manifests where the resource was declared. They can be used as input to an `events` query. * Add new `configuration-version` field, which contains the value that Puppet supplied during the agent run. * New `containing-class` field: if the resource is declared inside of a Puppet class, this field will contain the name of that class. * New `containment-path` field: this field is an array showing the full path to the resource from the root of the catalog (contains an ordered list of names of the classes/types that the resource is contained within). * New queryable timestamp fields: * `run-start-time`: the time (on the agent node) that the run began * `run-end-time`: the time (on the agent node) that the run completed * `report-receive-time`: the time (on the puppetdb node) that the report was received by PuppetDB * Restrict results to only include events that occurred in the latest report for a given node: `[=, latest-report?, true]` * New `event-counts` endpoint `v3` of the query API contains a new `event-counts` endpoint, which can be used to retrieve count data for an event query. The basic input to the endpoint is an event query, just as you'd provide to the `events` endpoint, but rather than returning the actual events, this endpoint returns counts of `successes`, `failures`, `skips`, and `noops` for the events that match the query. The counts may be aggregated on a per-resource, per-class, or per-node basis. * New `aggregate-event-counts` endpoint This endpoint is similar to the `event-counts` endpoint, but rather than aggregating the counts on a per-node, per-resource, or per-class basis, it returns aggregate counts across your entire population. * New `server-time` endpoint This endpoint simply returns a timestamp indicating the current time on the PuppetDB server. This can be used as input to time-based
[Puppet Users] Re: [Puppet-dev] Announce: PuppetDB 1.5.0 Available
It's not just the Precise packages that are missing. The complete Debian suite is missing too, squeeze, wheezy, jessy and sid. On Tuesday, 1 October 2013 04:59:16 UTC+2, blkperl wrote: No packages for precise/raring? Its missing debs for 1.5.0. Lucid seems fine Thanks, William On Mon, Sep 30, 2013 at 4:56 PM, Chris Price ch...@puppetlabs.comjavascript: wrote: PuppetDB 1.5.0 is now available for download! This is a new feature release that contains a few bug-fixes as well. = ## Downloads ## = Available in native package format at: http://yum.puppetlabs.com and http://apt.puppetlabs.com Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ # Documentation (including how to install): http://docs.puppetlabs.com/puppetdb/1.http://docs.puppetlabs.com/puppetdb/1.2 5 # Issues can be filed at: http://projects.puppetlabs.com/projects/puppetdb/issues ## PuppetDB 1.5.0 Release Notes ## Notable features and improvements: * (#21520) Configuration for soft failure when PuppetDB is unavailable This feature adds a new option 'soft_write_failure' to the puppetdb configuration. If enabled the terminus behavior is changed so that if a command or write fails, instead of throwing an exception and causing the agent to stop it will simply log an error to the puppet master log. * New v3 query API New `/v3` URLs are available for all query endpoints. The `reports` and `events` endpoints, which were previously considered `experimental`, have been moved into `/v3`. Most of the other endpoints are 100% backwards-compatible with `/v2`, but now offer additional functionality. There are few minor backwards-incompatible changes, detailed in the comments about individual endpoints below. * Query paging This feature adds a set of new HTTP query parameters that can be used with most of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`, `events`, `reports`, `event-counts`) to allow paging through large result sets over multiple queries. The available HTTP query parameters are: * `limit`: an integer specifying the maximum number of results to return. * `order-by`: a list of fields to sort by, in ascending or descending order. The legal set of fields varies by endpoint; see the documentation for individual endpoints for more info. * `offset`: an integer specifying the first result in the result set that should be returned. This can be used in combination with `limit` and `order-by` to page through a result set over multiple queries. * `include-total`: a boolean flag which, if set, will cause the HTTP response to contain an `X-Records` header indicating the total number of results that are available that match the query. (Mainly useful in combination with `limit`.) * New features available on `events` endpoint * The `events` data now contains `file` and `line` fields. These indicate the location in the manifests where the resource was declared. They can be used as input to an `events` query. * Add new `configuration-version` field, which contains the value that Puppet supplied during the agent run. * New `containing-class` field: if the resource is declared inside of a Puppet class, this field will contain the name of that class. * New `containment-path` field: this field is an array showing the full path to the resource from the root of the catalog (contains an ordered list of names of the classes/types that the resource is contained within). * New queryable timestamp fields: * `run-start-time`: the time (on the agent node) that the run began * `run-end-time`: the time (on the agent node) that the run completed * `report-receive-time`: the time (on the puppetdb node) that the report was received by PuppetDB * Restrict results to only include events that occurred in the latest report for a given node: `[=, latest-report?, true]` * New `event-counts` endpoint `v3` of the query API contains a new `event-counts` endpoint, which can be used to retrieve count data for an event query. The basic input to the endpoint is an event query, just as you'd provide to the `events` endpoint, but rather than returning the actual events, this endpoint returns counts of `successes`, `failures`, `skips`, and `noops` for the events that match the query. The counts may be aggregated on a per-resource, per-class, or per-node basis. * New `aggregate-event-counts` endpoint This endpoint is similar to the `event-counts` endpoint, but rather than aggregating the counts on a
[Puppet Users] Re: introducing puppetboard 0.0.1
Hey,
Good catch, I'll get that fixed asap.
--
Daniele Sluijters
On Tuesday, 13 August 2013 22:36:35 UTC+2, Ellison Marks wrote:
Er, excuse me, I misspoke. As it is it relies on having python 2.7+, not 3
for the formatting. Still, the Redhat family, by default, is still on 2.6.
On Tuesday, August 13, 2013 12:13:17 PM UTC-7, Ellison Marks wrote:
So I finally got the time to get this going, and it is indeed, very cool.
One hitch though: I grabbed the source from github, and most things seemed
to work, but the overview page errored out. It seems that it was using
python 3 syntax for it's format strings on line 86 and 88.
86: 'avg_resources_node': {:10.6f}.format(avg_resources_node['Value']),
87: 'mean_failed_commands': mean_failed_commands['MeanRate'],
88: 'mean_command_time': {:10.6f}.format(mean_command_time['MeanRate']),
I added a 0 to the format specification and it worked fine
86: 'avg_resources_node': {0:10.6f}.format(avg_resources_node['Value']),
87: 'mean_failed_commands': mean_failed_commands['MeanRate'],
88: 'mean_command_time':
{0:10.6f}.format(mean_command_time['MeanRate']),
On Wednesday, August 7, 2013 5:47:23 AM UTC-7, Daniele Sluijters wrote:
Hello everyone,
It’s a lovely grey and rainy day here in the Dutch summer, as good a day
as any to release a new little project.
Its name is Puppetboard and has as aim to replace Puppet Dashboard’s
reporting functionality. It does not nor will it include ENC features. It
does all this without storing any data itself but querying PuppetDB instead.
The whole thing is built in Python and relies on Flask and WTForms. The
communication logic has been split of in its own library called pypuppetdb
which makes heavy use of the requests library. The interface is powered by
Twitter Bootstrap with the Flatly theme.
Though I’ve pushed all the code out and made it public it’s all very
young but it works fairly well. However, I’ve committed numerous
barbarities in the code just to get things working and to figure out how to
handle certain things. For the foreseeable time in the future I’ll be
working on cleaning all this up and figuring out what I can do on my side
and on PuppetDB’s side to make all this work a little better. Especially
when it comes to dealing with big responses from PuppetDB...
This is the first time I’m open sourcing a project so that too is all
new to me. I’d welcome the feedback and if someone feels brave enough even
commits on the projects but try and be gentle about it :-). I’ll also be at
PuppetConf including the Developer Day so feel free to reach out to me in
person.
To the code:
* puppetboard: https://github.com/nedap/puppetboard
* pypuppetdb: https://github.com/nedap/pypuppetdb
I realise that puppetboard doesn't have a test suite right now but it
will soon. In order to do so I have to restructure a few things about it
first. The installation documentation will improve with it.
Pypuppetdb's test suite will be expanding the coming days once I'm done
mocking the HTTP requests _query() makes and manage to get a decent and big
enough set of test data to feed into PuppetDB. This will allow me to run
integration tests and benchmark certain changes I have in mind.
I’m hoping to be able to get a release out every month with improvements
to both projects, perhaps even faster in the beginning but it remains to be
seen how much time I’ll be able to spend on it.
A special thanks goes out to Ken Barber for helping out with all things
PuppetDB and coming up with a way to run PuppetDB on Travis so we can run
integration tests. Hunter, thank you for being so interested in this
project and pushing me to release it.
—
Daniele Sluijters
Nedap | Steppingstone
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Announce: PuppetDB 1.4.0 Available
Hey, Great work! I really like the addition of puppetdb-anonymize, that's going to help me out in a few situations. -- Daniele Sluijters On Friday, 9 August 2013 01:59:25 UTC+2, Ken Barber wrote: PuppetDB 1.4.0 is now available for download! This is a new feature release and the start of the 1.4 series of PuppetDB. === ## Downloads ## === Available in native package format at: http://yum.puppetlabs.com and http://apt.puppetlabs.com Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ # Documentation (including how to install): http://docs.puppetlabs.com/puppetdb/1.4 # Issues can be filed at: http://projects.puppetlabs.com/projects/puppetdb/issues # See our development board on Trello: http://links.puppetlabs.com/puppetdb-trello ## PuppetDB 1.4.0 Release Notes ## Notable features and improvements: * (#21732) Allow SSL configuration based on Puppet PEM files (Chris Price Ken Barber) This feature introduces some functions for reading keys and certificates from PEM files, and dynamically constructing java KeyStore instances in memory without requiring a .jks file on disk. It also introduces some new configuration options that may be specified in the `jetty` section of the PuppetDB config to initialize the web server SSL settings based on your Puppet PEM files. The tool `puppetdb-ssl-setup` has been modified now to handle these new parameters, but leave legacy configuration alone by default. * (#20801) allow */* wildcard (Marc Fournier) This allows you to use the default Accept: */* header to retrieve JSON documents from PuppetDB without needed the extra Accept: applicaiton/json header when using tools such as curl. * (#15369) Terminus for use with puppet apply (Ken Barber) This patch provides a new terminus that is suitable for facts storage usage with masterless or `puppet apply` usage. The idea is that it acts as a fact cache terminus, intercepting the first save request and storing the values in PuppetDB. * Avoid Array#find in Puppet::Resource::Catalog::Puppetdb#find_resource (Aman Gupta) This patch provides performance improvements in the terminus, during the synthesize_edges stage. For example, in cases with 10,000 resource (with single relationships) we saw a reduction from 83 seconds to 6 seconds for a full Puppet run after this patch was applied. * Portability fixes for OpenBSD (Jasper Lievisse Adriaanse) This series of patches from Jasper improved the scripts in PuppetDB so they are more portable to BSD based platforms like OpenBSD. * Initial systemd service files (Niels Abspoel) * Updated spec file for suse support (Niels Abspoel) This change wil make puppetdb rpm building possible on opensuse with the same spec file as redhat. * (#21611) Allow rake commands to be ran on Ruby 2.0 (Ken Barber) This allows rake commands to be ran on Ruby 2.0, for building on Fedora 19 to be made possible. * Add puppetdb-anonymize tool (Ken Barber) This patch adds a new tool 'puppetdb-anonymize' which provides users with a way to anonymize/scrub their puppetdb export files so they can be shared with third parties. * (#21321) Configurable SSL protocols (Deepak Giridharagopal) This patch adds an additional configuration option, `ssl-protocols`, to the `[jetty]` section of the configuration file. This lets users specify the exact list of SSL protocols they wish to support, such as in cases where they're running PuppetDB in an environment with strict standards for SSL usage. If the option is not supplied, we use the default set of protocols enabled by the local JVM. * Create new conn-lifetime setting (Chuck Schweizer Deepak Giridharagopal) This creates a new option called `conn-lifetime` that governs how long idle/active connections stick around. * (#19174) Change query parameter to optional for facts resources (Ken Barber) Previously for the /v2/facts and /v2/resources end-point we had documented that the query parameter was required, however a blank query parameter could be used to return _all_ data, so this assertion wasn't quite accurate. However one could never really drop the query parameter as it was considered mandatory and without it you would get an error. To align with the need to return all results at times, and the fact that making a query like '/v2/facts?query=' to do such a thing is wasteful, we have decided to drop the mandatory need for the 'query' parameter. This patch allows 'query' to be an optional parameter for /v2/facts resources by removing the validation check and updating
Re: [Puppet Users] introducing puppetboard 0.0.1
Hey, That's awesome, let me know how it goes. I'm not sure how well it will be able to handle itself at the scale of your infrastructure but only one way to find out! -- Daniele Sluijters On Thursday, 8 August 2013 01:47:07 UTC+2, Erik Dalén wrote: Cool stuff will try it out. I think we might have some Python projects at work that would be interested in using the pypuppetdb library as well. -- 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] introducing puppetboard 0.0.1
Hello everyone, It’s a lovely grey and rainy day here in the Dutch summer, as good a day as any to release a new little project. Its name is Puppetboard and has as aim to replace Puppet Dashboard’s reporting functionality. It does not nor will it include ENC features. It does all this without storing any data itself but querying PuppetDB instead. The whole thing is built in Python and relies on Flask and WTForms. The communication logic has been split of in its own library called pypuppetdb which makes heavy use of the requests library. The interface is powered by Twitter Bootstrap with the Flatly theme. Though I’ve pushed all the code out and made it public it’s all very young but it works fairly well. However, I’ve committed numerous barbarities in the code just to get things working and to figure out how to handle certain things. For the foreseeable time in the future I’ll be working on cleaning all this up and figuring out what I can do on my side and on PuppetDB’s side to make all this work a little better. Especially when it comes to dealing with big responses from PuppetDB... This is the first time I’m open sourcing a project so that too is all new to me. I’d welcome the feedback and if someone feels brave enough even commits on the projects but try and be gentle about it :-). I’ll also be at PuppetConf including the Developer Day so feel free to reach out to me in person. To the code: * puppetboard: https://github.com/nedap/puppetboard * pypuppetdb: https://github.com/nedap/pypuppetdb I realise that puppetboard doesn't have a test suite right now but it will soon. In order to do so I have to restructure a few things about it first. The installation documentation will improve with it. Pypuppetdb's test suite will be expanding the coming days once I'm done mocking the HTTP requests _query() makes and manage to get a decent and big enough set of test data to feed into PuppetDB. This will allow me to run integration tests and benchmark certain changes I have in mind. I’m hoping to be able to get a release out every month with improvements to both projects, perhaps even faster in the beginning but it remains to be seen how much time I’ll be able to spend on it. A special thanks goes out to Ken Barber for helping out with all things PuppetDB and coming up with a way to run PuppetDB on Travis so we can run integration tests. Hunter, thank you for being so interested in this project and pushing me to release it. — Daniele Sluijters Nedap | Steppingstone -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: introducing puppetboard 0.0.1
Hi Klavs, Thanks, I'll think about that. An API that could be used for notifications and such was already on my mind. Unfortunately I don't think I can currently ask PuppetDB for the statistics you mention but perhaps that can be added to PuppetDB. As far as notifying about failed runs through Nagios, we actually use a plugin that checks the report age and its content on every node. -- Daniele Sluijters On Wednesday, 7 August 2013 15:32:48 UTC+2, Klavs Klavsen wrote: It seems very cool. Thank you for sharing. One thing that I would be missing, before being able to switch (as gathered from screenshots - I haven't tested it yet :) - is the overview of failed, unreported and unresponsive hosts. Also - there would need to be a way to query this - just as I currently do from puppet-dashboard (for my nagios monitoring) - so that I can alert when I started getting failed runs etc. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Template with array and nested hash
Hi, So you have an array containing one or multiple hashes which in turn contains an array of rules which are hashes by themselves. In templates you use erb, so embedded ruby. Therefor you can use just about any construct from the Ruby language, including how you can do things with Arrays and Hashes. So, we start: % @squid_acls.each do |acl| % so now we have a loop for the outer part of the array # %= acl['comment'] =% here we just outputted what comment contained % acl['rules']. each do |rule| % now we're accessing the contents of the rules key. Since we know it's an array you can loop over it acl %= rule['aclname'] =% %= rule['acltype'] =% %= rule['arg'] =% % end % % end % This probably won't work out of the box like this but it should give you an idea on how to get started. -- Daniele Sluijters On Tuesday, 16 April 2013 06:26:25 UTC+2, Matthew Ceroni wrote: I have the following http://pastebin.com/dphfbV7z As outlined in the above I want to turn the data structure I have into what is outlined in a template. Not sure how to go about accessing and looping over the multiple levels in the data structure. Thanks On Tuesday, 16 April 2013 06:26:25 UTC+2, Matthew Ceroni wrote: I have the following http://pastebin.com/dphfbV7z As outlined in the above I want to turn the data structure I have into what is outlined in a template. Not sure how to go about accessing and looping over the multiple levels in the data structure. 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] Re: Generate YARD docs for modulepath
Hey, I had the same question. I can tell you that just using YARD won't work, you'll only get warnings about undocumentable classes. As far as I can understand, a Handler and Parser will have to be written for YARD if we want to use it to document Puppet code. Better even, `puppet doc` just needs to get fixed (which could then use YARD once a Handler and Parser have been written). -- Daniele Sluijters On Thursday, 11 April 2013 10:56:16 UTC+2, Sven Sporer wrote: I know that Puppet 3.1 uses YARD to document the Ruby code (not manifests). The question is if the parser logic for RDOC templates can be used together with YARD: * https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/rdoc/generators/puppet_generator.rb * https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/rdoc/parser.rb Sry for the confusion (and doubleposting). Am Donnerstag, 11. April 2013 10:43:15 UTC+2 schrieb Sven Sporer: Hi, Puppet 3.1 now uses YARD to generate its API documentation. Is anybody aware of the possibility to generate nice YARD docs for a given module path, replacing the default RDOC-style site from puppet doc --modulepath ...? Could the YARD Template from Puppet 3.1 be used for this? -- 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] Puppetlabs APT GPG key
Hi, I just started getting errors from APT: W: GPG error: http://apt.puppetlabs.com squeeze Release: The following signatures were invalid: BADSIG 1054B7A24BD6EC30 Puppet Labs Release Key (Puppet Labs Release Key) i...@puppetlabs.com It looks like they keyring was changed yesterday on the APT repository: keyring.gpg 09-Jan-2013 14:51 2.5K However, I've yet to see an announcement about this. So, was this actually done by Puppet Labs or is something else going on? Kind regards, -- Daniele Sluijters -- 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/-/e_avxSQVUNIJ. 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: Puppetlabs APT GPG key
Hi, With a bit of help from Haus we figured it out. The last time our apt-cacher-ng pulled in the apt.puppetabs.com repo something went wrong causing a few of the files to go corrupt, triggering the validation errors. This then trickled down to all the machines when apticron ran an apt-get update. The solution was to get rid of /var/cache/apt-cacher-ng/apt.puppetlabs.com and /var/lib/apt/lists/* (and then recreating /var/lib/apt/lists/partial) on the apt-cacher-ng machine. After that, apt-get clean and apt-get update were run on the apt-cacher-ng machine. it now pulled in everything correctly and everything started working again. How the issue occurred in the first place still remains a bit of a mystery. -- Daniele Sluijters On Thursday, 10 January 2013 09:02:14 UTC+1, Daniele Sluijters wrote: Hi, I just started getting errors from APT: W: GPG error: http://apt.puppetlabs.com squeeze Release: The following signatures were invalid: BADSIG 1054B7A24BD6EC30 Puppet Labs Release Key (Puppet Labs Release Key) i...@puppetlabs.com It looks like they keyring was changed yesterday on the APT repository: keyring.gpg 09-Jan-2013 14:51 2.5K However, I've yet to see an announcement about this. So, was this actually done by Puppet Labs or is something else going on? Kind regards, -- Daniele Sluijters -- 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/-/wedxctcj09YJ. 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] passenger used in puppet 3.0?
That depends. If you start Unicorn and make it listen to a Unix socket then no, you'll need something in front of it to accept the HTTP connections for you and then proxy that to the unicorn socket. You can also tell Unicorn to bind against an IP, in which case you won't need an nginx in front and you can just tell f5 where to find your unicorn(s). You will, in both cases, need something like God, supervisord or something else to check and restart the Puppet Master in case it stops/crashes. -- Daniele Sluijters On Wednesday, 28 November 2012 20:21:35 UTC+1, DJames wrote: we have f5's load balancer can it be used instead of Nginx? On Wednesday, November 28, 2012 10:30:24 AM UTC-5, jmslagle wrote: On 11/28/2012 09:53 AM, DJames wrote: current dev system is using passenger, but production (babystage) is using 3.0 version, and we have 1800+ servers (prod) that will be clients is passenger the way to go still? I was previously using passenger and just recently switched to using nginx/unicorn. I like the setup a lot better - I can't really quantify why other than the architecture of the way it does it seems better to me, and getting passenger working was a pain under RHEL6. General instructions here: http://projects.puppetlabs.com/projects/1/wiki/using_unicorn Some notes: 1) I ended up symlinking /etc/puppet to ~puppet/.puppet to fix the issue where puppet master not running as root will not look in the right place for it's config. 2) I couldn't find unicorn packages for RHEL - I ended up using gem2rpm and tweaking it to build. 3) I used supervisord instead of god because I'm more familiar with it. Again you'll likely need to build packages for it - I just updated the spec here: https://github.com/easel/supervisor-rpm There's a good puppet module to manage supervisord here: https://github.com/plathrop/puppet-module-supervisor Thanks, Jason -- 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/-/JZsw3NolatgJ. 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] Puppet 3 killed my environment variables
Hello, In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER and $LOGNAME environment variables are unset and nowhere to be found. I realise this change was necessary because it caused some weird start-up issues with Puppet but this also killed our RabbitMQ module. RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be set as it will try to write an erlang-cookie to it and horribly fail and go up in flames if it can't. Since Puppet 3 every Exec we have in the RabbitMQ module now fails because of this. We've tried changing the command to '$HOME=/var/lib/misc/puppet rabbitmqctl do something' but yet again the Exec type just nukes the environment too. This being the 'offending' pull request which got merged: https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7 So, short of patching Puppet to not do this or generate static wrappers for every rabbitmqctl command which then in turn get called by an Exec, how do we solve this? I really don't feel like generating wrappers for every Exec that needs one of those environment variables set. I'd actually expect that Exec would allow me to explicitly pass in environment variables that I really need set in that case but the docs don't seem to know anything about that. Kind regards, -- Daniele Sluijters -- 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/-/iOy3L_m66GUJ. 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 killed my environment variables
Hi,
Sorry, I got confused between two things. It's not the actual Exec type.
it's when a provider executes a command that the environment cannot be set.
--
Daniele Sluijters
On Wednesday, 3 October 2012 15:00:54 UTC+2, Stephen Gran wrote:
Hi,
On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters wrote:
Hello,
In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER
and $LOGNAME environment variables are unset and nowhere to be found.
I realise this change was necessary because it caused some weird
start-up issues with Puppet but this also killed our RabbitMQ module.
RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be
set as it will try to write an erlang-cookie to it and horribly fail
and go up in flames if it can't. Since Puppet 3 every Exec we have in
the RabbitMQ module now fails because of this. We've tried changing
the command to '$HOME=/var/lib/misc/puppet rabbitmqctl do something'
but yet again the Exec type just nukes the environment too. This being
the 'offending' pull request which got
merged:
https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7
So, short of patching Puppet to not do this or generate static
wrappers for every rabbitmqctl command which then in turn get called
by an Exec, how do we solve this? I really don't feel like generating
wrappers for every Exec that needs one of those environment variables
set. I'd actually expect that Exec would allow me to explicitly pass
in environment variables that I really need set in that case but the
docs don't seem to know anything about that.
Can you not just set resource defaults like:
Exec {
environment = HOME=/home/wibble
}
?
Cheers,
--
Stephen Gran
Senior Systems Integrator - The Guardian
Please consider the environment before printing this email.
--
Visit guardian.co.uk - newspaper of the year
www.guardian.co.ukwww.observer.co.uk www.guardiannews.com
On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition
www.guardian.co.uk/iPad
Save up to 37% by subscribing to the Guardian and Observer - choose the
papers you want and get full digital access.
Visit guardian.co.uk/subscribe
-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
Guardian News Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
Guardian News Media Limited
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
Registered in England Number 908396
--
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/-/ghtP6bqOcegJ.
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: Getting all variable occurrences from Hiera
Hi, True, however, that is already the case. A host right now is made up of two YAML files. Nevertheless I agree it would be nice to keep all information relevant to a specific node contained in its own YAML. I could easily create something that would just parse the files and generate DHCPD and DNS files from them without going through Puppet but that defeats the purpose. Plus one'd have to remember to run that code before committing. -- Daniele Sluijters On Thursday, 16 August 2012 23:08:26 UTC+2, Alexander Swen wrote: I hadn't thought of just separating that information into its own YAML file, that's an interesting solution and one I'll definitely be looking into to. But then, information about one host is kept in multiple files and it would be my aim to wrap all specific info for one host into one yaml. so that once you remove the host, you only have to remove that file. That yaml file should keep alle the specific params of that host. and every other module should be able to take advantage of that information. This is not only the case for dhcp, but for dns as well. and of course the /etc/network/interfaces file of the host itself. And to avoid needless redundancy of information, certain values should be written into that file maximum once. so, the ipaddress for example must not be written in some dns config yaml file as well. and in the hostname.yaml. Should you decide to change the ipaddress, you definitely forget either the bind or the dhcp config. I realize that this might lead into a feature req for Hiera. There must simply be a way to tell the dhcp and bind modules to have a look in all hostname.yaml files to collect all ipaddresses and macaddresses and hostnames. Best regards, Alex -- 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/-/hW_VCzOnl4MJ. 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: brew and macosx and puppet
Hello,
The problem is that you're running 'brew install nginx' as root, since
Puppet runs as root.
If you run that command as root on a console it will tell you:
9:35:11 r...@chell.portal.daenney.net ~ brew install nginx
Cowardly refusing to `sudo brew install'
And it exists with an exitcode of:
9:35:14 r...@chell.portal.daenney.net ~ echo $?
1 ↵
1
So, unless you can run that command as the actual user that owns the brew
installation this just won't work.
--
Daniele Sluijters
On Friday, 17 August 2012 09:20:53 UTC+2, Dan wrote:
any hints on installing a package through the 'brew' provider on macosx?
code:
exec { brew_install_nginx:
command = /usr/local/bin/brew install nginx,
creates = /usr/local/sbin/nginx,
path= /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin,
user = push,
}
brew install nginx works from the command line, outside of puppet
output:
$ ls /usr/local/sbin/nginx
ls: /usr/local/sbin/nginx: No such file or directory
$ /opt/bin/contact_puppet_server.sh
info: Retrieving plugin
info: Caching catalog for dev.push.am
info: Applying configuration version '1345186944'
err: /Stage[main]/Nginx::Install/Exec[brew_install_nginx]/returns: change
from notrun to 0 failed: /usr/local/bin/brew install nginx returned 1
instead of one of [0] at /etc/puppet/modules/nginx/manifests/install.pp:23
--
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/-/9Ox-OD1_m8QJ.
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: Installing puppet-dashboard on ubuntu precise
Hi, Are you sure there's no rack 1.3.5 somewhere around your system? If there is it is probably found in the $RUBYLIBDIR path before the one installed from gem so you're still seeing the error. If not, then it's getting interesting... -- Daniele Sluijters On Wednesday, 15 August 2012 07:17:38 UTC+2, Sam Morrison wrote: Hi, I'm trying to install dashboard on precise and I get the below error. I'm using the latest version that is available in the puppet apt repository. The package rdoc is installed (it's just a virtual package pointing to ruby) Are there some other missing dependencies that the package doesn't specify? I don't know ruby that well so finding it hard to debug. Also it's well after 2011-11-01 is that a problem too? Thanks, Sam root@admin:/usr/share/puppet-dashboard# rake RAILS_ENV=production db:migrate --trace NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after
[Puppet Users] Re: Custom types in environments working .... yes/no/maybe ?
Hi, We've ran into the same problem. Our current solution, which we're not happy about, is to also have the custom types on the master/production environment. Doing that at least the custom types are always available. Unfortunately, it makes it impossible to deploy an update of a custom type to a branch/environment for testing. -- Daniele Sluijters On Wednesday, 15 August 2012 19:06:03 UTC+2, Douglas wrote: My issue may be related to this bug: http://projects.puppetlabs.com/issues/13858 Custom types in environments require loading into master's libdir However, now I'm not so sure, This was working previously with a given client. However, after trying on a fresh client, it's failing with: err: Could not run Puppet configuration client: Could not find a default provider for logical_volume The server seems to have the files: /var/lib/puppet/lib/puppet/provider/logical_volume /var/lib/puppet/lib/puppet/type/logical_volume.rb And so does the client: /var/lib/puppet/lib/puppet/type/logical_volume.rb /var/lib/puppet/lib/puppet/provider/logical_volume pluginsync=true in /etc/puppet/puppet.conf. Using multiple environments and puppet 2.7.1. *sigh* Doug. -- 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/-/gf-jmlXC-tcJ. 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] Getting all variable occurrences from Hiera
Hello,
We've been using Hiera for a while and one of the things I'd like to do is
use the data we have in the YAML backend and generate our BIND zonefiles
and DHCPD.conf from it.
Every node has a stanza defined with it's 'primary' IP-address and
MAC-address like so:
hostname.yaml:
---
m_interface:
- ip: 127.0.0.1
- mac_address: aa:bb:cc:dd:ee:ff
Based on that information and the YAML file it was found in (so the node in
our case) I'd like to generate a dhcpd.conf like this:
host hostname(.yaml) {
fixed-address: m_interface[ip]
hardware ethernet: m_interface[mac_address]
Now, this can be done for a single node, however, I need a way to get that
information for every node. As far as I understand both hiera_hash and
hiera_array only walk the hierarchy upwards, not outwards (which is usually
what you want anyway).
I'm looking for something like a hiera_all that would return a hash with
the node name as key and value the m_interface stanza for that node.
At this point I'm not even sure this can be done so, anyone got any bright
ideas?
Kind regards,
--
Daniele Sluijters
--
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/-/UujM_sYrG7QJ.
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: Installing puppet-dashboard on ubuntu precise
Hi, The issue is probably that the Puppet package is requiring librack-ruby. In the case of Debian Squeeze this neatly resolves to 1.1.0 and there are no issues. Dashboard should be fixed to work with more recent versions of Rack though as Wheezy ships with 1.4.1 so the issue will be more prominent. What you can try for now is to uninstall the Ubuntu package and grab the Debian librack-ruby and install that through dpkg. It's probably going to want to upgrade librack-ruby the next time you run apt-get upgrade so you might have to hold the package if you go down this road. The issues are caused by endor/rails/railties/lib/rails/gem_depedency.rb and vendor_gem_source_index.rb that use deprecated functions. The fix should be fairly simple but someone actually has to get up and do it. The issue is being tracked in http://projects.puppetlabs.com/issues/9296 so I suggest you update that ticket. -- Daniele Sluijters On Wednesday, 15 August 2012 07:17:38 UTC+2, Sam Morrison wrote: Hi, I'm trying to install dashboard on precise and I get the below error. I'm using the latest version that is available in the puppet apt repository. The package rdoc is installed (it's just a virtual package pointing to ruby) Are there some other missing dependencies that the package doesn't specify? I don't know ruby that well so finding it hard to debug. Also it's well after 2011-11-01 is that a problem too? Thanks, Sam root@admin:/usr/share/puppet-dashboard# rake RAILS_ENV=production db:migrate --trace NOTE: Gem.source_index is deprecated, use Specification. It will be removed on or after 2011-11-01. Gem.source_index called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21. NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It will be removed on or after 2011-11-01. Gem::SourceIndex#initialize called from /usr/share/puppet-dashboard/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /usr/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed
[Puppet Users] Re: Custom types in environments working .... yes/no/maybe ?
I'm afraid I don't completely agree there. One of the benefits of environments is that it allows you to completely separate a change for a module/extension into a separate environment, without needing a separate master, SSL CA and so forth. As far as the point to not exposing the production master to untested code, fair enough. I guess there's a chance that untested Ruby code in a different environment could crash the master. Then again, I'll probably notice that about 10 seconds after deploying the actual code and if an agent can't check in for a few minutes that's not necessarily a problem. The point that we would be able to test Puppet extensions without putting them into production is moot really if Puppet would actually bother to load extensions from a environment specific libdir. There's plenty of ways to work around the fact that extensions in environments don't really work as one would expect them to but, that really ought be fixed in the first place, or environments removed all together. In it's current state the behaviour is slightly unspecified. The patch suggested in the ticket seems reasonable enough though I'm guessing one would have to tell Puppet its libdir now looks like /var/lib/puppet/master/lib/%= environment % for it to work. On Thursday, 16 August 2012 16:37:10 UTC+2, jcbollinger wrote: On Thursday, August 16, 2012 3:26:23 AM UTC-5, Daniele Sluijters wrote: Hi, We've ran into the same problem. Our current solution, which we're not happy about, is to also have the custom types on the master/production environment. Doing that at least the custom types are always available. Unfortunately, it makes it impossible to deploy an update of a custom type to a branch/environment for testing. For what it's worth, I would recommend using an entirely separate Puppet process for testing. If you like, it can run on the same server, but a different port. That would have several advantages for you, among them - you would be able to test modifications to your Puppet extensions without putting them into production - you would be able to test how changes apply to and affect your various environments (or if you use environments only for this purpose, then you could drop them altogether) - your production master would not be exposed to any unproven code - it would fit in more intuitively (to me) with source control, branches, etc. John -- 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/-/XGgPIjhbWKQJ. 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: Getting all variable occurrences from Hiera
Hi,
We already used stored configs but we can't use it for DHCP and DNS because
those records need to be created before the node actually syncs for the
first time, even before it's installed with an OS to begin with.
I hadn't thought of just separating that information into its own YAML
file, that's an interesting solution and one I'll definitely be looking
into to.
--
Daniele Sluijters
On Thursday, 16 August 2012 10:37:23 UTC+2, Daniele Sluijters wrote:
Hello,
We've been using Hiera for a while and one of the things I'd like to do is
use the data we have in the YAML backend and generate our BIND zonefiles
and DHCPD.conf from it.
Every node has a stanza defined with it's 'primary' IP-address and
MAC-address like so:
hostname.yaml:
---
m_interface:
- ip: 127.0.0.1
- mac_address: aa:bb:cc:dd:ee:ff
Based on that information and the YAML file it was found in (so the node
in our case) I'd like to generate a dhcpd.conf like this:
host hostname(.yaml) {
fixed-address: m_interface[ip]
hardware ethernet: m_interface[mac_address]
Now, this can be done for a single node, however, I need a way to get that
information for every node. As far as I understand both hiera_hash and
hiera_array only walk the hierarchy upwards, not outwards (which is usually
what you want anyway).
I'm looking for something like a hiera_all that would return a hash with
the node name as key and value the m_interface stanza for that node.
At this point I'm not even sure this can be done so, anyone got any bright
ideas?
Kind regards,
--
Daniele Sluijters
--
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/-/oujPthWMq6wJ.
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] hooking NewRelic into Puppet agent
Hello everyone,
I'm trying to hook NewRelic into the Puppet agent. Why? Because I'm pretty
positive at this point that the metrics Dashboard reports are not accurate
/ incomplete and I can't really split out those metrics in stuff like
'which commands take too long' or 'how long am I waiting on the network'
and so forth.
Now, I've been able to hook NewRelic into the Puppet agent by changing
/usr/bin/puppet to look like this:
#!/usr/bin/ruby1.8
require 'rubygems'
require 'newrelic_rpm'
require 'new_relic/agent/instrumentation/controller_instrumentation'
NewRelic::Agent.manual_start
include NewRelic::Agent::Instrumentation::ControllerInstrumentation
perform_action_with_newrelic_trace(:name = PuppetAgentRun:
#{`hostname`}, :category = :task) do
require 'puppet/util/command_line'
Puppet::Util::CommandLine.new.execute
end
This (and a newrelic.yml) gets me some basic information in NewRelic's
Background Tasks showing data like this:
Category Segment % Time Avg calls (per task call) Avg time (ms)
OtherTransaction Object/PuppetAgentRun: nl12s0020 50.2 1.0 28,540
External Net::HTTP[nl14s0008-vm5.healthcare.nedap.local]: POST 37.1 2.0
21,092
External Net::HTTP[nl14s0008-vm5.healthcare.nedap.local]: GET 8.8 190
5,003
External Net::HTTP[nl14s0008-vm5.healthcare.nedap.local]: PUT 3.8 2.0
2,160
External Net::HTTP[nl14s0008-vm5.healthcare.nedap.local]: HEAD 0.1 2.0
28.4
Though interesting it still doesn't tell me much so I want to do something
like this:
require 'puppet/configurer/downloader'
Puppet::Configurer::Downloader.class_eval do
include NewRelic::Agent::MethodTracer
add_method_tracer :evaluate
end
However, this is where it goes wrong. At that point, agents start
complaining:
/usr/lib/ruby/1.8/puppet/indirector.rb:6: uninitialized constant Puppet
(NameError)
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /usr/lib/ruby/1.8/puppet/ssl/host.rb:1
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /usr/lib/ruby/1.8/puppet/network/http_pool.rb:1
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /usr/lib/ruby/1.8/puppet/configurer.rb:4
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /usr/lib/ruby/1.8/puppet/configurer/downloader.rb:1
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /usr/bin/puppet:9
Now, one would think that a 'require puppet' would fix it but then
everything breaks with errors like this:
err: /Stage[main]/Ntp/File[/etc/ntp.conf]: Could not evaluate: Could not
retrieve information from environment production source(s)
puppet:///modules/ntp/ntp.conf at
/etc/puppet/environments/production/modules/ntp/manifests/init.pp:19
This goes on and on and causes failed runs, so we tried stuff like 'require
puppet/util' or 'require puppet/util/plugin' but eventually we always end
up with a error similar to:
uninitialized constant Puppet (NameError)
It would seem that Puppet code loads a lot of stuff itself instead of
letting Ruby handle it and at this point I'm at a loss. How do I hook into
Puppet classes and functions in a way that doesn't break the agent and
allows me / NewRelic to see what is going on?
Kind regards,
--
Daniele Sluijters
--
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/-/vTTpu6HJWngJ.
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: Announce: PuppetDB 0.9.2 Available
Hey, We just got hit with the same problem on Debian Squeeze: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze2) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) -- Daniele Sluijters -- 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/-/sI_eoEPcH_EJ. 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.
