[Puppet Users] rake module:push, puppet-blacksmith, and puppet 6

[David Schmitt]

Hi folks,

until tomorrow's PDK and puppetlabs_spec_helper release automated module
release jobs will need to have their puppet pinned to `~> 5.0`, to keep
using the deprecated `puppet module build` command, which was removed in
yesterday's puppet 6.0.0 release.

You can follow along PDK-1100
 for the actual change
required.


Apologies for the additional hiccup along the way,
David
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZ26Pm5VeAnS1V6JOUOtxubDc8Nqq%3DA2SBHJ2wZ%3Diz3Uw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Remove key&value from hash

[Albert Shih]

Hi,

I'm would like to have a profile for example for apache.

  profile::apache

who can pass some hash to apache. For example let's say I've

  profile::apache::vhosts:
vhost1:

vhost2:


and I want to do

class profile::apache (
  Hash $vhosts
  )
{

  create_resources('apache::vhost', $vhosts)

}

But now I want to add some parameter who's not in the apache::vhost, for
example :

  profile::apache::vhosts:
vhost1:
  - monitored : true
  
vhost2:
  - monitored : false
  

so before I can do the

  create_resources('apache::vhost', $something)

i need to exclude « monitored » from that hash table. And...I don't know
how to do that. I try map, reduce etc.. and was unable to exclude some
nested key/value from a hash.

Regards



--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
xmpp: j...@obspm.fr
Heure local/Local time:
Wed Sep 19 14:50:21 CEST 2018

-- 
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/20180919132426.GG5102%40io.chezmoi.fr.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Remove key&value from hash

[Henrik Lindberg]

On 2018-09-19 15:24, Albert Shih wrote:

Hi,

I'm would like to have a profile for example for apache.

   profile::apache

who can pass some hash to apache. For example let's say I've

   profile::apache::vhosts:
 vhost1:
 
 vhost2:
 

and I want to do

class profile::apache (
   Hash $vhosts
   )
{

   create_resources('apache::vhost', $vhosts)

}

But now I want to add some parameter who's not in the apache::vhost, for
example :

   profile::apache::vhosts:
 vhost1:
   - monitored : true
   
 vhost2:
   - monitored : false
   

so before I can do the

   create_resources('apache::vhost', $something)

i need to exclude « monitored » from that hash table. And...I don't know
how to do that. I try map, reduce etc.. and was unable to exclude some
nested key/value from a hash.

Regards



Puppet has a function named tree_each() that can be used to flatten and 
filter a tree structure of data. Once filtered it is possible to again 
create a Hash out of the result.


Documentation here: 
https://puppet.com/docs/puppet/5.5/function.html#treeeach


Here are two examples (both from the documentation; the first from 
tree_each(), and the second from Hash.new().


The first example shows the flattened filtered value.
To get the pruned hash in that example, do what is done in
Example 2 at the end - i.e. Hash($flattened_pruned_value, 'hash_tree').

It is really difficult to achieve the same with just reduce() and
filter() functions - you would have to more or less implement
the tree_each() function - but you don't have to since puppet has it :-)

Hope this helps you with what you were trying to do.

Also - note that it may be better for you (instead of filtering your 
values and then give the resulting structure to create_reources()), to

iterate over the structure and the simply have conditional logic
around the declaration of resources. That is much less magic to read.

Best
- henrik

Encourage you to play with these examples:

 EXAMPLE 1
# A tree of some complexity (here very simple for readability)
$tree = [
 { name => 'user1', status => 'inactive', id => '10'},
 { name => 'user2', status => 'active', id => '20'}
]
notice $tree.tree_each.filter |$v| {
 $value = $v[1]
 $value =~ Hash and $value[status] == active
}


 EXAMPLE 2

# A hash tree with 'water' at different locations
$h = { a => { b => { x => 'water'}}, b => { y => 'water'} }

# a helper function that turns water into wine
function make_wine($x) { if $x == 'water' { 'wine' } else { $x } }

# create a flattened tree with water turned into wine
$flat_tree = $h.tree_each.map |$entry| { [$entry[0], make_wine($entry[1])] }

# create a new Hash and log it
notice Hash($flat_tree, 'hash_tree')






--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
xmpp: j...@obspm.fr
Heure local/Local time:
Wed Sep 19 14:50:21 CEST 2018




--

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/pntklh%2430b%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: hiera can't find facts to read hierarchy files?

[chris]

Hi Sean,

I'm having the same issue, and I see what you said, I'm just too new to 
puppet.  Would it be possible for you (or others) to expand on how you 
fixed this (with and example)?

Chris

On Wednesday, November 29, 2017 at 11:15:49 AM UTC-6, Sean wrote:
>
> Thanks to PuppetLab's Mr. Lindberg who helped get my troubleshooting 
> focused in the right direction.
>
> Basically, I forgot to add my new parameters to the class parameter 
> definitions in the module's init.pp.
>
> DOH!
>
> On Tuesday, November 28, 2017 at 4:53:42 PM UTC-5, Sean wrote:
>>
>> Hi,
>> I'm quite confused about how I could have created this problem.  I have a 
>> module we'll call it "test" which has been using Hiera v5 module data for 
>> the last couple of releases...this works great on either puppet 4 or 5...as 
>> expected.
>>
>> Last week added a feature, which involved adding 1 new manifest file 
>> (which creates concat::fragment resources), 2 parameters to a hiera data 
>> file, and adding 2 concat file resources, each named by one of those 
>> parameters, to an existing manifest file (existing.pp below).  Fairly 
>> simple and straight forward change.  The parser passes the syntax checks 
>> for everything involved in the change.
>>
>> I have tested on both puppet 4 and 5 using a pair of centos7 vms, both 
>> produce the same result.
>>
>> # puppet apply -e "include test"
>> Warning: Unknown variable: 'test::dconf_default_config'. at 
>> /etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
>> Error: Evaluation Error: Missing title. The title expression resulted in 
>> undef at 
>> /etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
>>  
>> on node localhost.localdomain
>>
>> This parameter is the filename of the concat resource mentioned above.  
>> Running a puppet lookup (on either v4 or v5) produces this output for the 
>> module data section:
>>
>>   Module "test" Data Provider (hiera configuration version 5)
>> Using configuration 
>> "/etc/puppetlabs/code/environments/production/modules/test/hiera.yaml"
>> Hierarchy entry "Full Version"
>>   Path 
>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>> Original path: "%{facts.os.name}-%{facts.os.release.full}.yaml"
>> Path not found
>> Hierarchy entry "Major Version"
>>   Path 
>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>> Original path: "%{facts.os.name}-%{facts.os.release.major}.yaml"
>> Path not found
>> Hierarchy entry "Distribution Name"
>>   Path 
>> "/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
>> Original path: "%{facts.os.name}.yaml"
>> Path not found
>> Hierarchy entry "Operating System Family + Major Version"
>>   Path 
>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>> Original path: 
>> "%{facts.os.family}-%{facts.os.release.major}.yaml"
>> Path not found
>> Hierarchy entry "Operating System Family"
>>   Path 
>> "/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
>> Original path: "%{facts.os.family}.yaml"
>> Path not found
>> Hierarchy entry "common"
>>   Path 
>> "/etc/puppetlabs/code/environments/production/modules/test/data/common.yaml"
>> Original path: "common.yaml"
>> No such key: "test::dconf_default_config"
>>
>>
>> See how all the Hierarchy Paths have bad file names?  This leads me to 
>> think that somehow Hiera has lost the ability to parse facts in my feature 
>> branch of this module.  If I check the master branch out for the "test" 
>> module then Hiera produces the correct datafile names.
>>
>> How can that be?
>>
>

-- 
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/f97ce708-9ce8-43f4-bb92-2400cfaf9d82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: hiera can't find facts to read hierarchy files?

[Henrik Lindberg]

On 2018-09-19 17:41, ch...@fuzzyblender.com wrote:

Hi Sean,

I'm having the same issue, and I see what you said, I'm just too new to 
puppet.  Would it be possible for you (or others) to expand on how you 
fixed this (with and example)?


Chris



I had responded to Sean in an email - reposting it here now:

How did you run `puppet lookup` ?
If you gave it a node with --node it will use the stored facts for that 
node, otherwise you have to give it the facts to use for that node.
If not specifying a --node, lookup will use the facts for the host where 
you are running `puppet lookup`.


Maybe that is what is tricking you?

Try running with `puppet apply --debug` when testing - that turns on 
logging of --explain from all lookups including those made via APL.

When you do that, are the path's set?

Still having weird problems? Check your axioms - are you running the 
expected file in the expected environment etc.


- henrik


On Wednesday, November 29, 2017 at 11:15:49 AM UTC-6, Sean wrote:

Thanks to PuppetLab's Mr. Lindberg who helped get my troubleshooting
focused in the right direction.

Basically, I forgot to add my new parameters to the class parameter
definitions in the module's init.pp.

DOH!

On Tuesday, November 28, 2017 at 4:53:42 PM UTC-5, Sean wrote:

Hi,
I'm quite confused about how I could have created this problem. 
I have a module we'll call it "test" which has been using Hiera

v5 module data for the last couple of releases...this works
great on either puppet 4 or 5...as expected.

Last week added a feature, which involved adding 1 new manifest
file (which creates concat::fragment resources), 2 parameters to
a hiera data file, and adding 2 concat file resources, each
named by one of those parameters, to an existing manifest file
(existing.pp below).  Fairly simple and straight forward
change.  The parser passes the syntax checks for everything
involved in the change.

I have tested on both puppet 4 and 5 using a pair of centos7
vms, both produce the same result.

|
# puppet apply -e "include test"
Warning: Unknown variable: 'test::dconf_default_config'. at

/etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
Error: Evaluation Error: Missing title. The title expression
resulted in undef at

/etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
on node localhost.localdomain
|

This parameter is the filename of the concat resource mentioned
above.  Running a puppet lookup (on either v4 or v5) produces
this output for the module data section:

|
Module"test"DataProvider(hiera configuration version 5)
Using configuration
"/etc/puppetlabs/code/environments/production/modules/test/hiera.yaml"
Hierarchy entry "Full Version"

Path"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
Original path:"%{facts.os.name
}-%{facts.os.release.full}.yaml"
Pathnot found
Hierarchy entry "Major Version"

Path"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
Original path:"%{facts.os.name
}-%{facts.os.release.major}.yaml"
Pathnot found
Hierarchy entry "Distribution Name"

Path"/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
Original path:"%{facts.os.name }.yaml"
Pathnot found
Hierarchy entry "Operating System Family + Major Version"

Path"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
Original path:"%{facts.os.family}-%{facts.os.release.major}.yaml"
Pathnot found
Hierarchy entry "Operating System Family"

Path"/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
Original path:"%{facts.os.family}.yaml"
Pathnot found
Hierarchy entry "common"

Path"/etc/puppetlabs/code/environments/production/modules/test/data/common.yaml"
Original path:"common.yaml"
No such key:"test::dconf_default_config"

|

See how all the Hierarchy Paths have bad file names?  This leads
me to think that somehow Hiera has lost the ability to parse
facts in my feature branch of this module.  If I check the
master branch out for the "test" module then Hiera produces the
correct datafile names.

How can that be?

--
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 vie

[Puppet Users] Re: hiera can't find facts to read hierarchy files?

[Sean]

Wow, this was a long time ago :)

I can not speak to the deep bits on why I was seeing hiera files based on 
Puppet Facts not having correct file names when processing puppet lookup.

What I can say is that I was referencing a class params like 
$::test::dconf_default_config, 
but I had not defined dconf_default_conf in the init.pp's class params...

class test(
  ...
  String  $dconf_default_config,# This was missing, adding it fixed the 
issue.
  ...
) { 
...
}

Before adding the line, I just had the default value for that param defined 
in a fact driven hieradata file.  It all produced a very strange behavior 
though.



On Wednesday, September 19, 2018 at 12:14:47 PM UTC-4, 
ch...@fuzzyblender.com wrote:
>
> Hi Sean,
>
> I'm having the same issue, and I see what you said, I'm just too new to 
> puppet.  Would it be possible for you (or others) to expand on how you 
> fixed this (with and example)?
>
> Chris
>
> On Wednesday, November 29, 2017 at 11:15:49 AM UTC-6, Sean wrote:
>>
>> Thanks to PuppetLab's Mr. Lindberg who helped get my troubleshooting 
>> focused in the right direction.
>>
>> Basically, I forgot to add my new parameters to the class parameter 
>> definitions in the module's init.pp.
>>
>> DOH!
>>
>> On Tuesday, November 28, 2017 at 4:53:42 PM UTC-5, Sean wrote:
>>>
>>> Hi,
>>> I'm quite confused about how I could have created this problem.  I have 
>>> a module we'll call it "test" which has been using Hiera v5 module data for 
>>> the last couple of releases...this works great on either puppet 4 or 5...as 
>>> expected.
>>>
>>> Last week added a feature, which involved adding 1 new manifest file 
>>> (which creates concat::fragment resources), 2 parameters to a hiera data 
>>> file, and adding 2 concat file resources, each named by one of those 
>>> parameters, to an existing manifest file (existing.pp below).  Fairly 
>>> simple and straight forward change.  The parser passes the syntax checks 
>>> for everything involved in the change.
>>>
>>> I have tested on both puppet 4 and 5 using a pair of centos7 vms, both 
>>> produce the same result.
>>>
>>> # puppet apply -e "include test"
>>> Warning: Unknown variable: 'test::dconf_default_config'. at 
>>> /etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
>>> Error: Evaluation Error: Missing title. The title expression resulted in 
>>> undef at 
>>> /etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
>>>  
>>> on node localhost.localdomain
>>>
>>> This parameter is the filename of the concat resource mentioned above.  
>>> Running a puppet lookup (on either v4 or v5) produces this output for the 
>>> module data section:
>>>
>>>   Module "test" Data Provider (hiera configuration version 5)
>>> Using configuration 
>>> "/etc/puppetlabs/code/environments/production/modules/test/hiera.yaml"
>>> Hierarchy entry "Full Version"
>>>   Path 
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>>> Original path: "%{facts.os.name}-%{facts.os.release.full}.yaml"
>>> Path not found
>>> Hierarchy entry "Major Version"
>>>   Path 
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>>> Original path: "%{facts.os.name}-%{facts.os.release.major}.yaml"
>>> Path not found
>>> Hierarchy entry "Distribution Name"
>>>   Path 
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
>>> Original path: "%{facts.os.name}.yaml"
>>> Path not found
>>> Hierarchy entry "Operating System Family + Major Version"
>>>   Path 
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>>> Original path: 
>>> "%{facts.os.family}-%{facts.os.release.major}.yaml"
>>> Path not found
>>> Hierarchy entry "Operating System Family"
>>>   Path 
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
>>> Original path: "%{facts.os.family}.yaml"
>>> Path not found
>>> Hierarchy entry "common"
>>>   Path 
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/common.yaml"
>>> Original path: "common.yaml"
>>> No such key: "test::dconf_default_config"
>>>
>>>
>>> See how all the Hierarchy Paths have bad file names?  This leads me to 
>>> think that somehow Hiera has lost the ability to parse facts in my feature 
>>> branch of this module.  If I check the master branch out for the "test" 
>>> module then Hiera produces the correct datafile names.
>>>
>>> How can that be?
>>>
>>

-- 
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/513321ac-6867-4693-8789-1d10d14ce1e2%40googlegroups.com.
For more

[Puppet Users] Re: Updates to CA command line interaction in Puppet 6

[Simon Tideswell]

Hello

I've upgraded a test server from Puppet 5.5 to Puppet 6 and the upgrade was 
quite seamless.

However post upgrade the puppetserver ca command does not work: it yields 
403 denied errors. In auth.conf the new Puppet Server has elements like ...
allow: {
 extensions: {
  pp_cli_auth: "true"
  }
}
There's presumably the requirement to recreate the Puppet Server's own 
certificate with the additional extensions - but this doesn't appear to be 
documented anywhere? I've worked around this by using a simpler "allow" 
stanza including the Puppet Server's own certificate and it works, but it'd 
be nice if the post-upgrade requirement (of re-minting the certificate) was 
identified in the documentation. I can't say that recreating the 
certificate with the extension really seems to offer any obvious advantage 
over just using the server's own certname to be honest?

Simon

On Wednesday, September 19, 2018 at 2:33:05 AM UTC+10, Maggie Dreyer wrote:
>
> Hello!
>
> As you may know, we are about to release Puppet 6. This release contains *a 
> major update to the command line tools* that are used to interact with 
> Puppet's CA and certificates. The update makes the commands much faster and 
> more reliable, removes duplication, and makes the interface easier to 
> understand. However, this means that *some scripts and workflows will 
> have to be updated*.
>
> *What is getting removed:*
> * puppet cert
> * puppet ca
> * puppet certificate
> * puppet certificate_request
> *puppet certificate_revocation_list
>
> *What is new:*
> * puppetserver ca  
> (for CA tasks like signing and revoking certs)
> * puppet ssl (for agent-side tasks like submitting a CSR and fetching a 
> cert, though these steps will still usually be taken care of by an agent 
> run)
>
> We have been making updates to beaker and various test suites to account 
> for this change. If you use Beaker to do any CA or certificate interaction 
> in your tests, you will need to make some updates to test against Puppet 6:
> 1) Update to Beaker 4 and beaker-puppet 1. The latest release of both of 
> these projects contains updates for these CA changes. Details 
> 
> .
> 2) Update any tests or pre-suites that use one of the removed commands to 
> use the equivalent new command instead. For details, invoke `puppet cert` 
> in Puppet 6 for help output containing the mapping of old commands to new 
> alternatives. We will have docs pages up soon with this info.
>
> *The most recent Puppet 6 builds on puppet nightlies 
>  have these updates if you would like to 
> try them out ahead of the release.*
>
> Please feel free to reach out to us if you have any further questions or 
> feedback.
>
> 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/56ba04e5-c06e-4f31-a787-2f97e16cf3d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Updates to CA command line interaction in Puppet 6

[Simon Tideswell]

Forgot to mention: this is on Ubuntu 18 (Bionic) using the packages pulled 
from apt.puppetlabs.com. Simon

On Thursday, September 20, 2018 at 8:58:06 AM UTC+10, Simon Tideswell wrote:
>
> Hello
>
> I've upgraded a test server from Puppet 5.5 to Puppet 6 and the upgrade 
> was quite seamless.
>
> However post upgrade the puppetserver ca command does not work: it yields 
> 403 denied errors. In auth.conf the new Puppet Server has elements like ...
> allow: {
>  extensions: {
>   pp_cli_auth: "true"
>   }
> }
> There's presumably the requirement to recreate the Puppet Server's own 
> certificate with the additional extensions - but this doesn't appear to be 
> documented anywhere? I've worked around this by using a simpler "allow" 
> stanza including the Puppet Server's own certificate and it works, but it'd 
> be nice if the post-upgrade requirement (of re-minting the certificate) was 
> identified in the documentation. I can't say that recreating the 
> certificate with the extension really seems to offer any obvious advantage 
> over just using the server's own certname to be honest?
>
> Simon
>
> On Wednesday, September 19, 2018 at 2:33:05 AM UTC+10, Maggie Dreyer wrote:
>>
>> Hello!
>>
>> As you may know, we are about to release Puppet 6. This release contains *a 
>> major update to the command line tools* that are used to interact with 
>> Puppet's CA and certificates. The update makes the commands much faster and 
>> more reliable, removes duplication, and makes the interface easier to 
>> understand. However, this means that *some scripts and workflows will 
>> have to be updated*.
>>
>> *What is getting removed:*
>> * puppet cert
>> * puppet ca
>> * puppet certificate
>> * puppet certificate_request
>> *puppet certificate_revocation_list
>>
>> *What is new:*
>> * puppetserver ca  
>> (for CA tasks like signing and revoking certs)
>> * puppet ssl (for agent-side tasks like submitting a CSR and fetching a 
>> cert, though these steps will still usually be taken care of by an agent 
>> run)
>>
>> We have been making updates to beaker and various test suites to account 
>> for this change. If you use Beaker to do any CA or certificate interaction 
>> in your tests, you will need to make some updates to test against Puppet 6:
>> 1) Update to Beaker 4 and beaker-puppet 1. The latest release of both of 
>> these projects contains updates for these CA changes. Details 
>> 
>> .
>> 2) Update any tests or pre-suites that use one of the removed commands to 
>> use the equivalent new command instead. For details, invoke `puppet cert` 
>> in Puppet 6 for help output containing the mapping of old commands to new 
>> alternatives. We will have docs pages up soon with this info.
>>
>> *The most recent Puppet 6 builds on puppet nightlies 
>>  have these updates if you would like to 
>> try them out ahead of the release.*
>>
>> Please feel free to reach out to us if you have any further questions or 
>> feedback.
>>
>> 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/79019f37-9496-403d-8d0d-22ea0efa2a23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Updates to CA command line interaction in Puppet 6

[Maggie Dreyer]

Thanks for the feedback! We'll have docs around the upgrade scenario out
shortly. We had instructions around exactly what you did in release notes

for the 5.5 version where we started shipping the gem, as the best way
forward to switch to using it in an existing install. I think that will
probably continue to be the easiest way to enable the gem moving forward as
well when upgrading.

Using the extension allows us to ship an auth.conf file that works out of
the box for FOSS users doing new installs (we don't know their server
hostnames ahead of time, and using something like localhost can be
insecure). It's also resistant to hostname changes on the CA node.

Please let us know if you have any other issues!

On Wed, Sep 19, 2018 at 4:00 PM Simon Tideswell 
wrote:

> Forgot to mention: this is on Ubuntu 18 (Bionic) using the packages pulled
> from apt.puppetlabs.com. Simon
>
> On Thursday, September 20, 2018 at 8:58:06 AM UTC+10, Simon Tideswell
> wrote:
>>
>> Hello
>>
>> I've upgraded a test server from Puppet 5.5 to Puppet 6 and the upgrade
>> was quite seamless.
>>
>> However post upgrade the puppetserver ca command does not work: it yields
>> 403 denied errors. In auth.conf the new Puppet Server has elements like ...
>> allow: {
>>  extensions: {
>>   pp_cli_auth: "true"
>>   }
>> }
>> There's presumably the requirement to recreate the Puppet Server's own
>> certificate with the additional extensions - but this doesn't appear to be
>> documented anywhere? I've worked around this by using a simpler "allow"
>> stanza including the Puppet Server's own certificate and it works, but it'd
>> be nice if the post-upgrade requirement (of re-minting the certificate) was
>> identified in the documentation. I can't say that recreating the
>> certificate with the extension really seems to offer any obvious advantage
>> over just using the server's own certname to be honest?
>>
>> Simon
>>
>> On Wednesday, September 19, 2018 at 2:33:05 AM UTC+10, Maggie Dreyer
>> wrote:
>>>
>>> Hello!
>>>
>>> As you may know, we are about to release Puppet 6. This release contains *a
>>> major update to the command line tools* that are used to interact with
>>> Puppet's CA and certificates. The update makes the commands much faster and
>>> more reliable, removes duplication, and makes the interface easier to
>>> understand. However, this means that *some scripts and workflows will
>>> have to be updated*.
>>>
>>> *What is getting removed:*
>>> * puppet cert
>>> * puppet ca
>>> * puppet certificate
>>> * puppet certificate_request
>>> *puppet certificate_revocation_list
>>>
>>> *What is new:*
>>> * puppetserver ca 
>>> (for CA tasks like signing and revoking certs)
>>> * puppet ssl (for agent-side tasks like submitting a CSR and fetching a
>>> cert, though these steps will still usually be taken care of by an agent
>>> run)
>>>
>>> We have been making updates to beaker and various test suites to account
>>> for this change. If you use Beaker to do any CA or certificate interaction
>>> in your tests, you will need to make some updates to test against Puppet 6:
>>> 1) Update to Beaker 4 and beaker-puppet 1. The latest release of both of
>>> these projects contains updates for these CA changes. Details
>>> 
>>> .
>>> 2) Update any tests or pre-suites that use one of the removed commands
>>> to use the equivalent new command instead. For details, invoke `puppet
>>> cert` in Puppet 6 for help output containing the mapping of old commands to
>>> new alternatives. We will have docs pages up soon with this info.
>>>
>>> *The most recent Puppet 6 builds on puppet nightlies
>>>  have these updates if you would like to
>>> try them out ahead of the release.*
>>>
>>> Please feel free to reach out to us if you have any further questions or
>>> feedback.
>>>
>>> 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/79019f37-9496-403d-8d0d-22ea0efa2a23%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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