[Puppet Users] Variable Scoping = Root Canal
I've been struggling with puppet variable scope all day, well, for
several months actually.
I think I have pretty simple requirements. For any given node, I want
to be able to set a series of variables and include a set of classes,
based on three different aspects of a node, being physical location,
operating system, and function. If I try and do this with classes, I
find that variables set in a class included from a node, are not
visible to other classes included from that node.
node 'node1.fr.xxx.com' {
include facility::sjc
include ldap::client
}
In this example, variables defined in facility::sjc are not visible in
ldap::client (in this case, it would be the IP address of the local
LDAP server).
Another approach is to do everything with node inheritance, but in
order to model these three functions, you end up with nodes with names
like sjcDellBootServer or nycVmwareBootServer, which is just plain
stupid.
So... what am I missing here, and why is such a simple thing so
complicated in puppet? I'm not even sure if this email is lucid. I am
really annoyed and frustrated as hell.
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-us...@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: Variable Scoping = Root Canal
On 27 Giu, 09:02, Douglas Garstang wrote:
> I've been struggling with puppet variable scope all day, well, for
> several months actually.
>
> I think I have pretty simple requirements. For any given node, I want
> to be able to set a series of variables and include a set of classes,
> based on three different aspects of a node, being physical location,
> operating system, and function. If I try and do this with classes, I
> find that variables set in a class included from a node, are not
> visible to other classes included from that node.
>
> node 'node1.fr.xxx.com' {
> include facility::sjc
> include ldap::client
>
> }
>
> In this example, variables defined in facility::sjc are not visible in
> ldap::client (in this case, it would be the IP address of the local
> LDAP server).
>
> Another approach is to do everything with node inheritance, but in
> order to model these three functions, you end up with nodes with names
> like sjcDellBootServer or nycVmwareBootServer, which is just plain
> stupid.
Node names don't need to adapt to inheritance's logic.
You can do something like:
node sjc {
ldap_server="10.10.10.10"
}
node 'node1.fr.xxx.com' inherits sjc {
include ldap::client
}
When using nodes' inheritance the only real thing you've to care about
is to define variables BEFORE including any class.
So at the end it's better to include classes only in the node that
defines your host nad never in the "intermediary" nodes that can
represent facilities, networks or whatever.
On the other way, this also should work, if you want to define your
variables in a class:
class ldap::client {
include facility::sjc
do_something with "${facility::ldap_server}" in this class
BUT if you need to use "${facility::ldap_server}" in a template you
should reassing it to a local variable (dunno if the problem is the
colon or whatever I just found the problem and made a quick fix with
somehting like):
$my_ldap_server="${facility::ldap_server}"
and use $my_ldap_server in the template.
}
I'd avoid to use inheritance in the included class (facility::sjc
should not inherit anything)
Dunno if I've been clear with this example. Hope it helps
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Complex templating
Douglas Garstang writes: > On Sat, Jun 26, 2010 at 8:00 PM, Daniel Pittman wrote: >> "R.I.Pienaar" writes: >>> - "Douglas Garstang" wrote: >>> I've not quite figured out how to do complex templating in puppet yet. [...] Anyone know how I could do this? >>> >>> I find concatenated snippets work well for this kind of problem. >>> http://github.com/ripienaar/puppet-concat >> >> *nod* They are pretty much the best solution available at this time. > > I must be missing something fundamental then, because I am getting this: > > Could not run Puppet configuration client: Could not find dependent > Exec[concat_/tmp/foo] for File[/_tmp_foo/fragments/10__tmp_foo] at > /etc/puppet/modules/concat/manifests/fragment.pp:45 Did you follow the examples in the documentation of the module, and that R.I.Pienaar pointed you to? Can you post the code that isn't working for you? My guess is that you have not included the setup and overall file target sections, only a fragment, but without seeing what you wrote we could only guess at what you had actually done... Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ 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-us...@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: Variable Scoping = Root Canal
On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 wrote:
>
>
> On 27 Giu, 09:02, Douglas Garstang wrote:
>> I've been struggling with puppet variable scope all day, well, for
>> several months actually.
>>
>> I think I have pretty simple requirements. For any given node, I want
>> to be able to set a series of variables and include a set of classes,
>> based on three different aspects of a node, being physical location,
>> operating system, and function. If I try and do this with classes, I
>> find that variables set in a class included from a node, are not
>> visible to other classes included from that node.
>>
>> node 'node1.fr.xxx.com' {
>> include facility::sjc
>> include ldap::client
>>
>> }
>>
>> In this example, variables defined in facility::sjc are not visible in
>> ldap::client (in this case, it would be the IP address of the local
>> LDAP server).
>>
>> Another approach is to do everything with node inheritance, but in
>> order to model these three functions, you end up with nodes with names
>> like sjcDellBootServer or nycVmwareBootServer, which is just plain
>> stupid.
>
> Node names don't need to adapt to inheritance's logic.
> You can do something like:
> node sjc {
> ldap_server="10.10.10.10"
> }
>
> node 'node1.fr.xxx.com' inherits sjc {
> include ldap::client
> }
>
> When using nodes' inheritance the only real thing you've to care about
> is to define variables BEFORE including any class.
> So at the end it's better to include classes only in the node that
> defines your host nad never in the "intermediary" nodes that can
> represent facilities, networks or whatever.
>
> On the other way, this also should work, if you want to define your
> variables in a class:
>
> class ldap::client {
> include facility::sjc
>
> do_something with "${facility::ldap_server}" in this class
>
> BUT if you need to use "${facility::ldap_server}" in a template you
> should reassing it to a local variable (dunno if the problem is the
> colon or whatever I just found the problem and made a quick fix with
> somehting like):
> $my_ldap_server="${facility::ldap_server}"
>
> and use $my_ldap_server in the template.
>
> }
Al,
thanks for the examples and such. Your using pretty simplistic
examples, and I'm sorta beyond that point. Everything you said makes
sense, and is true. Trying to do a more complex implementation falls
apart though due to puppet's scoping issues.
The problem with doing something with "${facility::ldap_server}" is
that it should really be called "${facility::sjc::ldap_server}", and
when you do that, you completely destroy the whole point of
inheritance. The ldap client module itself should not directly
reference the "${facility::sjc::ldap_server}" variable, otherwise I
would see one ldap module for each facility!
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-us...@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: Variable Scoping = Root Canal
On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 wrote:
>
>
> On 27 Giu, 09:02, Douglas Garstang wrote:
>> I've been struggling with puppet variable scope all day, well, for
>> several months actually.
>>
>> I think I have pretty simple requirements. For any given node, I want
>> to be able to set a series of variables and include a set of classes,
>> based on three different aspects of a node, being physical location,
>> operating system, and function. If I try and do this with classes, I
>> find that variables set in a class included from a node, are not
>> visible to other classes included from that node.
>>
>> node 'node1.fr.xxx.com' {
>> include facility::sjc
>> include ldap::client
>>
>> }
>>
>> In this example, variables defined in facility::sjc are not visible in
>> ldap::client (in this case, it would be the IP address of the local
>> LDAP server).
>>
>> Another approach is to do everything with node inheritance, but in
>> order to model these three functions, you end up with nodes with names
>> like sjcDellBootServer or nycVmwareBootServer, which is just plain
>> stupid.
>
> Node names don't need to adapt to inheritance's logic.
> You can do something like:
> node sjc {
> ldap_server="10.10.10.10"
> }
>
> node 'node1.fr.xxx.com' inherits sjc {
> include ldap::client
> }
>
> When using nodes' inheritance the only real thing you've to care about
> is to define variables BEFORE including any class.
> So at the end it's better to include classes only in the node that
> defines your host nad never in the "intermediary" nodes that can
> represent facilities, networks or whatever.
That's awful. If you can't build an inheritance tree from generic to
specific, and assign variables at each step, that's a loss of a lot of
functionality, and just about makes everything impossible.
And, even if I do that, only including classes in the final node...
class A {
$var = 1
}
class B {
< do something with $var >
}
node A {
include class A
include class B
}
This doesn't work! But, it's doing what you suggested. Class B does
not have access to $var, because it's out of scope. This is exactly
what I want to do. I want to define an LDAP server variable in class
A, and then use it in class B.
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-us...@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] Variable Scoping = Root Canal
I think you could do:
node 'node1.fr.xxx.com' {
include facility::sjc
$my_ldap_server = $facility::sjc::ldap_server
include ldap::client
}
On Sun, Jun 27, 2010 at 2:02 AM, Douglas Garstang
wrote:
> I've been struggling with puppet variable scope all day, well, for
> several months actually.
>
> I think I have pretty simple requirements. For any given node, I want
> to be able to set a series of variables and include a set of classes,
> based on three different aspects of a node, being physical location,
> operating system, and function. If I try and do this with classes, I
> find that variables set in a class included from a node, are not
> visible to other classes included from that node.
>
> node 'node1.fr.xxx.com' {
> include facility::sjc
> include ldap::client
> }
>
> In this example, variables defined in facility::sjc are not visible in
> ldap::client (in this case, it would be the IP address of the local
> LDAP server).
>
> Another approach is to do everything with node inheritance, but in
> order to model these three functions, you end up with nodes with names
> like sjcDellBootServer or nycVmwareBootServer, which is just plain
> stupid.
>
> So... what am I missing here, and why is such a simple thing so
> complicated in puppet? I'm not even sure if this email is lucid. I am
> really annoyed and frustrated as hell.
>
> 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-us...@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-us...@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] Variable Scoping = Root Canal
On Sun, Jun 27, 2010 at 11:28 AM, Steve Neuharth
wrote:
> I think you could do:
>
> node 'node1.fr.xxx.com' {
> include facility::sjc
> $my_ldap_server = $facility::sjc::ldap_server
> include ldap::client
> }
That seems to work. Not pretty though. I'll go see if it causes any
other problems, apart from rubbing my logical brain the wrong way.
Thanks.
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-us...@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: Yet more variable scoping pain.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> I disagree. > > And I disagree with you. > > Not being able to do this is _REALLY_ annoying... no, it is absolutely right that this isn't possible. Actually, we would have a lot more pain if this would be possible. cheers pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwnp3kACgkQbwltcAfKi39yogCfexT5vqG+Llardua0GUPEH/fb S6gAn0aFw17Q/YyQtb0Qsz/8umBac5At =Rgk6 -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-us...@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] Borked Client Cert in 0.25
Here we go with puppet 0.25 certificate problems again. I had a system where puppet was running fine. I reinstalled it. Running puppet on the client causes this: "Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key". Fine... so I run 'puppetca --clean kick01.fr.xxx.com' on the server, who responds with: [r...@inst01 puppet]# puppetca --clean kick01.fr.xxx.com kick01.fr.xxx.com notice: Removing file Puppet::SSL::Certificate kick01.fr.xxx.com at '/var/lib/puppet/ssl/ca/signed/kick01.fr.xxx.com.pem' I then rerun puppet on the client and I am getting the same error. I must have done this hundreds of times with 0.24.8. What am I doing wrong now? 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-us...@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: Yet more variable scoping pain.
On Sun, Jun 27, 2010 at 12:33 PM, Peter Meier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > >>> I disagree. >> >> And I disagree with you. >> >> Not being able to do this is _REALLY_ annoying... > > no, it is absolutely right that this isn't possible. Actually, we would > have a lot more pain if this would be possible. Would love to see your workaround Pete... -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Borked Client Cert in 0.25
On Sun, Jun 27, 2010 at 12:34 PM, Douglas Garstang wrote: > Here we go with puppet 0.25 certificate problems again. > > I had a system where puppet was running fine. I reinstalled it. > Running puppet on the client causes this: > > "Could not request certificate: Retrieved certificate does not match > private key; please remove certificate from server and regenerate it > with the current key". > > Fine... so I run 'puppetca --clean kick01.fr.xxx.com' on the server, > who responds with: > > [r...@inst01 puppet]# puppetca --clean kick01.fr.xxx.com > kick01.fr.xxx.com > notice: Removing file Puppet::SSL::Certificate kick01.fr.xxx.com at > '/var/lib/puppet/ssl/ca/signed/kick01.fr.xxx.com.pem' > > I then rerun puppet on the client and I am getting the same error. I > must have done this hundreds of times with 0.24.8. What am I doing > wrong now? > > Doug. > *sigh* On the client, I removed the puppet rpm, blew away /var/lib/puppet, and reinstalled the puppet rpm again. Started puppet, it requested a certificate (but it logged nothing on the client about it, even in debug mode), signed it on the server, and I am still getting this on the client. warning: peer certificate won't be verified in this SSL session info: Caching certificate for kick01.fr.xxx.com err: Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key *sigh* -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Borked Client Cert in 0.25
On Sun, Jun 27, 2010 at 12:47 PM, Douglas Garstang wrote: > On Sun, Jun 27, 2010 at 12:34 PM, Douglas Garstang > wrote: >> Here we go with puppet 0.25 certificate problems again. >> >> I had a system where puppet was running fine. I reinstalled it. >> Running puppet on the client causes this: >> >> "Could not request certificate: Retrieved certificate does not match >> private key; please remove certificate from server and regenerate it >> with the current key". >> >> Fine... so I run 'puppetca --clean kick01.fr.xxx.com' on the server, >> who responds with: >> >> [r...@inst01 puppet]# puppetca --clean kick01.fr.xxx.com >> kick01.fr.xxx.com >> notice: Removing file Puppet::SSL::Certificate kick01.fr.xxx.com at >> '/var/lib/puppet/ssl/ca/signed/kick01.fr.xxx.com.pem' >> >> I then rerun puppet on the client and I am getting the same error. I >> must have done this hundreds of times with 0.24.8. What am I doing >> wrong now? >> >> Doug. >> > > *sigh* > > On the client, I removed the puppet rpm, blew away /var/lib/puppet, > and reinstalled the puppet rpm again. Started puppet, it requested a > certificate (but it logged nothing on the client about it, even in > debug mode), signed it on the server, and I am still getting this on > the client. > > warning: peer certificate won't be verified in this SSL session > info: Caching certificate for kick01.fr.xxx.com > err: Could not request certificate: Retrieved certificate does not > match private key; please remove certificate from server and > regenerate it with the current key > > *sigh* > Puppet is on crack. Even when the server isn't running, I STILL get this error! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Borked Client Cert in 0.25
On Jun 27, 2010, at 12:50 PM, Douglas Garstang wrote: > On Sun, Jun 27, 2010 at 12:47 PM, Douglas Garstang > wrote: >> On Sun, Jun 27, 2010 at 12:34 PM, Douglas Garstang >> wrote: >>> Here we go with puppet 0.25 certificate problems again. >>> >>> I had a system where puppet was running fine. I reinstalled it. >>> Running puppet on the client causes this: >>> >>> "Could not request certificate: Retrieved certificate does not match >>> private key; please remove certificate from server and regenerate it >>> with the current key". >>> >>> Fine... so I run 'puppetca --clean kick01.fr.xxx.com' on the server, >>> who responds with: >>> >>> [r...@inst01 puppet]# puppetca --clean kick01.fr.xxx.com >>> kick01.fr.xxx.com >>> notice: Removing file Puppet::SSL::Certificate kick01.fr.xxx.com at >>> '/var/lib/puppet/ssl/ca/signed/kick01.fr.xxx.com.pem' >>> >>> I then rerun puppet on the client and I am getting the same error. I >>> must have done this hundreds of times with 0.24.8. What am I doing >>> wrong now? >>> >>> Doug. >>> >> >> *sigh* >> >> On the client, I removed the puppet rpm, blew away /var/lib/puppet, >> and reinstalled the puppet rpm again. Started puppet, it requested a >> certificate (but it logged nothing on the client about it, even in >> debug mode), signed it on the server, and I am still getting this on >> the client. >> >> warning: peer certificate won't be verified in this SSL session >> info: Caching certificate for kick01.fr.xxx.com >> err: Could not request certificate: Retrieved certificate does not >> match private key; please remove certificate from server and >> regenerate it with the current key >> >> *sigh* >> > > Puppet is on crack. Even when the server isn't running, I STILL get this > error! I think I know what the problem is. I ran into this exact error message before. Try this: Step 1, run this on client: service puppet stop rm -R /var/lib/puppet Step 2, run this on server: puppetca --clean kick01.fr.xxx.com #Make sure to change this back Step 3, run this on client: #Restart the client how ever you like. I recommend this for testing: puppetd --test --verbose --debug I'm pretty sure this will work. If it does, I'll by happy to explain why you got all those different error messages. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Variable Scoping = Root Canal
Yup, I hear ya. This was a pain until I realized that the only
variables defined in nodes are inherited from node to node. The
variables defined in classes that are included by the node must be
expressed using the variable's full context. I just ended up mapping
certain variables to other variables in my server templates and it
seems to work fine. Modules will invariably use different variable
names for the same information so it seems like this kind of duct tape
is unavoidable.
--steev
tel: (612) 840-6253
On Jun 27, 2010, at 1:39 PM, Douglas Garstang
wrote:
> On Sun, Jun 27, 2010 at 11:28 AM, Steve Neuharth
> wrote:
>> I think you could do:
>>
>> node 'node1.fr.xxx.com' {
>> include facility::sjc
>> $my_ldap_server = $facility::sjc::ldap_server
>> include ldap::client
>> }
>
> That seems to work. Not pretty though. I'll go see if it causes any
> other problems, apart from rubbing my logical brain the wrong way.
> Thanks.
>
> 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-us...@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-us...@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: Borked Client Cert in 0.25
On Sun, Jun 27, 2010 at 1:33 PM, Patrick Mohr wrote: > > On Jun 27, 2010, at 12:50 PM, Douglas Garstang wrote: > >> On Sun, Jun 27, 2010 at 12:47 PM, Douglas Garstang >> wrote: >>> On Sun, Jun 27, 2010 at 12:34 PM, Douglas Garstang >>> wrote: Here we go with puppet 0.25 certificate problems again. I had a system where puppet was running fine. I reinstalled it. Running puppet on the client causes this: "Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key". Fine... so I run 'puppetca --clean kick01.fr.xxx.com' on the server, who responds with: [r...@inst01 puppet]# puppetca --clean kick01.fr.xxx.com kick01.fr.xxx.com notice: Removing file Puppet::SSL::Certificate kick01.fr.xxx.com at '/var/lib/puppet/ssl/ca/signed/kick01.fr.xxx.com.pem' I then rerun puppet on the client and I am getting the same error. I must have done this hundreds of times with 0.24.8. What am I doing wrong now? Doug. >>> >>> *sigh* >>> >>> On the client, I removed the puppet rpm, blew away /var/lib/puppet, >>> and reinstalled the puppet rpm again. Started puppet, it requested a >>> certificate (but it logged nothing on the client about it, even in >>> debug mode), signed it on the server, and I am still getting this on >>> the client. >>> >>> warning: peer certificate won't be verified in this SSL session >>> info: Caching certificate for kick01.fr.xxx.com >>> err: Could not request certificate: Retrieved certificate does not >>> match private key; please remove certificate from server and >>> regenerate it with the current key >>> >>> *sigh* >>> >> >> Puppet is on crack. Even when the server isn't running, I STILL get this >> error! > > I think I know what the problem is. I ran into this exact error message > before. Try this: > > Step 1, run this on client: > service puppet stop > rm -R /var/lib/puppet > > Step 2, run this on server: > puppetca --clean kick01.fr.xxx.com #Make sure to change this back > > Step 3, run this on client: > #Restart the client how ever you like. I recommend this for testing: > puppetd --test --verbose --debug > > > I'm pretty sure this will work. If it does, I'll by happy to explain why you > got all those different error messages. Thanks Patrick. I got it to work somehow, with some magic combination of commands, which may be what you suggested. Next time it happens (and that won't be too far off), I'll try running through your steps. 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-us...@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: Borked Client Cert in 0.25
On Jun 27, 2010, at 2:40 PM, Douglas Garstang wrote: > On Sun, Jun 27, 2010 at 1:33 PM, Patrick Mohr wrote: >> >> On Jun 27, 2010, at 12:50 PM, Douglas Garstang wrote: >> >>> On Sun, Jun 27, 2010 at 12:47 PM, Douglas Garstang >>> wrote: On Sun, Jun 27, 2010 at 12:34 PM, Douglas Garstang wrote: > Here we go with puppet 0.25 certificate problems again. > > I had a system where puppet was running fine. I reinstalled it. > Running puppet on the client causes this: > > "Could not request certificate: Retrieved certificate does not match > private key; please remove certificate from server and regenerate it > with the current key". > > Fine... so I run 'puppetca --clean kick01.fr.xxx.com' on the server, > who responds with: > > [r...@inst01 puppet]# puppetca --clean kick01.fr.xxx.com > kick01.fr.xxx.com > notice: Removing file Puppet::SSL::Certificate kick01.fr.xxx.com at > '/var/lib/puppet/ssl/ca/signed/kick01.fr.xxx.com.pem' > > I then rerun puppet on the client and I am getting the same error. I > must have done this hundreds of times with 0.24.8. What am I doing > wrong now? > > Doug. > *sigh* On the client, I removed the puppet rpm, blew away /var/lib/puppet, and reinstalled the puppet rpm again. Started puppet, it requested a certificate (but it logged nothing on the client about it, even in debug mode), signed it on the server, and I am still getting this on the client. warning: peer certificate won't be verified in this SSL session info: Caching certificate for kick01.fr.xxx.com err: Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key *sigh* >>> >>> Puppet is on crack. Even when the server isn't running, I STILL get this >>> error! >> >> I think I know what the problem is. I ran into this exact error message >> before. Try this: >> >> Step 1, run this on client: >> service puppet stop >> rm -R /var/lib/puppet >> >> Step 2, run this on server: >> puppetca --clean kick01.fr.xxx.com #Make sure to change this back >> >> Step 3, run this on client: >> #Restart the client how ever you like. I recommend this for testing: >> puppetd --test --verbose --debug >> >> >> I'm pretty sure this will work. If it does, I'll by happy to explain why >> you got all those different error messages. > > Thanks Patrick. I got it to work somehow, with some magic combination > of commands, which may be what you suggested. Next time it happens > (and that won't be too far off), I'll try running through your steps. > > Doug. This is an approximation of what probably happened. This is just to give a general idea, and may have some minor errors. When a client wants to get a signed certificate, it normally goes through these steps: 1) Client generates a private key. 2) Client generates a Certificate Sign Request (CSR) from its private key and other information. 3) Client contacts server. 4) If client doesn't have ca.pem, if downloads it from the server at this point 5) Client sends its CSR to the server and asks for its signed certificate. 6) If server has a signed certificate for that client name, it sends the certificate to the client. What probably happened with your client: 1) Client generates a private key. 2) Client generates a Certificate Sign Request (CSR) from its private key and other information. 3) Client contacts server. 4) If client doesn't have ca.pem, if downloads it from the server at this point 5) Client sends its CSR to the server and asks for its signed certificate. 6) If server has a signed certificate for that client name, it sends the certificate to the client. 7) Client is wiped 8) Client generates a private key. 9) Client generates a Certificate Sign Request (CSR) from its private key and other information. 10) Client contacts server. 11) If client doesn't have ca.pem, if downloads it from the server at this point 12) Client sends its CSR to the server and asks for its signed certificate. 13) Server sees that it already has the old signed certificate for that name and sends that certificate and ignores the CSR. 14) Client trys to use its certificate, but the cert matches the old private key instead of the new key so the certificate is unusable. At this point, even if the client can't see the server, it still has a key/cert pair that doesn't match each other so it will still give the same error message. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Complex templating
On Sun, Jun 27, 2010 at 3:20 AM, Daniel Pittman wrote:
> Douglas Garstang writes:
>> On Sat, Jun 26, 2010 at 8:00 PM, Daniel Pittman wrote:
>>> "R.I.Pienaar" writes:
- "Douglas Garstang" wrote:
> I've not quite figured out how to do complex templating in puppet yet.
>
> [...]
>
> Anyone know how I could do this?
I find concatenated snippets work well for this kind of problem.
http://github.com/ripienaar/puppet-concat
>>>
>>> *nod* They are pretty much the best solution available at this time.
>>
>> I must be missing something fundamental then, because I am getting this:
>>
>> Could not run Puppet configuration client: Could not find dependent
>> Exec[concat_/tmp/foo] for File[/_tmp_foo/fragments/10__tmp_foo] at
>> /etc/puppet/modules/concat/manifests/fragment.pp:45
>
> Did you follow the examples in the documentation of the module, and that
> R.I.Pienaar pointed you to?
>
> Can you post the code that isn't working for you?
>
> My guess is that you have not included the setup and overall file target
> sections, only a fragment, but without seeing what you wrote we could only
> guess at what you had actually done...
Using the simple use case example in the comments at the top of
concat/init.pp, simply,
node 'test01.fr.xxx.com' {
concat::fragment{
"foo.com_config":
target => "/etc/somefile",
content => template("dhcp/host.erb");
}
}
That's it. I figured it would take the contents of dhcp/host.erb and
append it to /etc/somefile, but instead I get the error:
Could not run Puppet configuration client: Could not find dependent
Exec[concat_/etc/named.conf] for
File[/_etc_named.conf/fragments/10_foo.com_config] at
/etc/puppet/modules/concat/manifests/fragment.pp:45
And now that I think about it... isn't this incredibly
inefficient? Doesn't the client basically have to reconstruct the file
from scratch every time?
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-us...@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] Complex templating
- "Douglas Garstang" wrote:
> On Sun, Jun 27, 2010 at 3:20 AM, Daniel Pittman
> wrote:
> > Douglas Garstang writes:
> >> On Sat, Jun 26, 2010 at 8:00 PM, Daniel Pittman
> wrote:
> >>> "R.I.Pienaar" writes:
> - "Douglas Garstang" wrote:
>
> > I've not quite figured out how to do complex templating in
> puppet yet.
> >
> > [...]
> >
> > Anyone know how I could do this?
>
> I find concatenated snippets work well for this kind of problem.
> http://github.com/ripienaar/puppet-concat
> >>>
> >>> *nod* They are pretty much the best solution available at this
> time.
> >>
> >> I must be missing something fundamental then, because I am getting
> this:
> >>
> >> Could not run Puppet configuration client: Could not find
> dependent
> >> Exec[concat_/tmp/foo] for File[/_tmp_foo/fragments/10__tmp_foo] at
> >> /etc/puppet/modules/concat/manifests/fragment.pp:45
> >
> > Did you follow the examples in the documentation of the module, and
> that
> > R.I.Pienaar pointed you to?
> >
> > Can you post the code that isn't working for you?
> >
> > My guess is that you have not included the setup and overall file
> target
> > sections, only a fragment, but without seeing what you wrote we
> could only
> > guess at what you had actually done...
>
> Using the simple use case example in the comments at the top of
> concat/init.pp, simply,
>
> node 'test01.fr.xxx.com' {
> concat::fragment{
> "foo.com_config":
> target => "/etc/somefile",
> content => template("dhcp/host.erb");
> }
> }
>
> That's it. I figured it would take the contents of dhcp/host.erb and
> append it to /etc/somefile, but instead I get the error:
you're basically just failing completely at reading documentation in the code
or examples given on the github page. This is a recurring theme in your mails.
> And now that I think about it... isn't this incredibly
> inefficient? Doesn't the client basically have to reconstruct the
> file from scratch every time?
it's not particularly inefficient, a couple of extra exec's isn't going to kill
anyone. I build machines with 500+ fragments and they execute very quick,
especially on 0.25.
A machine - low spec virtual machine - with 400 concat fragments:
Jun 27 23:30:32 bacula1 puppetd[8668]: Finished catalog run in 39.74 seconds
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Complex templating
On Sun, Jun 27, 2010 at 3:51 PM, R.I.Pienaar wrote:
>
> - "Douglas Garstang" wrote:
>
>> On Sun, Jun 27, 2010 at 3:20 AM, Daniel Pittman
>> wrote:
>> > Douglas Garstang writes:
>> >> On Sat, Jun 26, 2010 at 8:00 PM, Daniel Pittman
>> wrote:
>> >>> "R.I.Pienaar" writes:
>> - "Douglas Garstang" wrote:
>>
>> > I've not quite figured out how to do complex templating in
>> puppet yet.
>> >
>> > [...]
>> >
>> > Anyone know how I could do this?
>>
>> I find concatenated snippets work well for this kind of problem.
>> http://github.com/ripienaar/puppet-concat
>> >>>
>> >>> *nod* They are pretty much the best solution available at this
>> time.
>> >>
>> >> I must be missing something fundamental then, because I am getting
>> this:
>> >>
>> >> Could not run Puppet configuration client: Could not find
>> dependent
>> >> Exec[concat_/tmp/foo] for File[/_tmp_foo/fragments/10__tmp_foo] at
>> >> /etc/puppet/modules/concat/manifests/fragment.pp:45
>> >
>> > Did you follow the examples in the documentation of the module, and
>> that
>> > R.I.Pienaar pointed you to?
>> >
>> > Can you post the code that isn't working for you?
>> >
>> > My guess is that you have not included the setup and overall file
>> target
>> > sections, only a fragment, but without seeing what you wrote we
>> could only
>> > guess at what you had actually done...
>>
>> Using the simple use case example in the comments at the top of
>> concat/init.pp, simply,
>>
>> node 'test01.fr.xxx.com' {
>> concat::fragment{
>> "foo.com_config":
>> target => "/etc/somefile",
>> content => template("dhcp/host.erb");
>> }
>> }
>>
>> That's it. I figured it would take the contents of dhcp/host.erb and
>> append it to /etc/somefile, but instead I get the error:
>
> you're basically just failing completely at reading documentation in the code
> or examples given on the github page. This is a recurring theme in your
> mails.
Normally you could expect a simple use case to work just fine.
The documentation on the github page is way more complex than I need.
If I just extract the bit I need from the documentation in
readme.markdown, I get:
concat::fragment{"motd_fragment_$name":
target => "/etc/motd",
content => "-- $body\n"
}
which is basically how it's documented in init.pp, and the same as
what I am trying to do.
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-us...@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: Variable Scoping = Root Canal
On Jun 27, 7:38 pm, Douglas Garstang wrote:
> The problem with doing something with "${facility::ldap_server}" is
> that it should really be called "${facility::sjc::ldap_server}", and
> when you do that, you completely destroy the whole point of
> inheritance. The ldap client module itself should not directly
> reference the "${facility::sjc::ldap_server}" variable, otherwise I
> would see one ldap module for each facility!
>
> Doug
Ok, right. Then you can do something like:
class ldap::client {
include facility
use "${facility::ldap_server}" in this class
}
And in the facility class manage the logic to assign to ldap_server
the value you want according to the actual facility (this might be a
variable you define in nodes or a custom fact).
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Variable Scoping = Root Canal
On Jun 27, 8:25 pm, Douglas Garstang wrote:
> On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 wrote:
>
> > On 27 Giu, 09:02, Douglas Garstang wrote:
> >> I've been struggling with puppet variable scope all day, well, for
> >> several months actually.
>
> >> I think I have pretty simple requirements. For any given node, I want
> >> to be able to set a series of variables and include a set of classes,
> >> based on three different aspects of a node, being physical location,
> >> operating system, and function. If I try and do this with classes, I
> >> find that variables set in a class included from a node, are not
> >> visible to other classes included from that node.
>
> >> node 'node1.fr.xxx.com' {
> >> include facility::sjc
> >> include ldap::client
>
> >> }
>
> >> In this example, variables defined in facility::sjc are not visible in
> >> ldap::client (in this case, it would be the IP address of the local
> >> LDAP server).
>
> >> Another approach is to do everything with node inheritance, but in
> >> order to model these three functions, you end up with nodes with names
> >> like sjcDellBootServer or nycVmwareBootServer, which is just plain
> >> stupid.
>
> > Node names don't need to adapt to inheritance's logic.
> > You can do something like:
> > node sjc {
> > ldap_server="10.10.10.10"
> > }
>
> > node 'node1.fr.xxx.com' inherits sjc {
> > include ldap::client
> > }
>
> > When using nodes' inheritance the only real thing you've to care about
> > is to define variables BEFORE including any class.
> > So at the end it's better to include classes only in the node that
> > defines your host nad never in the "intermediary" nodes that can
> > represent facilities, networks or whatever.
>
> That's awful. If you can't build an inheritance tree from generic to
> specific, and assign variables at each step, that's a loss of a lot of
> functionality, and just about makes everything impossible.
You misunderstood. You can assign variables at each "step" in the
inheritance tree, and redefine them at more specific node steps.
It's just important to include whatever classes you need in your node
at the end of the inheritance tree, at the host-node level.
You could actually include classes in step-nodes only if they don't
use variables that might be defined (or redefined) at more specific
steps. That's why it's safer to include classes at the end, at host-
node level and define your variables, according to whatever logic you
need, in the nodes inheritance tree.
> And, even if I do that, only including classes in the final node...
>
> class A {
> $var = 1
>
> }
>
> class B {
> < do something with $var >
>
> }
>
> node A {
> include class A
> include class B
>
> }
>
> This doesn't work! But, it's doing what you suggested. Class B does
> not have access to $var, because it's out of scope. This is exactly
> what I want to do. I want to define an LDAP server variable in class
> A, and then use it in class B.
>
> Doug
You can do something like:
class B {
include A
< do something with ${A::var}
}
or, cleaner, define all your variables in a separated subclass that
can be included by every class that needs these variables (included
the same A class):
class B {
include A::params
< do something with ${A::params::var}
}
class A {
include A::params
# These A variables can be shared by other classes that include
A::params
}
Would this work?
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Variable Scoping = Root Canal
On Jun 27, 3:02 am, Douglas Garstang wrote: > > So... what am I missing here, and why is such a simple thing so > complicated in puppet? I'm not even sure if this email is lucid. I am > really annoyed and frustrated as hell. The only way I've found to do this and stay sane is to use extlookup.rb [0]. I resisted [1] for a while, since I kept telling myself that surely there had to be a good way to do this using only the base puppet functionality, but my life got much better once I gave in. [0] http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php [1] http://groups.google.com/group/puppet-users/browse_thread/thread/86c76e705b4ebe6c All the best, Brian Pitts -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Variable Scoping = Root Canal
Brian wrote: > On Jun 27, 3:02 am, Douglas Garstang wrote: >> So... what am I missing here, and why is such a simple thing so >> complicated in puppet? I'm not even sure if this email is lucid. I am >> really annoyed and frustrated as hell. > > The only way I've found to do this and stay sane is to use > extlookup.rb [0]. > Of interest perhaps here is that we're looking to put RI's extlookup function into core with 2.6 and adding JSON and YAML back-ends to the existing CSV back-end. Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
