[Puppet Users] Trouble adding client to Master -Not using expired certificate for ca from cache

[Veera Mani]

Hi,

I am running  puppet-server-2.7.25-1.el5  and puppet-2.7.20-1.el6.rf.noarch 
clients.

A puppet client   which is  running for  more than 5 years  is  rebuild  
and   while adding the server to the puppet infrastructure again , we are 
facing the below error.
The client  is  properly removed  from the master before it is re-built.  
But still  while adding the server back , the error occurs. 

running on Jul19 .. 

[root@client1 setup]# puppet agent --server wfpuppet.example.com 
>> --waitforcert 60 --test
>
> info: Creating a new SSL key for client1.example.com
>
> info: Caching certificate for ca
>
> info: Creating a new SSL certificate request for client1.example.com
>
> info: Certificate Request fingerprint (md5): 
>> CE:73:92:B6:37:76:52:57:45:86:C5:D8:68:22:3F:A0
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Caching certificate for ca
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Caching certificate for ca
>
> info: Caching certificate for client1.example.com
>
> info: Retrieving plugin
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at
>
>
>> ... Truncated ..
>
>
>> err: Could not retrieve catalog from remote server: 
>> Thread(#) not locked.
>
> warning: Not using cache on failed catalog
>
> err: Could not retrieve catalog; skipping run
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
> info: Not using expired certificate for ca from cache; expired at Tue Jul 
>> 16 19:12:20 UTC 2019
>
>
>> Truncated 
>
> err: Could not request certificate: stack level too deep
>
>

The configuration remains the same as in any  client which is working fine. 
Still facing the error?
Is puppet master caching the  expired certificate from cache ?

"expired certificate for ca from cache;"



I have  followed the below  puppet docs :

https://ask.puppet.com/question/16111/how-to-renew-expired-puppetmaster-certificates/
https://ask.puppet.com/question/32858/warning-certificate-puppet-ca-will-expire-on-how-to-renew-certificates-on-302/
 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e29c37cd-4d69-44a6-b51f-5eefaccff99f%40googlegroups.com.

Re: [Puppet Users] Puppet Module Best Practice (Roles/Profiles)

[Rob Nelson]

There are times auto-loading resources from hiera data makes sense, such as
mlocal users or sudoer.d snippets (though PLEASE use .each instead of
create-resources!). These resources should absolutely be resources you in
no way manage anywhere else. For sudoer.d, you might “include sudo;
$sudoers.each ...” in a base class and then use deep merges to populate the
hash in hiera, and that’s fine.

Where you can easily run into problems with this is with resource types
that are often managed elsewhere. Files, especially. It’s so easy to have a
hash of files that you keep adding to, and one day you end up with catalog
compilation failing because of duplicate resources because some “one-off”
fix you made now conflicts with a component module you use (ask me how I
know!). Even still, it IS possible to do this with careful maintenance.


I would ask why, though? The underlying concept of roles and profiles is to
use composition to create your desired state through layers. Having a
catch-all class works against such composition, you lose granularity
quickly. Your hiera data and hierarchy can get very complex as you try to
deliver certain resources to certain nodes via YAML, when it would be a lot
simpler to deliver those same resources through a properly composed role
written in Puppet DSL.

A simple (contrived) example might two nodes that get all their config
through a profile::base class via create_resources/.each. One is a web
server, the other a database server. The first needs an Apache config file,
an sshd.config file, and an application config file. The second needs a
my.cnf and an sshd.config file. You could place the sshd.config data in
default.yaml, the Apache and app configs in node_service/app1.yaml, and the
MySQL file in node_service/database.yaml. So far, so good.

Some time goes by and you decide to experiment with nginx and app1. You can
leave the app config in node_service/app1.yaml, but you have to move the
Apache config somewhere and add another layer to the hierarchy for the
webserver. Then  more time goes on and you see new config options for nginx
that are only available in rhel8, so you have to add a hierarchy level for
osfamily version+webserver. This rabbit hole gets deep, quickly.

Alternatively, you could assign role::MySQL (profile::base, profile::MySQL)
and role::app1::apache (profile::base, profile::Apache, profile::app1) to
the two nodes. When you check out nginx, you create role::app1::nginx
(profile::base, profile::nginx, profile::app1). Each config file is
included via the specific profile, and the data hierarchy is simpler
(default, osfamilyd/). This is far easier to hold in your head,
troubleshoot, and extend IMO.

I definitely think composition has significant benefits over using
catch-all parameters, though specific “collected” parameters can be
leveraging safely. I also think that managing YAML gets ugly quickly, not
to mention it is more reminiscent of certain other CM systems . In any
case, I hope this helps you evaluate the pros and cons of each approach and
how to find the solution that works for you!

On Thu, Jul 18, 2019 at 10:06 PM Lesley Kimmel 
wrote:

> As a trivial example maybe we suddenly found that we needed to add a
> configuration file to a bunch of systems quickly. Because my coworker's
> class includes a generic call to 'create_resources("file")' we can
> arbitrarily add any file with any content by simply adding some data to
> Hiera. Realistically, we should want to get this particular file integrated
> into a profile at some point. However, since it's so quick and easy to just
> add it to Hiera my coworker believes it is the better solution.
>
> However, that is somewhat besides the point. I guess the question may more
> accurately be asked as "Why is using profiles with focused base modules
> generally considered a best practice but a very generic, but flexible class
> (as described) is not?"
>
> On Thursday, July 18, 2019 at 8:49:25 PM UTC-5, LinuxDan wrote:
>>
>> There appears to be contradiction here.
>> If “one-off” changes for “new functionality” are needed, why are the
>> changes going into a base/profile module ?
>> Would some more specific and detailed examples be possible ?
>>
>> —
>>
>> "Sometimes I think the surest sign that intelligent life exists elsewhere
>> in the universe is that none of it has tried to contact us."
>>
>> Bill Waterson (Calvin & Hobbes)
>>
>> On Jul 18, 2019, at 8:59 PM, Lesley Kimmel  wrote:
>>
>> Hi all;
>> I'm a Linux engineer who went through a typical growth period with Puppet
>> and finally landed on the Roles and Profiles pattern which generally works
>> well.
>>
>> I have a coworker that started on after me and doesn't like this pattern
>> and having to update profiles or base modules when new functionality is
>> needed; especially for quick one-off things.
>>
>> So he's basically started creating one class containing 'create_resource'
>> declarations for the standard Puppet 

Re: [Puppet Users] Puppet Module Best Practice (Roles/Profiles)

[Lesley Kimmel]

As a trivial example maybe we suddenly found that we needed to add a 
configuration file to a bunch of systems quickly. Because my coworker's 
class includes a generic call to 'create_resources("file")' we can 
arbitrarily add any file with any content by simply adding some data to 
Hiera. Realistically, we should want to get this particular file integrated 
into a profile at some point. However, since it's so quick and easy to just 
add it to Hiera my coworker believes it is the better solution.

However, that is somewhat besides the point. I guess the question may more 
accurately be asked as "Why is using profiles with focused base modules 
generally considered a best practice but a very generic, but flexible class 
(as described) is not?"

On Thursday, July 18, 2019 at 8:49:25 PM UTC-5, LinuxDan wrote:
>
> There appears to be contradiction here. 
> If “one-off” changes for “new functionality” are needed, why are the 
> changes going into a base/profile module ?
> Would some more specific and detailed examples be possible ?
>
> —
>
> "Sometimes I think the surest sign that intelligent life exists elsewhere 
> in the universe is that none of it has tried to contact us."
>
> Bill Waterson (Calvin & Hobbes)
>
> On Jul 18, 2019, at 8:59 PM, Lesley Kimmel  > wrote:
>
> Hi all;
> I'm a Linux engineer who went through a typical growth period with Puppet 
> and finally landed on the Roles and Profiles pattern which generally works 
> well.
>
> I have a coworker that started on after me and doesn't like this pattern 
> and having to update profiles or base modules when new functionality is 
> needed; especially for quick one-off things.
>
> So he's basically started creating one class containing 'create_resource' 
> declarations for the standard Puppet resource types (file, user, group, 
> exec, etc.). Then he just adds all of the appropriate parameters in hashes 
> in Hiera. He's convinced this is the right way to do it since he hasn't yet 
> ran into a scenario where this doesn't work easily.
>
> I told him if it was the right way then all the smart people working with 
> and developing Puppet would have put it out as the best practice. However, 
> I can't seem to come up with a really great scenario that will convince 
> him. Can anyone share thoughts on scenarios where this patter will blow up 
> [hard]?
>
> Thanks!
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/c46b1e54-f3c1-4429-b270-68189e6937f0%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8143b443-4a28-45b4-9931-d200e3e91223%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Module Best Practice (Roles/Profiles)

['Dan White' via Puppet Users]

There appears to be contradiction here. 
If “one-off” changes for “new functionality” are needed, why are the changes 
going into a base/profile module ?
Would some more specific and detailed examples be possible ?

—
"Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us."
Bill Waterson (Calvin & Hobbes)

> On Jul 18, 2019, at 8:59 PM, Lesley Kimmel  wrote:
> 
> Hi all;
> I'm a Linux engineer who went through a typical growth period with Puppet and 
> finally landed on the Roles and Profiles pattern which generally works well.
> 
> I have a coworker that started on after me and doesn't like this pattern and 
> having to update profiles or base modules when new functionality is needed; 
> especially for quick one-off things.
> 
> So he's basically started creating one class containing 'create_resource' 
> declarations for the standard Puppet resource types (file, user, group, exec, 
> etc.). Then he just adds all of the appropriate parameters in hashes in 
> Hiera. He's convinced this is the right way to do it since he hasn't yet ran 
> into a scenario where this doesn't work easily.
> 
> I told him if it was the right way then all the smart people working with and 
> developing Puppet would have put it out as the best practice. However, I 
> can't seem to come up with a really great scenario that will convince him. 
> Can anyone share thoughts on scenarios where this patter will blow up [hard]?
> 
> Thanks!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/c46b1e54-f3c1-4429-b270-68189e6937f0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/D0AB5B8B-A154-4300-805D-71CE593C3F02%40icloud.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Module Best Practice (Roles/Profiles)

[Lesley Kimmel]

Hi all;
I'm a Linux engineer who went through a typical growth period with Puppet 
and finally landed on the Roles and Profiles pattern which generally works 
well.

I have a coworker that started on after me and doesn't like this pattern 
and having to update profiles or base modules when new functionality is 
needed; especially for quick one-off things.

So he's basically started creating one class containing 'create_resource' 
declarations for the standard Puppet resource types (file, user, group, 
exec, etc.). Then he just adds all of the appropriate parameters in hashes 
in Hiera. He's convinced this is the right way to do it since he hasn't yet 
ran into a scenario where this doesn't work easily.

I told him if it was the right way then all the smart people working with 
and developing Puppet would have put it out as the best practice. However, 
I can't seem to come up with a really great scenario that will convince 
him. Can anyone share thoughts on scenarios where this patter will blow up 
[hard]?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c46b1e54-f3c1-4429-b270-68189e6937f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] [INFO] Removal of nightly release packages from main yum/apt sites

[Molly Waggett]

Hey folks!

In an effort to reduce clutter and confusion on some of our public download
sites, we are removing all *-nightly-release packages from yum.puppet.com
 and apt.puppet.com
. Links like yum.puppet.com/puppet-nightly
 and
apt.puppet.com/puppet-nightly 
WILL BE REMOVED TODAY.

Nightly repositories and packages can still be found at nightlies.puppet.com
.

If you have any questions or concerns about these changes, please reply-all
to this email.

Thanks!

-- 
*Molly Waggett*
she/her/hers
Release Engineer @ Puppet, Inc.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAFOE68CJS9WvTbH7ZK5zUyFGkw3m51gqr%2BRXmesKLiHyvCNF%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.