R.I.Pienaar:
> here's a very simple one that loops an array and create 'notify'
> resources:
> define print { notify{"the message is: ${name}": } }
> print{["one", "two", "three"]: }
Strictly speaking, this isn't really "looping" on the array so much as
"mapping" on the array (there may be a more
vagn scott:
> I think one could make a case for getting rid of global variables
> entirely.
Functionally, this is common advice for avoiding the pitfalls of
puppet's peculiar dynamic scope. Newcomers are often advised to use
$::foo::bar::baz to avoid picking up data from unexpected places in the
vagn scott:
> Funny you should mention that. I have been playing around with
> separating the puppetmaster config from the agent config. See here:
>
> http://agawamtech.com/blog/?p=383
I solved this by having the puppetmasters all proxypass (they're running
in apache+passenger) their CA por
Nigel Kersten:
> On Sat, May 21, 2011 at 1:42 AM, Brice Figureau <
> brice-pup...@daysofwonder.com> wrote:
> > If you really want to simplify people's life, make those extra
> > attributes become metaparameters (but please keep the old syntax):
> >
> > user { luke: ensure => present, virtual => [bo
Nan Liu:
> On this subject, should we support regular expression?
> User <| title =~ /*adm/ |>
If you're going down this road, it's probably worthwhile to add the full
set of comparison operators such as <= and so forth.
--
"There should be a homonym exam before people are
issued keyboards."
Jordan Sissel:
> +1 to this. Any change here should also updae the export syntax as well.
>
> replace @@user { foo: ; }
> with export user { foo: ; }
Agreed!
> Any plans on making the realizing/importing queries changed as well?
>
> realize/query: User <| title == "foo" |>
> export query: User
jcbollinger:
> 1) The "include" statement expresses a requirement that the specified
> class be included in the resulting catalog, but it says nothing about
> the class's parameters.
>
> 2) If a class is named in at least one "include" statement that is
> executed while compiling a catalog, then t
Nigel Kersten:
> The file{} type can do all of the following:
>
> * manage single files
> * manage directories
> * manage symlinks
> * manage recursive file copies
I tend to use different defaults for the different types, so I would
love to be able to do:
File { mode => 0444 }
Di
Brian Gallew:
> A cons cell isn't actually that hard to produce in Puppet: you can use
> a hash. Each key is the member of the cell you want to keep, while
> the value is a throwaway.
Sure. I was actually talking about Nagios there, not Puppet.
> I'm not sure what you mean by deduplicating.
Martijn Grendelman:
> I'm afraid not.
This is distressing news.
I feel like there are two things conspiring to defeat me, here: one is
that nagios resource types like to enumerate *children* instead of
*parent* relationships. Having to maintain these static lists of
"members" is part of the cri
I've tried to achieve my overall goals with several different features
of Puppet, but I've hit a bit of a wall here. I think it's time for me
to explain what I'm trying to accomplish:
I want the enabling of a service in my manifests to configure
the monitoring of that service by a
I recently found myself needing to perform a similar task to that
desired by Udo Waechter in:
https://groups.google.com/group/puppet-users/browse_thread/thread/ea6a82d5e58fdb4e
Namely, I would like a file to exist on machine A iff any or all of
machines B-Z have some other resource.
My current
Markus Roberts:
> As a hack, I've occasionally done something like:
>
> diff --git a/lib/puppet/application/apply.rb
[...]
> -
> Puppet::Node::Environment.new(Puppet[:environment]).known_resource_types
> + print
> ZAML.dump(Puppet::Node::Environment.new(Puppet[:environment]).known_reso
Dan Bode:
> Hi Nick (long time :) )
Hi! Nearly a year, by now!
> It is possible to parse a given file and get an ASTArray back, is that
> sufficient? I am pretty sure you are going to have to get your hands
> into the Ruby code to really figure this out.
I suppose so, although I hope that's som
(sorry Sandor, I hit individual reply entirely by mistake earlier)
Sandor Szuecs:
> On Mar 1, 2011, at 12:14 PM, Nick Moffitt wrote:
> > Or is there already some easily-modifiable lint checker elsewhere?
>
> You probably want:
> puppet --parseonly
As of puppet 2.6.4 this
I mean to write a lint checker for my manifests, but I am not a ruby
developer to any degree of proficiency. What I think I would like is
some kind of serialization of the AST for a given .pp file, which I can
then import into my own Python code and analyze for undesirable
patterns.
Is there any
Nick Moffitt:
> http://pastebin.ubuntu.com/572759/
I should note that that's a rarified example. It really ought to pass
an ensure parameter down to those files!
--
Hey, how come nobody here in the future
has a time machine except me?
--
You received this message because
Daniel Hahler:
> http://daniel.hahler.de/puppet-definition-to-add-launchpad-ppa-repository
> gist: https://gist.github.com/844735
>
> This also supports APT keys via "apt::key".
To me, it's cleaner to ship files than to run programs. I tend to go
with something more like:
http://pastebi
Nick Moffitt:
> # :include:README.rdoc
> class readme {}
>
> I can then browse to __site__::readme in the rdoc HTML output, and see
> my long essay.
>
> > If it does, then I think adding this as the first line of
> > manifests/site.pp:
> >
Brice Figureau:
> I will check to see if :include: works correctly first.
I was just able to use it in front of a class:
# :include:README.rdoc
class readme {}
I can then browse to __site__::readme in the rdoc HTML output, and see
my long essay.
> If it does, then I think adding
Brice,
Thanks for your helpful answers.
Brice Figureau:
> > I saw someone say that it was good at finding "README" files, but:
> > ...was unable to find ./manifests/README or ./manifests/README.rdoc or
> > any other common combination. I tried using the :include: directive at
> > this p
I'm having a bit of trouble figuring out the best way to do my puppetdoc
stuff. I hope to have actual tutorial introductory "chapter" type
documentation as well as individual module documentation, but it seems
like all the examples I can find merely re-state the parameters that
puppetdoc already n
Martijn Grendelman:
> Would you be so kind to post the solution you cho(o)se in the end? I
> am interested in this too.. Thank you!
I'm afraid I chose a rather less glamorous solution to a very specific
problem. It suddenly occurred to me that for the majority of my needs
would be served by match
Nigel Kersten:
> On Wed, Feb 2, 2011 at 5:10 PM, Daniel Pittman wrote:
> > (Also, I went looking and found zero attempts to solve this in a
> > reusable, FOSS way, let alone working solutions.)
>
> Yep. I've been dreaming of a Puppet-integrated Password Safe for a while :)
Alas! I'm currently e
Roberto Bouza:
> Inline templates are a little bit dirty to do this, but they will
> work.
Yeah, it's totally a stopgap.
> A ruby file for mapping (all the CIDRs). and then a few libraries to
> use the ipaddr ruby lib and do calculations etc.
Yeah, my problem is that I'm not in a position where
Martijn Grendelman:
> Would you be so kind to post the solution you cho(o)se in the end? I am
> interested in this too.. Thank you!
At the moment I'm attempting something like a case statement that does
inline_template("<%= require 'ipaddr';
IPAddr.new('$thecidr').include?IPAddr.new('$theip') -%>
Mohamed Lrhazi:
> I guess my answer was: you can use ruby's library ipaddr inside
> templates, not sure about manifests.
That is an interesting approach, and suggests possible inline_template()
hacks. I note that of course Puppet itself can do CIDR tests in various
conf file settings, so clearly
I have a few settings that change based on the network that a system is
in, and I have a heterogeneous collection of networks (a few /24s, some
/25s, a /29 and a couple /27s, and hey look a /16 in rfc1918 space
and...). So I can't do simple regex matches on dotted-quad IP notation
and expect to ge
Al @ Lab42:
> You can build a file based on different "fragments" at least in 2 ways:
> - When you specify an array of templates , when using the content =>
> argument, these templates are actually appended in the defined order.
> - With the puppet-concat module by Rip
> https://github.com/ripiena
Thomas Bellman:
> Some init scripts support a 'condrestart' action, that will only
> restart the service if it is already running.
That is one behavior I was trying to avoid. I wanted a service to be
started or restarted iff it had been notified. Neutering the start and
stop commands did this
Nick Moffitt:
> Are you suggesting that I override the start command to a noop, and make
> sure the restart command works in that scenario? Thinking that over, it
> has potential. I suppose it would refrain from starting a crashed
> service, but it would pass the test in type/provid
Bill Proud:
> I would have thought that the simplest solution would be to not use a
> service at all but instead notify an exec from the file resource for
> the configuration. The exec could run a simple script that checks if
> the application is running and restarts it if it is.
The trouble with
Nigel Kersten:
> Can you use the "basic" service provider with fully-specified
> start/stop/restart commands to achieve what you need?
Are you suggesting that I override the start command to a noop, and make
sure the restart command works in that scenario? Thinking that over, it
has potential. I
Mark Stanislav:
> Fault tolerant infrastructure should be the point.
Absolutely, but the granularity of nagios and puppet (Every half hour?
Every ten minutes? Every five?) is simply too coarse to qualify as
fault-tolerance. Propping a broken service back on its feet at this
frequency is worse t
Mark Stanislav:
> I would recommend using Nagios event handlers for this if you want
> Nagios to essentially take the reigns of this problem. That way you
> will get your alerts and Nagios can react by starting the service
> again after x number of failures.
Actually, this is kind of the opposite
I'd like to know the best way to fix the refresh/restart behavior of
Service resources without using ensure => running.
I know that this is an unpopular requirement, but I do not want puppet
to restart dying services before my monitoring system notices. If a
service is fragile, I want to be woken
Let me start by saying that I am a fan of lexical scoping as a way of
increasing confidence in your execution models. I am hoping to move
from the now thoroughly debunked "wackyscope" model that used to plague
many programming languages over to proper lexical scoping in my puppet
configs. I'm jus
Nick Moffitt:
> # md5sum /home/foo/.ssh/authorized_keys; puppetd --environment=staging
> -t | grep 'checksum changed'; md5sum /home/foo/.ssh/authorized_keys
> fc9e4d3f84f99cff14a16dbe20f0db70 /home/foo/.ssh/authorized_keys
> notice:
> /Stage[main]/
Nick Moffitt:
> Further, grepping for a chunk of the options in this resource in the
> clientbucket finds hundreds of entries, and it would appear that all
> possible orderings are coming from the puppetmaster. I realize that
> technically there is a finite limit to the number of
I have found what I believe to be incorrect checksums in state.yaml, and
somewhat wasteful thrashing in the contents of exported
ssh_authorized_key resources (and possibly others).
My ultimate goal is to create a "stop the line" sort of system: if
someone has manually edited a puppet-managed file,
40 matches
Mail list logo
