CODEWITHSUNDEEP
puppet
Seyi Agboola
Seyi Agboola

Reputation: 59

why am I getting this error and what is solution doing to fix the error?

I am new to puppet I got this error on the puppet slave. After a bit of research on the internet, I found a solution that works, unfortunately, there was not a precise explanation as to the cause of the error or what the code was doing that fixed the issue. I really do not appreciate copy and pasting codes without understanding what the code is doing and how it was fixed/ I would really appreciate it if I can get an explanation of why the error occurred and what the code is doing to fix this issue thanks.

Error Message

Warning: Unable to fetch my node definition, but the agent run will continue:

Warning: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Info: Retrieving pluginfacts

Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate additional resources using 'eval_generate': SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet:///pluginfacts: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Info: Retrieving plugin

Error: /File[/opt/puppetlabs/puppet/cache/lib]: Failed to generate additional resources using 'eval_generate': SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Error: /File[/opt/puppetlabs/puppet/cache/lib]: Could not evaluate: Could not retrieve file metadata for puppet:///plugins: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Info: Loading facts

Error: Could not retrieve catalog from remote server: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Warning: Not using cache on failed catalog

Error: Could not retrieve catalog; skipping run

Error: Could not send report: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Solution

[root@host ~]# puppet config print ssldir

/etc/puppetlabs/puppet/ssl

[root@host ~]# mkdir /tmp/puppet-ssl-orig

[root@host ~]# mv /etc/puppetlabs/puppet/ssl/* /tmp/puppet-ssl-orig

[root@host ~]# puppet agent -t

Upvotes: 1

Views: 5880

Answers (2)

Vincent Gerris
Vincent Gerris

Reputation: 7557

Puppet sucks and this SSL nonsense is one of the big reasons. Here is the quick and dirty way, for CentOS 7 and puppet 6 I believe. Note that this removes the certs on both sides so if other clients used the master, you will have to reset them too.

Conditions : hostname op both client and server is known to both ( for example host entries in /etc/hosts with proper name and IP, or DNS ).

On the master:

rm -rf $(puppet master --configprint ssldir)
systemctl restart puppetmaster

On the client:

rm -rf /etc/puppetlabs/puppet/ssl/
puppet agent --test --verbose #( agent run creates/requests certs )

Then on the master again:

puppet cert sign --all

Then run the agent again and it should work. It depends on the puppet version if intermediate CA certificates are used with all problems with that and there are incompatibilities between versions too.

Upvotes: 0

John Bollinger
John Bollinger

Reputation: 181932

The error messages you present show that the problem revolved around the agent failing to establish an SSL connection with the master. There isn't enough information in the messages themselves or the other materials presented to determine a priori the specific nature of the problem, but the mitigation you performed was to remove all the agent's stored certificates (including its own). From the fact that this solved the problem, we can deduce that the agent was rejecting the master's host certificate.

Very likely this situation arose from the agent previously having synced with a master, but then trying to request a catalog from a cryptographically different master. For example, reinstalling Puppet on the master will typically wipe out any previous cryptographic certificates, which could produce this effect. Or this is also what you would expect to happen if a bona fide evil actor tried to impersonate the real master with one under their own control (unless they had managed to steal the real master's certs).

In any event, wiping out the agent's existing certs would cause it to

  • generate a new certificate for itself and a corresponding certificate-signing request
  • accept the master's certificate and CA certificate upon the next catalog request, and submit the CSR
  • accept a new signed certificate for itself from the master

That all the certificate-signing bits succeeded indicates also that the master had no record of a certificate previously issued to this particular agent, which also supports the theory of the master having been swapped out from under the agent.

Upvotes: 0

Related Questions