Re: [Puppet Users] Validating a puppet configuration
On 1 August 2011 15:47, Nikolay Sturm goo...@erisiandiscord.de wrote: * Lars Kellogg-Stedman [2011-07-29]: I am trying to place some sanity checks (currently as git pre-commit hooks) in our configuration repository to avoid committing invalid Puppet configurations. This is exactly the use case for cucumber-puppet. It compiles your Does anyone do this on a large scale? I have 140 manifests managing over 1600 resources. Writing cucumber for all that seems quite burdensome John -- 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: add ip address of another EC2 instance automatically in the hosts file of existing EC2 instance
You can indeed use Exported resources. See the first example in this documentation: http://docs.puppetlabs.com/guides/exported_resources.html The example shows how to have every host export its SSH public key, and then collect every host’s key and install it in the ssh_known_hosts file (which is what the sshkey type does); this would include the host doing the exporting. You should be able to do the same sort of thing with each host's IP address, and collect them in the hosts file. On Jul 30, 1:57 am, newguy aimanparv...@gmail.com wrote: HI guys I have a Ubuntu EC2 puppetmaster, 3 types of clients connect to this master; client A, B ,C . I want to add the ip address of client B in a module M of client A. Lets assume that I don't know their ip addresses before hand. Is that possible through puppet??? and if yes how? Thanks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Custom fact question
The Fact will get downloaded ahead of the manifest being compiled. You just need to add a require = Service[myservice] to the config file. John -- 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: Puppet 2.7.1, variable scoping, best practices
Hi,
I am bringing back a topic that I started a month ago. Summer holidays
prevented me from following up on it back then, but they didn't make the
problem go away, unfortunately ;-)
Having installed Puppet 2.7.1 on my testserver yesterday, I am now bugged
by log messages, that tell me not to use dynamic variable lookups:
Jun 29 13:31:09 os1 puppet-master[31910]: Dynamic lookup of
$ssh_permitrootlogin at /etc/puppet/templates/etc/ssh/sshd_config.erb:28
is deprecated. Support will be removed in Puppet 2.8. Use a
fully-qualified variable name (e.g., $classname::variable) or
parameterized classes.
Now, I have been reading up on variable scoping and trying to figure out
how to rewrite my manifests to embrace best practices, but I am confused
on how to proceed, and I can't really find any working examples, so I turn
here for help.
My current setup is something like this:
node basenode {
$somevar = defaultvalue
$someothervar = anotherdefault
}
[...]
In any class or module I use $somevar and $someothervar as I please, and I
understand that this a) is not a recommended practice and b) will stop
working in Puppet 2.8.
So, what should I do?
It's not actually clear to me whether top level includes inside node
declarations, but IMHO it should. If it does, and if you do not rely
on defining different values for $somevar or $someothervar inside your
classes (see below), then you should be able to solve your problem by
changing all appearance of $somevar and $someothervar to $::somevar
and $::someothervar (i.e. use their fully-qualified names as the
warning suggests). It should be pretty easy to test whether that
works for you.
In classes that have been defined in the top scope (imported in site.pp),
I can use the fully qualified names ($::somevar). That results in the
correct value, and it doesn't generate any warnings about dynamic scoping.
However, inside modules, this doesn't work. I get empty values when I try
that. For example:
In nodes.pp:
node basenode {
$syslocation = Server room
}
node testserver inherits basenode {
$syslocation = Martijn's office
}
In modules/snmp/manifests/init.pp:
notify { System location: $syslocation: }
notify { System location qualified: $::syslocation: }
results in:
notice: System location qualified:
notice: /Stage[main]/Snmp/Notify[System location qualified: ]/message:
defined 'message' as 'System location qualified: '
notice: System location: Martijn's office
notice: /Stage[main]/Snmp/Notify[System location: Martijn's
office]/message: defined 'message' as 'System location: Martijn's office'
The 'dynamic' name works (but gives a warning), the fully-qualified name
doesn't work. The use of curly braces ${::syslocation} doesn't make any
difference.
Switching to parameterized classes sounds nice, but that would mean that
the 'generic' class would have to get /every/ variable I use as a
parameter and pass it on to subsequent classes where needed. That sounds
incredibly clumsy to me.
As regulars here will know, I am not a big fan of parameterized
classes. Puppetlabs likes them, and pushes them, but I think they are
rarely the best tool for the job. Perhaps the thing that they are
most appropriate for, however, is avoiding dynamic scoping. More on
that below.
You are right that for your manifest design, solving the problem via
class parameterization would require your Class[generic] to be
parameterized with all the variables it uses directly plus all those
needed by the classes it includes. I think this is one reason that
Puppetlabs' style guide now recommends avoiding classes including
other classes. Once your manifests become complex enough that that is
painful, they suggest using an external node classifier. If you don't
buy in to parameterized classes, however, then that advice does not
stand up so well.
Inhttp://docs.puppetlabs.com/guides/scope_and_puppet.htmlI read:
If you re using dynamic scope to share resource defaults, there s no
way around it: you ll have to repeat yourself in each file that the
defaults apply to.
Is this what's biting me here? Well, this sounds like something I can live
with, after all: it's not the default values I care about, it's the
overriding values.
Forgive me for being didactic:
In Puppet 2.8.0, variables declared outside any class can be
overridden by declarations of the same variable name within classes.
Within a class that does so and any class it includes, recursively,
the variable's unqualified name resolves to the class's definition,
not the top-level one. Except that this nests, so that if an included
class also defines a variable having the same simple name, then it and
its included classes see *its* definition. This is called dynamic
scoping.
Dynamic scoping presents at least two problems:
1) When a class refers to externally defined variables by their simple
names, it is hard to know
[Puppet Users] Re: Custom fact question
On Jul 29, 7:55 am, Oliver Beattie oli...@obeattie.com wrote: Hi, I need to use the output of a script to set the value of a variable. I understand the only way to do this is to use a custom Facter fact. However, this script will only run when (naturally) it's been installed, which is something Puppet takes care of. Conf files, which I would very much like to be able to install as part of the same run depend on the variable being set. So, it seems I have myself a lovely little chicken and egg problem — any ideas? If you only need the script for this purpose then instead of writing a custom fact that reports the output of your script, convert your script into the custom fact. You have the full power of Ruby at your disposal. If that's sufficient then it's cleaner in multiple ways. It sounds like that may not be enough for you, however. If there are reasons other than script installation why you want the fact value to be computed somewhere in the middle of the run, then you have two options that I can see: 1) Accept that (at least) two Puppet runs will sometimes be required to move a client into its intended state. 2) Move the needed code from your existing script to one of the affected Package's install scripts. Naturally, this requires rolling a custom version of that package. John -- 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: Custom fact question
On Jul 29, 11:17 am, Paul Morgan jumanji...@gmail.com wrote: On Jul 29, 2011 9:25 AM, Oliver Beattie oli...@obeattie.com wrote: I need it to run at a specified point during the manifest though. The value of the fact depends on a package being installed. And my config files depend on the value of the fact Will stages (pre, main, etc) help in this case? No. Run stages are a mechanism for establishing resource relationships, and they do not induce additional fact computations. No matter how many stages are defined, the facts for a given run are always determined exactly once, after pluginsync (if that's enabled) but before everything else. John -- 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: Master failover and cert names.
HI Doug, I am also facing the same issue after following the steps from the book. I tried with nginx and passenger and i mentioned it on the following post. http://groups.google.com/group/puppet-users/browse_thread/thread/44bc89455ccc311a# Regards, Kevin Douglas Garstang wrote: Well, this is frustrating. Let's say I have two puppet masters, where one is active, and the other is a hot stand by. Obviously each is going to have a different FQDN. Everything will work fine when the client talks to the server that signed it's certificate. However, after a failover to the secondary master, it's all going to fail because the FQDN of the master will not match. I've been searching around, reading the mailing list, and am surprised to find very little information on this. The new Pro Puppet book skims over this detail. You'd think they'd have some proof it before selling it. Douglas Did you read the chapter carefully? The Front End Load Balancer Configuration section explains this pretty clearly. Several times. Starts on page 99. Can't find any reference to it. Also, I'd like to point out, that the book talks initially about setting up a separate primary and secondary CA, but after mentioning that these should go on a separate server, only details how to do it on the puppet master. Putting the CA function on a different server is not a trivial thing and I spent a few hours yesterday reading between the lines, trying to work out how to put in on a separate server, and finally gave up about 1am this morning. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] prep for 2.8: scopes and variables: nodes are not classes
prep for 2.8: scopes and variables: nodes are not classes
I have been preparing for 2.8 by
experimenting with 2.7.X and seeing
what it takes to get rid of the
warnings. I would like to share my
results in a number of upcoming posts.
Begin with the simple question of
hard-wiring scopes. the 'shocking'
revelation is that variables defined
in nodes are no longer visible outside
the node. So, if you rely on that for
configuration, you should rewrite the
node as a class, and then include that
class in a trivial node. You can then
get at the variables by explicitly
mentioning the scope of the class.
This post doesn't talk about default
values, inheritance, or specialization.
I will talk about that later.
Attached are three scripts
01_config.pp
old style
defines variables in nodes
relies on dynamic scope
02_config.pp
broken
failed attempt to qualify variables
nodes are not classes
nodes cannot be named as a scope
03_config.pp
fixed, new style
all variables defined in classes
nodes as containers for classes
no variables defined in nodes
Of course it is still possible
to define resources and variables
in nodes. But the variables will
not be visible in any class scope and
cannot be used to implicitly configure
classes.
Comments and corrections welcome.
--vagn
results of running the three scripts:
vagn@nika:~/puppet-nika/patterns$ ./01_config.pp
notice: Scope(Class[main]): puppet version: 2.7.2
notice: Scope(Class[Legacy]): var1_global is global
warning: Dynamic lookup of $var2_base_node at
/u0/home/vagn/puppet-nika/patterns/01_config.pp:21 is deprecated.
Support will be removed in Puppet 2.8. Use a fully-qualified variable
name (e.g., $classname::variable) or parameterized classes.
notice: Scope(Class[Legacy]): var2 defined in base node
warning: Dynamic lookup of $var3_node at
/u0/home/vagn/puppet-nika/patterns/01_config.pp:22 is deprecated.
Support will be removed in Puppet 2.8. Use a fully-qualified variable
name (e.g., $classname::variable) or parameterized classes.
notice: Scope(Class[Legacy]): var3 defined in default (aka host) node
notice: Finished catalog run in 0.15 seconds
vagn@nika:~/puppet-nika/patterns$ ./02_config.pp
notice: Scope(Class[main]): puppet version: 2.7.2
notice: Scope(Class[Legacy]): var1_global is global
warning: Scope(Class[Legacy]): Could not look up qualified variable
'base::var2_base_node'; class base could not be found at
/u0/home/vagn/puppet-nika/patterns/02_config.pp:21
notice: Scope(Class[Legacy]):
warning: Scope(Class[Legacy]): Could not look up qualified variable
'default::var3_node'; class default could not be found at
/u0/home/vagn/puppet-nika/patterns/02_config.pp:22
notice: Scope(Class[Legacy]):
notice: Finished catalog run in 0.15 seconds
vagn@nika:~/puppet-nika/patterns$ ./03_config.pp
notice: Scope(Class[main]): puppet version: 2.7.2
notice: Scope(Class[Foo]): var1_global is global
notice: Scope(Class[Foo]): var2 defined in base node
notice: Scope(Class[Foo]): var3 defined in default (aka host) node
notice: Finished catalog run in 0.15 seconds
vagn@nika:~/puppet-nika/patterns$
--
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.
#! /usr/bin/puppet apply
$version = inline_template(%= `puppet --version` %)
notice(puppet version: ${version})
$var1_global = var1_global is global
node base {
$var2_base_node = var2 defined in base node
}
node default inherits base {
$var3_node = var3 defined in default (aka host) node
include legacy
}
class legacy {
notice(${::var1_global})
notice(${var2_base_node}) # warn
notice(${var3_node}) # warn
}
#! /usr/bin/puppet apply
$version = inline_template(%= `puppet --version` %)
notice(puppet version: ${version})
$var1_global = var1_global is global
node base {
$var2_base_node = var2 defined in base node
}
node default inherits base {
$var3_node = var3 defined in default (aka host) node
include legacy
}
class legacy {
notice(${::var1_global})
notice(${base::var2_base_node}) # fail
notice(${default::var3_node}) # fail
}
# both failures above are because nodes cannot be
# named as a class scope
#! /usr/bin/puppet apply
$version = inline_template(%= `puppet --version` %)
notice(puppet version: ${version})
$var1_global = var1_global is global
class base {
$var2_base_node = var2 defined in base node
}
class default_class inherits base {
$var3_node = var3 defined in default (aka host) node
include foo
}
class foo {
notice(${::var1_global})
Re: [Puppet Users] Re: Master failover and cert names.
On Mon, Aug 1, 2011 at 8:03 AM, linuxbsdfreak linuxbsdfr...@gmail.comwrote: HI Doug, I am also facing the same issue after following the steps from the book. I tried with nginx and passenger and i mentioned it on the following post. http://groups.google.com/group/puppet-users/browse_thread/thread/44bc89455ccc311a# Regards, Kevin Thanks for the reply Kevin. Good to know I'm not the only one. Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Temporary requirements
Hi, I'm quite new to Puppet.. I'm wondering if someone could point me in the right direction regarding the best way to manage a temporary requirement within Puppet? The scenario is, every server in our estate of Debian machines requires some monitoring software which is not provided as a Debian package. So we have a Puppet class, monitor::install which we include to distribute the src code and do an unattended configure, make make install. Obviously this requires the make gcc packages. But, as standard, we do not want these packages to be installed any of the machines during normal operation once the install has taken place. How do people generally manage such transient requirements? -- 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: 2.6 and modules: Invalid resource type
Seeing exactly the same, nearly the same setup (using $environment instead of hardcoding production/development, trying to use my own extension). Running puppet 2.6.9 on CentOS 5.6 (both master and agent). I did not see any issue about this yet, but since I'm just starting with puppet it might very well be me. Any clues? -- 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/-/-VokCYsf8o4J. 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] are storeconfigs supposed to work with rails3?
Hi, I'm trying to use stored configs with puppet 2.7.1 But I get the following error once puppet agent connects to the master: err: !!! Outdated mysql gem. Upgrade to 2.8.1 or later. In your Gemfile: gem 'mysql', '2.8.1'. Or use gem 'mysql2' This seems to be activerecord (3.0.9) check - BUT I've both mysql (2.8.1) mysql2 (0.3.6) installed - using ruby 1.8.7 Might be this since I'm using too recent rails version? - I've installed rails (3.0.9) with all the dependencies. Is puppetstoreconfigs supposed to work ok with rails3 or I should use rails2 only? Thanks Alex -- 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] Facter 1.6.0 and CentOS 6.0
We just started testing CentOS 6.0 here, and I'm using Facter 1.6.0 If I run this command from my CentOS 5.x test machine: [root@puppetclient.nj1:~]# facter --version 1.6.0 [root@puppetclient.nj1:~]# facter | grep lsb lsbdistcodename = Final lsbdistdescription = CentOS release 5.3 (Final) lsbdistid = CentOS lsbdistrelease = 5.3 lsbmajdistrelease = 5 lsbrelease = :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch I get reasonable results. But if I do that from my CentOS 6.0 test machine: [root@cos6test.nj1:~]# facter --version 1.6.0 [root@cos6test.nj1:~]# facter | grep lsb [root@cos6test.nj1:~]# I get remarkably less kosher results. Is this a known issue? Is there any work-around? It's really breaking my CentOS 6 servers' ability to find their REPOs. :-) Cheers, D -- 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] running shell command including parenthesis for custom fact
Hi,
I'm trying to retrieve a configuration value from a local file in a
custom fact. I'm having some problems with this though. I hope,
someone can point me to the right direction.
My configuration file looks something like this:
cat /tmp/example.properties
my.application.wsdl.url=http://myserver.mydomain.de:8080/path/to/
application?wsdl
My custom fact would have a line like this:
myserver=%x{cat /tmp/example.properties| sed -n s|
my.application.*http://\(.*\):.*|\1|p }.chomp
Unfortunatley this doesn't work. The custom fact returns an undefined
variable. It seems to me, that the cause is a combination of the use
of parenthesis and/or backslashes and the %x operator, because
irb(main):001:0 s = system 'cat /tmp/example.properties | sed -n s|
my.application.*http://\(.*\):.*|\1|p'
myserver.mydomain.de
= true
is working.
irb(main):006:0 s = %x[ cat /tmp/example.properties | sed -n s|
application|\1|p ]
= my.\001.wsdl.url=http://myserver.mydomain.de:8080/path/to/
application?wsdl\n
is working (at least I get a result).
irb(main):004:0 s = %x[ cat /tmp/example.properties | sed -n s|
my.application.*http://\(.*\):.*|\1|p ]
=
is not working
I tried removing and doubling the backslashes to no avail.
Does someone have an idea, what I'm doing wrong or what other approach
would be possible?
Thanks in advance, Daniela
--
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] Facter 1.6.0 and CentOS 6.0
On 30/07/11 05:26, Derek J. Balling wrote: We just started testing CentOS 6.0 here, and I'm using Facter 1.6.0 If I run this command from my CentOS 5.x test machine: [root@puppetclient.nj1:~]# facter --version 1.6.0 [root@puppetclient.nj1:~]# facter | grep lsb lsbdistcodename = Final lsbdistdescription = CentOS release 5.3 (Final) lsbdistid = CentOS lsbdistrelease = 5.3 lsbmajdistrelease = 5 lsbrelease = :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch I get reasonable results. But if I do that from my CentOS 6.0 test machine: [root@cos6test.nj1:~]# facter --version 1.6.0 [root@cos6test.nj1:~]# facter | grep lsb [root@cos6test.nj1:~]# I get remarkably less kosher results. Is this a known issue? Is there any work-around? It's really breaking my CentOS 6 servers' ability to find their REPOs. :-) You need to have the lsb_release command installed for the lsb* results to appear. Fedora/Redhat have it in the redhat-lsb package, so it possibly has a similar name under CentOS. HTH, Dan -- 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] Facter 1.6.0 and CentOS 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is this a known issue? Is there any work-around? It's really breaking my CentOS 6 servers' ability to find their REPOs. :-) You need to have the lsb_release command installed for the lsb* results to appear. Fedora/Redhat have it in the redhat-lsb package, so it possibly has a similar name under CentOS. yes, this is the missing package. It has the same name on centos. ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk42z70ACgkQbwltcAfKi3/TxQCfcaJFWkiyBKhpAWQ6grnIUkJ4 fBUAn2ZiusnYKuM5F51UscOg2e6WrTgf =xBYh -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.
Re: [Puppet Users] Temporary requirements
On 08/01/2011 06:40 AM, David wrote: The scenario is, every server in our estate of Debian machines requires some monitoring software which is not provided as a Debian package. You should make your own debian package(s) for the monitoring software instead of installing from source on every machine. -- 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] Facter 1.6.0 and CentOS 6.0
Is the redhat-lsb package installed? IIRC it provides the necessary info for the lsb facts. On Aug 1, 2011 8:27 AM, Derek J. Balling dr...@megacity.org wrote: We just started testing CentOS 6.0 here, and I'm using Facter 1.6.0 If I run this command from my CentOS 5.x test machine: [root@puppetclient.nj1:~]# facter --version 1.6.0 [root@puppetclient.nj1:~]# facter | grep lsb lsbdistcodename = Final lsbdistdescription = CentOS release 5.3 (Final) lsbdistid = CentOS lsbdistrelease = 5.3 lsbmajdistrelease = 5 lsbrelease = :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch I get reasonable results. But if I do that from my CentOS 6.0 test machine: [root@cos6test.nj1:~]# facter --version 1.6.0 [root@cos6test.nj1:~]# facter | grep lsb [root@cos6test.nj1:~]# I get remarkably less kosher results. Is this a known issue? Is there any work-around? It's really breaking my CentOS 6 servers' ability to find their REPOs. :-) Cheers, D -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Facter 1.6.0 and CentOS 6.0
Peter Meier wrote :
Is this a known issue? Is there any work-around? It's really breaking my
CentOS 6 servers' ability to find their REPOs. :-)
You need to have the lsb_release command installed for the lsb* results
to appear.
Fedora/Redhat have it in the redhat-lsb package, so it possibly has a
similar name under CentOS.
yes, this is the missing package. It has the same name on centos.
The minimal install option doesn't install the redhat-lsb package. I
personally prefer it that way, since it pulls in a bunch of useless
stuff (in my case, required to be LSB compliant), but it does make
it a bit more tricky to detect your OS release.
Workaround are simple enough, things like :
if $::operatingsystem == RedHat and $::operatingsystemrelease 6
And also selectors like these (note that $operatingsystemrelease
includes the minor version such as '5.7' or '6.1') :
$foo = $::operatingsystemrelease ? {
/^5/ = $rhel5,
/^6/ = $thel6,
}
Of course you can also do this, still without relying on redhat-lsb :
$foo = ${::operatingsystem}${::operatingsystemrelease} ? {
/^RedHat5/ = $rhel5,
/^RedHat6/ = $thel6,
}
You will need to update that regexp before RHEL 50 ;-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 14 (Laughlin) - Linux kernel 2.6.35.13-91.fc14.x86_64
Load : 0.49 0.45 0.42
--
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: Not getting errors/warnings/etc in reports
On Thu, Jul 21, 2011 at 7:37 AM, Peter Meier peter.me...@immerda.ch wrote:
I'm still not getting my error() messages in the report yaml ... why?
Probably, because functions are evaluated on the master, while the
report is created on the client when the catalog is applied. So these
messages never get sent down the client...
~pete
Ah, yes, that makes sense I guess. Puppet.error() calls within the
resources executed on the clients get added to the client report, but
Puppet.error() calls executed during compile time don't because they
executed on the server.
For now I've done:
define report::err($withpath=false) {
notify { $name:
tag = 'err',
withpath = $withpath,
loglevel = 'err',
}
}
It's a little annoying because it causes the creation of this resource
to also be logged with loglevel = err, along with the message. But I
think I can live with that.
--
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] Managing sudo via puppet using #includedir
Is anyone having success with #includedir option in sudo? I have a module that uses a definition to create files in /etc/sudoers.d/ which is referenced in the main suders file as #includedir /etc/sudoers, but these entries are not getting referenced when sudo is used. I'm running CentOS 5 and 6, which which sudo-1.7.2p1 and sudo-1.7.2p2 respectively. Here's a weird symptom the problem I'm having... # visudo -c -f /etc/sudoers.d/zabbix-puppet /etc/sudoers.d/zabbix-puppet: syntax error near line 0 parse error in /etc/sudoers.d/zabbix-puppet near line 0 (((NOTE: I made absolutely no changes , just did :q))) # visudo -f /etc/sudoers.d/zabbix-puppet /etc/sudoers.d/zabbix-puppet: syntax error near line 0 # visudo -c -f /etc/sudoers.d/zabbix-puppet /etc/sudoers.d/zabbix-puppet: parsed OK This is my sudoers file... ## Sudoers allows particular users to run various commands as ## the root user, without needing the root password. ## ## Examples are provided at the bottom of the file for collections ## of related commands, which can then be delegated out to particular ## users or groups. ## ## This file must be edited with the 'visudo' command. ## Host Aliases ## Groups of machines. You may prefer to use hostnames (perhaps using ## wildcards for entire domains) or IP addresses instead. # Host_Alias FILESERVERS = fs1, fs2 # Host_Alias MAILSERVERS = smtp, smtp2 ## User Aliases ## These aren't often necessary, as you can use regular groups ## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname ## rather than USERALIAS # User_Alias ADMINS = jsmith, mikem ## Command Aliases ## These are groups of related commands... ## Networking # Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, / sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/ wvdial, /sbin/iwconfig, /sbin/mii-tool ## Installation and management of software # Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum ## Services # Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig ## Updating the locate database # Cmnd_Alias LOCATE = /usr/bin/updatedb ## Storage # Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/ partprobe, /bin/mount, /bin/umount ## Delegating permissions # Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, / bin/chgrp ## Processes # Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/ killall ## Drivers # Cmnd_Alias DRIVERS = /sbin/modprobe # Defaults specification # # Disable ssh hostname sudo cmd, because it will show the password in clear. # You have to run ssh -t hostname sudo cmd. # ## Defaultsrequiretty # # Preserving HOME has security implications since many programs # use it when searching for configuration files. # Defaultsalways_set_home Defaultsenv_reset Defaultsenv_keep = COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS Defaultsenv_keep += MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE Defaultsenv_keep += LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES Defaultsenv_keep += LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE Defaultsenv_keep += LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY # # Adding HOME to env_keep may enable a user to run unrestricted # commands via sudo. # # Defaults env_keep += HOME # Defaultssecure_path = /sbin:/bin:/usr/sbin:/usr/bin ## Next comes the main part: which users can run what software on ## which machines (the sudoers file can be shared between multiple ## systems). ## Syntax: ## ## userMACHINE=COMMANDS ## ## The COMMANDS section may have other options added to it. ## ## Allow root to run any commands anywhere rootALL=(ALL) ALL ## Allows members of the 'sys' group to run networking, software, ## service management apps and more. # %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS ## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL ## Same thing without a password # %wheelALL=(ALL) NOPASSWD: ALL ## Allows members of the users group to mount and unmount the ## cdrom as root # %users ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom ## Allows members of the users group to shutdown this system # %users localhost=/sbin/shutdown -h now #includedir /etc/sudoers.d And this is the /etc/sudoers.d/zabbix-puppet zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/start_puppet What's so strange is if I take that exact line, and put it in /etc/ sudoers , it works just fine. So I know the syntax and such is correct, however it doesn't get called via #includedir. Thanks - Trey -- 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
Re: [Puppet Users] Temporary requirements
Yup. This is totally the right way to do that.
If you don't want to, I would suggest that you compile once, tar up
the content, and just untar it on the machine.
If you really, really want to go through installing the compiler,
building, then removing it, you can: write your script to use apt to
install the packages, build, and then uninstall again. Maybe specify
'package { gcc: ensure = absent }' so that puppet enforces.
...but, um, this really doesn't add that much security to your system.
Sending a binary, or a portable language tool, is not that hard for
an attacker.
daniel
On Mon, Aug 1, 2011 at 09:17, vagn scott vagnsc...@gmail.com wrote:
On 08/01/2011 06:40 AM, David wrote:
The scenario is, every server in our estate of Debian machines
requires some monitoring software which is not provided as a Debian
package.
You should make your own debian package(s) for the monitoring software
instead of installing from source on every machine.
--
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 Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Class inheritance or virtual resources to manage apache modules
I want to start out with an apache class that will disable all modules
except for a pre-defined list, thus establishing a baseline of active
modules.
Then as needed, other classes could enable a module that they require
that would have been disabled by the baseline state.
Its possible several classes may try to enable the same module (1 or
more classes needing module1 could be on a single node)
What is the 'right' way to do this? I've played with virtual
resources and class inheritance.
I hope to avoid class inheritance if possible as virtual resources
seems to be the correct way to do this kind of thing.
I however have had troubles with doing that and have ultimately ended
up with the following using inheritance:
class apache2::modules {
# list apache modules to enable
$enable_apachemods = [ module1, module2, module3, ]
# list apache modules to disable, basically all modules would be
listed here by default
$disable_apachemods = [ module4, module5, module6, ]
# Process list of apache modules to enable
a2mod { $enable_apachemods: ensure = present, notify =
Exec[apache2reload] }
# Process list of apache modules to disable
a2mod { $disable_apachemods: ensure = absent, notify =
Exec[apache2reload] }
}
Then as I have other classes defined that require a specific apache
module they should simply set it to 'present'.
class application1 {
include apache2::modules::app1
...
}
class apache2::modules::app1 inherits apache2::modules {
A2mod['module4'] { ensure = 'present', require =
Package['modulepackage'] }
}
class application2 {
include apache2::modules::app2
...
}
class apache2::modules::app2 inherits apache2::modules {
A2mod['module4'] { ensure = 'present', require =
Package['modulepackage'] }
}
I get the following error when I do it this way:
Error 400 on SERVER: Parameter 'ensure' is already set on
A2mod[module4]... cannot redefine at
--
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] Temporary requirements
Take a look at Jordan Sissel's FPM software if you want a cheap way of
making a deb.
Ken.
On Aug 1, 2011 7:10 PM, Daniel Pittman dan...@puppetlabs.com wrote:
Yup. This is totally the right way to do that.
If you don't want to, I would suggest that you compile once, tar up
the content, and just untar it on the machine.
If you really, really want to go through installing the compiler,
building, then removing it, you can: write your script to use apt to
install the packages, build, and then uninstall again. Maybe specify
'package { gcc: ensure = absent }' so that puppet enforces.
...but, um, this really doesn't add that much security to your system.
Sending a binary, or a portable language tool, is not that hard for
an attacker.
daniel
On Mon, Aug 1, 2011 at 09:17, vagn scott vagnsc...@gmail.com wrote:
On 08/01/2011 06:40 AM, David wrote:
The scenario is, every server in our estate of Debian machines
requires some monitoring software which is not provided as a Debian
package.
You should make your own debian package(s) for the monitoring software
instead of installing from source on every machine.
--
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 Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] certificate authority chaining and verification
Hello all, I've recently installed a puppet PKI as detailed in the Multiple Certificate Authorities document. However, when I try to list the signed certificates using puppet cert list --all, I get the following output: - bnjpuppet02.mydomain.com (57:51:05:FF:03:5A:C2:4D:3B:E2:BF:CF:18:B3:C8:4C) (unable to get issuer certificate) I assume that this is because the CA cert that I am using is in fact signed by another CA, and the cert for that is not available to the above command. Now when, I replace $ssldir/ca/ca_crt.pem with a full certificate chain, starting with my machine's local CA, then the above error goes away, and I get a different error message: - bnjpuppet02.mydomain.com (57:51:05:FF:03:5A:C2:4D:3B:E2:BF:CF:18:B3:C8:4C) (unable to get certificate CRL) My first question is what do I need to do to make this second error go away. I have already tried playing with the certificate_revocation flag to no effect. Also, I'm assuming that this will impact the ability of puppet to verify my clients. Or is that a function of setting up the CA chain at the authentication end point? (I'm using mongrel with an apache proxy.) I am using puppet 2.7.1. Thanks very much in advance. John Guthrie jguth...@book.com This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please contact the sender immediately and take the steps necessary to delete the message completely from your computer system. Not Intended as a Substitute for a Writing: Notwithstanding the Uniform Electronic Transaction Act or any other law of similar effect, absent an express statement to the contrary, this e-mail message, its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind this sender, barnesandnoble.com llc, barnesandnoble.com inc. or any other person or entity. -- 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] Managing sudo via puppet using #includedir
It's working here for RHEL 5 6. Check the owner and perms of sudoers.d, that's probably not your problem, but it's the only one we've had. -- 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 puppet agent --server a valid command?
It is not listed in the command details on this page? http://docs.puppetlabs.com/man/agent.html But it is cited as an example of a valid puppet agent command at the very bottom of the page. Kinda confusing. -- 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] Help with troubleshooting error: invalid option: --server
Hi there. Can somebody help me diagnose an error? On the Puppet Master node, we've started the Puppet Master with: ubuntu@domU-12-31-39-09-x-x:~$ sudo puppet master Then from a node where we want to apply updates, I ran: ubuntu@ip-10-72-x-x:~$ sudo puppet agent --server domU-12-31-39-x-x- x.compute-1.internal --waitforcert 60 --test info: Creating a new SSL key for ip-10-72-x-x.ec2.internal warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for ip-10-72-x- x.ec2.internal info: Certificate Request fingerprint (md5): 68:E4:58:EB:B9:57:15:E5:00:8B:5E:25:39:FC:80:6D warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session notice: Did not receive certificate warning: peer certificate won't be verified in this SSL session info: Caching certificate for ip-10-72-x-x.ec2.internal /usr/lib/ruby/1.8/rdoc/dot/dot.rb:28: warning: already initialized constant NODE_OPTS /usr/lib/ruby/1.8/rdoc/dot/dot.rb:46: warning: already initialized constant EDGE_OPTS /usr/lib/ruby/1.8/rdoc/dot/dot.rb:76: warning: already initialized constant GRAPH_OPTS puppet: invalid option: --server err: Could not retrieve catalog from remote server: hostname was not match with the server certificate warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run Why are we getting the invalid option: --server error. Is my syntax wrong? Also, note that on the Puppet Master, I had to run this command to get it to sign the certificate: sudo puppet cert --sign `sudo puppet cert --list` Any thoughts? -- 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] Is puppet agent --server a valid command?
On Mon, Aug 1, 2011 at 1:50 PM, Blueplastic sam...@blueplastic.com wrote: It is not listed in the command details on this page? http://docs.puppetlabs.com/man/agent.html But it is cited as an example of a valid puppet agent command at the very bottom of the page. Kinda confusing. -- 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. If you do a `puppet agent --help` from the command line, you'll see something that looks like this: *OPTIONS* *===* *Note that any configuration parameter that's valid in the configuration* *file is also a valid long argument. For example, 'server' is a valid* *configuration parameter, so you can specify '--server servername' as* *an argument.* Any puppet.conf configuration parameter can be specified from the command line as an argument. So, --server servername would be the syntax here. -Gary -- 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] Multi site best practices
I'm currently using Puppet (2.7.1) to manage a single site. I'm in the process of bringing up a second data center which of course will be managed by Puppet. The number of managed sites will grow to at least 7 in the near future. How is everyone else handling multiple sites within puppet? Here's what I'm thinking of doing: * Puppet master per site * Central Dashboard instance * Central CA Suggestions? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Temporary requirements
Thanks for the replies.
I did start off down the route of distributing binaries but was having
problems getting them to run on the different architectures involved
and ended up with multiple packages - and every time I needed to tweak
the build config I was having to rebuild multiple times.
It was so much easier to build on each machine... I perceived the
issue of removing gcc make afterwards as being an easier problem to
solve. I thought there may be a way to do it without having to drop
down to scripting - but then again - the whole configure/make process
is just a set of scripts so no difference I guess.
Thanks again for the replies.
On Aug 1, 7:09 pm, Daniel Pittman dan...@puppetlabs.com wrote:
Yup. This is totally the right way to do that.
If you don't want to, I would suggest that you compile once, tar up
the content, and just untar it on the machine.
If you really, really want to go through installing the compiler,
building, then removing it, you can: write your script to use apt to
install the packages, build, and then uninstall again. Maybe specify
'package { gcc: ensure = absent }' so that puppet enforces.
...but, um, this really doesn't add that much security to your system.
Sending a binary, or a portable language tool, is not that hard for
an attacker.
daniel
On Mon, Aug 1, 2011 at 09:17, vagn scott vagnsc...@gmail.com wrote:
On 08/01/2011 06:40 AM, David wrote:
The scenario is, every server in our estate of Debian machines
requires some monitoring software which is not provided as a Debian
package.
You should make your own debian package(s) for the monitoring software
instead of installing from source on every machine.
--
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 Labs Developer –http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices
On Aug 1, 6:37 am, Martijn Grendelman mart...@iphion.nl wrote:
[...]
In classes that have been defined in the top scope (imported in site.pp),
I can use the fully qualified names ($::somevar). That results in the
correct value, and it doesn't generate any warnings about dynamic scoping.
However, inside modules, this doesn't work. I get empty values when I try
that. For example:
In nodes.pp:
node basenode {
$syslocation = Server room
}
node testserver inherits basenode {
$syslocation = Martijn's office
}
In modules/snmp/manifests/init.pp:
notify { System location: $syslocation: }
notify { System location qualified: $::syslocation: }
results in:
notice: System location qualified:
notice: /Stage[main]/Snmp/Notify[System location qualified: ]/message:
defined 'message' as 'System location qualified: '
notice: System location: Martijn's office
notice: /Stage[main]/Snmp/Notify[System location: Martijn's
office]/message: defined 'message' as 'System location: Martijn's office'
The 'dynamic' name works (but gives a warning), the fully-qualified name
doesn't work. The use of curly braces ${::syslocation} doesn't make any
difference.
Well that's something I didn't know before, but it appears to mesh
well with Vagn's recent observations about preparing for Puppet 2.8:
http://groups.google.com/group/puppet-users/browse_thread/thread/6f1e087a6daba343
[I wrote:]
3) There is another built-in alternative to dynamically-scoped
variables: the extlookup() function. Using extlookup() to retrieve
data for your resources can allow you to minimize the number of
parameters you need to pass, or even to avoid class parameterization
altogether. I think this is a great way to go, but Puppetlabs's style
guide disfavors it.
The big question here is: would that be future-proof??
Considering that Puppet supports user-defined functions, and that
extlookup() even started out as such, I think it's reasonably safe to
expect that you could continue to use extlookup() at least into the
mid-term future. Even if Puppetlabs were to yank extlookup() back out
of the standard distribution, you could put it back in as a custom
function at your site. The source is available and freely reusable,
of course.
Extlookup() has the added advantage for you that its data model maps
very cleanly onto the node taxonomy you described (global defaults,
internal / external, specific node). From that angle, at least, it
should be straightforward to convert your existing manifest design to
use extlookup().
John
--
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: Managing sudo via puppet using #includedir
From the sudoer docs it mentioned making the files in /etc/sudoers.d be 440, but what about the folder? Here's the perms on /etc/sudoers.d drwxr-xr-x 2 root root 4096 Jul 26 19:16 . drwxr-xr-x. 64 root root 4096 Jul 26 19:16 .. -r--r- 1 root root 53 Jul 26 19:16 zabbix-puppet - Trey On Aug 1, 3:47 pm, Len Rugen lenru...@gmail.com wrote: It's working here for RHEL 5 6. Check the owner and perms of sudoers.d, that's probably not your problem, but it's the only one we've had. -- 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: Managing sudo via puppet using #includedir
These are the perms we're using for that functionality: dr-xr-x--- 2 root root 4096 Jul 7 18:09 /etc/sudoers.d -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Mon, Aug 1, 2011 at 2:49 PM, treydock treyd...@gmail.com wrote: From the sudoer docs it mentioned making the files in /etc/sudoers.d be 440, but what about the folder? Here's the perms on /etc/sudoers.d drwxr-xr-x 2 root root 4096 Jul 26 19:16 . drwxr-xr-x. 64 root root 4096 Jul 26 19:16 .. -r--r- 1 root root 53 Jul 26 19:16 zabbix-puppet - Trey On Aug 1, 3:47 pm, Len Rugen lenru...@gmail.com wrote: It's working here for RHEL 5 6. Check the owner and perms of sudoers.d, that's probably not your problem, but it's the only one we've had. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Managing sudo via puppet using #includedir
On 08/01/2011 01:41 PM, treydock wrote: #includedir /etc/sudoers.d Maybe without the quotation marks? -- 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.
[Puppet Users] Re: Is puppet agent --server a valid command?
Cool, thanks for the clarification Gary. On Aug 1, 2:02 pm, Gary Larizza ccsh...@gmail.com wrote: On Mon, Aug 1, 2011 at 1:50 PM, Blueplastic sam...@blueplastic.com wrote: It is not listed in the command details on this page? http://docs.puppetlabs.com/man/agent.html But it is cited as an example of a valid puppet agent command at the very bottom of the page. Kinda confusing. -- 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. If you do a `puppet agent --help` from the command line, you'll see something that looks like this: *OPTIONS* *===* *Note that any configuration parameter that's valid in the configuration* *file is also a valid long argument. For example, 'server' is a valid* *configuration parameter, so you can specify '--server servername' as* *an argument.* Any puppet.conf configuration parameter can be specified from the command line as an argument. So, --server servername would be the syntax here. -Gary -- 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: Help with troubleshooting error: invalid option: --server
Just wanted to say this turned out to be an Amazon problem. The Amazon EC2 console showed the private DNS for the PuppetMaster node to be X. But SSHing into server X and running 'hostname' to get the name showed Y. There was a mismatch between what Amazon console thought the DNS was and what the server itself thought it was. Reboot of PuppetMaster did not fix this. We just launched a new PuppetMaster node and the issue fixed itself. On Aug 1, 12:50 pm, Blueplastic sam...@blueplastic.com wrote: Hi there. Can somebody help me diagnose an error? On the Puppet Master node, we've started the Puppet Master with: ubuntu@domU-12-31-39-09-x-x:~$ sudo puppet master Then from a node where we want to apply updates, I ran: ubuntu@ip-10-72-x-x:~$ sudo puppet agent --server domU-12-31-39-x-x- x.compute-1.internal --waitforcert 60 --test info: Creating a new SSL key for ip-10-72-x-x.ec2.internal warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for ip-10-72-x- x.ec2.internal info: Certificate Request fingerprint (md5): 68:E4:58:EB:B9:57:15:E5:00:8B:5E:25:39:FC:80:6D warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session notice: Did not receive certificate warning: peer certificate won't be verified in this SSL session info: Caching certificate for ip-10-72-x-x.ec2.internal /usr/lib/ruby/1.8/rdoc/dot/dot.rb:28: warning: already initialized constant NODE_OPTS /usr/lib/ruby/1.8/rdoc/dot/dot.rb:46: warning: already initialized constant EDGE_OPTS /usr/lib/ruby/1.8/rdoc/dot/dot.rb:76: warning: already initialized constant GRAPH_OPTS puppet: invalid option: --server err: Could not retrieve catalog from remote server: hostname was not match with the server certificate warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run Why are we getting the invalid option: --server error. Is my syntax wrong? Also, note that on the Puppet Master, I had to run this command to get it to sign the certificate: sudo puppet cert --sign `sudo puppet cert --list` Any thoughts? -- 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: Managing sudo via puppet using #includedir
Ok , so this was actually two problems...
The first , can't have quotes around the folder location in
#includedir...
Second is the way I was populating those files...
Here's the sudo module definition...
define sudo::directive (
$ensure=present,
$content=,
$source=
) {
# sudo skipping file names that contain a .
$dname = regsubst($name, '\.', '-', 'G')
file {/etc/sudoers.d/${dname}:
ensure = $ensure,
owner = root,
group = root,
mode= 0440,
content = $content ? {
= undef,
default = $content,
},
source = $source ? {
= undef,
default = $source,
},
require = Package[sudo],
}
}
The content method doesn't work, or at least not in the way I've
implemented it...
So this doesn't work...
sudo::directive { zabbix-puppet:
ensure = present,
content = zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/
start_puppet,
#source = puppet:///files/zabbix_sudocmd,
}
And this works...
sudo::directive { zabbix-puppet:
ensure = present,
#content = zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/
start_puppet,
source = puppet:///files/zabbix_sudocmd,
}
The file zabbix_sudocmd contains the same text as the Content
line, however it seems to not add a necessary new line character, as
this is the debug output from puppet when I change from source to
content...
debug: /Stage[main]/Role_zabbix_client/Sudo::Directive[zabbix-puppet]/
File[/etc/sudoers.d/zabbix-puppet]/content: Executing 'diff -u /etc/
sudoers.d/zabbix-puppet /tmp/puppet-file20110801-18801-1wfv1td-0'
--- /etc/sudoers.d/zabbix-puppet2011-08-01 18:45:16.248138294 -0500
+++ /tmp/puppet-file20110801-18801-1wfv1td-02011-08-01
18:53:53.566133754 -0500
@@ -1 +1 @@
-zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/start_puppet
+zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/start_puppet
\ No newline at end of file
debug: file_bucket_file supports formats: b64_zlib_yaml marshal pson
raw yaml; using yaml
info: /Stage[main]/Role_zabbix_client/Sudo::Directive[zabbix-puppet]/
File[/etc/sudoers.d/zabbix-puppet]: Filebucketed /etc/sudoers.d/zabbix-
puppet to main with sum 2ecb3670db9e458970153bf00d64b325
notice: /Stage[main]/Role_zabbix_client/Sudo::Directive[zabbix-puppet]/
File[/etc/sudoers.d/zabbix-puppet]/content: content changed '{md5}
2ecb3670db9e458970153bf00d64b325' to '{md5}
348da8bc5d9eacaf6334b092d95001eb'
Notice the No newline at end of file...
I can use content if I add a \n to the end of the line, which
doesn't seem like it should be necessary, but it works.
Thanks!!
- Trey
On Aug 1, 6:35 pm, vagn scott vagnsc...@gmail.com wrote:
On 08/01/2011 01:41 PM, treydock wrote:
#includedir /etc/sudoers.d
Maybe without the quotation marks?
--
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] Multi site best practices
On 08/01/2011 05:04 PM, Jared Curtis wrote: * Central Dashboard instance * Central CA Would it be a problem if your central CA and dashboard became unavailable? -v -- 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: Puppet 2.7.1, variable scoping, best practices
I recommend taking a look at R I Pienaar's alternative extlookup
implementation. It supports YAML in addition to csv which allows for the
full range of available variable types to be pulled in from external
sources. I've combined this with a YAML-based ENC to put all variables for
a single node into one YAML file. It's working well for me.
On Aug 1, 2011 2:20 PM, jcbollinger john.bollin...@stjude.org wrote:
On Aug 1, 6:37 am, Martijn Grendelman mart...@iphion.nl wrote:
[...]
In classes that have been defined in the top scope (imported in site.pp),
I can use the fully qualified names ($::somevar). That results in the
correct value, and it doesn't generate any warnings about dynamic
scoping.
However, inside modules, this doesn't work. I get empty values when I try
that. For example:
In nodes.pp:
node basenode {
$syslocation = Server room
}
node testserver inherits basenode {
$syslocation = Martijn's office
}
In modules/snmp/manifests/init.pp:
notify { System location: $syslocation: }
notify { System location qualified: $::syslocation: }
results in:
notice: System location qualified:
notice: /Stage[main]/Snmp/Notify[System location qualified: ]/message:
defined 'message' as 'System location qualified: '
notice: System location: Martijn's office
notice: /Stage[main]/Snmp/Notify[System location: Martijn's
office]/message: defined 'message' as 'System location: Martijn's office'
The 'dynamic' name works (but gives a warning), the fully-qualified name
doesn't work. The use of curly braces ${::syslocation} doesn't make any
difference.
Well that's something I didn't know before, but it appears to mesh
well with Vagn's recent observations about preparing for Puppet 2.8:
http://groups.google.com/group/puppet-users/browse_thread/thread/6f1e087a6daba343
[I wrote:]
3) There is another built-in alternative to dynamically-scoped
variables: the extlookup() function. Using extlookup() to retrieve
data for your resources can allow you to minimize the number of
parameters you need to pass, or even to avoid class parameterization
altogether. I think this is a great way to go, but Puppetlabs's style
guide disfavors it.
The big question here is: would that be future-proof??
Considering that Puppet supports user-defined functions, and that
extlookup() even started out as such, I think it's reasonably safe to
expect that you could continue to use extlookup() at least into the
mid-term future. Even if Puppetlabs were to yank extlookup() back out
of the standard distribution, you could put it back in as a custom
function at your site. The source is available and freely reusable,
of course.
Extlookup() has the added advantage for you that its data model maps
very cleanly onto the node taxonomy you described (global defaults,
internal / external, specific node). From that angle, at least, it
should be straightforward to convert your existing manifest design to
use extlookup().
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
