I’ve seen this before as well. It appears to be documented in PUP-2931. There
are a lot of issues running the Puppet CA in an active/active HA configuration
like this. I suggest you pick one master to be the CA and send all CA requests
to that master.
--
You received this message because you a
Did you ever get to the bottom of this? I'm seeing a similar issue. We
have a janky dual master setup where one master rsyncs /var/lib/puppet (and
uses the same certificate) from the other master and the other master runs
haproxy and sends 60% of requests to the other one. We are seeing some
n
On 10/29/2014 07:27 PM, Cliff Wells wrote:
>
> Key compomise is the default revocation reason; that's what Puppet
> will record if no other is specified.
>
> I remain dubious that anything within Puppet automatically revoked
> your certificates.
>
>
> I'm not. We've also experienced
On Wednesday, March 19, 2014 2:14:15 PM UTC-7, jcbollinger wrote:
>
>
>
> On Wednesday, March 19, 2014 10:15:19 AM UTC-5, st...@wtfast.com wrote:
>>
>> What would happen if I chattr +i ca_crl.pem to prevent it being updated?
>>
>> Certificate revocation is something that should be manually contro
I'm not sure about test suite or UI terminii, I'm just running Puppet from
the repos at puppetlabs (its not Puppet enterprise). This is happening in
production but I can't reproduce it, it just happens apparently at random.
I've set the crl file immutable, hopefully next time something tries to
On Wednesday, March 19, 2014 10:15:19 AM UTC-5, st...@wtfast.com wrote:
>
> What would happen if I chattr +i ca_crl.pem to prevent it being updated?
>
> Certificate revocation is something that should be manually controlled
> anyway.
>
> Suppose that the Puppet error message is wrong (or at leas
What would happen if I chattr +i ca_crl.pem to prevent it being updated?
Certificate revocation is something that should be manually controlled
anyway.
Suppose that the Puppet error message is wrong (or at least misleading) and
the problem is not revocation. If the crl.pem file is immutable and
No. Only one puppet master.
On Wednesday, March 19, 2014 7:56:23 AM UTC-7, Jesse Throwe wrote:
>
> Steve,
>
> Do you, perchance, have multiple puppet masters in play?
>
> On Wed, Mar 19, 2014 at 9:58 AM, jcbollinger
> >
> wrote:
> >
> >
> > On Tuesday, March 18, 2014 10:25:02 AM UTC-5, st..
I don't have one of the actual messages handy right now but when it occurs
I run 'puppet agent --test' and instead of doing its work it presents an
error message which explains that the certificate (of the node I ran puppet
on) has been revoked. This is what led me to believe that the problem wa
Steve,
Do you, perchance, have multiple puppet masters in play?
On Wed, Mar 19, 2014 at 9:58 AM, jcbollinger wrote:
>
>
> On Tuesday, March 18, 2014 10:25:02 AM UTC-5, st...@wtfast.com wrote:
>>
>> These are not new nodes but not old either, only a few months. The
>> date/time is correct. The DN
On Tuesday, March 18, 2014 10:25:02 AM UTC-5, st...@wtfast.com wrote:
>
> These are not new nodes but not old either, only a few months. The
> date/time is correct. The DNS is correct. I have not manually set
> certificate lifetimes to be shorter than the default. However sometimes
> these nod
These are not new nodes but not old either, only a few months. The
date/time is correct. The DNS is correct. I have not manually set
certificate lifetimes to be shorter than the default. However sometimes
these nodes might not check in for a few days.
This was recently a big problem as the cert
On Monday, March 17, 2014 1:26:03 PM UTC-5, st...@wtfast.com wrote:
>
> Hi,
> I've been having issues with certificates being revoked without any human
> intervention or oversight; one day a node will try to do an update and it
> can't because its certificate is revoked.
>
> There is definitely
13 matches
Mail list logo
