[Puppet Users] Getting puppet bolt to work with facts

[Andy Hall]

So I have a plan where I get facts...here is the relevant section...

  $target_facts = run_plan('facts', 'targets' => $targets)
  $target_facts.each |$result| {
  $target = $result['target']
  $targetfacts = $result['value']
  $os_release = $targetfacts['os']['release']['major']
  $kernel_version = $targetfacts['kernelrelease']

But I get this error...

  Evaluation Error: Operator '[]' is not applicable to an Undef Value.

This is referring to the following line which attempts to assign a fact...

  $os_release = $targetfacts['os']['release']['major']

Any ideas what I am doing wrong here ?

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/bdb4434a-d308-48b3-aa8d-c92fb964f873n%40googlegroups.com.

[Puppet Users] issue regenerating puppetserver CA cert to add DNS alt names

[Andy Hall]

we are running puppetserver 6.12 and are following the guide here to
regenerate the cert to add dns alt names :
https://puppet.com/docs/puppet/6.21/ssl_regenerate_certificates.html#regenerate_agent_certs_and_add_dns_alt_names

however there are a number of steps which fail because essentially the
puppetserver can either no longer respond due to the cert being
revoked or because it has been stopped ( please see output below ) am
I missing something here ?

[root@sl1-puppet puppetserver]# puppetserver ca clean --certname
sl1-puppet.server.domain.com
Revoked certificate for sl1-puppet.server.domain.com
Cleaned files related to sl1-puppet.server.domain.com

[root@sl1-puppet puppetserver]# puppet ssl clean
Error: Could not run: Failed to connect to the CA to determine if
certificate sl1-puppet.server.domain.com has been cleaned
Wrapped exception:
certificate verify failed [certificate revoked for
CN=sl1-puppet.server.domain.com]

[root@sl1-puppet puppetserver]# puppet resource service puppetserver
ensure=stopped
Notice: /Service[puppetserver]/ensure: ensure changed 'running' to 'stopped'
service { 'puppetserver':
  ensure   => 'stopped',
  provider => 'systemd',
}

[root@sl1-puppet puppetserver]# puppetserver ca generate --certname
sl1-puppet.server.domain.com --subject-alt-names
puppet,ld4-puppet-lb.server.domain.com --ca-client
Fatal error when running action 'generate'
  Error: Failed connecting to
https://sl1-puppet.server.domain.com:8140/status/v1/simple/ca
  Root cause: 503 "Service Unavailable"

thanks very much for any help you can provide on this.

-- 
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/CAOp5WB4xs%2BGCVbd_CO8TETYx_%2BAhdt1RjmjFbJmwj4mSctjieg%40mail.gmail.com.

[Puppet Users] Re: Reminder: Puppet Platform GPG signing changes starting January 11, 2021, action may be required

[Andy Hall]

OK great that makes sense...in fact I guess you mean since July 2019 as I 
see the newer key in puppet6-release from a while ago which is good...

# rpm -qi puppet6-release
Name: puppet6-release 
Version : 6.0.0 
Release : 5.el6  
Install Date: Sat 28 Sep 2019 01:15:09 PM BST

# rpm -ql puppet6-release
/etc/pki/rpm-gpg/RPM-GPG-KEY-2025-04-06-puppet6-release
/etc/pki/rpm-gpg/RPM-GPG-KEY-puppet6-release

Thanks.

On Tuesday, 12 January 2021 at 19:01:46 UTC eric.g...@puppet.com wrote:

> Hi Andy, 
>
> Sorry for the confusion. Let's see if I can clear it up.
>
> The release packages already contain both the old key (due to expire 
> August 17, 2021) and the new key (due to expire April 6, 2025). They've 
> been this way since last July. The Description is misleading, I admit.
>
> Yesterday, I flipped an internal switch that any packages released after 
> the switch would be signed with the new key. Puppet Platform will continue 
> their normal release process and will be viable with either key until the 
> old one expires in August.
>
> As this rolls out in the coming weeks, I won't be terribly surprised if 
> there's an occasional unforeseen problem with a package.  I encourage 
> bringing any issues to our attention and we'll work to fix them as quickly 
> as I can.
>
> Eric
>
> On Tuesday, January 12, 2021 at 3:43:41 AM UTC-8 Andy Hall wrote:
>
>> hey eric why do we not see the latest key in the release packages then ? 
>> thanks.
>>
>> # yum info puppet-release
>> Available Packages
>> Name: puppet-release
>> Arch: noarch
>> Version : 1.0.0
>> Release : 14.el6
>> Description : Release packages for the Puppet repository
>> : 
>> : Contains the following components:
>> : gpg_key 2019.4.8
>> : repo_definition 2020.06.02
>>
>> # yum info puppet6-release
>> Available Packages
>> Name: puppet6-release
>> Arch: noarch
>> Version : 6.0.0
>> Release : 10.el6
>> Description : Release packages for the Puppet 6 repository
>> : 
>> : Contains the following components:
>> : gpg_key 2019.4.8
>> : repo_definition 2020.05.18
>>
>> On Monday, 11 January 2021 at 22:05:04 UTC eric.g...@puppet.com wrote:
>>
>>>
>>> Puppet Platform GPG signing was initially scheduled for November last 
>>> year but it was delayed until just now.
>>>
>>> Today I made the internal change to start signing with the updated key.
>>>
>>>
>>> On Wednesday, October 21, 2020 at 4:24:41 PM UTC-7 Eric Griswold wrote:
>>>
>>>> Why This Change 
>>>>
>>>> Puppet sets its package signing keys to expire on a set schedule for 
>>>> good security practices.
>>>> Summary 
>>>>
>>>> On November 2, 2020, Puppet Release Engineering will start signing 
>>>> Puppet Platform and Puppet Enterprise packages with an updated GPG key.
>>>> This is an explanation of how various existing users will be affected 
>>>> by this change and what actions they will need to take. 
>>>>
>>>> FOSS users can update their release packages and import the new GPG key 
>>>> now so that when the GPG key changes, they will not see any problems 
>>>> installing software.
>>>> Puppet Enterprise Users 
>>>>
>>>> Puppet Enterprise users do not need to take any specific action, the 
>>>> GPG change will be handled inside the PE installer.
>>>> FOSS Users 
>>>>
>>>> Puppet Release Engineering updated the yum and apt release packages to 
>>>> contain both the new key and the current key just before June 3, 2020. If 
>>>> you have installed or updated the release package since that date you 
>>>> should already have the new key.
>>>>
>>>> SLES users, however, need to take an additional step:
>>>> SLES Users 
>>>>
>>>> SLES users need to take these steps. (Replace "puppet-release" with 
>>>> "puppet5-release" or "puppet6-release" if you are using those packages) 
>>>>
>>>>1. 
>>>>
>>>>Download the updated GPG key: $ curl --remote-name --location 
>>>>https://yum.puppet.com/RPM-GPG-KEY-puppet-20250406
>>>>2. 
>>>>
>>>>Import the updated GPG key: $ sudo rpm --import 
>>>>RPM-GPG-KEY-p

[Puppet Users] Re: Reminder: Puppet Platform GPG signing changes starting January 11, 2021, action may be required

[Andy Hall]

hey eric why do we not see the latest key in the release packages then ? 
thanks.

# yum info puppet-release
Available Packages
Name: puppet-release
Arch: noarch
Version : 1.0.0
Release : 14.el6
Description : Release packages for the Puppet repository
: 
: Contains the following components:
: gpg_key 2019.4.8
: repo_definition 2020.06.02

# yum info puppet6-release
Available Packages
Name: puppet6-release
Arch: noarch
Version : 6.0.0
Release : 10.el6
Description : Release packages for the Puppet 6 repository
: 
: Contains the following components:
: gpg_key 2019.4.8
: repo_definition 2020.05.18

On Monday, 11 January 2021 at 22:05:04 UTC eric.g...@puppet.com wrote:

>
> Puppet Platform GPG signing was initially scheduled for November last year 
> but it was delayed until just now.
>
> Today I made the internal change to start signing with the updated key.
>
>
> On Wednesday, October 21, 2020 at 4:24:41 PM UTC-7 Eric Griswold wrote:
>
>> Why This Change 
>>
>> Puppet sets its package signing keys to expire on a set schedule for good 
>> security practices.
>> Summary 
>>
>> On November 2, 2020, Puppet Release Engineering will start signing Puppet 
>> Platform and Puppet Enterprise packages with an updated GPG key.
>> This is an explanation of how various existing users will be affected by 
>> this change and what actions they will need to take. 
>>
>> FOSS users can update their release packages and import the new GPG key 
>> now so that when the GPG key changes, they will not see any problems 
>> installing software.
>> Puppet Enterprise Users 
>>
>> Puppet Enterprise users do not need to take any specific action, the GPG 
>> change will be handled inside the PE installer.
>> FOSS Users 
>>
>> Puppet Release Engineering updated the yum and apt release packages to 
>> contain both the new key and the current key just before June 3, 2020. If 
>> you have installed or updated the release package since that date you 
>> should already have the new key.
>>
>> SLES users, however, need to take an additional step:
>> SLES Users 
>>
>> SLES users need to take these steps. (Replace "puppet-release" with 
>> "puppet5-release" or "puppet6-release" if you are using those packages) 
>>
>>1. 
>>
>>Download the updated GPG key: $ curl --remote-name --location 
>>https://yum.puppet.com/RPM-GPG-KEY-puppet-20250406
>>2. 
>>
>>Import the updated GPG key: $ sudo rpm --import 
>>RPM-GPG-KEY-puppet-20250406
>>3. 
>>
>>Update the SLES puppet-release package $ zypper update puppet-release
>>
>> All Other FOSS users 
>>
>> All other FOSS users need only upgrade to the latest puppet-release 
>> package. (Replace "puppet-release" with "puppet5-release" or 
>> "puppet6-release" if you are using those packages) 
>>
>> For the apt users:  $ sudo apt-get upgrade puppet-release
>>
>> For the yum users: $ sudo yum update puppet-release
>> Further Notes 
>>
>> Puppet GPG signing key, 2020 edition 
>>  
>> contains this and some more information about updating the GPG key using 
>> Puppet.
>>
>> Eric Griswold
>>
>> Puppet Release Engineering
>>
>

-- 
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/bd59894b-82b0-43e0-ba19-bcc8ca000db6n%40googlegroups.com.

Re: [Puppet Users] updating concat breaks puppet run

[Andy Hall]

thanks for the explanation I'll update our code then the module and try 
again...

On Thursday, August 20, 2020 at 8:25:08 PM UTC+1 Ben Ford wrote:

> Subscribe to Concat['/etc/exports'] instead.
>
> The concat type used to be a defined type that wrapped a file resource 
> many years ago. It's now a first class citizen itself.
>
> On Thu, Aug 20, 2020 at 4:28 AM Andy Hall  wrote:
>
>> we have updated the concat module and it no longer likes our code...so
>> this used to work fine...
>>
>>   concat { "/etc/exports":
>> ensure => present,
>>   }
>>
>>   Concat::Fragment {
>> content => "# HEADER: This file is managed by Puppet. DO NOT EDIT.\n",
>> order   => '0',
>>   }
>>
>>   concat::fragment { 'nfs_exports_header':
>> target  => "/etc/exports",
>>   }
>>
>>   exec { 'reload_nfs_exports':
>> command => "exportfs -ra",
>> subscribe => File["/etc/exports"],
>> refreshonly => true,
>>   }
>>
>> ...but after updating to concat version 6.2 we get this error...
>>
>> Server Error: Could not find resource 'File[/etc/exports]' in
>> parameter 'subscribe' (file:
>>
>> /etc/puppetlabs/code/environments/production/modules/flex/manifests/profiles/archive/server.pp,
>> line: 34)
>>
>> what has changed for this to break ? does concat itself not declare
>> the file ? this works fine once we roll back the version.
>>
>> any help most appreciated 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/CAOp5WB7Ew4cz%3D1zo8oSHK4Y74kAdqteXWp%3DG%3D1YBZD3Vrx5Sxw%40mail.gmail.com
>> .
>>
>

-- 
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/da3ef8dc-564f-4a05-823d-e3f669888cd7n%40googlegroups.com.

[Puppet Users] updating concat breaks puppet run

[Andy Hall]

we have updated the concat module and it no longer likes our code...so
this used to work fine...

  concat { "/etc/exports":
ensure => present,
  }

  Concat::Fragment {
content => "# HEADER: This file is managed by Puppet. DO NOT EDIT.\n",
order   => '0',
  }

  concat::fragment { 'nfs_exports_header':
target  => "/etc/exports",
  }

  exec { 'reload_nfs_exports':
command => "exportfs -ra",
subscribe => File["/etc/exports"],
refreshonly => true,
  }

...but after updating to concat version 6.2 we get this error...

Server Error: Could not find resource 'File[/etc/exports]' in
parameter 'subscribe' (file:
/etc/puppetlabs/code/environments/production/modules/flex/manifests/profiles/archive/server.pp,
line: 34)

what has changed for this to break ? does concat itself not declare
the file ? this works fine once we roll back the version.

any help most appreciated 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/CAOp5WB7Ew4cz%3D1zo8oSHK4Y74kAdqteXWp%3DG%3D1YBZD3Vrx5Sxw%40mail.gmail.com.

Re: [Puppet Users] undefined method platform for nil:NilClass since puppetserver upgrade

[Andy Hall]

So here's a strange onewe rebooted the server and the problem has 
stopped. I think some of the puppetserver instances were not running 
properlywhich is why it was intermittentbut hey all OK now. Thanks.

On Thursday, July 16, 2020 at 3:55:54 PM UTC+1, Becca Robinson wrote:
>
> Hi Andy,
>
> I haven’t seen this before, but I have a thought.
> Have you tried removing the new line at the end so the closing of the 
> package resource collector isn’t on a new line?
>
> Similar to this?
>
>
> if("${rhsmtrue}" and $::operatingsystem == 'RedHat'){
>   Rhsm_register <| |> 
>   -> Yumrepo <| |> 
>   -> Package <| provider != ‘rpm' |>
> }
> else{
>  Yumrepo <| |> -> Package <| provider != 'rpm' |>
> }
>
> -- 
> *Becca Robinson*
>
>
>
>
> On Jul 16, 2020, at 2:14 AM, Andy Hall > 
> wrote:
>
> if("${rhsmtrue}" and $::operatingsystem == 'RedHat'){
>  Rhsm_register <| |> -> Yumrepo <| |> -> Package <| provider != 'rpm'
> |>  <-- THIS IS THE LINE IN QUESTION
> }
> else{
>  Yumrepo <| |> -> Package <| provider != 'rpm' |>
> }
>
>
>

-- 
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/cf1b9844-6912-4c8a-a2b2-b56bd8822e32o%40googlegroups.com.

[Puppet Users] undefined method platform for nil:NilClass since puppetserver upgrade

[Andy Hall]

hey there I recently update puppetserver to 6.12.1 ( along with
puppetdb to 6.11.2 and puppet-agent to 6.17.0 ) and occasionally on
some puppet runs ( I cannot determine why it happens sometimes and not
others ) we see the following reported...

Error while evaluating a Virtual Query, undefined method `platform'
for nil:NilClass (file:
/etc/puppetlabs/code/environments/production/manifests/site.pp, line:
14, column: 3)

...this is the very first manifest that gets parsed and here is the
code itself ( I have compressed it but will refer to the line in
question )...

# site.pp
# global resource defaults
Exec { path => '/bin:/sbin:/usr/bin:/usr/sbin' }
File { backup => 'main' }
User { managehome => true }
# global resource ordering - rhsm before yumrepos
$rhsmtrue = hiera('flex::general::redhat::manage_rhsm',false)
if("${rhsmtrue}" and $::operatingsystem == 'RedHat'){
  Rhsm_register <| |> -> Yumrepo <| |> -> Package <| provider != 'rpm'
|>  <-- THIS IS THE LINE IN QUESTION
}
else{
  Yumrepo <| |> -> Package <| provider != 'rpm' |>
}
# use flex roles and profiles for all nodes
node default {
  include ::flex
}

Can anyone please help explain what may be happening here ? I can
confirm that we do not see this error in our logs prior to the
upgrade.

As it is calling the "rhsm_register" type could it be the
subscription_manager module we are running is no longer supported by
the version of puppet ?

But surely you would not break code within a major 6.x release ?

Thanks for any help you can provide !!

-- 
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/CAOp5WB4FL-S41%2B6-BOSiD_zH6ju3OhxcxDF7-oaNpwJW0XhWmA%40mail.gmail.com.

[Puppet Users] Re: bad URI when parsing yumrepo baseurl

[Andy Hall]

OK my bad...I have included the string "baseurl=" in the actual baseurl 
attributesilly me. please ignore.

On Wednesday, 6 May 2020 17:10:28 UTC+1, Andy Hall wrote:
>
> please can someone tell me what is wrong with this as it is a valid URI 
> and should work...
>  
>  if ($::operatingsystemmajrelease == '5') or ($::operatingsystemmajrelease 
> == '6') {
> yumrepo { 'vmware-tools':
>   baseurl => "baseurl=
> http://packages.vmware.com/tools/releases/10.1.0/rhel${::operatingsystemmajrelease}/x86_64
> ",
>   descr  => 'vmware',
>   enabled => 1,
>   gpgcheck => 1,
>   gpgkey  => '
> https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub',
> }
>   }
>
> Error: Failed to apply catalog: Parameter baseurl failed on Yumrepo[vmware
> -tools]: Validate method failed for class baseurl: bad URI(is not URI?): 
> baseurl=http://packages.vmware.com/tools/releases/10.1.0/rhel6/x86_64
>
> as you can see this is a real URI: 
> http://packages.vmware.com/tools/releases/10.1.0/rhel5/x86_64
>
> the parser seems to be as follows: 
> https://github.com/ruby/ruby/blob/master/lib/uri/rfc3986_parser.rb
>
> 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/b27d756a-3f03-40ec-b58a-fc1e8675ce61%40googlegroups.com.

[Puppet Users] bad URI when parsing yumrepo baseurl

[Andy Hall]

please can someone tell me what is wrong with this as it is a valid URI and 
should work...
 
 if ($::operatingsystemmajrelease == '5') or ($::operatingsystemmajrelease 
== '6') {
yumrepo { 'vmware-tools':
  baseurl => 
"baseurl=http://packages.vmware.com/tools/releases/10.1.0/rhel${::operatingsystemmajrelease}/x86_64";
,
  descr  => 'vmware',
  enabled => 1,
  gpgcheck => 1,
  gpgkey  => 
'https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub',
}
  }

Error: Failed to apply catalog: Parameter baseurl failed on Yumrepo[vmware-
tools]: Validate method failed for class baseurl: bad URI(is not URI?): 
baseurl=http://packages.vmware.com/tools/releases/10.1.0/rhel6/x86_64

as you can see this is a real 
URI: http://packages.vmware.com/tools/releases/10.1.0/rhel5/x86_64

the parser seems to be as 
follows: https://github.com/ruby/ruby/blob/master/lib/uri/rfc3986_parser.rb

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/df05feee-d109-4669-86db-94e122cc9479%40googlegroups.com.

Re: [Puppet Users] Install software by running script

[Andy Hall]

exactly just push the devs of the package resource type to add a new 
provider. I mean nodejs is kinds popular now so I see no reason not to add 
it...

On Tuesday, April 14, 2020 at 7:04:46 AM UTC+1, Dirk Heinrichs wrote:
>
> Am Samstag, den 11.04.2020, 12:15 +0200 schrieb Martin Alfke:
>
> Of course for just pip/bundle/etc. I can do something like
>
>   exec { 'install':
> command => 'pip/bundle/npm install',
> creates => 'some file created by the pip/bundle/npm
> }
>
> but still it's painful because if the pip/bundle/npm failed the exec would
> not be execute again, unless you put every file create by the 1
> dependencies need for every software.
>
> The worst case for me is those software installed by some
>
>   wget 'URL' | sh
>
> (Ok I know it's not secure...) but well...
>
>
> The same pattern: let the wget | sudo bash command run on a dev platform 
> or a container and build a package.
>
>
> Either this, or: Write a package provider, like the ones already available 
> for Ruby gems or Python modules, which turns this into
>
> package { 'foo':
> ...
> provider => npm,
> ...
> }
>
>
> Bye...
>
> Dirk
>
> -- 
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18
> *Email*: dhei...@opentext.com 
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan, 
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you 
> are not the intended recipient (or have received this e-mail in error) 
> please notify the sender immediately and destroy this e-mail. Any 
> unauthorized copying, disclosure or distribution of the material in this 
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
> Weitergabe dieser Mail sind nicht gestattet.
>

-- 
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/89c471a3-fc4e-466f-ad7d-0cb81e7d77f8%40googlegroups.com.

Re: [Puppet Users] How to turn on Centos 8 repo

[Andy Hall]

As stated above if you match the existing file with a yumrepo resource then 
yes it will effectively change just the file but puppet will now own that 
so it has to match or else it will create a new file.

So if the existing file looks like this...

[BaseOS]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=BaseOS&infra=$infra
#baseurl=http://mirror.centos.org/$contentdir/$releasever/BaseOS/$basearch/os/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial

And you now want to just enable it then something like this may work...

yumrepo { 'BaseOS':
  desc => 'CentOS-$releasever - Base
  mirrorlist => 
'http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=BaseOS&infra=$infra'
  gpgcheck => 0
  enabled => 1
  gpgkey => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial'
}

And if you can't get it to work and you absolutely cannot have two similar 
files with one disabled and one enabled then look a something like fileline 
in the stdlib to edit a line in a file - but the yumrepo resource type is 
the way to go.

Tip: you need to get a test host so you can just start playing with this 
stuff and seeing how it works. Also please read the resource type docs as 
they are great : https://puppet.com/docs/puppet/5.5/types/yumrepo.html

On Sunday, March 29, 2020 at 3:04:50 AM UTC+1, Keyzer Suze wrote:
>
> Hi
>
> Okay sorry for the confusion.
>
> So brand new centos 8 install
>
> all the repo files are in the /etc/yum.repo.d directory
>
> I want to turn on the high availability repo 
>
> I would rather not replace the whole files - yes I can see its contents, 
> but I don't want to maintain the file in puppet I want to maintain the 
> state of the repo
>
> on a very basic level I want to change the enabled option in the file to 1 
> / true
>
>
>
>
>
>
>
> On Sat, Mar 28, 2020 at 3:30 AM warron.french  > wrote:
>
>> Keyser, do you mean what syntax to generate a repo file for the CentOS 
>> high availability packages?
>>
>> I am trying to understand your requirement clearly.
>> --
>> Warron French
>>
>>
>>
>> On Fri, Mar 27, 2020 at 1:10 AM Keyzer Suze > > wrote:
>>
>>> Hi
>>>
>>> Looking at configure brand new installs
>>>
>>> basically i have Centos 8 template (VMWare) and I create new machines, 
>>> login assign name to it and run puppet agent.
>>>
>>> I wanted to use high availability packages and i need to turn on the 
>>> repo.
>>>
>>> Not sure the best way of doing it, I don't want to recreate the file, 
>>> just want to turn on enabled 
>>>
>>>
>>> thanks
>>>
>>>
>>>
>>> On Thu, Mar 26, 2020 at 11:30 PM warron.french >> > wrote:
>>>
 Did you get an answer Keyzer?

 Do you still have the file /etc/yum.repos.d/Centos-Base.repo, or do you 
 need to recreate the entire repo from scratch?  How I respond depends on 
 your answer.

 --
 Warron French



 On Tue, Mar 24, 2020 at 7:51 PM Keyzer Suze >>> > wrote:

> Hi
>
> I want to turn on the high availability repo.
>
> How to I do that, with re creating the repo file ?
>
> A
>
> -- 
> 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/59832e87-1dda-45fc-a226-2e6a2f75d667%40googlegroups.com
>  
> 
> .
>
 -- 
 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/CAJdJdQn%3DsK007M49Zox%3DqVuK%2B9kbxy%2Brkf28e-4ehZHnW0tWmQ%40mail.gmail.com
  
 
 .

>>> -- 
>>> 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/CANmbM4HfKK8NQ1rS4Mi8tD6Ay8Zg4_ywqXFVKP0sH%3DgWy3DTAw%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because y

Re: [Puppet Users] How to turn on Centos 8 repo

[Andy Hall]

Puppet needs to own the file to use the yumrepo resource type so if you 
ensure all aspects match then effectively using the enabled parameter 
should just change that file. But if anything doesn't match then yes it 
will create a new file. But is shouldn't be too difficult to work it out 
from the docs after a few puppet runs to get it right 
: https://puppet.com/docs/puppet/5.5/types/yumrepo.html

If that just doesn't work then look at file_line from stdlib if you have to.

On Friday, March 27, 2020 at 5:10:28 AM UTC, Keyzer Suze wrote:
>
> Hi
>
> Looking at configure brand new installs
>
> basically i have Centos 8 template (VMWare) and I create new machines, 
> login assign name to it and run puppet agent.
>
> I wanted to use high availability packages and i need to turn on the repo.
>
> Not sure the best way of doing it, I don't want to recreate the file, just 
> want to turn on enabled 
>
>
> thanks
>
>
>
> On Thu, Mar 26, 2020 at 11:30 PM warron.french  > wrote:
>
>> Did you get an answer Keyzer?
>>
>> Do you still have the file /etc/yum.repos.d/Centos-Base.repo, or do you 
>> need to recreate the entire repo from scratch?  How I respond depends on 
>> your answer.
>>
>> --
>> Warron French
>>
>>
>>
>> On Tue, Mar 24, 2020 at 7:51 PM Keyzer Suze > > wrote:
>>
>>> Hi
>>>
>>> I want to turn on the high availability repo.
>>>
>>> How to I do that, with re creating the repo file ?
>>>
>>> A
>>>
>>> -- 
>>> 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/59832e87-1dda-45fc-a226-2e6a2f75d667%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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/CAJdJdQn%3DsK007M49Zox%3DqVuK%2B9kbxy%2Brkf28e-4ehZHnW0tWmQ%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
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/9939c16f-e3e4-4392-bd30-2e4f5e02a7dc%40googlegroups.com.

[Puppet Users] Re: Puppetserver performance plummeting a few hours after startup

[Andy Hall]

So we saw similar and with only the default maximum 4 puppetserver jruby 
instances would often get 5 or 6 clients connecting at once which in turn 
led to blocking and then a queue building as more clients connected. We 
would check port 8140 and often see over 80 established connections.

Now that we have doubled the max-active-instances to 8 and increased the 
JVM heap size to 4GB the concurrent connections are able to be handled and 
a queue no longer builds so puppet runs are much quicker and the server 
does not get so bogged down.

I hope this helps.

On Thursday, February 6, 2020 at 10:51:42 AM UTC, Martijn Grendelman wrote:
>
> Hi,
>
> A question about Puppetserver performance.
>
> For quite a while now, our primary Puppet server is suffering from severe 
> slowness and high CPU usage. We have tried to tweak its settings, giving it 
> more memory (Xmx = 6 GB at the moment) and toying with the 
> 'max-active-instances' setting to no avail. The server has 8 virtual cores 
> and 12 GB memory in total, to run Pupperserver, PuppetDB and PostgreSQL.
>
> Notably, after a restart, the performance is acceptable for a while 
> (several hours, up to a almost day), but then it plummets again.
>
> We figured that the server was just unable to cope with the load (we had 
> over 270 nodes talking to it in 30 min intervals), so we added a second 
> master that now takes more than half of that load (150 nodes). That did not 
> make any difference at all for the primary server. The secondary server 
> however, has no trouble at all dealing with the load we gave it.
>
> In the graph below, that displays catalog compilation times for both 
> servers, you can see the new master in green. It has very constant high 
> performance. The old master is in yellow. After a restart, the compile 
> times are good (not great) for a while.The first dip represents ca. 4 
> hours, the second dip was 18 hours. At some point, the catalog compilation 
> times sky-rocket, as does the server load. 10 seconds in the graph below 
> corresponds to a server load of around 2, while 40 seconds corresponds to a 
> server load of around 5. It's the Puppetserver process using the CPU.
>
> The second server, the green line, has a consistent server load of around 
> 1, with 4 GB memory (2 GB for the Puppetserver JVM) and 2 cores (it's an 
> EC2 t3.medium).
>
>
>
> If I have 110 nodes, doing two runs per hour, that each take 30 seconds to 
> run, I would still have a concurrency of less than 2, so Puppet causing a 
> consistent load of 5 seems strange. My first thought would be that it's 
> garbage collection or something like that, but the server plenty of memory 
> (OS cache has 2GB).
>
> Any ideas on what makes the Puppetserver starting using so much CPU? What 
> can we try to keep it down?
>
> Thanks,
> Martijn Grendelman
>
>

-- 
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/f2d5182f-cf48-4612-9806-e7a29c9cb7c2%40googlegroups.com.

[Puppet Users] service resource running always makes a corrective change

[Andy Hall]

Hey there - we have a server where part of the manifest is as follows:

  service { 'nfs':
enable  => true,
ensure  => running,
  }

Nice and simple however on every puppet run we get the following output 
which is recorded as a change:

[root@server ~]# puppet agent --test


Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for server
Info: Applying configuration version '1573029117'


Notice: /Stage[main]/Flex::Profiles::Archive::Server/Service[nfs]/ensure: 
ensure changed 'stopped' to 'running' (corrective)
Info: /Stage[main]/Flex::Profiles::Archive::Server/Service[nfs]: 
Unscheduling refresh on Service[nfs]


Notice: Applied catalog in 18.92 seconds


Could it be something to do with the fact that it is systemd ? This is 
CentOS 7:

[root@server ~]# service nfs status
Redirecting to /bin/systemctl status nfs.service
● nfs-server.service - NFS server and services
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; 
vendor preset: disabled)
  Drop-In: /run/systemd/generator/nfs-server.service.d
   └─order-with-mounts.conf
   Active: active (exited) since Fri 2019-11-01 20:31:00 GMT; 4 days ago
 Main PID: 28173 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/nfs-server.service


Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.


[root@server ~]# systemctl cat nfs

# /usr/lib/systemd/system/nfs-server.service
[Unit]
Description=NFS server and services
DefaultDependencies=no
Requires= network.target proc-fs-nfsd.mount
Requires= nfs-mountd.service
Wants=rpcbind.socket network-online.target
Wants=rpc-statd.service nfs-idmapd.service
Wants=rpc-statd-notify.service


After= network-online.target local-fs.target
After= proc-fs-nfsd.mount rpcbind.socket nfs-mountd.service
After= nfs-idmapd.service rpc-statd.service
Before= rpc-statd-notify.service


# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service gssproxy.service


Wants=nfs-config.service
After=nfs-config.service


[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils


Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/exportfs -r
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
ExecStartPost=-/bin/sh -c 'if systemctl -q is-active gssproxy; then 
systemctl reload gssproxy ; fi'
ExecStop=/usr/sbin/rpc.nfsd 0
ExecStopPost=/usr/sbin/exportfs -au
ExecStopPost=/usr/sbin/exportfs -f


ExecReload=-/usr/sbin/exportfs -r


[Install]
WantedBy=multi-user.target


# /run/systemd/generator/nfs-server.service.d/order-with-mounts.conf
# Automatically generated by nfs-server-generator


[Unit]
RequiresMountsFor=/export/nfs/sl1-uat-permtest

Any thoughts on how this could be handled more gracefully ? Thanks very 
much.

-- 
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/5b3b2cde-db75-400d-85f9-2e9cbc995dc8%40googlegroups.com.

[Puppet Users] puppet server connection limit / throttling ?

[Andy Hall]

Hi there we have a puppetserver 6.4.0 which is currently handling about 450 
clients. In terms of performance over our legacy 3.8 instance it is great - 
clearly clojure is faster than a rails app behind a web proxy :-) But we 
notice that when we hit approx. 90 established connection to TCP port 8140 
any new client puppet-agent connections "hang" at this stage as seen from 
debug output:

Debug: Creating new connection for https://server.company.com:8140
Debug: Starting connection for https://server.company.com:8140

This isn't just waiting for a catalog to compile - it often sits there for 
minutes with no response. In fact if we reboot the puppet server thus 
clearing the connections the client then runs normally as expected - with 
just a small delay waiting for its catalog.

I'm pretty sure this is not some OS / TCP stack limitation so wonder if 
there is some config which might be throttling this at the application 
level ? I hope approx. 450 clients is not the stage we need to start 
scaling to multiple catalog servers ??

Thanks for your help, Andy.




-- 
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/52b4d184-6ecd-409a-ad26-d623762539d2%40googlegroups.com.

Re: [Puppet Users] puppetdb 6x not deactivating from catalogs table

[Andy Hall]

Thanks Zachary that doc is a great help. I'll lower the node-purge-ttl and 
see how it performs.

On Friday, 4 October 2019 22:14:04 UTC+1, Zachary Kent wrote:
>
> Hi Andy,
>
> Are you seeing the deactivated nodes' catalogs turn up in query results 
> from PDB or only when you query the postgres table directly?
>
> I'm wondering if you might be hitting some strangeness around the 
> node-purge-ttl 
> <https://puppet.com/docs/puppetdb/6.3/configure.html#node-purge-ttl> 
> setting. This setting specifies the amount of time that the PDB garbage 
> collection process will wait before permanently deleting a node even if it 
> has been deactivated or expired. This setting is needed on the enterprise 
> side of things but could be preventing the nodes that you have deactivated 
> from being deleted right away. 
>
> I tried setting this value to node-purge-ttl=1s locally and was able to 
> confirm that deactivating a node and then sending a purge_nodes command 
> <https://puppet.com/docs/puppetdb/6.3/api/admin/v1/cmd.html#post-pdbadminv1cmd>
>  
> to the admin endpoint triggered gc and deleted the node.
>
> Note that if you do try this approach you may want to consider using a 
> batch_limit for the purge_nodes admin command. Otherwise the PDB will try 
> to delete everything at once which may take a while. See this blog post 
> <https://puppet.com/blog/preventative-maintenance-for-puppetdb-node-purge-ttl>
>  
> that discusses some of the related issues. 
>
> Changing this setting will also speed up the purging of data from nodes 
> that have fallen inactive for longer than node-ttl 
> <https://puppet.com/docs/puppetdb/6.3/configure.html#node-ttl> which is 
> another thing to consider if you care about querying for nodes that have 
> stopped checking in longer than node-ttl. 
>
> Hope this helps!
>
>
> On Thu, Oct 3, 2019 at 10:25 AM Andy Hall  > wrote:
>
>> hey there we have just migrated hundreds of hosts from 3.x to 6.x and 
>> although lots of work we are almost home and dry but have an issue with 
>> puppetdb which I hope can be solved. we are running puppetdb-6.3.4 but when 
>> removing an old node as follows:
>>
>> puppet node deactivate 
>>
>> the information is _not_ getting removed from puppetdb and we have to run 
>> the following sql manually:
>>
>> delete from catalogs where certname in (select certname from certnames 
>> where deactivated is not null);
>>
>> this is far from ideal and we really need this functionality to work 
>> again as we have numerous exported resources such as nagios which have to 
>> be removed when decommissioning a host.
>>
>> please advise if this is a known issue or if we are doing something wrong.
>>
>> thanks very much and keep up the good work !!
>>
>> -- 
>> 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/9f3a3c96-29ec-401d-b3d4-cf6b8270535f%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/9f3a3c96-29ec-401d-b3d4-cf6b8270535f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/6c54e96c-e09f-4e24-9bd1-b09d7c9d8919%40googlegroups.com.

[Puppet Users] puppetdb 6x not deactivating from catalogs table

[Andy Hall]

hey there we have just migrated hundreds of hosts from 3.x to 6.x and 
although lots of work we are almost home and dry but have an issue with 
puppetdb which I hope can be solved. we are running puppetdb-6.3.4 but when 
removing an old node as follows:

puppet node deactivate 

the information is _not_ getting removed from puppetdb and we have to run 
the following sql manually:

delete from catalogs where certname in (select certname from certnames 
where deactivated is not null);

this is far from ideal and we really need this functionality to work again 
as we have numerous exported resources such as nagios which have to be 
removed when decommissioning a host.

please advise if this is a known issue or if we are doing something wrong.

thanks very much and keep up the good work !!

-- 
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/9f3a3c96-29ec-401d-b3d4-cf6b8270535f%40googlegroups.com.

[Puppet Users] Re: puppet bolt templates ??

[Andy Hall]

Fantastic all works now. If I have any further questions I'll create a new 
thread. 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/f56fa397-fc09-4329-9c41-69b793d2cfb4%40googlegroups.com.

[Puppet Users] Re: puppet bolt templates ??

[Andy Hall]

OK so how do I get the plan to read from the inventory file ?? I am running 
this plan :

bolt plan run puppet6::puppet_upgrade -i inventory.yaml --nodes 
puppet6_nodes

And am getting this error :

puppet6::puppet_upgrade: expects a value for parameter 'location'

Here is my inventory file :

groups:
  - name: puppet6_nodes
nodes:
  - host-name-01
vars:
  location: ldn1

And here is the plan with params :

plan puppet6::puppet_upgrade(
  TargetSpec $nodes,
  String $location,
) {

  apply($nodes) {
class { 'puppet6::upgrade': location => $location }
  }

}

Do the nodes and vars not get passed from the inventory to the plan ?? 
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/5adc8511-5ba9-4aa8-81ee-0569f8b8216a%40googlegroups.com.

[Puppet Users] Re: puppet bolt templates ??

[Andy Hall]

OK this is great. Really looking forward to using this more. Being able to 
leverage our existing puppet codebase and modules for a quick agentless 
solution means we don't have to migrate everything to ansible. Thanks again 
for all your help !!

-- 
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/18a54f1a-f66e-472a-a9bd-0bdaec0b7202%40googlegroups.com.

[Puppet Users] Re: puppet bolt templates ??

[Andy Hall]

This works great thanks very much for your help. I just had to add the 
location param to the plan itself as follows:

plan profiles::puppet_upgrade(
  TargetSpec $servers,
  String $location,
) {

It works perfectly !! Could I ask if the params can be read from a file 
similar to hiera (or an inventory in ansible) rather than being passed on 
the command line ? If bolt can do that then I'd never write another 
playbook again :-)

-- 
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/81e65ade-ee01-487f-9346-d45711b290e9%40googlegroups.com.

[Puppet Users] Re: puppet bolt templates ??

[Andy Hall]

That's great thanks !! So if I want to pass a param to the template from 
the command line would this work ??

1. The command:

bolt plan run profiles::puppet_upgrade servers=hostname.domain.com 
location=uk --user root

2. The plan:

plan profiles::puppet_upgrade(
  TargetSpec $servers,
) {

  apply($servers) {
class { 'profiles::upgrade': location => $location }
  }
}

3. The manifest:

class profiles::upgrade ($location = undef) {

  file { '/root/my_file.txt':
  ensure  => file,
  content => epp('my_module/my_file.epp', { '$_location' => '$location' 
})
  }
}

4. The template:

location = <%= $_location %>

-- 
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/4bf85107-2d24-42f2-a641-e09e8f189fa4%40googlegroups.com.

[Puppet Users] puppet bolt templates ??

[Andy Hall]

hey there just starting using bolt and has a simple plan which applies a 
manifest but I'd know like to write a dynamic file from a template like epp 
in puppet. is this possible ? I do not see anything in the docs except just 
uploading a static file : 
https://puppet.com/docs/bolt/latest/running_bolt_commands.html#concept-6839

please do let me know if this is possible - it's great being able to write 
a manifest and templates would be the icing on the cake !

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/0695dc07-ea52-406a-a19d-8fccd95417e8%40googlegroups.com.

[Puppet Users] Re: sshkeys from puppetdb failing after migration to puppet 6

[Andy Hall]

OK it seems all is well and that error is shown if the sshpubkey_username 
fact is not yet available in the puppetdb. Once available it all works fine.

-- 
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/61fc0623-0d04-4a9e-a379-5cb3696e9d1a%40googlegroups.com.

[Puppet Users] sshkeys from puppetdb failing after migration to puppet 6

[Andy Hall]

Hey there. We use the combination of jtopjian/sshkeys and 
dalen/puppetdbquery as it's a great solution to store and retrieve sshkeys 
from puppetdb. Currently we are migrating from puppet 3.8 to 6.6 and all 
issues have been ironed out except for the following:

When calling query_facts against puppetdb 6 I can see the connection on 
port 8081 with tcpdump but get the following error:


Error while evaluating a Function Call, undefined method facts_query for 
#


Which seems to relate to the following code in the query_facts function:


parser = PuppetDB::Parser.new

query = parser.facts_query query, facts_for_query if query.is_a? String 

parser.facts_hash(puppetdb.query(:facts, query, :extract => [:certname, 
:name, :value]), facts)


Of course we will check with the module authors but wonder has anyone else 
seen something similar and could it relate to the version of puppetdb ? As 
noted we can see the database connection being made but can't view the 
payload due to SSL. Any help would be greatly appreciated.

-- 
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/eb98b80c-354e-4be9-833c-5e84376a6922%40googlegroups.com.

Re: [Puppet Users] PUPPET 6.0 : PuppetDB SSL Engine issue

[Andy Hall]

Hmm perhaps I should RTFM : 
https://puppet.com/docs/puppetdb/6.0/maintain_and_tune.html#redo-ssl-setup-after-changing-certificates

On Friday, 16 November 2018 16:49:20 UTC, Andy Hall wrote:
>
> Apologies for the late reply but do you know how to re-create the certs 
> for PuppetDB ? Is there a specific PuppetDB group who may be able to answer 
> this ? Thanks very much.
>
> On Wednesday, 3 October 2018 19:04:26 UTC+1, Maggie Dreyer wrote:
>>
>> If you regenerated your CA as part of fixing the issues with the 
>> master/agent connection, did you also regenerate the certificates for 
>> PuppetDB? Not having really any experience with PuppetDB, I could see thi 
>> error being cause by still using certificates issued by the old certificate 
>> authority.
>>
>> On Wed, Oct 3, 2018 at 10:58 AM Andy Hall  wrote:
>>
>>> Just fixed an issue with the puppetserver ca after a 5.x to 6.x upgrade 
>>> (see post "PUPPET 6.0 : CSR from master does not match the agent public 
>>> key" for more details) but now experience the following issue with PuppetDB 
>>> (maybe a problem with the Java KeyStore ?):
>>>
>>> AGENT:
>>>
>>> # puppet agent --test
>>>
>>> Warning: Unable to fetch my node definition, but the agent run will 
>>> continue:
>>> Warning: Error 500 on SERVER: Server Error: Could not retrieve facts for 
>>> andy-puppet6-test.london.company.com: Failed to find facts from 
>>> PuppetDB at puppet:8140: Failed to execute '/pdb/query/v4/nodes/
>>> andy-puppet6-test.london.company.com/facts' on at least 1 of the 
>>> following 'server_urls': https://ldn1-puppet5.london.company.com:8081
>>>
>>> Info: Retrieving pluginfacts
>>> Info: Retrieving plugin
>>> Info: Retrieving locales
>>> Info: Loading facts
>>>
>>> Error: Could not retrieve catalog from remote server: Error 500 on 
>>> SERVER: Server Error: Failed to execute 
>>> '/pdb/cmd/v1?checksum=53837e24e8b91d10fc3a81a657b83258c0ab3f8f&version=5&certname=
>>> andy-puppet6-test.london.company.com&command=replace_facts&producer-timestamp=1538588583'
>>>  
>>> on at least 1 of the following 'server_urls': 
>>> https://ldn1-puppet5.london.company.com:8081
>>>
>>> Warning: Not using cache on failed catalog
>>> Error: Could not retrieve catalog; skipping run
>>>
>>> MASTER:
>>>
>>> ==> /var/log/puppetlabs/puppetserver/puppetserver.log <==
>>> 2018-10-03T18:49:26.860+01:00 ERROR [qtp1255475413-70] 
>>> [c.p.h.c.i.PersistentSyncHttpClient] Error executing http request
>>> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>>> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529)
>>> at 
>>> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>>> at 
>>> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
>>> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
>>> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
>>> at 
>>> org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:265)
>>> at 
>>> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:305)
>>> at 
>>> org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:509)
>>> at 
>>> org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
>>> at 
>>> org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
>>> at 
>>> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
>>> at 
>>> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
>>> at 
>>> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
>>> at 
>>> org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
>>> at 
>>> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
>>> at java.lang.Thread.run(Thread.java:748)
>>> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>>> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
>>> 

Re: [Puppet Users] PUPPET 6.0 : PuppetDB SSL Engine issue

[Andy Hall]

Apologies for the late reply but do you know how to re-create the certs for 
PuppetDB ? Is there a specific PuppetDB group who may be able to answer 
this ? Thanks very much.

On Wednesday, 3 October 2018 19:04:26 UTC+1, Maggie Dreyer wrote:
>
> If you regenerated your CA as part of fixing the issues with the 
> master/agent connection, did you also regenerate the certificates for 
> PuppetDB? Not having really any experience with PuppetDB, I could see thi 
> error being cause by still using certificates issued by the old certificate 
> authority.
>
> On Wed, Oct 3, 2018 at 10:58 AM Andy Hall  > wrote:
>
>> Just fixed an issue with the puppetserver ca after a 5.x to 6.x upgrade 
>> (see post "PUPPET 6.0 : CSR from master does not match the agent public 
>> key" for more details) but now experience the following issue with PuppetDB 
>> (maybe a problem with the Java KeyStore ?):
>>
>> AGENT:
>>
>> # puppet agent --test
>>
>> Warning: Unable to fetch my node definition, but the agent run will 
>> continue:
>> Warning: Error 500 on SERVER: Server Error: Could not retrieve facts for 
>> andy-puppet6-test.london.company.com: Failed to find facts from PuppetDB 
>> at puppet:8140: Failed to execute '/pdb/query/v4/nodes/
>> andy-puppet6-test.london.company.com/facts' on at least 1 of the 
>> following 'server_urls': https://ldn1-puppet5.london.company.com:8081
>>
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Retrieving locales
>> Info: Loading facts
>>
>> Error: Could not retrieve catalog from remote server: Error 500 on 
>> SERVER: Server Error: Failed to execute 
>> '/pdb/cmd/v1?checksum=53837e24e8b91d10fc3a81a657b83258c0ab3f8f&version=5&certname=
>> andy-puppet6-test.london.company.com&command=replace_facts&producer-timestamp=1538588583'
>>  
>> on at least 1 of the following 'server_urls': 
>> https://ldn1-puppet5.london.company.com:8081
>>
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>>
>> MASTER:
>>
>> ==> /var/log/puppetlabs/puppetserver/puppetserver.log <==
>> 2018-10-03T18:49:26.860+01:00 ERROR [qtp1255475413-70] 
>> [c.p.h.c.i.PersistentSyncHttpClient] Error executing http request
>> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529)
>> at 
>> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>> at 
>> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
>> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
>> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
>> at 
>> org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:265)
>> at 
>> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:305)
>> at 
>> org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:509)
>> at 
>> org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
>> at 
>> org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
>> at 
>> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
>> at 
>> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
>> at 
>> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
>> at 
>> org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
>> at 
>> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330)
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
>> at 
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
>> at 
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
>> at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
>> at sun.security.ssl.Handshaker$1.run(Handshaker.ja

[Puppet Users] PUPPET 6.0 : PuppetDB SSL Engine issue

[Andy Hall]

Just fixed an issue with the puppetserver ca after a 5.x to 6.x upgrade 
(see post "PUPPET 6.0 : CSR from master does not match the agent public 
key" for more details) but now experience the following issue with PuppetDB 
(maybe a problem with the Java KeyStore ?):

AGENT:

# puppet agent --test

Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: Error 500 on SERVER: Server Error: Could not retrieve facts for 
andy-puppet6-test.london.company.com: Failed to find facts from PuppetDB at 
puppet:8140: Failed to execute 
'/pdb/query/v4/nodes/andy-puppet6-test.london.company.com/facts' on at 
least 1 of the following 'server_urls': 
https://ldn1-puppet5.london.company.com:8081

Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Failed to execute 
'/pdb/cmd/v1?checksum=53837e24e8b91d10fc3a81a657b83258c0ab3f8f&version=5&certname=andy-puppet6-test.london.company.com&command=replace_facts&producer-timestamp=1538588583'
 
on at least 1 of the following 'server_urls': 
https://ldn1-puppet5.london.company.com:8081

Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

MASTER:

==> /var/log/puppetlabs/puppetserver/puppetserver.log <==
2018-10-03T18:49:26.860+01:00 ERROR [qtp1255475413-70] 
[c.p.h.c.i.PersistentSyncHttpClient] Error executing http request
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529)
at 
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
at 
sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:265)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:305)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:509)
at 
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
at 
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
... 9 common frames omitted
Caused by: sun.security.validator.ValidatorException: PKIX path validation 
failed: java.security.cert.CertPathValidatorException: Path does not chain 
with any of the trust anchors
at 
sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:362)
at 
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:270)
at sun.security.validator.Validator.validate(Validator.java:262)
at 
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at 
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
at 
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
... 17 common frames omitted
Caused by: java.security.cert.CertPathValidatorException: Path does not 
chain with any of the trust anchors
at 
sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:154)
at 
sun.security.provider.certpath.PKIXC

Re: [Puppet Users] PUPPET 6.0 : CSR from master does not match the agent public key

[Andy Hall]

Thanks Maggie these instructions were perfect. The cert didn't have the 
extension you refer to so i recreated the ca setup on the master and then 
tried again with good results this time :

AGENT:

# puppet agent --test --noop
Info: Creating a new SSL key for andy-puppet6-test.london.company.com
Info: Downloaded certificate for ca from ldn1-puppet5.london.company.com
Info: csr_attributes file loading from 
/etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for 
andy-puppet6-test.london.company.com
Info: Certificate Request fingerprint (SHA256): 
28:81:65:77:76:3A:7C:53:D7:D6:63:0E:27:0B:8C:74:DF:10:7C:53:99:3B:7D:42:EC:E1:48:FC:9B:91:70:A7
Exiting; no certificate found and waitforcert is disabled

MASTER:

# puppetserver ca sign --certname andy-puppet6-test.london.company.com
Successfully signed certificate request for 
andy-puppet6-test.london.flextrade.com

Thanks again for you help - we can begin the migration of agents to 6.x now 
:-)

On Monday, 1 October 2018 18:24:50 UTC+1, Maggie Dreyer wrote:
>
> The new `puppetserver ca` tool makes requests to the CA API (specifically 
> the `certificate_status(es)` endpoints), using the master's host cert for 
> authorization. The master's cert is created with a special extension 
> authorizing it to talk to those endpoints, allowed via a rule in 
> `auth.conf`. A permissions issue would be expected in an upgrade scenario, 
> when the CA files and master cert were created by an old Puppet Server, 
> that did not add the new auth extension to the cert. However, I think you 
> said this was a new install?
>
> Some things to check:
>
>- That these two rules exist in your `auth.conf` file (located by 
>default at `/etc/puppetlabs/puppetserver/conf.d/auth.conf`): 
>
> https://github.com/puppetlabs/puppetserver/blob/master/ezbake/config/conf.d/auth.conf#L49-L77
>   - If they don't exist, you can add them.
>   - That your master cert has the required extension. To check this, 
>run `openssl x509 -noout -text -in 
>/etc/puppetlabs/puppet/ssl/certs/.pem`. In the output, look 
>for these two lines:
>
> 1.3.6.1.4.1.34380.1.3.39:
>> ..true 
>>
>
> If the cert doesn't have the extension, your best bet may be to
> 1) stop puppetserver
> 2) delete `/etc/puppetlabs/puppet/ssl/*` on your master (assuming this is 
> still a test setup and no agents are relying on the existing CA setup) 
> 3) run `puppetserver ca setup`. This will generate a brand new CA with all 
> the certs in the expected state for a Puppet 6 Server.
> 4) restart puppetserver
> From here, the command should be usable, assuming your `auth.conf` is 
> correct. You will have to also delete the SSL files on your agent node(s) 
> in order to get it to talk to the new CA that you just regenerated.
>
> All of this should have been correct out of the box, but if you've been 
> doing anything odd in your SSL directory trying to get this to work, (doing 
> an agent run on the master after deleting some certs comes to mind) there's 
> always a chance something got messed up along the way.
>
> Please let me know if none of this fixes it for you. I have filed PUP-9187 
> <https://tickets.puppetlabs.com/browse/PUP-9187> to fix up the error 
> messaging that initially led you in the wrong direction.
> Thanks,
> Maggie
>
> On Mon, Oct 1, 2018 at 9:57 AM Andy Hall  > wrote:
>
>> Hi Maggie - thanks for the reply.
>>
>> When I run the new command this is what we get :
>>
>> # puppetserver ca clean --certname andy-puppet6-test.london.company.com
>> Error:
>> When attempting to revoke certificate '
>> andy-puppet6-test.london.company.com', received:
>>   code: 403
>>   body: Forbidden request: /puppet-ca/v1/certificate_status/
>> andy-puppet6-test.london.company.com (method :put). Please see the 
>> server logs for details.
>>
>> And here are the server logs :
>>
>> ==> /var/log/puppetlabs/puppetserver/puppetserver.log <==
>> 2018-10-01T17:48:10.393+01:00 ERROR [qtp1126042654-72] [p.t.a.rules] 
>> Forbidden request: ldn1-puppet5.london.company.com(10.2.69.190) access 
>> to /puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
>> (method :put) (authenticated: true) denied by rule 'puppetlabs cert status'.
>>
>> ==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==
>> 10.2.69.190 - - [01/Oct/2018:17:48:10 +0100] "PUT 
>> /puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
>> HTTP/1.1" 403 145 "-" "PuppetserverCaCli" 6
>>
>> Any thoughts on why the perms seem broke

Re: [Puppet Users] PUPPET 6.0 : CSR from master does not match the agent public key

[Andy Hall]

Again great response thankyou for this. It is actually an upgrade from 5.x 
but I will try out the proposed solutions and let you know how I get on. 
Andy.

On Monday, 1 October 2018 18:24:50 UTC+1, Maggie Dreyer wrote:
>
> The new `puppetserver ca` tool makes requests to the CA API (specifically 
> the `certificate_status(es)` endpoints), using the master's host cert for 
> authorization. The master's cert is created with a special extension 
> authorizing it to talk to those endpoints, allowed via a rule in 
> `auth.conf`. A permissions issue would be expected in an upgrade scenario, 
> when the CA files and master cert were created by an old Puppet Server, 
> that did not add the new auth extension to the cert. However, I think you 
> said this was a new install?
>
> Some things to check:
>
>- That these two rules exist in your `auth.conf` file (located by 
>default at `/etc/puppetlabs/puppetserver/conf.d/auth.conf`): 
>
> https://github.com/puppetlabs/puppetserver/blob/master/ezbake/config/conf.d/auth.conf#L49-L77
>   - If they don't exist, you can add them.
>   - That your master cert has the required extension. To check this, 
>run `openssl x509 -noout -text -in 
>/etc/puppetlabs/puppet/ssl/certs/.pem`. In the output, look 
>for these two lines:
>
> 1.3.6.1.4.1.34380.1.3.39:
>> ..true 
>>
>
> If the cert doesn't have the extension, your best bet may be to
> 1) stop puppetserver
> 2) delete `/etc/puppetlabs/puppet/ssl/*` on your master (assuming this is 
> still a test setup and no agents are relying on the existing CA setup) 
> 3) run `puppetserver ca setup`. This will generate a brand new CA with all 
> the certs in the expected state for a Puppet 6 Server.
> 4) restart puppetserver
> From here, the command should be usable, assuming your `auth.conf` is 
> correct. You will have to also delete the SSL files on your agent node(s) 
> in order to get it to talk to the new CA that you just regenerated.
>
> All of this should have been correct out of the box, but if you've been 
> doing anything odd in your SSL directory trying to get this to work, (doing 
> an agent run on the master after deleting some certs comes to mind) there's 
> always a chance something got messed up along the way.
>
> Please let me know if none of this fixes it for you. I have filed PUP-9187 
> <https://tickets.puppetlabs.com/browse/PUP-9187> to fix up the error 
> messaging that initially led you in the wrong direction.
> Thanks,
> Maggie
>
> On Mon, Oct 1, 2018 at 9:57 AM Andy Hall  > wrote:
>
>> Hi Maggie - thanks for the reply.
>>
>> When I run the new command this is what we get :
>>
>> # puppetserver ca clean --certname andy-puppet6-test.london.company.com
>> Error:
>> When attempting to revoke certificate '
>> andy-puppet6-test.london.company.com', received:
>>   code: 403
>>   body: Forbidden request: /puppet-ca/v1/certificate_status/
>> andy-puppet6-test.london.company.com (method :put). Please see the 
>> server logs for details.
>>
>> And here are the server logs :
>>
>> ==> /var/log/puppetlabs/puppetserver/puppetserver.log <==
>> 2018-10-01T17:48:10.393+01:00 ERROR [qtp1126042654-72] [p.t.a.rules] 
>> Forbidden request: ldn1-puppet5.london.company.com(10.2.69.190) access 
>> to /puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
>> (method :put) (authenticated: true) denied by rule 'puppetlabs cert status'.
>>
>> ==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==
>> 10.2.69.190 - - [01/Oct/2018:17:48:10 +0100] "PUT 
>> /puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
>> HTTP/1.1" 403 145 "-" "PuppetserverCaCli" 6
>>
>> Any thoughts on why the perms seem broke for this ?
>>
>> Big fan of puppet and we really want to migrate away from 3.x so 
>> hopefully we can get this working !
>>
>> Thanks, Andy.
>>
>> On Friday, 28 September 2018 19:38:11 UTC+1, Maggie Dreyer wrote:
>>>
>>> Hello!
>>>
>>> For cleaning the cert on the master, are you trying to use `puppet cert 
>>> clean`? This error message needs to be updated to instead say "On the 
>>> master: use `puppetserver ca clean --certname `". The 
>>> `puppet cert` command was removed in 6.0.0, see 
>>> https://puppet.com/docs/puppet/6.0/release_notes.html#puppet-600 and 
>>> https://puppet.com/docs/puppetserver/6.0/subcommands.html#ca. But due 
>>> to https://tickets.puppetlabs.com/browse/PUP-9155, it

Re: [Puppet Users] PUPPET 6.0 : CSR from master does not match the agent public key

[Andy Hall]

Hi Maggie - thanks for the reply.

When I run the new command this is what we get :

# puppetserver ca clean --certname andy-puppet6-test.london.company.com
Error:
When attempting to revoke certificate 
'andy-puppet6-test.london.company.com', received:
  code: 403
  body: Forbidden request: 
/puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
(method :put). Please see the server logs for details.

And here are the server logs :

==> /var/log/puppetlabs/puppetserver/puppetserver.log <==
2018-10-01T17:48:10.393+01:00 ERROR [qtp1126042654-72] [p.t.a.rules] 
Forbidden request: ldn1-puppet5.london.company.com(10.2.69.190) access to 
/puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
(method :put) (authenticated: true) denied by rule 'puppetlabs cert status'.

==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==
10.2.69.190 - - [01/Oct/2018:17:48:10 +0100] "PUT 
/puppet-ca/v1/certificate_status/andy-puppet6-test.london.company.com 
HTTP/1.1" 403 145 "-" "PuppetserverCaCli" 6

Any thoughts on why the perms seem broke for this ?

Big fan of puppet and we really want to migrate away from 3.x so hopefully 
we can get this working !

Thanks, Andy.

On Friday, 28 September 2018 19:38:11 UTC+1, Maggie Dreyer wrote:
>
> Hello!
>
> For cleaning the cert on the master, are you trying to use `puppet cert 
> clean`? This error message needs to be updated to instead say "On the 
> master: use `puppetserver ca clean --certname `". The 
> `puppet cert` command was removed in 6.0.0, see 
> https://puppet.com/docs/puppet/6.0/release_notes.html#puppet-600 and 
> https://puppet.com/docs/puppetserver/6.0/subcommands.html#ca. But due to 
> https://tickets.puppetlabs.com/browse/PUP-9155, it doesn't always 
> correctly report its failure. Starting in 6.0.1, `puppet cert` will always 
> error helpfully information about the new alternative commands. Please let 
> me know if you are still having issues after trying `puppetserver ca clean`.
>
> And regardless of whether this fixes your issue, we really appreciate your 
> letting us know when our errors and/or docs are less than helpful. Thanks!
> Maggie
>
> On Fri, Sep 28, 2018 at 11:05 AM Andy Hall  > wrote:
>
>> Just deployed a new puppet 6.0 client / server setup and getting the 
>> classic CSR signing issue (see details below). Please help clarify my 
>> understanding so I can troubleshoot this (I'm sure there's a quick fix for 
>> this) :
>>
>> N.B. The usual "remove the SSL dir on the client and clean the cert on 
>> the server" is NOT working.
>>
>> So I think this is what happens :
>>
>> 1. The agent creates an SSL cert and sends if to the master to be signed 
>> - a Certificate Signing Request (CSR).
>>
>> 2. The master signs the cert with its own CA and the key of the agent.
>>
>> 3. The signed cert is returned to the agent which compares the keys to 
>> ensure they match.
>>
>> It would seem that somehow the key being returned is mangled and doesn't 
>> match so is rejected by the agent.
>>
>> This happens from the very first attempt to join an agent to the master 
>> and I am at a loss of how to fix this.
>>
>> Here's is the request from the agent to the master :
>>
>> ==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==
>> 10.2.73.60 - - [28/Sep/2018:18:34:07 +0100] "GET 
>> /puppet-ca/v1/certificate/andy-puppet6-test.london.company.com HTTP/1.1" 
>> 404 65 "-" "Puppet/6.0.0 Ruby/2.5.1-p57 (x86_64-linux)" 3
>> 10.2.73.60 - - [28/Sep/2018:18:34:07 +0100] "GET 
>> /puppet-ca/v1/certificate_request/andy-puppet6-test.london.company.com 
>> HTTP/1.1" 200 1622 "-" "Puppet/6.0.0 Ruby/2.5.1-p57 (x86_64-linux)" 3
>>
>> And here is the output from the agent :
>>
>> # puppet agent --test --noop
>> Info: Creating a new SSL key for andy-puppet6-test.london.company.com
>> Info: Downloaded certificate for ca from puppet
>> Error: Could not request certificate: The CSR retrieved from the master 
>> does not match the agent's public key.
>> CSR fingerprint: 
>> 9A:16:DA:95:9C:FB:90:89:78:EB:01:86:21:B0:24:E1:B0:66:80:43:ED:58:0B:A5:08:9C:24:60:C8:DE:F5:13
>> CSR public key: Public-Key: (4096 bit)
>> Modulus:
>> 00:9c:ba:32:5e:c9:e9:72:7b:36:17:9a:aa:f6:8e:
>> e2:a4:73:0a:95:4d:ae:ca:81:96:1c:02:f3:45:e5:
>> 6e:13:70:e1:dc:83:dc:88:96:4c:5e:40:d1:eb:c4:
>> 62:81:8b:9f:25:96:1a:56:1d:ba:cd:25:a8:b2:21:
>> 72:e6:ef:f3:63:b1:02:65:19:4d:e8:28:9e:bf:40:
>> 04:

[Puppet Users] PUPPET 6.0 : CSR from master does not match the agent public key

[Andy Hall]

Just deployed a new puppet 6.0 client / server setup and getting the 
classic CSR signing issue (see details below). Please help clarify my 
understanding so I can troubleshoot this (I'm sure there's a quick fix for 
this) :

N.B. The usual "remove the SSL dir on the client and clean the cert on the 
server" is NOT working.

So I think this is what happens :

1. The agent creates an SSL cert and sends if to the master to be signed - 
a Certificate Signing Request (CSR).

2. The master signs the cert with its own CA and the key of the agent.

3. The signed cert is returned to the agent which compares the keys to 
ensure they match.

It would seem that somehow the key being returned is mangled and doesn't 
match so is rejected by the agent.

This happens from the very first attempt to join an agent to the master and 
I am at a loss of how to fix this.

Here's is the request from the agent to the master :

==> /var/log/puppetlabs/puppetserver/puppetserver-access.log <==
10.2.73.60 - - [28/Sep/2018:18:34:07 +0100] "GET 
/puppet-ca/v1/certificate/andy-puppet6-test.london.company.com HTTP/1.1" 
404 65 "-" "Puppet/6.0.0 Ruby/2.5.1-p57 (x86_64-linux)" 3
10.2.73.60 - - [28/Sep/2018:18:34:07 +0100] "GET 
/puppet-ca/v1/certificate_request/andy-puppet6-test.london.company.com 
HTTP/1.1" 200 1622 "-" "Puppet/6.0.0 Ruby/2.5.1-p57 (x86_64-linux)" 3

And here is the output from the agent :

# puppet agent --test --noop
Info: Creating a new SSL key for andy-puppet6-test.london.company.com
Info: Downloaded certificate for ca from puppet
Error: Could not request certificate: The CSR retrieved from the master 
does not match the agent's public key.
CSR fingerprint: 
9A:16:DA:95:9C:FB:90:89:78:EB:01:86:21:B0:24:E1:B0:66:80:43:ED:58:0B:A5:08:9C:24:60:C8:DE:F5:13
CSR public key: Public-Key: (4096 bit)
Modulus:
00:9c:ba:32:5e:c9:e9:72:7b:36:17:9a:aa:f6:8e:
e2:a4:73:0a:95:4d:ae:ca:81:96:1c:02:f3:45:e5:
6e:13:70:e1:dc:83:dc:88:96:4c:5e:40:d1:eb:c4:
62:81:8b:9f:25:96:1a:56:1d:ba:cd:25:a8:b2:21:
72:e6:ef:f3:63:b1:02:65:19:4d:e8:28:9e:bf:40:
04:c7:77:21:2f:5c:d8:20:07:63:60:c9:ac:75:44:
34:d0:bd:cf:8c:ae:31:37:8a:16:f3:08:92:a4:c1:
66:54:53:03:be:b4:02:17:52:93:c2:eb:42:82:90:
5d:db:b6:92:b1:ae:21:f0:e0:a6:9e:04:4e:0f:eb:
39:2f:17:f6:89:41:3a:08:b0:13:18:ff:82:2e:20:
cc:83:d6:67:f6:24:97:a2:8b:72:6d:c6:9c:99:cb:
70:9d:2b:7b:bd:0a:21:0d:9d:51:7c:22:f8:d0:e3:
cc:f7:2a:d9:e0:09:8c:1b:f5:7a:6c:69:88:5b:d2:
32:c2:c5:d7:b3:1d:c0:8f:23:a9:50:ab:1e:9b:4a:
cf:1e:f7:b3:de:7e:b6:b7:1e:ce:63:fd:ee:10:55:
48:32:8c:46:65:c2:46:43:90:49:2a:d8:b0:02:96:
19:71:e8:25:18:5f:c6:8f:79:67:36:da:03:04:83:
e1:06:6b:29:43:51:76:52:05:c9:22:d0:39:94:0b:
3b:07:62:66:79:d4:5a:36:af:c4:a3:2f:e1:f9:7b:
60:1b:55:33:31:52:87:87:53:41:85:86:58:64:ef:
32:77:8e:33:8c:8d:b3:f5:82:e2:16:a4:6c:65:f0:
f0:10:71:98:f5:da:ae:c0:df:5f:fa:8a:58:8f:7d:
69:4f:ea:8f:c7:36:22:f2:9f:85:30:c5:49:c6:ab:
f4:63:16:bd:ba:5d:a2:c1:06:8a:f9:6a:9b:bc:6a:
ee:01:2b:d2:75:cd:91:ad:a7:d1:45:e8:b6:a7:45:
51:0b:20:3b:05:c6:0d:06:17:2d:44:a9:33:2e:51:
b8:0b:ce:d4:db:f2:33:b9:42:3d:2b:22:1a:1e:f8:
09:14:43:9e:f0:82:8f:c8:71:74:8d:b2:ee:37:52:
0b:af:5c:4d:94:48:b2:94:81:32:03:fc:b5:6a:a6:
f2:c5:59:3c:09:44:f3:57:2f:3e:11:3b:6e:6f:36:
af:66:a6:10:e0:c7:4f:6a:74:5a:aa:48:51:62:e9:
cd:1d:72:43:20:7a:8b:80:c9:0f:1c:14:a8:87:15:
ee:93:95:55:9e:ae:48:4c:e0:4b:63:0b:88:00:fd:
1f:f1:30:a7:8b:d2:42:6a:1b:89:74:eb:46:67:c8:
32:d9:e1
Exponent: 65537 (0x10001)

Agent public key: Public-Key: (4096 bit)
Modulus:
00:cd:0a:ab:52:c8:34:62:3c:86:49:f5:18:7c:3c:
96:90:3d:0b:53:f9:5c:48:a6:38:e4:2c:84:4a:af:
5a:b7:1f:93:a7:4c:e5:dd:f3:a2:52:9d:b2:39:f4:
d3:2b:f0:8a:06:fd:f2:52:40:ec:9f:42:ed:b6:89:
63:b0:ed:62:cf:77:91:87:27:e1:f9:0b:a5:b8:d1:
a6:96:96:24:db:43:9f:5b:bd:8f:d5:29:d8:2b:f1:
57:2a:46:93:ce:cc:12:d4:e9:0d:24:fc:ef:42:11:
b8:db:a2:a3:51:23:bb:d4:97:18:a1:50:7a:7f:27:
70:cb:95:24:3c:31:35:90:77:35:68:eb:4c:41:0b:
1b:b3:1e:7b:2c:86:fa:72:27:3d:27:4c:71:07:13:
6d:58:ed:95:04:69:15:4c:5b:f2:7e:8e:73:21:65:
6e:eb:f1:64:ab:bc:67:55:1b:32:b9:1c:2c:c2:71:
9f:06:fa:a2:61:b7:03:ec:69:f7:9b:64:21:d1:af:
8a:ea:7b:99:48:7f:a0:27:f3:93:20:54:24:db:26:
b0:e7:38:24:fe:52:71:3c:79:f7:62:cf:97:e1:56:
16:35:90:2d:9e:69:c0:b7:ca:31:45:64:d7:44:16:
8c:1c:c2:a8:11:34:a4:ce:1e:37:61:c7:bb:94:16:
b1:e5:d7:74:70:67:56:e8:20:59:a5:12:39:01:95:
c2:ca:09:59:0d:a3:58:0a:1a:83:27:80:55:46:26:
46:9b:9d:69:57:42:97:b1:7d:cb:1e:a7:65:99:47:
f4:e8:ae:72:0b:a4:10:32:68:46:8b:77:19:6a:7a:
fa:32:3c:f8:2d:ff:cf:55:c3:43:64:3f:56:eb:e2:
8f:be:2d:d3:ec:55:d9:df:a4:c0:f4:ca:f7:44:38:
71:3e:1f:29:c9:b1:dc:bb:04:a1:90:ab:d9:ce:2f:
8b:77:87:ef:fa:47:c4:8c:ce:46:60:53:5c:d2:8f:
7f:4a:ad:ec:54:10:49:18:0f:7e:10:a9:c9:a9:5e:
8a:ce:2e:9d:55:19:95:fc:15:f2:35:1e:c0:81:f2:
03:39:4a:11:2c:ab:ba:0e:da:d8:eb:e7: