Re: [Puppet Users] One master per environment, or one to rule them all?

[Daniel Urist]

Option (2) allows you to test upgrades to the puppet infrastructure itself,
which changes not infrequently.

On Wed, Oct 11, 2017 at 3:15 PM, Antony Gelberg 
wrote:

> I've asked a similar question on the Terraform mailing-list but on
> reflection, I think it's more appropriate here.
>
> Let's say I need several environments, and I'm using AWS, with each
> environment in a separate VPC. I'm going to configure instances with Puppet
> (and deploy with Jenkins). I see two basic design options here:
>
> *Option 1: Puppet master in one environment / VPC, either:*
>
>1. In their own VPC, e.g. "devops".
>2. Less-optimally, piggy-backed on an application environment VPC,
>e.g. "staging".
>
> This master would be responsible for configuring all servers across all
> other environments / VPCs.
>
> Implications:
>
>- Have to open up security groups, scope for environments to affect
>each other.
>- Configuring Puppet environments using something like r10k, high
>dependency on that enviroment
>- VPCs will have to have different CIDRs (not sure if this is a big
>deal).
>
>
> *Option 2: Every environment to have its own Puppet master.*
>
> Implications:
>
>- More costly.
>- Feels "cleaner", each Puppet master only needs to handle one
>environment.
>- Less likely for environments to interfere with each other.
>- Potentially less (or more?) pain with managing Puppet environments.
>- Might be overly complex.
>
> Is either of these an obviously better choice than the other? If (1) is
> better, is sub-option (1) or (1) better?
> Or are both options both viable and sane?
>
> NB Assume that "master" may mean "masters" according to the need.
>
> --
> 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/d5c26bc6-c7ce-4439-8073-41c462f9ded2%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/CAEo6%3DKaD-qaEy8hhi6ACqEVqz1KRhfyBh5YLk1tviwf4TMs54Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] ERB variable scope

[Daniel Urist]

Thanks very much.

It would be great if the template doc page (
https://docs.puppet.com/puppet/5.3/lang_template.html) gave more guidance
on epp vs erp, use cases for each and possible gotchas like this.

On Fri, Oct 6, 2017 at 4:17 PM, Henrik Lindberg 
wrote:

> On 06/10/17 11:28, Daniel Urist wrote:
>
>> I've noticed in classes with multiple templates that ERB variables seem
>> to share a single scope. That caught me by surprise-- is that intended
>> behavior?
>>
>>
> Intended or not - that is the behavior, and this is Ruby so it is possible
> to mutate things that should be immutable.
>
> There is great responsibility when writing code in ERB because of the
> generality and power available in Ruby. Suggest using EPP instead where
> problems like this one does not occur.
>
> Best,
> - henrik
>
> Here's a simple test case:
>>
>> class erb_scope_test (
>> )
>> {
>>$myarr1 = [ 'one' ]
>>$myarr2 = [ 'two' ]
>>
>>$str1 = inline_template("<%= @myarr1.concat(@myarr2) %>")
>>notify { $str1: }
>>
>>$str2 = inline_template("<%= @myarr1.concat(@myarr2) %>")
>>notify { $str2: }
>> }
>>
>> Notice: ["one", "two"]
>> Notice: ["one", "two", "two"]
>>
>> --
>> 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 > puppet-users+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/puppet-users/CAEo6%3DKbd8wMO9rvzHMe4W-bo%2BizqLxyAyEf4Th
>> WScOAgpL%2BkdA%40mail.gmail.com <https://groups.google.com/d/m
>> sgid/puppet-users/CAEo6%3DKbd8wMO9rvzHMe4W-bo%2BizqLxyAyEf4T
>> hWScOAgpL%2BkdA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/puppet-users/or8vca%242te%241%40blaine.gmane.org.
> 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/CAEo6%3DKY%2B16i7Nxpaj9yDo%3DsY_YW6WdBfPUVHC0Dw2jBas7JQdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] ERB variable scope

[Daniel Urist]

I've noticed in classes with multiple templates that ERB variables seem to
share a single scope. That caught me by surprise-- is that intended
behavior?

Here's a simple test case:

class erb_scope_test (
)
{
  $myarr1 = [ 'one' ]
  $myarr2 = [ 'two' ]

  $str1 = inline_template("<%= @myarr1.concat(@myarr2) %>")
  notify { $str1: }

  $str2 = inline_template("<%= @myarr1.concat(@myarr2) %>")
  notify { $str2: }
}

Notice: ["one", "two"]
Notice: ["one", "two", "two"]

-- 
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/CAEo6%3DKbd8wMO9rvzHMe4W-bo%2BizqLxyAyEf4ThWScOAgpL%2BkdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Force custom service provider to never be default

[Daniel Urist]

I've written a simple custom service provider for monit that inherits from
the debian provider. Since this is running on debian systems, I want to use
the debian "enable" to enable/disable running at boot, but I want monit to
manage the running service rather than puppet.

Puppet::Type.type(:service).provide :monitdummy, :parent => :debian do
>   desc <<-'EOT'
> Dummy provider for monit; always reports status as "running" so puppet
> doesn't manage the running state
>   EOT
>
>   confine :exists => "/usr/bin/monit"
>
>   def startcmd
> [ "/bin/true" ]
>   end
>   def stopcmd
> [ "/bin/true" ]
>   end
>   def restartcmd
> [ "/bin/true" ]
>   end
>   def statuscmd
> [ "/bin/true" ]
>   end
> end
>

It works for what I need. My problem is that this has now become the
default provider on my system, according to facter:

# facter -p | grep service
> service_provider => monitdummy


I've tried adding a call to "defaultfor" like this:

defaultfor :operatingsystem => 'none'


...but that doesn't have any effect, I guess because it's inheriting the
defaultfor from the debian provider and there can be multiple?

Looking at the code in
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider.rb,
there is the function "self.specificity" that picks the provider with the
most ancestors, so I guess that's why my provider gets picked over debian.

I realize I could set debian as the default provider with "Service {
provider => 'debian' }" in a high-level manifest, but that seems less than
ideal since it short-circuits puppet's provider selection-- what I'd really
like would be for a way to ensure that my custom provider is never the
default.

Is there any way to do 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/CAEo6%3DKYU449ig7VmDYiLYkhpjDz9-jMP_aXx7isSyQkpOxiRew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: hiera_include failing with undefined method "cached_file_data"

[Daniel Urist]

Fixed by restarting puppetserver per
https://tickets.puppetlabs.com/browse/PUP-7337

It looks like the debian packages are missing a restart trigger:
https://tickets.puppetlabs.com/browse/PA-681

On Mon, Mar 13, 2017 at 11:10 AM, Daniel Urist  wrote:

> I've tried replacing the call to hiera_include() with a call to include()
> like this (per https://docs.puppet.com/puppet/latest/function.html#
> hierainclude) , but that results in the same error:
>
> include( lookup("roles::${role}", {'merge' => 'unique' }) )
>
>
> On Mon, Mar 13, 2017 at 10:53 AM, Daniel Urist  wrote:
>
>> So, this just started happening on all my  nodes following upgrade to
>> puppet-agent 1.9.3-1jessie on my puppet master:
>>
>> root@nweb8:/# puppet agent -t
>>> Info: Retrieving pluginfacts
>>> Info: Retrieving plugin
>>> Info: Loading facts
>>> Error: Could not retrieve catalog from remote server: Error 500 on
>>> SERVER: {"message":"Server Error: Evaluation Error: Error while evaluating
>>> a Function Call, undefined method `cached_file_data' for
>>> # at
>>> /etc/puppetlabs/code/environments/production/manifests/site.pp:48:3 on
>>> node nweb8.ucar.edu","issue_kind":"RUNTIME_ERROR","stacktrace":["Warning:
>>> The 'stacktrace' property is deprecated and will be removed in a future
>>> version of Puppet. For security reasons, stacktraces are not returned with
>>> Puppet HTTP Error responses."]}
>>
>>
>> The relevant code in my site.pp is this:
>>
>> node default {
>>>   hiera_include('bogusplaceholder', "roles::${role}")
>>> }
>>
>>
>> According to the docs, the hiera_include function should still be
>> supported.
>>
>>
>

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

[Puppet Users] Re: hiera_include failing with undefined method "cached_file_data"

[Daniel Urist]

I've tried replacing the call to hiera_include() with a call to include()
like this (per
https://docs.puppet.com/puppet/latest/function.html#hierainclude) , but
that results in the same error:

include( lookup("roles::${role}", {'merge' => 'unique' }) )


On Mon, Mar 13, 2017 at 10:53 AM, Daniel Urist  wrote:

> So, this just started happening on all my  nodes following upgrade to
> puppet-agent 1.9.3-1jessie on my puppet master:
>
> root@nweb8:/# puppet agent -t
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Loading facts
>> Error: Could not retrieve catalog from remote server: Error 500 on
>> SERVER: {"message":"Server Error: Evaluation Error: Error while evaluating
>> a Function Call, undefined method `cached_file_data' for
>> # at /etc/puppetlabs/code/
>> environments/production/manifests/site.pp:48:3 on node nweb8.ucar.edu
>> ","issue_kind":"RUNTIME_ERROR","stacktrace":["Warning: The 'stacktrace'
>> property is deprecated and will be removed in a future version of Puppet.
>> For security reasons, stacktraces are not returned with Puppet HTTP Error
>> responses."]}
>
>
> The relevant code in my site.pp is this:
>
> node default {
>>   hiera_include('bogusplaceholder', "roles::${role}")
>> }
>
>
> According to the docs, the hiera_include function should still be
> supported.
>
>

-- 
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/CAEo6%3DKYx3Njo54-EJ3%3D0FK1XNAgQUr78%3D8iR8qQRuzQ2mPiVVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] hiera_include failing with undefined method "cached_file_data"

[Daniel Urist]

So, this just started happening on all my  nodes following upgrade to
puppet-agent 1.9.3-1jessie on my puppet master:

root@nweb8:/# puppet agent -t
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER:
> {"message":"Server Error: Evaluation Error: Error while evaluating a
> Function Call, undefined method `cached_file_data' for
> # at
> /etc/puppetlabs/code/environments/production/manifests/site.pp:48:3 on node
> nweb8.ucar.edu","issue_kind":"RUNTIME_ERROR","stacktrace":["Warning: The
> 'stacktrace' property is deprecated and will be removed in a future version
> of Puppet. For security reasons, stacktraces are not returned with Puppet
> HTTP Error responses."]}


The relevant code in my site.pp is this:

node default {
>   hiera_include('bogusplaceholder', "roles::${role}")
> }


According to the docs, the hiera_include function should still be supported.

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

Re: [Puppet Users] Re: hiera deep hash merges broken

[Daniel Urist]

It turns out my issue was caused by eyaml no longer supporting deep hash
merges. I've worked around my issue by separating out plain yaml and eyaml.
Fortunately none of my existing code does a deep hash merge on the eyaml
keys.

It would be great to get some reassurance that eyaml will continue to be
properly supported going forward-- my impression is that it's pretty
popular; certainly it's very useful.

On Wed, Feb 15, 2017 at 4:51 PM, Francois Lafont <
francois.lafont.1...@gmail.com> wrote:

> On 02/15/2017 09:24 PM, Eric Sorenson wrote:
>
> > That's great to hear François, thank you for testing the patch!
>
> You are welcome. :)
>
> > Our plan at
> > this point is to accumulate a couple more fixes and ship a new build by
> > Tuesday 21 Feb -
> >
> > I don't want to generate a new build containing only the fix in PUP-7215
> > because
> > (a) there is QA work underway on the current release that may turn up new
> > things that need fixing by the end of the week
> > (b) there is a simple workaround in PUP-7216 which is that you can
> > s/hiera_hash/lookup/ as the function that you call.
>
> Ok, no problem, it's better to hold your workflow.
>
> Bye.
> François Lafont
>
>
> --
> 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/442a6d8a-387b-1dbc-031b-4605842b706f%40gmail.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/CAEo6%3DKZ%3D4LPZQJBtD8UZoNxrVS8gu_E5uZD7am8RSJu4abZ%2BUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: hiera deep hash merges broken

[Daniel Urist]

Just found this issue, which seems to describe what's going on:
https://github.com/TomPoulton/hiera-eyaml/issues/222
So eyaml is broken wrt hash merges? Are there any workarounds available?


On Tue, Feb 14, 2017 at 12:35 PM, Daniel Urist  wrote:

> To get deep hash merges in hiera, I have been using the following in my
> hiera.yaml:
>
>
>> ---
>> :merge_behavior: deeper
>> :backends:
>>   - eyaml
>
>
> And in one of my classes, a call to hiera_hash() like this:
>
> $if_merged = hiera_hash('profiles::pserver::interfaces')
>
>
> However, with  puppetserver version 2.7.2-1puppetlabs1, this is now broken
> and fails with this error:
>
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER:
>> Internal Server Error: org.jruby.exceptions.RaiseException: (Exception)
>> Hiera type mismatch: expected Hash and got Array
>
>
> I've tried commenting out ":merge_behavior: deeper" in hiera.yaml and
> using a lookup function instead:
>
> $if_merged = lookup('profiles::pserver::interfaces', Hash, 'deep')
>
>
> However, I'm not getting a merged hash when I do this.
>
> How can I get a deep merge hash?
>
>
>

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

[Puppet Users] hiera deep hash merges broken

[Daniel Urist]

To get deep hash merges in hiera, I have been using the following in my
hiera.yaml:


> ---
> :merge_behavior: deeper
> :backends:
>   - eyaml


And in one of my classes, a call to hiera_hash() like this:

$if_merged = hiera_hash('profiles::pserver::interfaces')


However, with  puppetserver version 2.7.2-1puppetlabs1, this is now broken
and fails with this error:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER:
> Internal Server Error: org.jruby.exceptions.RaiseException: (Exception)
> Hiera type mismatch: expected Hash and got Array


I've tried commenting out ":merge_behavior: deeper" in hiera.yaml and using
a lookup function instead:

$if_merged = lookup('profiles::pserver::interfaces', Hash, 'deep')


However, I'm not getting a merged hash when I do this.

How can I get a deep merge hash?

-- 
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/CAEo6%3DKbvqrNfMpNEHgfS%2BiTG%3Du%3D78BYMPbg83NzyOvTX%2B9ZDvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] hiera_hash, lookup, Hiera 5

[Daniel Urist]

I have been using ":merge_behavior: deeper" in my hiera.yaml file to turn
on deep hash merges with hiera_hash, but now this appears to be broken.

The latest docs (at https://docs.puppet.com/puppet/4.9/lookup_quick.html)
suggest using the lookup() function, but then state this:

IMPORTANT: These docs are outdated, and replacement pages are coming soon.
> Puppet lookup is now called Hiera 5, and it works differently from what’s
> described on this page.


So, how do I get hiera hash merges right now? I'm on debian jessie with the
following versions:

puppetserver  2.7.2-1puppetlabs1
puppet-agent 1.9.1-1jessie

I also have clients running the puppet agent from jessie backports, version
3.8.5-2~bpo8+1, but I'm assuming this problem is on the server side.

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

[Puppet Users] logrotate and puppetserver debian package

[Daniel Urist]

The release notes for puppetserver state the following (
https://docs.puppet.com/puppetserver/latest/release_notes.html):

Debian upgrade note: On Debian-based Linux distributions, logrotate will
> continue to attempt to manage your Puppet Server log files until
> /etc/logrotate.d/puppetserver is removed. These logrotate attempts are
> harmless, but will generate a duplicate archive of logs. As a best
> practice, delete puppetserver from logrotate.d after upgrading to Puppet
> Server 2.6.


However, the latest debian jessie package for puppetserver (version
2.6.0-1puppetlabs1) still contains the file /etc/logrotate.d/puppetserver.

Is this just an oversight (bug!) in the package, or is logrotate still
needed for Debian?

-- 
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/CAEo6%3DKbcmcGK9zc4J6KcoucC-6wg2N%2B7fHfjy1hWmVML_WsR3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

There doesn't seem to be an issue when I run my test code with "puppet
apply".

I've tried this under puppet agents v.4.5.0 and v.3.8.5

On Fri, May 20, 2016 at 10:56 AM, Matthaus Owens 
wrote:

> Daniel,
> Thanks for filing the ticket. I'll take a stab at reproducing it today.
> Did you only see it with puppet runs against a master, or also with local
> puppet apply?
>
> On Fri, May 20, 2016 at 8:20 AM, Daniel Urist  wrote:
>
>> I filed a bug: https://tickets.puppetlabs.com/browse/SERVER-1356
>>
>> On Fri, May 20, 2016 at 6:41 AM, JeremyCampbell <
>> jeremycampbel...@gmail.com> wrote:
>>
>>> I can confirm the same issue on Puppetserver v2.4.0
>>>
>>> --
>>> 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/62c4f502-e46b-4cef-9fc6-71767eb1d5c3%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/62c4f502-e46b-4cef-9fc6-71767eb1d5c3%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> 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/CAEo6%3DKaa43cJg%3Daddt%2B%3DTR1%2B%2BH0C8vm2eAmvYUevcqPuNkHNfg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CAEo6%3DKaa43cJg%3Daddt%2B%3DTR1%2B%2BH0C8vm2eAmvYUevcqPuNkHNfg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/CACD%3DwAfyDLQuTgOjF_UbLYB24g9KAnLYVmYybDGe6vL_iHrzdw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CACD%3DwAfyDLQuTgOjF_UbLYB24g9KAnLYVmYybDGe6vL_iHrzdw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CAEo6%3DKa2S37btXmJd7idhr4d8Prs0YMz%2BGExO0x8ZZf2HpkF%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

I filed a bug: https://tickets.puppetlabs.com/browse/SERVER-1356

On Fri, May 20, 2016 at 6:41 AM, JeremyCampbell 
wrote:

> I can confirm the same issue on Puppetserver v2.4.0
>
> --
> 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/62c4f502-e46b-4cef-9fc6-71767eb1d5c3%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/CAEo6%3DKaa43cJg%3Daddt%2B%3DTR1%2B%2BH0C8vm2eAmvYUevcqPuNkHNfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

Here's some code to try:

  $var1 = undef
  $var2 = "undef"
  $var3 = 'undef'
  $var4 = "'undef'"
  $var5 = '"undef"'
  notify { "VAR1: ${var1} VAR2: ${var2} VAR3: ${var3} VAR4: ${var4} VAR5:
${var5}": }

When run, this results in:

  Notice: VAR1:  VAR2:  VAR3:  VAR4: 'undef' VAR5: "undef"

On Thu, May 19, 2016 at 8:30 AM, Daniel Urist  wrote:

> puppetserver: 2.3.2-1puppetlabs1
> puppet client: 3.8.5-2~bpo8+1
>
> Both server and clients are running Debian 8 (jessie); the puppet client
> is from the Debian backports repo.
>
> On Wed, May 18, 2016 at 3:40 PM, Matthaus Owens 
> wrote:
>
>> Daniel,
>> Which version of Puppet are you seeing this on?
>>
>> On Wed, May 18, 2016 at 2:33 PM, Daniel Urist  wrote:
>>
>>> I have been using the yo61 logrotate module from puppetforge (
>>> https://forge.puppet.com/yo61/logrotate), which seems to be the most
>>> popular, but it recently stopped working, with many errors about undefined
>>> parameters.
>>>
>>> The issue seems to be the use of the string 'undef' as a default value;
>>> for example:
>>>
>>> define logrotate::rule(
>>>> $create_owner   = 'undef',
>>>>
>>>
>>> Later on in the code, there are comparisons against the actual string
>>> 'undef'; for example:
>>>
>>>
>>>   if ($create_owner != 'undef') and ($create_mode == 'undef') {
>>>> fail("Logrotate::Rule[${name}]: create_owner requires create_mode")
>>>>}
>>>
>>>
>>> Regardless of whether this is best practice, these comparisons are now
>>> failing, apparently because the string 'undef' is now treated as the value
>>> undef. I've confirmed this by printing the string with notify (prints
>>> nothing when it's 'undef'), and changing it to something else, which does
>>> print.
>>>
>>> I'm not sure exactly when this changed or if it's intended behavior or a
>>> bug, but it does seem odd that now apparently 'undef' === undef
>>>
>>> --
>>> 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/CAEo6%3DKYjAx286r9NNvKtGU3PscrAZ77H5_HXc9CXO1LLa552sg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/puppet-users/CAEo6%3DKYjAx286r9NNvKtGU3PscrAZ77H5_HXc9CXO1LLa552sg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CAEo6%3DKZ-Ayz5pz%3Djs-EdO8%2BbkP7seQjKNBL-NSKjCnFzdhSavQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

puppetserver: 2.3.2-1puppetlabs1
puppet client: 3.8.5-2~bpo8+1

Both server and clients are running Debian 8 (jessie); the puppet client is
from the Debian backports repo.

On Wed, May 18, 2016 at 3:40 PM, Matthaus Owens  wrote:

> Daniel,
> Which version of Puppet are you seeing this on?
>
> On Wed, May 18, 2016 at 2:33 PM, Daniel Urist  wrote:
>
>> I have been using the yo61 logrotate module from puppetforge (
>> https://forge.puppet.com/yo61/logrotate), which seems to be the most
>> popular, but it recently stopped working, with many errors about undefined
>> parameters.
>>
>> The issue seems to be the use of the string 'undef' as a default value;
>> for example:
>>
>> define logrotate::rule(
>>> $create_owner   = 'undef',
>>>
>>
>> Later on in the code, there are comparisons against the actual string
>> 'undef'; for example:
>>
>>
>>   if ($create_owner != 'undef') and ($create_mode == 'undef') {
>>> fail("Logrotate::Rule[${name}]: create_owner requires create_mode")
>>>}
>>
>>
>> Regardless of whether this is best practice, these comparisons are now
>> failing, apparently because the string 'undef' is now treated as the value
>> undef. I've confirmed this by printing the string with notify (prints
>> nothing when it's 'undef'), and changing it to something else, which does
>> print.
>>
>> I'm not sure exactly when this changed or if it's intended behavior or a
>> bug, but it does seem odd that now apparently 'undef' === undef
>>
>> --
>> 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/CAEo6%3DKYjAx286r9NNvKtGU3PscrAZ77H5_HXc9CXO1LLa552sg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CAEo6%3DKYjAx286r9NNvKtGU3PscrAZ77H5_HXc9CXO1LLa552sg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAEo6%3DKa5FpwNDBXfnEACFUD0_%3Dm2efTJEnCiheN7sNhnxxEEVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

I have been using the yo61 logrotate module from puppetforge (
https://forge.puppet.com/yo61/logrotate), which seems to be the most
popular, but it recently stopped working, with many errors about undefined
parameters.

The issue seems to be the use of the string 'undef' as a default value; for
example:

define logrotate::rule(
> $create_owner   = 'undef',
>

Later on in the code, there are comparisons against the actual string
'undef'; for example:


  if ($create_owner != 'undef') and ($create_mode == 'undef') {
> fail("Logrotate::Rule[${name}]: create_owner requires create_mode")
>}


Regardless of whether this is best practice, these comparisons are now
failing, apparently because the string 'undef' is now treated as the value
undef. I've confirmed this by printing the string with notify (prints
nothing when it's 'undef'), and changing it to something else, which does
print.

I'm not sure exactly when this changed or if it's intended behavior or a
bug, but it does seem odd that now apparently 'undef' === undef

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

Re: [Puppet Users] Avoiding duplicate exported resource

[Daniel Urist]

I've managed to solve this with query_resources() from puppedbquery to
generate an array of the resources and ensure_resource() to only create a
single instance. That seems to be the cleanest way at the moment to handle
this.

On Mon, Mar 7, 2016 at 9:25 AM, Ken Barber  wrote:

> >> Model wise, in an ideal world, the proxied/virtual address would be a
> >> 'node' of sorts, and have that entry, but if no box exists to compile
> >> that catalog, well then we're just talking crazy :-).
> >>
> >
> >
> > Well no, if the proxied / virtual address is not a property specific to
> any
> > individual node, then it is a property of the overall site configuration.
> > Puppet therefore does not need to determine this from the nodes;
> instead, it
> > needs to *apply* it to them.  As such, it ought to be recorded in the
> Hiera
> > data repository from which Puppet is working.  If it's in the data, then
> it
> > does not need to be communicated between nodes via exported resources.
> > Rather, Puppet should draw it from the same source for all nodes that
> need
> > it for any purpose.
>
> I think you've missed my modelling point or perspective, I was simply
> expressing that if you could do it, you would record the intended
> exported resource to a virtual node that maps to the virtual address,
> but this isn't possible today. Hiera isn't part of the resulting
> model, its just input that creates the graph. This is academic though,
> its not possible anyway.
>
> Irrespective of this imaginary world, one could store the data in
> hiera to be consumed, if one chose to - or somewhere else, it matters
> little for the resulting graph.
>
> ken.
>
> --
> 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/CAE4bNTk-D4w96-7729kOzZhx%2B4DnkR7VrR0Uat9x8HmnFribPA%40mail.gmail.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/CAEo6%3DKYjR2ifPKpnGeLAkv%2Bo4P2tG%2BT6kxvoJAMiCHCsWt7vgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Avoiding duplicate exported resource

[Daniel Urist]

I've created a module to configure a caching nginx proxy. I am running
several of these proxies behind a load balancer. They all proxy the same
external address. I'd like to export a nagios host/service for monitoring
the external address, which will then be collected on my nagios server. The
problem is, since I have several instances of the proxy managed by puppet,
and the exported host/service is identical on each, I end up with duplicate
resources. I could give the resources unique names (e.g. by appending the
proxy's hostname to the resource name), but then I end up with multiple
identical hosts/services in nagios, which doesn't work.

The puppet stdlib module has an "ensure_resource" function, but there
doesn't seem to be a way to use this on an exported resource collector.

I guess one workaround would be to set a parameter in the proxy module, for
example "export_address" and have that default to "false", and only set it
to "true" for one node, but that's kind of ugly since one node then needs
to be special.

Surely this isn't an uncommon use case-- what's the best way to work around
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/CAEo6%3DKbwrCYz3ovqo-E0u7EH-Jep%2BwrxEW3FhV1v8-G%3DRr%2B80w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: PuppetDB 2.3.8 has been released!

[Daniel Urist]

Is there any update on when puppetdb will be available for Debian 8
(jessie)? Puppetserver is now available according to the announcement for
v.2.1.2.


On Wed, Oct 14, 2015 at 4:34 PM, Wyatt Alt  wrote:

> PuppetDB 2.3.8  October 14, 2015
>
> PuppetDB 2.3.8 Downloads
>
> 
>
> Available in native package format in the release repositories at:
>
> http://yum.puppetlabs.com and http://apt.puppetlabs.com
>
> For information on how to enable the Puppet Labs repos, see:
>
>
> http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#open-source-repositories
>
> Binary tarball: http://downloads.puppetlabs.com/puppetdb/
>
> Source: http://github.com/puppetlabs/puppetdb
>
> Please report feedback via the Puppet Labs tickets site, using an affected
> PuppetDB version of 2.3.8: https://tickets.puppetlabs.com/browse/PDB
>
> Documentation: http://docs.puppetlabs.com/puppetdb/2.3/
>
> Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb
>
> PuppetDB 2.3.8 Release Notes
>
> 
>
> PuppetDB 2.3.8 is a backwards-compatible bugfix release that fixes an
> issue where simultaneous updates to large numbers of fact values could
> produce a prepared statement that exceeded the max allowed by the Postgres
> JDBC driver. See https://tickets.puppetlabs.com/browse/PDB-2003 for
> details.
>
> For more information and upgrade advice, consult the detailed release
> notes here:
>
> https://docs.puppetlabs.com/puppetdb/2.3/release_notes.html
>
> Contributors
>
> 
> Ken Barber, Ryan Senior, Wyatt Alt
>
> --
> 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/CAJDiH3EXsYgy_Nm5ZWkVbV%2B3Lvd1k%3DFa5H6ZwN3VryVMXe1buQ%40mail.gmail.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/CAEo6%3DKZsJLXBkj1fgkPTAqod6qNnNk%3D%2BzGPW8tr2LEPdJ7O7jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Announce: Puppet Agent 1.2, Facter 3, Puppet 4.2, Hiera 3

[Daniel Urist]

Are there up-to-date instructions for how to install from the apt repos for
jessie?

On Fri, Jun 26, 2015 at 12:13 PM, Eric Sorenson <
eric.soren...@puppetlabs.com> wrote:

>
> Last night we rolled a patch release which includes a fix for FACT-1055, a
> regression which inadvertently broke backward compatibility for external
> facts
> that are not pluginsync'ed from modules:
> https://tickets.puppetlabs.com/browse/FACT-1055
>
> The new AIO bundle (puppet-agent-1.2.1) is available in all of the Puppet
> Collection 1 repositories.
>
> I also neglected to mention in the original announcement that we now have
> package repositories for Debian Jessie and Mac OS X Mavericks (10.9) and
> Yosemite (10.10) and these OSes will be part of the regular release
> pipelines
> going forward.
>
>
> On Wed, 24 Jun 2015, Eric Sorenson wrote:
>
>  There's a new All-in-One Puppet Agent release available! This release
>> bundles
>> new versions of several component projects and is downloadable now
>> through the Puppet Collection 1 repository.
>>
>> * Puppet 4.2 includes several features and bug fixes, and officially
>> deprecates
>>   Windows 2003. Release notes here:
>> http://docs.puppetlabs.com/puppet/4.2/reference/release_notes.html
>> * Facter 3, the rewritten C++-based facter, is now the baseline Facter
>>   implementation. Read more here:
>> https://puppetlabs.com/blog/speeding-up-puppet-on-windows
>> * Hiera 3 is included, which contains a change to the default
>>   hierarchy and datadir location. This is technically a semver break, so
>> it's
>>   a new major version. The gory details:
>> http://docs.puppetlabs.com/hiera/3.0/release_notes.html
>>
>> Get installation instructions and read about Puppet Collections, our
>> Linux-distribution-style repositories for Puppet related projects, here:
>> https://puppetlabs.com/blog/welcome-puppet-collections
>>
>> Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0
>> puppet platform // coffee // techno // bicycles
>>
>>
> Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0
> puppet platform // coffee // techno // bicycles
>

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

[Puppet Users] Quoting keys in hiera lookups

[Daniel Urist]

Is there any way to quote keys in hiera lookups so hiera doesn't interpret
periods as further lookups?

For example, if I have yaml that looks like this:

myservertype:
  host1.domain:
  somekey: somevalue
  host2.domain:
  somekey.somevalue

The periods in the keys host1.domain and host2.domain are valid YAML, but
If I attempt to do a hiera lookup with
hiera("myservertype.host1domain.somekey'), hiera complains that the data
object doesn't exist, because (I surmise) it's interpreting the periods
'host1.domain' as further lookups. If the key doesn't have a period, the
lookup succeeds. I've tried quoting the keys in both the yaml file and the
hiera lookup, but that doesn't help.

I can work around this by doing hiera("myservertype") and then pulling out
the value with a puppet array lookup, which is what I'm doing now, but this
seems pretty inefficient.

-- 
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/CAEo6%3DKZu4E-oMzPL_%3DT%3DMhtZFZfLtTo%2Bxzbmxq-_Hgwhf2uY%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.