[Puppet Users] Apache module + Ubuntu 18.04 + mpm prefork breaks PHP version

[comport3]

Hi All,

When testing the latest version of ' puppetlabs-apache', in default mode 
and settings on Ubuntu 18.04 it works fine.

When changing the mpm + php + cgi it all ends in tears when the PHP version 
mysteriously tries to go from 7.2 (available and default on OS) to 7.0.

Ala -
```
class { 'apache':
  mpm_module => 'prefork'
}
include ::apache::mod::cgi
include ::apache::mod::php
```

Any ideas how to override the 7.0 value and get 7.2?

If not, how to submit a bug request for the module?

Neither of these entries in Hiera did anything useful -
apache::params::phpXXX: libapache2-mod-php7.2
apache::params::php_version: 7.2

-- 
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/31f03856-85ac-4007-a367-a9f2d54567e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[comport3]

Hi John,

Thank you for your response. I tried putting the parameters directly into 
Hiera as suggested and nothing happened.

I don't fully understand Part 2: "2. You need any applicable resource-like 
declaration of class postgresql::server in the manifest set to not itself 
bind a value to the config_hash parameter."

Can you help me understand better what to do here please?

Chadwick - also, thanks, will check that out too.

-- 
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/d68afb5e-d8be-4198-9b58-397e0e0359a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[Eirik Øverby]

Hi,

> I don't fully understand Part 2: "2. You need any applicable resource-like 
> declaration of class postgresql::server in the manifest set to not itself 
> bind a value to the config_hash parameter."

You are probably declaring your class/resource setting default values for 
parameters directly in the .pp file. This will override whatever you're 
defining in Hiera. Just leave the declaration like

class foo:bar ( $param1, $param2='test' ) { ... }

In this way $param1 is considered mandatory, and if it's defined in hiera all 
is good (the hiera value will be used). Rparam2 is optional, and will be 
assigned the value 'test' no matter what hiera says - unless you instantiate 
the class with that parameter explicitly set.

/Eirik

-- 
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/B1A88929-5741-4EE6-9F35-FBD54B0F44D3%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[KevinR]

Hi Eirik,

the parameter behavior is actually the other way around:

class foo:bar(
$param1, # This enables you to provide 'param1' when instantiating 
the class,
 # and it enables auto-parameter-lookup for 
foo::bar::param1 in Hiera.
 # if no value is given or found in Hiera, the value of 
$param1 will be undef.

$param2='test'   # This enables you to provide 'param2' when instantiating 
the class,
 # and it enables auto-parameter-lookup for 
foo::bar::param2 in Hiera.
 # if no value is given or found in Hiera, the value of 
$param2 will be 'test'.
) { ... }

In other words, specifying = after a parameter in the class 
parameter definition, will enable you to provide a default value that is 
used as a last resort.

-Kevin

On Thursday, October 18, 2018 at 10:50:15 AM UTC+2, Eirik Øverby wrote:
>
> Hi, 
>
> > I don't fully understand Part 2: "2. You need any applicable 
> resource-like declaration of class postgresql::server in the manifest set 
> to not itself bind a value to the config_hash parameter." 
>
> You are probably declaring your class/resource setting default values for 
> parameters directly in the .pp file. This will override whatever you're 
> defining in Hiera. Just leave the declaration like 
>
> class foo:bar ( $param1, $param2='test' ) { ... } 
>
> In this way $param1 is considered mandatory, and if it's defined in hiera 
> all is good (the hiera value will be used). Rparam2 is optional, and will 
> be assigned the value 'test' no matter what hiera says - unless you 
> instantiate the class with that parameter explicitly set. 
>
> /Eirik

-- 
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/c2931a67-fe86-4fdc-99e2-b4e11d4d97e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[Eirik Øverby]

> class foo:bar(
> $param1, # This enables you to provide 'param1' when instantiating 
> the class,
>  # and it enables auto-parameter-lookup for foo::bar::param1 
> in Hiera.
>  # if no value is given or found in Hiera, the value of 
> $param1 will be undef.
> 
> $param2='test'   # This enables you to provide 'param2' when instantiating 
> the class,
>  # and it enables auto-parameter-lookup for foo::bar::param2 
> in Hiera.
>  # if no value is given or found in Hiera, the value of 
> $param2 will be 'test'.
> ) { ... }
> 
> In other words, specifying = after a parameter in the class 
> parameter definition, will enable you to provide a default value that is used 
> as a last resort.

Really? We just had to modify about 20 classes in our end because the hiera 
values were *not* used when defaults were specified in the class definitions.. 
Is there some obscure option/setting we've inherited from puppet2/3 that we're 
being bitten by?

And to Chadwick - sorry for the apparently bad advice :-)

/Eirik

-- 
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/35F60FFD-9962-4AA6-9685-6ABBB41F4E55%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[KevinR]

Hi Eirik,

I can't speak for those antique 2.x/3.x versions ;-)

The automatic parameter lookup feature is available from Puppet 4.8 
onwards, see the official description of it here 
.
As you can see from the documentation, setting parameter defaults is 
evaluated as Step 3, which comes after Hiera. You could only overrule Hiera 
if you provided parameters directly to the resource-like declaration as 
described in Step1.

-Kevin

On Thursday, October 18, 2018 at 1:57:41 PM UTC+2, Eirik Øverby wrote:
>
> > class foo:bar( 
> > $param1, # This enables you to provide 'param1' when 
> instantiating the class, 
> >  # and it enables auto-parameter-lookup for 
> foo::bar::param1 in Hiera. 
> >  # if no value is given or found in Hiera, the value of 
> $param1 will be undef. 
> > 
> > $param2='test'   # This enables you to provide 'param2' when 
> instantiating the class, 
> >  # and it enables auto-parameter-lookup for 
> foo::bar::param2 in Hiera. 
> >  # if no value is given or found in Hiera, the value of 
> $param2 will be 'test'. 
> > ) { ... } 
> > 
> > In other words, specifying = after a parameter in the class 
> parameter definition, will enable you to provide a default value that is 
> used as a last resort. 
>
> Really? We just had to modify about 20 classes in our end because the 
> hiera values were *not* used when defaults were specified in the class 
> definitions.. Is there some obscure option/setting we've inherited from 
> puppet2/3 that we're being bitten by? 
>
> And to Chadwick - sorry for the apparently bad advice :-) 
>
> /Eirik

-- 
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/379bbfd4-7688-4806-9145-592614264ead%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[jcbollinger]

On Thursday, October 18, 2018 at 6:57:41 AM UTC-5, Eirik Øverby wrote:
>
> > class foo:bar( 
> > $param1, # This enables you to provide 'param1' when 
> instantiating the class, 
> >  # and it enables auto-parameter-lookup for 
> foo::bar::param1 in Hiera. 
> >  # if no value is given or found in Hiera, the value of 
> $param1 will be undef. 
> > 
> > $param2='test'   # This enables you to provide 'param2' when 
> instantiating the class, 
> >  # and it enables auto-parameter-lookup for 
> foo::bar::param2 in Hiera. 
> >  # if no value is given or found in Hiera, the value of 
> $param2 will be 'test'. 
> > ) { ... } 
> > 
> > In other words, specifying = after a parameter in the class 
> parameter definition, will enable you to provide a default value that is 
> used as a last resort. 
>
> Really? We just had to modify about 20 classes in our end because the 
> hiera values were *not* used when defaults were specified in the class 
> definitions.. Is there some obscure option/setting we've inherited from 
> puppet2/3 that we're being bitten by? 
>
>

No, there is no option or setting that modulates this behavior.  It has 
always worked that way, from the time automated data binding was introduced 
in Puppet 3, and it has always been the intended (and IMO sensible) 
behavior.

I speculate that you've confused the semantics of class *definitions* with 
those of resource-like class *declarations*.  What you presented is the 
skeleton of a class definition, and a simple completion of it might be

class foo:bar ( $param1, $param2='test' ) {
  notify { 'foo::bar params':
msg => "param1 = ${param1}, param2 = ${param2}"
  }
}

That simply defines what class foo::bar means.  It is roughly analogous to 
a function or method definition in many general-purpose programming 
languages.

The corresponding analogue of a function *call*, on the other hand, is a 
class declaration.  There are two kinds, "include-like" and 
"resource-like".  The first is performed via an include, require, or contain 
statement, and does not provide a means to express class parameter values 
in the manifest.  For example,

include foo::bar

That is preferable in many contexts, but it is also possible to declare 
classes as if "class" were a resource type:

class { 'foo::bar ':
  # Parameter and metaparameter bindings may appear here, such as:
  param1 => 42
}

Either way, every class parameter must be bound to a value.  Puppet 
determines each parameter's value by checking the following sources, in 
order:

   1. The value specified in a resource-like class declaration has highest 
   precedence if such a value exists.  This is what I suspect you had in mind.
   2. The Puppet data lookup facility (a generalization of Hiera)
   3. The default value provided by the class definition, if any.

The first source from which a value for the parameter can be obtained is 
used, and if none of those provides a value then the catalog builder 
bails.  Thus, if you want a value from Hiera to be used for parameter 
$foo::bar::param2 then in addition to providing such a value in the data, 
you must ensure that any resource-like declaration of the class that is 
evaluated avoids binding a value to that parameter.  And this is the same 
thing I was saying in my earlier response.

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b8656471-bc16-4284-b8e2-8f326db3dc36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Using variable for user password hash causes password updated each run.

[James Perry]

I have been asked to set password for a user so it is unique on every 
single host we support. I have a script that generates the password and I 
had pulled it in via a generate call. The scripts takes in two of facter 
values to be used to aid in generating the password. 

$myvar = generate("/bin/sh","myscript.sh"."value1","value2")
user { 'bob':
 password => "${myvar}",
 }


This value is coming in as expected. When I pass it to the password => block 
it gets set as expected. Cool, but then it isn't. 

Each time puppet runs for the host, it keeps changing the user's password 
hash even though the hash from the script is the same as that on the host. 
Even that could be acceptable, except, these hosts are audited for password 
changes. Root being shown as updated every puppet run fails the audit. 

When I define it as a static hash aka '$1$salt$ab12k3oa01ksf01810' it 
doesn't keep resetting the password

Notice: Local environment: 'production' doesn't match server specified node 
environment 'passfix', switching agent to 'passfix'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for tlistmrrh511.myhost.net
Info: Applying configuration version '1539886469'
*Notice: /Stage[main]/Users::mypassword/User[bob]/password: created 
password*
Notice: Applied catalog in 4.52 seconds
[root@tlistmrrh511 ~]#
[root@tlistmrrh511 ~]# puppet agent -tv
Notice: Local environment: 'production' doesn't match server specified node 
environment 'passfix', switching agent to 'passfix'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for tlistmrrh511.myhost.net
Info: Applying configuration version '1539886484'
*Notice: /Stage[main]/Users::myassword/User[bob]/password: created password*
Notice: Applied catalog in 4.36 seconds

I have tried a number of ways to get this work inside puppet without using 
exec. Searching on this came up with creating custom facts to get the hash 
or hierra, which we don't use, to do this step. Having user hashes 
available as a fact won't pass an audit either. Basically this all needs to 
happen on the Puppet master and be pushed to all clients.

It seems that Puppet has a way to compare the old has with the new one when 
the hash is put between ' ', but I'm passing in a var.

I don't see any indication of why it is failing the comparrison. I have 
even set passwd => generate(... and it behaves the same way. 

What am I doing wrong here? It is quite frustrating.  

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/4bc322cd-c3bc-44fa-9c6a-1ccd6a778b81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Certificate Issues

[Rohit]

 Hello, we currently have a puppet docker container setup and are 
experiencing certificate issues. Basically, in our docker setup (on our 
main server) I had generated and signed new certificates, but the puppet_db 
container keeps restarting. Here are logs from the puppet_db container:

‘Error: Could not retrieve catalog from remote server: SSL_connect 
returned=1 errno=0 state=error: certificate verify failed: [unable to get 
local issuer certificate for /CN=our.puppet.domain]
Error: Could not retrieve catalog; skipping run
Error: Could not send report: SSL_connect returned=1 errno=0 
state=error: certificate verify failed: [unable to get local issuer 
certificate for /CN=our.puppet.domain]’

I have tried series of steps to solve this problem as it looks like Puppet 
is not functioning correctly as our servers are not properly listening to 
the host server. Any idea what I can do to solve this problem? For 
reference, we are running Puppet_DB version 4.2 and Puppet Server version 
2.7.2, all of which is set up on a docker container environment on one 
server.

-- 
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/66479e42-5d70-41b0-a0d9-0774e273fdab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] pip package provider on Redhat

[Sergei Gerasenko]

Yeah, I know we're old. I'm asking in general though (imagining it would be 
happening with the current version for example?), what would be an elegant 
way to fix this?

On Wednesday, October 17, 2018 at 5:22:05 AM UTC-5, Ben Ford wrote:
>
> Hi Sergei!
>
> Puppet 3.x is quite old, and in fact has been end-of-lifed for 655 days as 
> of today! (December 31, 2016). It is no longer receiving security or bug 
> fixes. If you upgrade to a modern version, you'll see that there's are new 
> pip and pip3 providers that use the appropriate commands. 
> https://github.com/puppetlabs/puppet/blob/1707f2ca46867651095e01379bd01dab08076b8b/lib/puppet/provider/package/pip.rb#L55-L65
>
>
> On Wed, Oct 17, 2018 at 11:18 AM Sergei Gerasenko  > wrote:
>
>> Hello,
>>
>> I'm running puppet 3.5.1 and the pip package provider has this bit:
>>
>>   def self.cmd
>> case Facter.value(:osfamily)
>>   when "RedHat"
>> "pip-python"
>>   else
>> "pip"
>> end
>>   end
>>
>> As you can see, when the OS is RedHat, it wants to use the pip-python 
>> command, but it's not available for latest versions of Redhat/CentOS. Is 
>> there an easy way to override the command for that provider without 
>> altering the puppet source code?
>>
>> -- 
>> 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/c15b51cd-23fa-4406-ad92-ff3e2b63c839%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/6351ceeb-5495-4348-bc89-2a74da54ff14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Gurus, Question

[avanbevers]

Puppet Gurus, I am looking for a person or contracting company to assist my 
company in the Washington DC area for a Contract Puppet SME. Where is a 
good place to look or post? Any help would be appreciated. The agencies 
around here DONT specialize in it and I am fed a lot of BS. Any help would 
be 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/a3ff5af1-1580-4f4d-b419-9a5ee75fb8f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Certificate Issues

[Morgan Rhodes]

Hi Rohit,

Is the hostname from `/CN=our.puppet.domain` showing up in your 
puppetserver's certificate? You can verify that with `puppet cert list 
--all` on the puppetserver container. This looks like a DNS issue.

On Thursday, October 18, 2018 at 11:41:16 AM UTC-7, Rohit wrote:
>
>  Hello, we currently have a puppet docker container setup and are 
> experiencing certificate issues. Basically, in our docker setup (on our 
> main server) I had generated and signed new certificates, but the puppet_db 
> container keeps restarting. Here are logs from the puppet_db container:
>
> ‘Error: Could not retrieve catalog from remote server: SSL_connect 
> returned=1 errno=0 state=error: certificate verify failed: [unable to get 
> local issuer certificate for /CN=our.puppet.domain]
> Error: Could not retrieve catalog; skipping run
> Error: Could not send report: SSL_connect returned=1 errno=0 
> state=error: certificate verify failed: [unable to get local issuer 
> certificate for /CN=our.puppet.domain]’
>
> I have tried series of steps to solve this problem as it looks like Puppet 
> is not functioning correctly as our servers are not properly listening to 
> the host server. Any idea what I can do to solve this problem? For 
> reference, we are running Puppet_DB version 4.2 and Puppet Server version 
> 2.7.2, all of which is set up on a docker container environment on one 
> server.
>

-- 
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/1a315e30-fd7f-4da8-ba52-52da56756311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Apache module + Ubuntu 18.04 + mpm prefork breaks PHP version

[comport3]

OK I have managed to debug this one.

It only seems to apply when using mpm_module: prefork with cgid and/or php

There is a fix to the Apache module as follows:
 Bump the $php_version in params.pp from 7.0 to 7.2 on line 268

Add this section beneath the preceding logic around line 85/86 in mpm.pp:
  if $mpm == 'prefork' and $::operatingsystem == 'Ubuntu' and 
$::operatingsystemrelease == '18.04' {
# workaround 
https://bugs.launchpad.net/ubuntu/+source/mpm-itk/+bug/1286882
# https://bugs.launchpad.net/ubuntu/+source/php7.2/+bug/1771934
# https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1782806
exec {
  '/usr/sbin/a2dismod mpm_event':
onlyif  => '/usr/bin/test -e 
/etc/apache2/mods-enabled/mpm_event.load',
require => Package['httpd'],
before  => Package['libapache2-mod-php7.2'],
}

Hopefully this helps someone in the future.

On Thursday, October 18, 2018 at 7:43:55 PM UTC+11, comport3 wrote:
>
> Hi All,
>
> When testing the latest version of ' puppetlabs-apache', in default mode 
> and settings on Ubuntu 18.04 it works fine.
>
> When changing the mpm + php + cgi it all ends in tears when the PHP 
> version mysteriously tries to go from 7.2 (available and default on OS) to 
> 7.0.
>
> Ala -
> ```
> class { 'apache':
>   mpm_module => 'prefork'
> }
> include ::apache::mod::cgi
> include ::apache::mod::php
> ```
>
> Any ideas how to override the 7.0 value and get 7.2?
>
> If not, how to submit a bug request for the module?
>
> Neither of these entries in Hiera did anything useful -
> apache::params::phpXXX: libapache2-mod-php7.2
> apache::params::php_version: 7.2
>

-- 
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/f3cffaf4-dd68-4c4b-ae87-9398ce0d3d19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet 6 removed native Nagios provider

[comport3]

Hi All,

We are testing some Nagios stuff on Puppet 6 and it seems all the 
previously native functionality was completely removed.

Is it available to be re-added via a Module? If not, why was it removed - 
technical issues, etc??

Example to reproduce:

(on server to be monitored, exporting it's 'nagios_host' resource)
  @@nagios_host { $::fqdn :
tag=> "nagios-${lookup('nagios_server')}",
ensure => present,
address => $facts['networking.ip'],
use=> 'wan-host',
hostgroups => (lookup('nagios_hostgroups', {merge => deep})).join(','),
target => "/etc/nagios3/conf.d/puppet.d/host_${::fqdn}.cfg",
  }

(on monitoring server collecting this exported resource:

*Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Evaluation Error: Error while evaluating a Resource 
Statement, Unknown resource type: 'nagios_host'*

-- 
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/0f91c67f-36f7-4c3e-ab7c-d4a98d0be144%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 6 removed native Nagios provider

[Angel L. Mateo]

El 19/10/18 a las 5:45, comport3 escribió:

Hi All,

We are testing some Nagios stuff on Puppet 6 and it seems all the 
previously native functionality was completely removed.


Is it available to be re-added via a Module? If not, why was it removed 
- technical issues, etc??



https://forge.puppet.com/puppetlabs/nagios_core

--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 86337

--
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/57dee60c-25fa-f855-1ec5-9ba4cea07aa8%40um.es.
For more options, visit https://groups.google.com/d/optout.