[Puppet Users] Announcement: Release of Bolt 0.24.0

[Kate Lopresti]

Hello Everyone!

We end the month with the release of Bolt 0.24.0. Highlights include:

   - Updated versions of Ruby and OpenSSL for Bolt packages
   - Included path to module content for Show command results
   - Added support for control repo as boltdir, different input methods for
   implementations, and unknown keys in task metadata

For more information on these features as well as resolved issues, see:
https://puppet.com/docs/bolt/0.x/bolt_release_notes.html

To try this new version, follow the installation instructions for your
operating system at:
https://puppet.com/docs/bolt/0.x/bolt_installing.html


Thanks!
--
Kate Lopresti
Senior Technical Writer
kate.lopre...@puppet.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/CA%2B%2BkvapoCKSouPkoqL27sp6FsENWhgLPORm6TdF5U6jRkuWqcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Unknown resource type after Upgrade

[Josh Cooper]

On Thu, Sep 27, 2018 at 3:55 AM Christian Reiß 
wrote:

> Hey Rafael,
>
> thanks for your reply. Ironically I was readind the deprecated logs and
> seem to have missed that, After doing a puppet module install the error
> changed to
>
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER:
> Server Error: Evaluation Error: Error while evaluating a Type-Name, Could
> not autoload puppet/type/nagios_service: no such file to load -- puppet/
> util/nagios_maker (file: /etc/puppetlabs/code/environments/production/
> modules/pn_icinga/manifests/client/raid.pp, line: 15, column: 3) on node
> outleapt.test
>
>
This is a bug in the nagios_core module. Any time a module type or provider
loads helper code (for example
https://github.com/puppetlabs/puppetlabs-nagios_core/blob/d97ec08c78d966a500cf172f6575329f82df27a6/lib/puppet/type/nagios_service.rb#L1)
it needs to use require_relative or pass a relative path to require. The
reason is because the master needs to serve multiple environments, so we
can't add the environment-specific module path to the global ruby
$LOAD_PATH. Please open a MODULES ticket with component set to nagios_core.

This wasn't an issue prior to puppet6, because the nagios type/provider was
in core puppet, and so was in the $LOAD_PATH.

Mind pushing me once more in the right direction?
>
> -Chris.
>
>
> Am Donnerstag, 27. September 2018 11:25:34 UTC+1 schrieb Rafael Tomelin:
>>
>> Hi dear,
>>
>> This link the puppet6 release notes.
>> https://puppet.com/docs/puppet/6.0/release_notes.html#deprecations
>>
>>
>>- The Nagios types no longer ship with Puppet, and are now available
>>as the puppetlabs/nagios_core module from the Forge.
>>
>>
>> Em qui, 27 de set de 2018 às 07:14, Christian Reiß 
>> escreveu:
>>
>>> Hey folks,
>>>
>>> I am currently upgrading to 6.x on a test setup using my live puppet
>>> code; trying to get it to work with 6.x.
>>> One weird issue I am getting is that alle default definitions (upper
>>> case classes) are faulting:
>>>
>>> Error: Could not retrieve catalog from remote server: Error 500 on
>>> SERVER: Server Error: Evaluation Error: Resource type not found:
>>> Nagios_service (file: /etc/puppetlabs/code/environments/production/
>>> modules/pn_icinga/manifests/client/checks.pp, line: 83, column: 3) on
>>> node outleapt.test
>>> Warning: Not using cache on failed catalog
>>> Error: Could not retrieve catalog; skipping run
>>>
>>>
>>>
>>> The corresponding manifest looks like this:
>>>
>>> Nagios_service {
>>> check_period  => '24x7',
>>> ensure=> $::pn_icinga::client::installed,
>>> host_name => $::trusted['certname'],
>>> initial_state => 'o',
>>> max_check_attempts=> '3',
>>> notification_interval => '5',
>>> notification_options  => 'w,u,c,r',
>>> notification_period   => $notification_period,
>>> notifications_enabled => '0',
>>> [...]
>>> }
>>>
>>> Did I miss a regression somewhere?
>>> Any help is greatly appreciated!
>>>
>>> -Chris.
>>>
>>> --
>>> 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/bde5ac1d-f1ef-4454-885d-b499f22062c8%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> Atenciosamente,
>>
>> Rafael Tomelin
>>
>> skype: rafael.tomelin
>>
>> E-mail: rafael@gmail.com
>>
>> RHCE  - Red Hat Certified Engineer
>> PPT-205 - Puppet Certified Professional 2017
>> Zabbix- ZABBIX Certified Specialist
>> LPI3
>> ITIL v3
>>
> --
> 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/c2b29923-114f-4a82-8a66-cba5e428ca4b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Josh Cooper | Software Engineer
j...@puppet.com | @coopjn

-- 
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/CA%2Bu97umPBP%3DrLECbiRcFeLEcAo1vUoQAPiz%2BtoyT02RcDqPvmw%40mail.gmail.com.
For more options, visit h

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

[Justin Stoller]

On Thu, Sep 27, 2018 at 9:12 AM  wrote:

> Hi again,
>
> I also tried to set allow-unauthenticated: true for rule "puppetlabs cert
> status" and that worked.
> Now I was able to sign the csr.
>

Be aware, this is a very dangerous way to solve the problem. This will
allow anyone with http access to your CA to sign certs. Maybe your network
is secure enough that that's okay, but in general folks should only
whitelist the certnames or secure extensions that are allowed to admin a CA.

HTH,
Justin


>
> And sorry, puppetserver ca list now also works.
>
> Yours Henri
>
> Am Donnerstag, 20. September 2018 00:58:06 UTC+2 schrieb 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/9c901fae-18fb-4a76-91ad-b6cd35b761ef%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/CA%2B%3DBEqVdw4jYWGc6cNKF6Lxk6LmNq%2BjLcH28fn%3DyYvPyA-D-yA%40mail.gmail.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]

Here are a few options that should work:

1) whitelist the master's certname (which is more secure than
allow-unauthenticated anyway). See the example at the bottom of this section
 in the docs.
2) Another community member also created
https://github.com/smortex/puppet-add-cli-auth-to-certificate yesterday,
which adds the auth extension to your master cert.

For all of these things, *it's important to remember to restart your
server.* The auth.conf file in particular won't be reloaded until you
restart the server.

Let me know if you can't get any of this to work.

On Thu, Sep 27, 2018 at 9:12 AM  wrote:

> Hi,
>
> @Simon: Could you please describe how you solved that problem?
>
> I already invested hours to at least find the reason for the problem that
> "puppetserver ca list" gives me a 403 Forbidden, but couldn't solve it
> until now.
> And unfortunately this thread is the only  document I could find on google
> which refers to "pp_cli_auth".
>
> Simply replacing ...
> allow: {
>extensions: {
>pp_cli_auth: "true"
>}
> }
> by ...
> allow-unauthenticated: true
> ... did not work for me.
>
> That's a real big problem because we can't create new VMs for our
> customers now until it will be documented how to deal with this issue.
>
> Many thanks in advance,
> yours Henri
>
> Am Donnerstag, 20. September 2018 00:58:06 UTC+2 schrieb 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/16046491-82af-4321-93cc-c5a32f3385a3%40googlegroups.com
> 

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

[schomaecker]

Hi again,

I also tried to set allow-unauthenticated: true for rule "puppetlabs cert 
status" and that worked.
Now I was able to sign the csr.

And sorry, puppetserver ca list now also works.

Yours Henri

Am Donnerstag, 20. September 2018 00:58:06 UTC+2 schrieb 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/9c901fae-18fb-4a76-91ad-b6cd35b761ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[schomaecker]

Hi,

@Simon: Could you please describe how you solved that problem?

I already invested hours to at least find the reason for the problem that 
"puppetserver ca list" gives me a 403 Forbidden, but couldn't solve it 
until now.
And unfortunately this thread is the only  document I could find on google 
which refers to "pp_cli_auth".

Simply replacing ...
allow: {
   extensions: {
   pp_cli_auth: "true"
   }
}
by ...
allow-unauthenticated: true
... did not work for me.

That's a real big problem because we can't create new VMs for our customers 
now until it will be documented how to deal with this issue.

Many thanks in advance,
yours Henri

Am Donnerstag, 20. September 2018 00:58:06 UTC+2 schrieb 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/16046491-82af-4321-93cc-c5a32f3385a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppetserver does not auto-load.

[Christian Reiß]

I have a wierd question:

On a fresh Server (Centos 7, PuppetServer 6) with only one nagios class 
(with nagios_core from forge I am getting this error:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Evaluation Error: Error while evaluating a Resource 
Statement, Could not autoload puppet/type/nagios_service: no such file to 
load -- puppet/util/nagios_maker (file: 
/etc/puppetlabs/code/environments/production/manifests/site.pp, line: 4, 
column: 3) on node hyposulphuric

If I do a puppet apply however, the same site.pp applies correctly without 
issues (well, it complains about exporting ressources not possible). Why 
would a puppet apply correctly load the puppet forge module when then 
puppet server (puppet agent --test) does not and yields above error?

I have been hitting my head against the issue all day.
Any help is greatly appreciated.

-Chris.

-- 
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/b0c75235-39ab-434d-850a-84912a6a1fb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Unknown resource type after Upgrade

[Christian Reiß]

Hey Rafael,

thanks for your reply. Ironically I was readind the deprecated logs and 
seem to have missed that, After doing a puppet module install the error 
changed to

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Evaluation Error: Error while evaluating a Type-Name, Could 
not autoload puppet/type/nagios_service: no such file to load -- puppet/util
/nagios_maker (file: /etc/puppetlabs/code/environments/production/modules/
pn_icinga/manifests/client/raid.pp, line: 15, column: 3) on node outleapt.
test

Mind pushing me once more in the right direction?

-Chris.


Am Donnerstag, 27. September 2018 11:25:34 UTC+1 schrieb Rafael Tomelin:
>
> Hi dear,
>
> This link the puppet6 release notes.
> https://puppet.com/docs/puppet/6.0/release_notes.html#deprecations
>
>
>- The Nagios types no longer ship with Puppet, and are now available 
>as the puppetlabs/nagios_core module from the Forge.
>
>
> Em qui, 27 de set de 2018 às 07:14, Christian Reiß  > escreveu:
>
>> Hey folks,
>>
>> I am currently upgrading to 6.x on a test setup using my live puppet 
>> code; trying to get it to work with 6.x.
>> One weird issue I am getting is that alle default definitions (upper case 
>> classes) are faulting:
>>
>> Error: Could not retrieve catalog from remote server: Error 500 on SERVER
>> : Server Error: Evaluation Error: Resource type not found: Nagios_service 
>> (file: /etc/puppetlabs/code/environments/production/modules/pn_icinga/
>> manifests/client/checks.pp, line: 83, column: 3) on node outleapt.test
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>>
>>
>>
>> The corresponding manifest looks like this:
>>
>> Nagios_service {
>> check_period  => '24x7',
>> ensure=> $::pn_icinga::client::installed,
>> host_name => $::trusted['certname'],
>> initial_state => 'o',
>> max_check_attempts=> '3',
>> notification_interval => '5',
>> notification_options  => 'w,u,c,r',
>> notification_period   => $notification_period,
>> notifications_enabled => '0',
>> [...]
>> }
>>
>> Did I miss a regression somewhere?
>> Any help is greatly appreciated!
>>
>> -Chris.
>>
>> -- 
>> 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/bde5ac1d-f1ef-4454-885d-b499f22062c8%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> Atenciosamente,
>
> Rafael Tomelin
>
> skype: rafael.tomelin
>
> E-mail: rafael@gmail.com 
>
> RHCE  - Red Hat Certified Engineer
> PPT-205 - Puppet Certified Professional 2017
> Zabbix- ZABBIX Certified Specialist
> LPI3 
> ITIL v3
>

-- 
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/c2b29923-114f-4a82-8a66-cba5e428ca4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Unknown resource type after Upgrade

[Rafael Tomelin]

Hi dear,

This link the puppet6 release notes.
https://puppet.com/docs/puppet/6.0/release_notes.html#deprecations


   - The Nagios types no longer ship with Puppet, and are now available as
   the puppetlabs/nagios_core module from the Forge.


Em qui, 27 de set de 2018 às 07:14, Christian Reiß <
reiss.symgen...@gmail.com> escreveu:

> Hey folks,
>
> I am currently upgrading to 6.x on a test setup using my live puppet code;
> trying to get it to work with 6.x.
> One weird issue I am getting is that alle default definitions (upper case
> classes) are faulting:
>
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER:
> Server Error: Evaluation Error: Resource type not found: Nagios_service (
> file: /etc/puppetlabs/code/environments/production/modules/pn_icinga/
> manifests/client/checks.pp, line: 83, column: 3) on node outleapt.test
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
>
>
> The corresponding manifest looks like this:
>
> Nagios_service {
> check_period  => '24x7',
> ensure=> $::pn_icinga::client::installed,
> host_name => $::trusted['certname'],
> initial_state => 'o',
> max_check_attempts=> '3',
> notification_interval => '5',
> notification_options  => 'w,u,c,r',
> notification_period   => $notification_period,
> notifications_enabled => '0',
> [...]
> }
>
> Did I miss a regression somewhere?
> Any help is greatly appreciated!
>
> -Chris.
>
> --
> 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/bde5ac1d-f1ef-4454-885d-b499f22062c8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Atenciosamente,

Rafael Tomelin

skype: rafael.tomelin

E-mail: rafael.tome...@gmail.com

RHCE  - Red Hat Certified Engineer
PPT-205 - Puppet Certified Professional 2017
Zabbix- ZABBIX Certified Specialist
LPI3
ITIL v3

-- 
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/CAGEUqbAZL5VeQzR9JS1JQEUEqrbrmDDm0iWD%2BpD9AawruKv%3Dkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Unknown resource type after Upgrade

[Christian Reiß]

Hey folks,

I am currently upgrading to 6.x on a test setup using my live puppet code; 
trying to get it to work with 6.x.
One weird issue I am getting is that alle default definitions (upper case 
classes) are faulting:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Evaluation Error: Resource type not found: Nagios_service (
file: /etc/puppetlabs/code/environments/production/modules/pn_icinga/
manifests/client/checks.pp, line: 83, column: 3) on node outleapt.test
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run



The corresponding manifest looks like this:

Nagios_service {
check_period  => '24x7',
ensure=> $::pn_icinga::client::installed,
host_name => $::trusted['certname'],
initial_state => 'o',
max_check_attempts=> '3',
notification_interval => '5',
notification_options  => 'w,u,c,r',
notification_period   => $notification_period,
notifications_enabled => '0',
[...]
}

Did I miss a regression somewhere?
Any help is greatly appreciated!

-Chris.

-- 
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/bde5ac1d-f1ef-4454-885d-b499f22062c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.