Re: [Puppet Users] parse puppet yaml in java
On Fri, Apr 29, 2011 at 17:34, Peter Meier wrote: >> I am playing with snakeyaml and trying to use a custom class to parse >> yaml returned by puppet as mentioned in >> http://code.google.com/p/snakeyaml/wiki/Documentation#Custom_Class_Loader >> >> But I am not sure how to deal with "--- !ruby/object:Puppet::Run:" and >> "!ruby/sym report: !ruby/object:Puppet::Transaction::Report" >> >> These seem to be ruby specific. > > afair you should be able to just strip that off, before pass it to the > yaml reader. There have been some discussion about that on the list and > I think this was the solution. *nod* The two tags are: '!ruby/sym' which identifies a "symbol" in Ruby. Translating it as a string should be more than satisfactory for most practical purposes. The other identifies a specific Ruby object; you might want to model that as a Java object, or just treat it as a pool of data – whatever works for you. If you lost both those YAML type tags you really wouldn't loose much information. Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] parse puppet yaml in java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I am playing with snakeyaml and trying to use a custom class to parse > yaml returned by puppet as mentioned in > http://code.google.com/p/snakeyaml/wiki/Documentation#Custom_Class_Loader > > But I am not sure how to deal with "--- !ruby/object:Puppet::Run:" and > "!ruby/sym report: !ruby/object:Puppet::Transaction::Report" > > These seem to be ruby specific. afair you should be able to just strip that off, before pass it to the yaml reader. There have been some discussion about that on the list and I think this was the solution. ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk27WQAACgkQbwltcAfKi3+ImQCglHbndbFbCczd8FsDC2vS9Y8O LXYAoITcmr+RrGDxB+GVm5FTo7o7Ram4 =marw -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Is this a valid statement?
Thanks for the help.
I opted to used strings on the variables, which to me is not good!!!
(not a proper defined language)
I should be able to use the types true, false and should be able to
check for the nothing/nil/undef variable which I can't and I think is
bad.
Once again, thanks for your help.
On Apr 29, 6:14 am, Jan wrote:
> On 04/28/2011 10:01 PM Roberto Bouza wrote:
>
> > That is the problem. :-)
>
> > If its false/true I need to do stuff like
>
> > if $enabled != undef {
> > class { 'doit': enabled => $enabled } # This here will use true or
> > false to delete or add files for example
> > }
>
> > But if it's undef I don't even want to include the class.
>
> Maybe this way?
>
> $foo = "true"
>
> if $foo in [ "true", "false" ] {
> alert "foo!"
>
> }
>
> [12:41:25] $ puppet apply test.pp
> alert: Scope(Class[main]): foo!
>
> ;)
>
> signature.asc
> < 1KViewDownload
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Is this a bug?
Hello,
Going through the style sheet I was modifying some classes and I hit
this, maybe a bug maybe not:
--- test.pp ---
$mount = 'aebec:aebec'
$splitted = split($mount, ':')
# Intentionally getting a nil/empty/not there/ element from the array
#
$test = $splitted[4]
alert($test)
# This doesn't work
$no_dq = regsubst($test, 'e', ',', 'G')
alert($no_dq)
# This works but is not the style standard way of using a single
variable
$with_dq = regsubst("$test", 'e', ',', 'G')
alert($with_dq)
--- end test.pp ---
puppet apply test.pp
alert: Scope(Class[main]):
alert: Scope(Class[main]): e
alert: Scope(Class[main]):
Any help will be appreciated.
Thank you.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] scope of default values
On Fri, Apr 29, 2011 at 7:27 AM, Andreas Kuntzagk
wrote:
> Hi,
>
> I'm still quite new to puppet so forgive me if I ask stupid questions or use
> wrong terminology.
>
> I have default values for mount defined inside a class. Are these defaults
> only valid for mounts of this class or for all?
>
> class test {
>
> Mount {
> fstype => "nfs4",
> }
> mount{"test1":
> device => "server1:/test",
> }
> }
Resource defaults apply to all resource in the same scope, so Mount
defaults apply to all mount resource in the class test and not your
entire manifests. Be aware this will propagate to classes you include
in test so class a would be affected as well in the example below:
class test {
include a
Mount {...}
}
> Since I also have many nfsmounts and want to make sure that the mountpoint
> exist, I'd like to use require. Is there a way I can reference the name of
> the mountpoint in the require? Like so.
>
> mount {"test2":
> device => "server1:/test2",
> require => File[$name]
> }
If you have a file resource dependent on a Mount['test2'], the require
attribute should be in the file resource.
file { "/test2/"
ensure => directory,
require => Mount['test2'],
}
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Suggestions for using tags and variable for an Array
Hi,
Thanks for your help. I tried the stuff. It works. Learing somethng
new everday.
On 27 Apr., 19:22, Nan Liu wrote:
> On Wed, Apr 27, 2011 at 8:17 AM, linuxbsdfreak
> wrote:
> > Hi,
>
> > Thanks for your reply. The problem with the tagging is solved. However
> > i am confused with the 2nd part. I actually want to do somethng like
> > this to delete files:
>
> > I am creating a class called config_variables in which i want to have
> > an array of dirs of files to delete:
>
> > class config_variables {
>
> > $oldfilestoremove = [ "file1", "file2" ]
> > $path_to_data = "/tmp"
> > $path_to_data2 = "/opt"
>
> > }
>
> > Then i want to declare another class according to different
> > environments. However i would like to do some sort of if condition
> > with the path variable and change it according to different
> > environments using the tags. The purge-data is a general define i have
> > and has a delete function which uses the $name variable and the path
> > variable defined below as parameters:
>
> > class purge_old_data inherits config_variables {
>
> > purge-data::delete{
> > $oldfilestoremove
> > if tagged(tst_env) or if tagged(stg_env)
> > {
> > path => "$path_to_data",
> > }
> > if tagged(prd_env)
> > {
> > path => "$path_to_data2",
> > }
>
> > }
> > }
>
> You can't use an if statement within a resource declaration only
> selectors. So do the if conditional before you declare
> purge-data::delete custom resource.
>
> if ... {
> $my_path = $path_to_data} elsif ... {
>
> $my_path = $path_to_data2
>
> }
>
> purge-data::delete { $oldfilestoremove:
> path => $my_path,
>
> }
>
> Thanks,
>
> Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Force resigning of existing certificates
Yea, I'm new to puppet ... sounds like now I have to worry about certs eventually expiring and regenerate/sign them to keep nodes happy? Seems Trevor suggests increasing TTL. How can I do this if I wanted to? Thanks, Jake On Apr 28, 9:30 am, Matt Wise wrote: > Unfortunately, this is still a 'missing feature' of Puppet IMO. I applaud > Foreman for adding it as functionality though in their own code. For our > situation, we ended up writing our own CGI script on the Puppet CA servers as > well as a client-side script that runs periodically on the clients to verify > whether or not their cert is still valid. When their cert gets > close-to-expiring, it checks in with the CGI script and supplies the original > CSR that the host used for its first cert request to puppet. Our CGI script > then has permissions to run some openssl commands, and generates a whole new > cert for the client and passes it back. This all happens over SSL of course, > and is only allowed for clients that still have a valid certificate anyways. > Its not pretty, but its how we solved the problem... and its worked so far. > We have ~600 hosts and they each get a new cert every 25 days. > > Ideally there would be this functionality built into puppet... when a client > checked in, the server would check if the cert is within X days of expiring. > If it is, it would generate a new cert and pass it back to the client > automatically. Of course this would be an 'option', but it seems like an > obvious feature addition. > > I looked and could not find an actual bug report requesting this > functionality explicitly, so I opened one: > > http://projects.puppetlabs.com/issues/7272 > > On Apr 27, 2011, at 2:54 PM, Ohad Levy wrote: > > > > > > > > > > > On Thu, Apr 28, 2011 at 12:17 AM, Jake - USPS > > wrote: > > OK, just had to post this! I found a solution to my issues that may > > help others. > > >http://glarizza.posterous.com/managing-puppet-ssl-certificates > > > fyi - as the original author of that script... the same functionality > > exists within foreman. > > > Ohad > > > Basically a CGI script located on you CA Server. You can pass the > > hostname/certname that you want to clean via http to the script and > > have it clean it off the CA Server. More details in the link above. > > This is working great for me and I'll be using it until similar > > functionality is included by default in puppet. > > > Regards, > > Jake > > > On Apr 14, 8:50 am, Jake - USPS wrote: > > > Nevermind, looks like its in 2.7.0rc1 > > > >http://groups.google.com/group/puppet-users/browse_thread/thread/b3b5... > > > cb01221 (#3360) Add an allow_duplicate_certs option > > > > On Apr 14, 8:45 am,Jake-USPS wrote: > > > > > Thanks for the reply. I'm just starting to understand puppet, so I > > > > would like not to mess with that ... yet. It does look very > > > > interesting though, so thanks for bringing that up. > > > > > Derek, > > > > > Thanks for the bug. That looks like it includes some things that I > > > > would like ... like the allow duplicate cert and whatnot. It looks > > > > like its status closed as of 14 hours ago. Does that mean it is in > > > > some release of puppet now, or just that code it ready to eventually > > > > be implemented? I'd like to start trying it out right away as my > > > > 'solution' doesn't seem to work well with dashboard. > > > > > Thanks, > > > >Jake > > > > > On Apr 14, 8:41 am, Ohad Levy wrote: > > > > > > On Thu, Apr 14, 2011 at 4:31 > > > > > PM,Jake-USPSwrote: > > > > > > > Also, what is foreman and how could it help. Not familiar with that > > > > > > product. > > > > > > Foreman takes care for the entire process, things like provisioning, > > > > > class > > > > > assignments and reportings are all done though it (and many many other > > > > > features). > > > > > > see http://theforeman.orgformoredetails. > > > > > > Ohad > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/puppet-users?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.
Re: [Puppet Users] Re: run stages and mixed class styles
On 04/29/2011 12:29 PM, R.I.Pienaar wrote: > > Sounds like you want resource chaining[1] > > careful though this has an unfortunate side effect that it > will also realize all virtual packages with the provider apt > onto a node. > > point is you *can* tweak dependencies as a result of including > a class. Not exactly what I'm looking for, then. > [1] http://docs.puppetlabs.com/guides/language_guide.html#chaining-resources Anyway, thanks for the pointer. -- vagn If we had some ham, we could have eggs and ham, if we only had some eggs. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Adding multiple sudoer files to sudoers.d
On Fri, Apr 29, 2011 at 9:53 AM, takrishnan wrote:
> I would like add multiple sudoer files to the sudoers.d directory and
> would like someone to help.
>
> I'm thinking something like should work but it's no.
>
> init.pp
> -
> class sudoers {
> file:
> :
> :
> pkg:
> :
> :
> }
>
> class sudoers::$sudogroup {
> file {"$dirpath/$sudogroup":
> path => "$dirpath/$sudogroup",
> source => "puppet:///modules/sudoers/sudoers.d/
> $sudogroup",
> require => "File[/etc/sudoers.d]";
> }
> }
What you are looking for is a define resource instead of a class.
define sudoers::config {
file { "/path/to/sudoers.d/${name}:
source => "puppet:///modules/sudoers/sudoers.d/${name}",
}
}
The require File[/etc/sudoers.d] should not be necessary, since it's
an implied dependency (puppet knows it's a file under that directory,
and you can find all implied dependency using --graph). You can use
the define like it's any standard resource:
sudoers::config { "group1": }
sudoers::config { "group2": }
...
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Adding multiple sudoer files to sudoers.d
I would like add multiple sudoer files to the sudoers.d directory and
would like someone to help.
I'm thinking something like should work but it's no.
init.pp
-
class sudoers {
file:
:
:
pkg:
:
:
}
class sudoers::$sudogroup {
file {"$dirpath/$sudogroup":
path => "$dirpath/$sudogroup",
source => "puppet:///modules/sudoers/sudoers.d/
$sudogroup",
require => "File[/etc/sudoers.d]";
}
}
site.pp
-
node sudonode {
include sudoers::group1
include sudoers::groups2
:
:
}
Is this possible?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: run stages and mixed class styles
- Original Message -
> On 04/29/2011 10:53 AM, jcbollinger wrote:
> >
> > On the conceptual level, what does it or *should* it mean that a
> > node
> > has Class['proxy']? To you it seems to mean that the node
> > positively
> > uses an HTTP proxy, at least for Apt. But it could instead mean
> > that
> > the node's proxy configuration is managed, which might include
> > ensuring that it doesn't use a proxy.
> >
>
> This is an excellent starting point. Let's just focus
> on this assertion: "The proxy configuration is managed".
>
> And let us add that, if the proxy config is wrong, packages may
> not get installed on a node (for one puppet run anyway).
>
> The most likely downside is that a puppet run will partially fail
> because the proxy gets configured somewhere in the middle of the run.
> But, on the next run, things work ok, so not a showstopper.
>
> And, let's forget for the moment that there or non-puppet solutions.
>
> And, I will leave out any example implementation, so there is nothing
> to
> pick at there.
>
> But any solution in puppet should, as you point out, either establish
> or remove a proxy, depending on something. Maybe a choice of
> apt::proxy or apt::noproxy, or maybe some parameter or variable
> value.
>
> But by its nature the proxy config is something we would like to have
> happen first.
>
> Can this be expressed in puppet as a drop in? Can I design a module
> that manages the proxy, such that when I add that module to an
> existing
> design, I don't have to visit every module and add a require in order
> to control the order of things?
>
> It appears that I cannot.
Sounds like you want resource chaining[1], you can resource chaining to affect
the order of lots of other resources/classes.
So:
class aptproxy {
# set up the proxy
Class["aptproxy"] -> Package <| provider == apt |>
}
now if you include the proxy class it will adjust the
relationships on packages using apt else those packages
wont have the relationship at all.
careful though this has an unfortunate side effect that it
will also realize all virtual packages with the provider apt
onto a node.
point is you *can* tweak dependencies as a result of including
a class.
[1] http://docs.puppetlabs.com/guides/language_guide.html#chaining-resources
--
R.I.Pienaar
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: run stages and mixed class styles
On 04/29/2011 10:53 AM, jcbollinger wrote: > > On the conceptual level, what does it or *should* it mean that a node > has Class['proxy']? To you it seems to mean that the node positively > uses an HTTP proxy, at least for Apt. But it could instead mean that > the node's proxy configuration is managed, which might include > ensuring that it doesn't use a proxy. > This is an excellent starting point. Let's just focus on this assertion: "The proxy configuration is managed". And let us add that, if the proxy config is wrong, packages may not get installed on a node (for one puppet run anyway). The most likely downside is that a puppet run will partially fail because the proxy gets configured somewhere in the middle of the run. But, on the next run, things work ok, so not a showstopper. And, let's forget for the moment that there or non-puppet solutions. And, I will leave out any example implementation, so there is nothing to pick at there. But any solution in puppet should, as you point out, either establish or remove a proxy, depending on something. Maybe a choice of apt::proxy or apt::noproxy, or maybe some parameter or variable value. But by its nature the proxy config is something we would like to have happen first. Can this be expressed in puppet as a drop in? Can I design a module that manages the proxy, such that when I add that module to an existing design, I don't have to visit every module and add a require in order to control the order of things? It appears that I cannot. What changes to puppet would make it possible? 1. all classes are in stage[main] by default. Then the API for the proposed proxy module could require that - stage[proxy] be defined - stage[proxy] is put in sequence before any stages that allow packages to be installed and the implementation could have a helper class that does the actual configuration, with only the helper class declared as being in stage[proxy] Something similar could be done to solve the reboot problem. The API for the reboot module could require that - stage[reboot] be defined - stage[reboot] is last in sequence - modules would post a need to reboot with notify => Class[ "reboot" ] John, BTW thanks for your answers. They are very helpful. -- vagn -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Deploy puppet via NFS?
On 4/28/11 11:57 AM, Forrie wrote: Thanks for the feedback. It will make life a lot easier if I can deploy/maintain puppet via a RO NFS mount point. I presume you have the local stuff like /etc/ init.d/puppetmaster /etc/sysconfig/puppet /etc/puppet/puppet.conf managed separately and located on each system? Correct. I thought it might be interesting to have the configs on NFS, but I don't know if that would scale very well. I think this is possible, depending on the installation. Some Puppet customers have deploy Puppet world wide, cross continents, where the stateless nature of NFS would not provide a suitable solution. For smaller/geographically confined environments, a single source deployment/management method might be worth researching. Regards, Dominic Thanks! On Apr 26, 8:13 pm, Dominic Maraglia wrote: Hello, On 4/25/11 2:13 PM, Forrie wrote: How do you handle the *.rpm prerequisites of puppet itself. If one installs (deploys) puppet on an NFS mount, presumably you would also include enterprise-ruby (or standard) with those dependencies there. Enterprise Ruby seems to have rolled their own rpms, prefixed with "pe-". Actually, we (Puppet) do not package Enterprise Ruby; however, we do package Ruby 1.8.7 and do indeed name the rpm "pe-ruby". This is done to differentiate the Puppet "stack" Ruby from a possible pre-installed vendor Ruby. Puppet Enterprise's (pe) Ruby binary can be found here "/opt/puppet/bin/ruby" On 4/26/11 12:55 PM, Forrie wrote: I was referring to the RPMs that ship with Enterprise Puppet -- I haven't poked through the code, but if they get installed into the system, then that would pretty much negate (or make more difficult) creating an NFS-deployed Puppet for use. We have not specifically tested a single shared deployment as described by Mohamed (below). We do support and test installation, on all our supported operating systems, from a RO NFS mount point. Cheers, Dominic Maraglia Puppet Labs On Apr 25, 9:43 pm, Mohamed Lrhaziwrote: Sorry ignore my last statement... I did not use REE on Solaris, but used OpenCSW which packages all the software to go under /opt/csw, including ruby and puppet, and makes it straightforward to share the whole /opt/csw readonly over NFS I still think REE with facter and puppet in one directory should be work fine too. Thanks, Mohamed, -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: run stages and mixed class styles
On Apr 28, 2:07 pm, vagn scott wrote:
> On 04/28/2011 09:54 AM, jcbollinger wrote:
> >
> > You have to do some sort of provisioning to get Puppet working in the
> > first place, so option (1) wouldn't really be so bad.
> >
>
> There is no question that it could be done in provisioning.
>
> My question is really: How do stages work?
> Can I use stages to, as in this example, set up
> a proxy that should be in place before
> any other classes are expressed?
Run stages leverage Puppet's existing dependency system, to which the
"require" and "before" resource metaparameters and other features are
also hooked. A run stage essentially creates a node in the dependency
graph such that all classes assigned to that stage have a "before"
relationship with that stage and a "require" relationship with all
previous stages.
You can achieve exactly the same effect without run stages, but it can
be messy.
> > Absolutely the wrong direction (says me). To the extent possible --
> > and that's a very large extent -- use only *un*parameterized classes.
> > I don't see any particular reason to expect that using only
> > parameterized classes would help here, anyway.
> >
>
> Oh good. But, to rephrase the question, can I control the
> stage an unparameterized class gets expressed in? Or, is
> it guaranteed that unparameterized classes are expressed in
> stage[main]? Because if not, it is useless to have
> parameterized classes that want to run before stage[main].
You can use the class { "foo": ... } syntax with unparameterized
classes to assign them to stages (or simply as an alternative to
"include"), but only once each. I do not recommend also "include" ing
the same classes elsewhere in the manifest, which otherwise you could
do with an unparameterized class.
> > First, consider why you (think you) need class Proxy to be
> > parameterized.
>
> Because, according to the docs I've seen, only parameterized
> classes run in stages other than stage[main]. Please clarify
> if I'm mistaken.
You are mistaken. You must use the class {"foo": } syntax to assign a
class to a run stage, but that class does not need to be
parameterized.
> > From where does the parameter value come? If it's
> > really fixed for all nodes, as in your example, then it would be
> > better to make it an ordinary variable of class Proxy, or even to
> > inline it. Perhaps you could switch to using source=> instead of
> > content=>; then you could change the proxy host at need without
> > modifying any manifests.
>
> Don't get sidetracked by the details of the example.
> My question is about expressing sequence dependencies in puppet.
> The proxy is a real-life example of something that should be done first,
> never mind that there are other ways to do it.
My point is not so much to quibble the details, but to assert that
parameterized classes in general are not everything that they are
cracked up to be. I like run stages better than parameterized
classes, to the extent that they are separable, but I don't think
those are the first tool anyone should reach for to deal with resource
ordering issues. That's why I am suggesting alternatives.
> > Then recognize that run stages are purely a convenience feature,
> > providing nothing that you cannot get by using Puppet's dependency
> > system more directly. For instance, you could consider doing this at
> > top level:
> >
> > Package { require => Class['proxy'] }
>
> But I really don't want to require it.
> I want to express that IF a node has Class['proxy'],
> then proxy needs to go first.
That strikes me as a possible conceptualization problem, and,
separately, a possible design problem:
On the conceptual level, what does it or *should* it mean that a node
has Class['proxy']? To you it seems to mean that the node positively
uses an HTTP proxy, at least for Apt. But it could instead mean that
the node's proxy configuration is managed, which might include
ensuring that it doesn't use a proxy.
And that's where the design problem comes in: what do you do if a node
configured with a proxy ever needs to be reconfigured for direct
connection? Simply excluding Class['proxy'] from that node's manifest
doesn't do the job: you must actively manage the config file absent.
You could do that by including a different class instead, but it's
smoother to give Class['proxy'] enough brains to know whether to
configure the node with a proxy or without. If you do that then you
can include it on every node, and you probably would want to do so.
> > Any package that does not specify its own require parameter
> > will then be applied after class proxy.
>
> This breaks modularity, orthogonality and encapsulation.
Any resource that affects the application of resources in different
scopes does this -- for an oh-so-random example, a resource that
affects how the system's package provider operates. Problems without
those characteristics are poor candidates for run stages in the first
[Puppet Users] scope of default values
Hi,
I'm still quite new to puppet so forgive me if I ask stupid questions or use
wrong terminology.
I have default values for mount defined inside a class. Are these defaults only
valid for mounts of this class or for all?
class test {
Mount {
fstype => "nfs4",
}
mount{"test1":
device => "server1:/test",
}
}
Since I also have many nfsmounts and want to make sure that the mountpoint
exist, I'd like to use require. Is there a way I can reference the name of the
mountpoint in the require? Like so.
mount {"test2":
device => "server1:/test2",
require => File[$name]
}
regards, Andreas
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Is this a valid statement?
On 04/28/2011 10:01 PM Roberto Bouza wrote:
> That is the problem. :-)
>
> If its false/true I need to do stuff like
>
> if $enabled != undef {
> class { 'doit': enabled => $enabled } # This here will use true or
> false to delete or add files for example
> }
>
> But if it's undef I don't even want to include the class.
Maybe this way?
$foo = "true"
if $foo in [ "true", "false" ] {
alert "foo!"
}
[12:41:25] $ puppet apply test.pp
alert: Scope(Class[main]): foo!
;)
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Automating Nagios with Puppet
Hi,
beware of this if you change default file locations:
"You can purge Nagios resources using the resources type, but only in
the default file locations. This is an architectural limitation"
on Debian I prefer to link /etc/nagios3/conf.d to /etc/nagios
greetings,
Lluís
El dt 26 de 04 de 2011 a les 12:44 +0200, en/na Cedric Jeanneret va
escriure:
> Hello again,
>
> Yes, of course you can change the directory.
>
> Check out the mentioned module, we put all the nagios stuff in /etc/nagios.d
> directory, keeping clean a /etc/nagios3 directory. For what I've seen, it
> seems to do exactly what you're trying to do.
>
> For the basic:
> nagios accept different directories for its configuration, you have to add
> them in your nagios.cfg file using the cfg_dir directive. This can be done
> using either a simple file, a template or with augeas (not sure for the
> latest point).
>
> Cheers,
>
> C.
>
> On Tue, 26 Apr 2011 11:48:32 +0200
> Juan-Francisco Diez wrote:
>
> > OK, thenks for your help. I solved the trouble using the $hostname fact in
> > front of services definitions.
> >
> > But I have another question about this:
> >
> > Is it possible to define the directory where the file are created in the
> > nagios server?
> >
> > Now the files are stored in the /etc/nagios.
> >
> >
> > 2011/4/26 Cedric Jeanneret
> >
> > > Hello,
> > >
> > > Maybe have a look at our nagios module:
> > > https://github.com/camptocamp/puppet-nagios
> > >
> > > Your problem is that resources with same name are exported from multiple
> > > hosts, and that make puppet crash with duplicated definition (as it's
> > > exported resources, the error message is different ;) ).
> > > You should name your nagios resources with the fqdn embedded so that it
> > > will be really unique across the DB.
> > >
> > > Cheers,
> > >
> > > C.
> > >
> > > On Tue, 26 Apr 2011 01:29:03 -0700 (PDT)
> > > Fransua33 wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I'm trying to automate the nagios configuration of new host through
> > > > Puppet. For this I define a nagios module with the generic
> > > > configuration of my Nagios host definition. The module look like
> > > > this:
> > > >
> > > > class nagios {
> > > > $packagelist=["nagios"]
> > > >
> > > > package { $packagelist:
> > > > ensure => "installed"
> > > > }
> > > >
> > > > $servicelist=["nagios", "httpd"]
> > > >
> > > > service { $servicelist:
> > > > ensure => "running",
> > > > hasstatus => "true",
> > > > hasrestart => "true"
> > > > }
> > > >
> > > > # collect resources and populate /etc/nagios/nagios_*.cfg
> > > > Nagios_host <<| |>>
> > > > Nagios_service <<| |>>
> > > > Nagios_hostextinfo <<| |>>
> > > >
> > > > class target {
> > > > @@nagios_host { $fqdn:
> > > > ensure => "present",
> > > > use =>
> > > "ingacceso_$operatingsystem-server",
> > > > alias => $hostname,
> > > > address => $ipaddress,
> > > > contacts=>
> > > "farconada,henry,fsariego,jfdiez"
> > > > }
> > > >
> > > > @@nagios_hostextinfo { $fqdn:
> > > > ensure => "present",
> > > > icon_image_alt => $operatingsystem,
> > > > icon_image => "$operatingsystem.png"
> > > > }
> > > >
> > > > @@nagios_service { "Host - Carga CPU":
> > > > use => "ingacceso_generic-service",
> > > > host_name => "$fqdn",
> > > > check_command => "check_nrpe!check_load"
> > > > }
> > > >
> > > > @@nagios_service { "Host - CPU":
> > > > use => "ingacceso_generic-
> > > > service",
> > > > host_name => "$fqdn",
> > > > check_command => "check_nrpe!check_cpu"
> > > > }
> > > >
> > > > @@nagios_service { "Host - Ping":
> > > > use => "ingacceso_generic-
> > > > service",
> > > > host_name => "$fqdn",
> > > > check_command => "check_ping!400.0,20%!
> > > > 900.0,60%"
> > > > }
> > > >
> > > > @@nagios_service { "Host - /":
> > > > use => "ingacceso_generic-
> > > > service",
> > > > host_name => "$fqdn",
> > > > check_command => "check_nrpe!check_raiz"
> > > > }
> > > >
> > > > @@nagios_service { "Host - /boot":
> > > > use => "ingacceso_generic-
> > > > service",
> > > >
Re: [Puppet Users] matching nodes with ReExp
On Fri, Apr 29, 2011 at 04:20:58AM -0700, Sans wrote:
> node /^farm0\d+$/ inherits workernode {
>
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find node 'farm029.example.com' on node
> farm029.example.com
That regex is saying, match farm0 at the start of a string and then only
match digits until the end of the string.
So it matches to farm029 and then stops in failure as its found
characters. If all your hosts are in the same domain just removing the $
(end of string matcher) should work.
/^farm0\d+/
Otherwise /^farm0\d+.example.com$/ will also work, and be more precise.
Dean
--
Dean Wilson
http://www.unixdaemon.net @unixdaemon
http://www.puppetcookbook.com @puppetcookbook
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] matching nodes with ReExp
Dear all,
According to the Puppet doc, I used this:
node /^farm0\d+$/ inherits workernode {
}
in the node.pp to match any host like farm001.example.com but I get
error on the client nodes:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find node 'farm029.example.com' on node
farm029.example.com
warning: Not using cache on failed catalog
Any idea what's I'm doing wrong? FYI, if I remove the "example.com"
part and use only "/^farm0\d+/" it works. Much appreciated your help.
Cheers!!!
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Automating Nagios with Puppet
Hi Gabriel, I overlooked the "nagios::target" class. Thanks for pointing that out. Cheers!! On Apr 28, 5:14 pm, Gabriel Filion wrote: > Hello, > > Judging from the manifests that the OP sent, the HTTP server is run on > the nagios server, not on each node: the "nagios" class is included only > on the node 'nagiosserver', while the class "nagios::target" is included > everywhere. > > It is possible to run a Nagios server without a web server, but you > won't be able to access its web interface. > > -- > Gabriel Filion -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Automating Nagios with Puppet
Hi Gabriel, I overlooked the "nagios::target" class. Thanks for pointing that out. Cheers!! On Apr 28, 5:14 pm, Gabriel Filion wrote: > Hello, > > Judging from the manifests that the OP sent, the HTTP server is run on > the nagios server, not on each node: the "nagios" class is included only > on the node 'nagiosserver', while the class "nagios::target" is included > everywhere. > > It is possible to run a Nagios server without a web server, but you > won't be able to access its web interface. > > -- > Gabriel Filion -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users]
http://klute-it.de/images/ate.php -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
