[Puppet Users] Using puppet cert generate on a client -- why doesn't this work?
I'm running a two headed puppetmaster and have disabled crl's. Let's
call them the primary and the secondary. The primary and secondary
both use the primary as their master. The secondary only is used when
the primary isn't responding (I wrap the puppetd call in cron with a
short shell script)
I'm managing these ca files on the masters, pushing them with puppet itself...
$ grep file\ { certs.pp
file { /var/lib/puppet/ssl/ca/ca_crt.pem:
file { /var/lib/puppet/ssl/ca/ca_key.pem:
file { /var/lib/puppet/ssl/ca/private/ca.pass:
file { /var/lib/puppet/ssl/certs/ca.pem:
file { /var/lib/puppet/ssl/ca/ca_crl.pem: (ensures absent, we
don't need them in our environment.)
Then, in order to generate the ssl certs for the webservice, I generate this:
# If this isn't working, try puppet cert clean $::fqdn first
exec {/usr/bin/puppet cert --generate --certdnsnames $aliases $::fqdn:
creates = [/var/lib/puppet/ssl/certs/${::fqdn}.pem,
/var/lib/puppet/ssl/private_keys/${::fqdn}.pem,
/var/lib/puppet/ssl/public_keys/${::fqdn}.pem,
/var/lib/puppet/ssl/ca/signed/${::fqdn}.pem,
],
user= root,
notify = Service['httpd'],
}
I create these manually so I can pass the --certdnsnames $aliases for
the puppetmaster DNS cname.
This seems to work fine for the primary. But when the secondary tries
to run against the primary, it fails with
err: /File[/var/lib/puppet/lib]: Failed to generate additional
resources using 'eval_generate: certificate verify failed
err: /File[/var/lib/puppet/lib]: Could not evaluate: certificate
verify failed Could not retrieve file metadata for
puppet://primary/plugins: certificate verify failed
I would think that the certs would be good because I generate them
with the exact same CA's as the primary. If I remove the certs and go
through a normal signing process, it works. It is only when I use
puppet cert --generate on the secondary do the certs fail.
I'm almost considering running puppet cert --generate with --ssldir to
point it someplace else to generate certs with cnames ONLY for the web
server (apache), and then have another set of certs in the normal
place generated for client/master signing.
But it is bothering me that I don't understand what is going on. How
does signing work?
My impression is that the client connects to the SSL port on the
master, verifies that the SSL keys are good (validates against
/var/lib/puppet/ssl/certs/ca.pem for authenticity and verifies it has
the right hostname signed (or aliased)).
What happens next? Does the client present a cert also signed by the
CA to prove it is allowed to perform queries?
What's the cleanest way around this?
--
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] Software inventory
On Wed, Sep 21, 2011 at 9:45 AM, Glenn Bailey replic...@dallaslamers.org wrote: Howdy, Before I go about writing one myself, anyone out there written a software inventory module/fact for gathering a list of all installed rpms/debs on a system? Got a few ideas floating around in my head, but wanted to see if/what other folks have done .. We've written some custom facts that return a JSON string and then we wrote a custom function that uses PSON.parse() to process and return the native data. Since puppet supports arrays and dictionaries, this works well. One problem is if you have any Nones/Nulls in your JSON, PSON.parse() doesn't handle them right. Once bubbled up to puppet, they don't come out as undef.. they come out as some strange type that puppet doesn't recognize as false yet has no value. So we post process the PSON.parse() and clean out the Ruby nil's and just make them . -- 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: scoping question - I want a node specific global var
On Tue, Aug 16, 2011 at 4:46 PM, Scott Smith sc...@ohlol.net wrote: Some times doing things the right way requires going through the pain of changing your current practices for the better. Sometimes your schedule doesn't allow you to refactor that much right now. -- 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: scoping question - I want a node specific global var
On Wed, Aug 17, 2011 at 6:44 AM, jcbollinger john.bollin...@stjude.org wrote:
* We're not using ENC
Fair enough. I don't use one either, but it was worth pointing out
the possibility.
Yes, and it is an additional argument to migrate there eventually.
* I want the special information right alongside the node decl. This
reduces chance for error and makes the data more maintainable.
So that's the constraint that is really biting you, in more ways than
one, and I feel obligated to observe that it is a style / practices
issue, not an infrastructure issue.
But it is a good style. It is bad style to spread the information in
several places where they can get out of sync with each other. We did
our best to deploy our puppet deployment according to the best
practices at the time, and it would even still work with the current
version of puppet; I just don't want to depend on dynamic scoping
which is going away.
Yes, the ENC solves that, but I need a workaround now, not later after
we've migrated to ENC. We have a deadline for implementing the
failover and I'm trying to find the cleanest interim solution.
Ok, so that rules out regex hostname matching, both in node
declarations and in selector expressions. It makes it less palatable,
but by no means impossible to use a selector somewhere to choose a
value for $failover. It remains your stipulation that $failover be
assigned in the node declaration that narrows your options here.
Yes - I don't want the failover variable buried in manifests further
below. It is an attribute of the node, not the classes the node
includes.
Your constraint that the failover information be in the node
declarations is again what's driving you here. It is not consistent
to insist that node declarations must contain more information, but at
the same time complain that they become longer / more complex.
It is consistent if I have to jump through hoops of making them more
complex just to set an attribute :)
Maybe the answer is to make a case statement in the nodes.pp that sets
$IMSPECIAL globally based on the hostname... which was one of your
suggestions. But I don't like maintaining two lists of host regex's,
which could get out of date.
Is there no specifier to reach my node's scope? i.e.,
$mynode::IMSPECIAL? Maybe in Ruby?
Only dynamic scoping, as far as I know, and that's going away. Also,
it doesn't work with node inheritance the way you would like it to do.
That's unfortunate.. 'cause I can refer to an arbitrary class with
$foo::var. I'd hoped there was some scoping sugar to refer to my node
scope.
I can refer to my parent class by name, so I 'd think it natural to
want to refer to node scopes.
node a { include c }
class b { $b = 1 }
class c inherits b { notice($b::b) }
or
class b {
$b = 1
notice($c::c)
}
class c {
$c = 2
include b
notice($b::b)
}
It may be that Hiera provides a way to paper over this problem. I
We'll definitely check out Hiera someday, but right now isn't the time.
Alternatively, you could drop the plan to use node inheritance. You
must have a viable plan for identifying your failover nodes by their
hostnames (even if its just knowing specific names),
We have specific names, but it is prone to error as we add more. I'm
not the only one maintaining this puppet environment. The real
problem is that we deployed this failover site using the same naming
conventions as non-failover systems in the same datacenter.
We do have a machine database that we query inside of puppet to make
some variables... i.e., $machine_database::location,
$machine_database::category. I think THAT is how we're going to have
to solve this problem for now -- which is sort of like solving it with
an ENC. Eventually we want to have this db drive the ENC anyway.
for your original
idea is predicated on such a plan. Therefore, instead of applying
that logic to choose which node declaration to apply, you can instead
use it either within node declarations or without to set your magic
variable or class parameter, or to include a different / extra class.
For example:
node /.*our-db\d+/ {
$failover = $hostname ? { /our-db\d+/ = false, default = true }
include system:our_db
}
I'm not following -- doesn't that example have the same problem? The
variable $failover has no visibility outside of this scope.
Anyway, discussing it more internally, we're going to use an attribute
of the machine database.
Thanks for all the suggestions -- saves me time from heading down wrong paths!
Rich
--
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: scoping question - I want a node specific global var
On Tue, Aug 16, 2011 at 6:23 AM, jcbollinger john.bollin...@stjude.org wrote:
[Lots of good ideas]
Of those, I would recommend either extlookup() or your ENC (if you
have one), with my personal preference being extlookup(). I think
Hiera may offer an even better solution (though similar to
extlookup()), but I'm not familiar enough with it to feel comfortable
recommending it.
Unfortunately I've thought of some of those and they don't quite fit
with our existing infrastructure.
* We're not using ENC
* I want the special information right alongside the node decl. This
reduces chance for error and makes the data more maintainable.
Let me give more background:
We have a nodes.pp with a lot of hosts in it. We map a nodename to a
single class...
node /our-squid\d+/ { include system:our_squid }
node /our-db\d+/ { include system:our_db }
and so on.
We are making a failover site.
node /special-our-squid\d+/ { include system::our_squid}
node /special-our-db\d+/ { include system::our_db }
I don't want to confuse the issue with more details, but due to some
legacy naming conventions, we can't (..shouldn't...) use /^special-*/
to determine the sites are failover. We would like the attribute in
puppet.
I could do class { system::our_db: failover = failover }, except I
want that failover attribute within the class that system::our_db
derives from.
class system {
// Am I special?
}
class system::our_db($failover) inherits system {
// Am I special, too?
}
So ideally (except that this won't work with the new scoping rules in
the future), I'd like to
node /special-our-db\d+/ { $SPECIAL=true
include system::our_db }
Now, I could make a class
class special($yesorno = false) {
$SPECIAL = $yesorno
}
and include that in all nodes, and change it to false in the special
nodes It isn't very elegant and makes our node file a lot
messier. Each node is two lines now.. there must be a more elegant
solution.
Maybe the answer is to make a case statement in the nodes.pp that sets
$IMSPECIAL globally based on the hostname... which was one of your
suggestions. But I don't like maintaining two lists of host regex's,
which could get out of date.
Is there no specifier to reach my node's scope? i.e.,
$mynode::IMSPECIAL? Maybe in Ruby?
--
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] scoping question - I want a node specific global var
Is it possible to do something like this within the new scoping rules?
It seems that $::IMSPECIAL doesn't refer to the decl in node a. And
I can't use class parms as the variable is evaluated in a base class.
Suggestions? Currently using puppet 2.7.1
node a {
$IMSPECIAL=true
include foo
}
class bar {
if $IMSPECIAL {
notice(I'm special!)
}
}
class foo inherits bar {
// other stuff...
}
--
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] Re: Not getting errors/warnings/etc in reports
On Tue, Jul 19, 2011 at 11:03 AM, Rich Rauenzahn rraue...@gmail.com wrote:
I assumed this would have been fixed by 2.7.1, but it appears that
when we call the functions err(), warning(), etc., that they don't get
added to the report object, which we are using to generate nagios
alerts.
I'm guessing I'll have to write my own to do that -- does anyone have
any examples of logging the error message and also adding it to the
report object? (... and I don't really want to use the exec {
/bin/false: } workaround)
Digging through the code it looks like puppet adds messages internally
using Puppet.warning(), Puppet.error(), so I made a custom function to
call these directly.
I'm still not getting my error() messages in the report yaml ... why?
And is there any workaround?
--
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] Not getting errors/warnings/etc in reports
I assumed this would have been fixed by 2.7.1, but it appears that
when we call the functions err(), warning(), etc., that they don't get
added to the report object, which we are using to generate nagios
alerts.
I'm guessing I'll have to write my own to do that -- does anyone have
any examples of logging the error message and also adding it to the
report object? (... and I don't really want to use the exec {
/bin/false: } workaround)
Rich
--
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] puppet never finishing when there are thousands of resources
We are using puppet to export nagios resources (now we're using file resources to represent them) and the number of resources is probably in the thousands -- our puppet runs take 6GB (on the client side) and then just sort of spin forever (it's been running for a couple of hours now -- and no, we're not paging.) We're using puppet 2.6.4 and ruby 1.8.6 -- upgrading is on our roadmap, but we need to fight a few other fires first. Anyone have any suggestions for fixing this? Or how to mitigate this? I wonder if something isn't scaling -- like maybe the number of edges in the puppet DAG is increasing exponentially Rich -- 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] imports, defined(), and conflicts
We're trying to write a rule that imports a bunch of nagios
Nagios_host rules. But then we take a list of machines and add
Nagios_host rules for them as well. Some of the systems might
overlap, and we were hoping to use puppet to weed them out.
We assumed if we did
class a {
Nagios_host
Nagios_service
}
class b {
...
if ! defined Nagios_host[$a_host] {
nagios_host { $a_host: ...}
nagios_service { ... }
}
...
}
include a
include b
That we could count on using the defined() function to determine
whether something was already defined and define it if it isn't.
This isn't working -- we get a duplicate nagios_service entry, which
tells me either one of our hosts in registering a nagios_service,
without a nagios_host entry, or I can't count at all on the evaluation
order of 's and resource definitions.
I just verified the node has a nagios_host defined. Is there any
other way around this problem? (I have some other ideas, like a
concat file with the hosts defined and the grep -v'ing them.. but was
hoping for something more elegant.)
--
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] exporting resources that aren't built-in resources...
We seem to be able to export resources (and import them) just fine if they are basic resources, like nagios_* -- but we don't seem to be able to do it with defines, like @@concat::fragment. $ puppet -V 2.6.4 Is this a bug? Intended behavior? Are we doing something wrong? -- 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: exporting resources that aren't built-in resources...
On Wed, Jun 22, 2011 at 3:03 PM, Rich Rauenzahn rraue...@gmail.com wrote: We seem to be able to export resources (and import them) just fine if they are basic resources, like nagios_* -- but we don't seem to be able to do it with defines, like @@concat::fragment. $ puppet -V 2.6.4 Is this a bug? Intended behavior? Are we doing something wrong? ugh. We were only using a single not a . nevermind Rich -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] any better way to manage access control via /etc/passwd
On Mon, Apr 11, 2011 at 7:30 PM, hai wu haiwu...@gmail.com wrote: We need to manage /etc/passwd where there would be one line at the very end of the file to restrict access to all users not explictly allowed: +::/sbin/nologin If using delete_lines and append_if_no_such_lines (similar to this one at http://www.debian-administration.org/articles/528) to manage access control, each time a few new users got appended to /etc/passwd file, the above line would be deleted and appended, for many times, while it only needs to be done once. Any better way to manage this file in terms of access control? Augeas is buggy and I filed a bug report on this already. I just dealt with this in our puppet config -- I wrote a nis_modify_passwd script that has a --checkonly flag (for the exec's onlyif condition), and a --add function. I used lckpwdf (3) - get shadow password file entry ulckpwdf (3) - get shadow password file entry to lock the passwd file during the change -- and made sure not to edit the passwd file in place -- I make a 2nd copy, then mv it into place to ensure it works when out of diskspace. BUT.. after doing all of this, I later realized that in the nsswitch.conf, 'compat' mode for /etc/passwd sets the default for NIS to not allow anyone unless explicitly added to the /etc/passwd. So another way to deal with this is to change your nsswitch.conf to be 'compat' and not 'files nis'. In other words, 'files nis' more or less does a #include of all NIS users, so you have to added an explicit global /sbin/nologin to your passwd file -- but 'compat' allows you to hand pick which NIS users you want and defaults to nologin. Unfortunately, useradd doesn't seem to handle +user's... Rich -- 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] Using puppet/augeas to manage config entry AND matching comment
Seems like Augeas doesn't have a really good concept of conf file
entry AND a comment that goes with it. I can 'ins' a comment before
the configuration item, but every time augeas runs, it will add
another.
I can re-'set' the comment before the existing configuration item, but
that won't work if the comment doesn't already exist. Kind of a
chicken and egg.
This is what I have, and it doesn't work. Probably the match fails on
the insert because the node doesn't exist at all -- too bad there
isn't an unless..
define sysctl::set($value, $comment=undef) {
include sysctl
$key = $name
if $comment {
$comment_use = $comment
} else {
$comment_use = Managed by puppet: $key = $value
}
$sysctl = '/files/etc/sysctl.conf'
augeas { sysctl::set $key = $value:
changes = [ set $sysctl/$key '$value, ],
notify = Service['sysctl'],
}
augeas { sysctl::set insert comment for $key = $value:
changes = [ ins #comment before $sysctl/$key ],
onlyif = match
$sysctl/#comment[following-sibling::*[1][self::$key]] size == 0,
require = Augeas[sysctl::set $key = $value],
}
augeas { sysctl::set change comment for $key = $value:
changes = [ set
$sysctl/#comment[following-sibling::*[1][self::$key]] '$comment_use'
],
onlyif = match
$sysctl/#comment[following-sibling::*[1][self::$key]] size 0,
require = Augeas[sysctl::set $key = $value],
}
}
--
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: Using puppet/augeas to manage config entry AND matching comment
On Wed, Apr 6, 2011 at 11:14 AM, Rich Rauenzahn rraue...@gmail.com wrote:
Seems like Augeas doesn't have a really good concept of conf file
entry AND a comment that goes with it. I can 'ins' a comment before
the configuration item, but every time augeas runs, it will add
another.
I can re-'set' the comment before the existing configuration item, but
that won't work if the comment doesn't already exist. Kind of a
chicken and egg.
This is a better approximation -- the only bug in this now (I think)
is that if the comment is cleared, but still exists, it will add
another one. I could add an additional remove of the node if the size
is 0, before I insert, but I'm already invoking augeas more than I
want for one change.
define sysctl::set($value, $comment=undef) {
include sysctl
$key = $name
if $comment {
$comment_use = $comment
} else {
$comment_use = Managed by puppet: $key = $value
}
$sysctl = '/files/etc/sysctl.conf'
augeas { sysctl::set $key = $value:
changes = [ set $sysctl/$key '$value,
],
notify = Service['sysctl'],
}
augeas { sysctl::set insert comment for $key = $value:
changes = [ ins #comment before $sysctl/$key,
set
$sysctl/#comment[following-sibling::*[1][self::$key]] '$comment_use',
],
onlyif = match
$sysctl/#comment[following-sibling::*[1][self::$key]] size == 0,
require = Augeas[sysctl::set $key = $value],
}
augeas { sysctl::set change comment for $key = $value:
changes = [ set
$sysctl/#comment[following-sibling::*[1][self::$key]] '$comment_use'
],
onlyif = match
$sysctl/#comment[following-sibling::*[1][self::$key]] size 0,
require = Augeas[sysctl::set $key = $value],
}
}
--
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: returning a hash (json object) from custom function?
On Thu, Feb 10, 2011 at 8:35 AM, Peter Meier peter.me...@immerda.ch wrote: Could you file a bugreport[1], if there isn't yet one? Thanks! Then the chances are high that it will get fixed. I'd love to, but so far no matter how many times I reset my password, it thinks my login is invalid. Rich -- 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] parsing (and returning) json data in puppet in custom function
I see there is a bug open about this,
http://projects.puppetlabs.com/issues/6621
but I can't login to puppetlabs.
define test() {
$foo3 = json_parse(bad|,'':)
notice($foo3)
$type = type($foo3) # our custom function that returns class
notice(type=$type)
if $foo3 == { notice(foo3 is '') }
if $foo3 == undef { notice(foo3 is undef) }
if !$foo3 { notice(foo3 is not true) }
if $foo3 { notice(foo3 is true) }
$foo4 = undef
if $foo4 == undef { notice(foo4 is undef) }
if $foo4 == { notice(foo4 is '') }
}
test { a: }
notice: Scope(Test[a]): type=NilClass
notice: Scope(Test[a]): foo3 is true
notice: Scope(Test[a]): foo4 is undef
notice: Scope(Test[a]): foo4 is ''
So nil from a custom function evaluates as true, and neither nor undef.
The bug mentions ... (actually, I'll BCC Nigel, the author of that comment)
'and since we introduced the Ruby DSL, you’re free to incorporate
manifests that use the actual nil'
How? Maybe that doesn't do what I hope it does..
--
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] Trying to write a visudo checker
On 3/4/2011 12:23 AM, Alan Barrett wrote: On Thu, 03 Mar 2011, Rich Rauenzahn wrote: It seems someone got clever and decided to look at exec's and look for managed filenames in argument lists and create implicit dependencies from them? Argh! Yes, the unwanted dependencies are very annoying. Using file names like /dir/subdir/./file instead of /dir/subdir/file is enough to fool the code that adds implicit dependencies. Ah, what I did instead was just do exec = diff /.$path1 /.$path2. I was imagining doing much more invasive methods last night. 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] Trying to write a visudo checker
This visudo checker I've written (based on some examples from the web
and puppet training materials) causes a dependency loop -- but only
when I include the unless = diff It seems someone got clever
and decided to look at exec's and look for managed filenames in
argument lists and create implicit dependencies from them? Argh!
I also tried just making the exec a refreshonly from the sudoers_check
file's notify, but then the sudoers file itself ignored the bad return
from the exec even though it requires = the exec.
My best solution so far is to just let the visudo run every time...
$ puppet --version
2.6.4
define sudo::fragment($source, $order=10) {
concat::fragment { ${name}_sudoers:
source = $source,
target = $sudo::config::sudoers,
}
concat::fragment { ${name}_sudoers_check:
source = $source,
target = $sudo::config::sudoers_check,
}
}
class sudo::config($sudoers=/etc/sudoers) {
$sudoers_check = ${sudoers}.check
}
class sudo {
include concat::setup
$sudoers = $sudo::config::sudoers
$sudoers_check = $sudo::config::sudoers_check
package { sudo:
ensure = installed,
}
concat { $sudoers_check:
owner = root,
group = root,
mode= 440,
warn= true,
}
exec { visudo -cf $sudoers_check:
path= /usr/sbin/:/usr/bin,
require = [Concat[$sudoers_check], Package[sudo]],
unless = diff $sudoers $sudoers_check,
}
concat { $sudoers:
owner = root,
group = root,
mode= 440,
require = [Exec[visudo -cf $sudoers_check], File[$sudoers_check]],
warn= true,
}
}
class { sudo::config: sudoers = /tmp/sudoers }
sudo::fragment { ob:
source = puppet:///modules/sudo/sudoers,
#source = /etc/passwd,
}
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: Exec[visudo -cf /tmp/sudoers.check] =
File[/var/lib/puppet/concat/_tmp_sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers] =
File[/var/lib/puppet/concat/_tmp_sudoers/fragments], Exec[visudo -cf
/tmp/sudoers.check] =
File[/var/lib/puppet/concat/_tmp_sudoers/fragments], Exec[visudo -cf
/tmp/sudoers.check] = File[/tmp/sudoers], Exec[concat_/tmp/sudoers]
= File[/tmp/sudoers], File[/tmp/sudoers] = Exec[visudo -cf
/tmp/sudoers.check],
File[/var/lib/puppet/concat/_tmp_sudoers/fragments] =
File[/var/lib/puppet/concat/_tmp_sudoers/fragments/10_ob_sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers] =
Exec[concat_/tmp/sudoers], File[/var/lib/puppet/concat/_tmp_sudoers]
= Exec[concat_/tmp/sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers/fragments] =
Exec[concat_/tmp/sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers/fragments] =
Exec[concat_/tmp/sudoers], Exec[visudo -cf /tmp/sudoers.check] =
Exec[concat_/tmp/sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers/fragments/10_ob_sudoers] =
Exec[concat_/tmp/sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers/fragments.concat.out] =
Exec[concat_/tmp/sudoers],
File[/var/lib/puppet/concat/_tmp_sudoers/fragments.concat] =
Exec[concat_/tmp/sudoers], File[/var/lib/puppet/concat/_tmp_sudoers]
= File[/var/lib/puppet/concat/_tmp_sudoers/fragments.concat.out],
Exec[visudo -cf /tmp/sudoers.check] =
File[/var/lib/puppet/concat/_tmp_sudoers/fragments.concat.out],
File[/var/lib/puppet/concat/_tmp_sudoers] =
File[/var/lib/puppet/concat/_tmp_sudoers/fragments.concat],
Exec[visudo -cf /tmp/sudoers.check] =
File[/var/lib/puppet/concat/_tmp_sudoers/fragments.concat]; try using
the '--graph' option and open the '.dot' files in OmniGraffle or
GraphViz
--
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] Keeping a directory clean at top level
Say we have a directory called /FOO-- we want to only have in it what puppet puts into it. I want to remove any symlinks, empty directories, or files in it that don't belong -- but only one level deep. If the subdirectory has content, I don't want it removed -- ideally, I'd like a failure. This is because we might have some systems misconfigured (prior to deploying puppet) and we want to manually fix them -- the content in /FOO/bar might be important. Hmm - maybe this is a case for audit? ...but doesn't seem to fit what I want to do. Maybe it doesn't work in command line mode since there isn't a history recorded. I've been trying puppet resource file /tmp/empty_me ensure=directory purge=true source=/tmp/empty recurse=true recurselimit=1 force=true recurselimit=0 does nothing. recurselimit=1 stll causes the directory's contents to be removed. Without force, empty directories aren't removed. Without recurse my directory isn't purged. Any ideas? Is this possible to do without making my own file resource type? -- 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] force directory to symlink, but only if empty
I was surprised to find that
file { $foo:
ensure = symlink,
target = '/tmp/foo',
}
doesn't replace $foo if $foo is an empty directory.
Is there a particular combination of options to the file resource that
would replace the directory with the symlink if empty, but wouldn't
filebucket the contents and the directory if it wasn't empty?
recurse=false doesn't do it...
Rich
--
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] force directory to symlink, but only if empty
On Mon, Feb 14, 2011 at 5:20 PM, Nan Liu n...@puppetlabs.com wrote:
On Mon, Feb 14, 2011 at 5:17 PM, Rich Rauenzahn rraue...@gmail.com wrote:
I was surprised to find that
file { $foo:
ensure = symlink,
target = '/tmp/foo',
}
doesn't replace $foo if $foo is an empty directory.
Is there a particular combination of options to the file resource that
would replace the directory with the symlink if empty, but wouldn't
filebucket the contents and the directory if it wasn't empty?
See http://docs.puppetlabs.com/references/latest/type.html#file
force = true
That is what I'm doing. But force also empties the directory if it
has contents. I don't want 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] returning a hash (json object) from custom function?
We have a command line utility that queries a database to get certain
facts about our hosts -- I wanted to write a custom function to obtain
all of those facts at once. The tool outputs JSON and I wanted to
take that output and return a hash back into puppet where I could
access the facts like...
$a = host_info()
if $a['in_maintenance'] == 'yes' {
} ...
etc, etc.
Right now I'm getting:
can't convert Array into String at ... Which I assume means that
puppet is expecting a string back from the custom function.
Maybe I just need to make a fact out of these instead and prefix them
with foo_in_maintenance, etc., etc., etc., but I'd really rather use
structured data.
--
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: returning a hash (json object) from custom function?
Ok, I was mistaken. Returning a hash works. It would be helpful if
the ruby exceptions bubbled up to puppet reported the correct line
number from the ruby source -- if that is possible.
Rich
On Mon, Feb 7, 2011 at 4:18 PM, Rich Rauenzahn rraue...@gmail.com wrote:
We have a command line utility that queries a database to get certain
facts about our hosts -- I wanted to write a custom function to obtain
all of those facts at once. The tool outputs JSON and I wanted to
take that output and return a hash back into puppet where I could
access the facts like...
$a = host_info()
if $a['in_maintenance'] == 'yes' {
} ...
--
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] certificate fails to verify
On Sat, Feb 5, 2011 at 7:54 PM, Tim Dunphy bluethu...@gmail.com wrote: Hello list!! I am a new puppet user and I am having trouble getting the server to verify the client cert. I know this has been covered before but I have tried several things and no luck as of yet. This probably isn't your problem, but I want to post an experience I had with getting the certificates to validate. We inadvertently removed /var/lib/puppet/ssl on the puppetmaster and needed to recertify all of the clients against the new CA the puppetmaster created. The clients would sort of half validate, but still had cert errors. I checked their clocks, I removed the ssl directory on the client, I removed all the files in /var/lib/puppet -- nothing worked. Finally I remembered our puppetmaster is front-ended by nginx -- and it also uses the puppet ssl keys -- and I hadn't restarted it since changing the puppetmaster's keys, etc. Once I restarted it, everything worked again. -- 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] failing with fail() without failing everything
We would like to have a default node applied to systems, but also
trigger a failure so that we notice the system in puppet-dashboard.
At the moment we're doing...
node default {
include system_defaults
fail($hostname doesn't have a node to apply to it)
}
Unfortunately this seems to fail before the system_defaults class can
be applied to the node (which we want applied every time). And err()
doesn't propagate up to the dashboard.
Is there any way to accomplish what I want?
Rich
--
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] How to include the Scope(...) in a generated string?
I'd like to include similar information that notice() spits out in a file I am generating -- basically so that anyone looking at the generated file (actually a file fragment) could trace it back to the class that is generating the entry. Using $name within the file fragment is the closest I am getting to what I want -- is there anything better? -- 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] redefining resource with a fully qualified name
This works:
$ cat foo.pp
define aaa($x=1) {
notice(\$x=$x)
}
class b {
aaa { xxx: x=2 }
}
class c inherits b{
Aaa[xxx] { x=3 }
}
include c
--
But this doesn't:
--
$ cat foo.pp
define scope::aaa($x=1) {
notice(\$x=$x)
}
class b {
scope::aaa { xxx: x=2 }
}
class c inherits b{
Scope:aaa[xxx] { x=3 }
}
include c
The reason I want to do this is that I was writing my own define of
yumrepo -- I was hoping that if I fully qualified it (yum::yumrepo),
it wouldn't conflict with the default one.
--
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: redefining resource with a fully qualified name
On Wed, Jan 26, 2011 at 10:18 AM, Rich Rauenzahn rraue...@gmail.com wrote:
class c inherits b{
Scope:aaa[xxx] { x=3 }
}
I remember seeing an example now:
Scope:Aaa[xxx]
-- capitalize both components.
Rich
--
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.
