[Puppet Users] Multiple compile server and single CA server set up - certificate issues

[Soham Chakraborty]

Hi,

I am trying to achieve the following in Ubuntu 18.04 (bionic):

1) I want to have several Puppet servers act as compile masters. They will 
be load balanced and point to a DNS record in AWS. 

2) All the compile masters will share same Puppet CA server. The CA server 
be responsible for only signing certificates and nothing else.

This should be reasonably easy to implement but I am not getting odd SSL 
errors at every turn. I am looking to know how I should go about creating a 
setup like this with open source Puppet. The steps that I am following now 
are something like this:

1) Provision the instance from a packer template. I am installing Puppet 
5.5.6 from the packer template.
2) Login to the server and install puppetserver. 
3) Disable internal CA service from services.d/ca.cfg file.
4) Edit puppet.conf to point master to the DNS name of the load balancer. 
Don't do any change of ca server for now. Don't run any puppet agent as 
well.
5) Provision another instance from the same packer template. 
6) Install puppetserver. 
7) Edit it's puppet.conf to point to the DNS name of the load balancer and 
also change ca server to this server itself.
8) Run puppet agent -t on the compile master created in step 1.
9) Sign the cert in CA server. 

Is this all that there is? Do I need to do any config change in the 
webserver.conf of the Puppet compile master? If so, what would be required 
changes? What files should be copied over from the CA server to the compile 
server?

What files need to be copied over from CA server to the compile server and 
where they should be placed? 

Right now in my CA server, I am getting this error: 

# puppet agent -t
Warning: Setting autosign is deprecated.
   (location: 
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/settings.rb:1169:in 
`issue_deprecation_warning')
Warning: Setting ca is deprecated.
   (location: 
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/settings.rb:1169:in 
`issue_deprecation_warning')
Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: SSL_connect returned=1 errno=0 state=error: certificate verify 
failed: [ok for /CN=puppetserver.org.com]
Info: Retrieving pluginfacts
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate 
additional resources using 'eval_generate': SSL_connect returned=1 errno=0 
state=error: certificate verify failed: [ok for /CN=puppetserver.org.com]
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: 
Could not retrieve file metadata for puppet:///pluginfacts: SSL_connect 
returned=1 errno=0 state=error: certificate verify failed: [ok for 
/CN=puppetserver.org.com]
Info: Retrieving plugin
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Failed to generate 
additional resources using 'eval_generate': SSL_connect returned=1 errno=0 
state=error: certificate verify failed: [ok for /CN=puppetserver.org.com]
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Could not evaluate: Could 
not retrieve file metadata for puppet:///plugins: SSL_connect returned=1 
errno=0 state=error: certificate verify failed: [ok for 
/CN=puppetserver.org.com]
Error: Could not retrieve catalog from remote server: SSL_connect 
returned=1 errno=0 state=error: certificate verify failed: [ok for 
/CN=puppetserver.org.com]
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Error: Could not send report: SSL_connect returned=1 errno=0 state=error: 
certificate verify failed: [ok for /CN=puppetserver.org.com]
root@puppet-ca-server:~#

And in Puppet compile master, I am getting:

# puppet agent -t
Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: execution expired
Info: Retrieving pluginfacts
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate 
additional resources using 'eval_generate': execution expired
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: 
Could not retrieve file metadata for puppet:///pluginfacts: execution 
expired
Info: Retrieving plugin
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Failed to generate 
additional resources using 'eval_generate': execution expired
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Could not evaluate: Could 
not retrieve file metadata for puppet:///plugins: execution expired
Error: Could not retrieve catalog from remote server: execution expired
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
root@puppetserver:~#

The nodes are not yet in site.pp but I would expect the errors to be 
different. 

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/c6d93372-bb2d-4f6b-8db8-136cbd55f464%40googlegroups.com.
For more

[Puppet Users] Upgrade to puppet-agent 5.3.5 report failure

[Darragh Bailey]

Hi,


Currently in the process of testing out an upgrade to version 5 of the 
puppet-agent within our local virtual environment used to validate changes 
before they can be landed and I'm running into a few problems around the 
report at the end run.

Have 5 VMs in a vagrant environment, that are initially bootstrapped with 
some scripts to get the puppet 5 packages installed, then uses puppet apply 
to perform some initial setup around network/apt-caching, followed by 
applying the 'puppet_server' provisioner which runs puppet agent.

Unfortunately I'm seeing an error, that doesn't occur on all the VM's and 
I'm not sure how to debug it further or understand what's missing.

vagrant up
...
==> srv-1: Warning: Event['previous_value'] contains a Process::Status 
value. It will be converted to the String 'pid 30408 exit 1'
==> srv-1: Warning: Event['previous_value'] contains a Process::Status 
value. It will be converted to the String 'pid 32434 exit 1'
==> srv-1: Error: Could not send report: Error 400 on SERVER: Bad Request: 
The request body is invalid: Could not intern from json: Internal Error: 
Puppet Context ':loaders' missing

==> srv-3: Warning: Event['previous_value'] contains a Process::Status 
value. It will be converted to the String 'pid 28777 exit 1'
==> srv-3: Error: Could not send report: Error 400 on SERVER: Bad Request: 
The request body is invalid: Could not intern from json: Internal Error: 
Puppet Context ':loaders' missing


What is also surprising is that it doesn't occur on all of the VM's, and 
subsequently it doesn't appear if I re-run the provisioning with: vagrant 
up --provision --provision-with puppet_server

There was a suggestion that there could be some stale code around as the 
image starts with puppet 3 pre-installed, but I've got the bootstrapping 
scripts to purge the old packages and delete any files that could have been 
placed under /var/lib/puppet and /etc/puppet

bash code:

package=puppet5-release-xenial.deb
env https_proxy=$HTTPS_PROXY wget \
--quiet --continue -O /tmp/$package https://apt.puppetlabs.com/$package
dpkg -i /tmp/$package
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get purge --yes puppet hiera facter
rm -rf /var/lib/puppet /etc/puppet
apt-get install --yes --no-install-recommends puppet-agent=5.3.5-1xenial 
ruby policykit-1

Currently pinned to 5.3.5 because there was an issues with a subsequent 
release and decided to just pin to the same version as the upgraded puppet 
master was running.

I've tried switching the clients to 5.5.8 and I get the same error, so it's 
not solved by moving to the most recent version.

Grep'ing through /var/lib/puppet hasn't been illuminating, didn't spot 
anything when switching it to use debug, and neither has been inspecting 
the puppet master log so I'm not sure where exactly to look?

The quick fix is to disable reporting within the virtual environment, which 
certainly solves the problem, but seems like the wrong approach.

Any thoughts on how to debug this? What do I need to enable on the puppet 
master to be able to capture report requests both good and bad so I can see 
what it is that is being sent that gets rejected, and what should be sent?

--
Darragh Bailey

-- 
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/7eb96a09-bc89-4b02-b014-9dcaef16612e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Elegant way to supply facts to `puppet apply`

[jcbollinger]

On Monday, November 26, 2018 at 12:51:57 PM UTC-6, Abhijeet Rastogi wrote:
>
>
> puppet lookup command has a nice --facts option which accepts a 
> structured json/yaml file to upload files.
>
> Why does that option not exist for puppet apply? Is the environment 
> variable the only option?
>
>

puppet apply presumes that you want to use the facts for the local node, 
since that's the node to which the generated catalog will be applied.  It 
therefore uses the same mechanism to determine the appropriate facts as the 
agent does, which, by default, is by running facter.

puppet lookup has a different orientation.  It is an alternative to a 
*server*-side mechanism, rather than a client-side one.  Therefore, it does 
not assume that you want to use the facts for the current node.  The --facts 
option provides a convenient mechanism for communicating multiple facts and 
structured facts to it, since it cannot rely on being fed the facts 
internally by the catalog builder.

Other responses have already pointed out that puppet apply does afford you 
other alternatives, which you can access by manipulating the facts_terminus 
setting. You should be able to do that either in the config file or on the 
command line.  In particular, there is a "yaml" facts terminus, though it's 
unclear to me how it chooses the file from which to read facts.


John

-- 
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/a3c1406e-9266-4ea8-8ed9-da82969e1884%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Elegant way to supply facts to `puppet apply`

[Eric Sorenson]

You could put that same yaml or json in /etc/puppetlabs/facter/facts.d and 
the whole data structure will be available under $facts ...

--eric0

On Monday, November 26, 2018 at 11:14:27 AM UTC-8, Henrik Lindberg wrote:
>
> On 2018-11-23 03:27, Abhijeet Rastogi wrote: 
> > Hi everyone, 
> > 
> > 
> > puppet lookup command has a nice --facts option which accepts a 
> > structured json/yaml file to upload files. 
> > 
> > Why does that option not exist for puppet apply? Is the environment 
> > variable the only option? 
> > 
>
> There is a way to make it read other facts than the default getting the 
> facts for the node apply is running on. To use that you need to change 
> the facts terminus setting 
> https://puppet.com/docs/puppet/5.3/indirection.html#yaml-terminus-1 
>
> Warning: That is not easy to use. 
>
> For puppet lookup we wanted something simpler and choose to expose the 
> option directly as it is a common use case to experiment with lookup CLI 
> and different facts. 
>
> Suggest you file a ticket with a feature request for puppet apply. 
>
> Best, 
> - henrik 
>
> > Puppet version: 6.0.4 
> > 
> > Thanks, 
> > Abhijeet 
> > 
> > -- 
> > 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/c9c7ea63-cd97-4dbc-9c45-ee78e5cb9d4b%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/puppet-users/c9c7ea63-cd97-4dbc-9c45-ee78e5cb9d4b%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
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/bf91272c-4872-455f-871b-bf1a23edfe83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.