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

[Matthaus Owens]

Daniel,

Which version of Puppet are you seeing this on?

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

[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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%40mail.gmail.com.

[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"

[JeremyCampbell]

I can confirm the same issue on Puppetserver v2.4.0

[Daniel Urist]

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

On Fri, May 20, 2016 at 6:41 AM, JeremyCampbell <jeremyca...@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...@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.

[Matthaus Owens]

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?

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.

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACD%3DwAfyDLQuTgOjF_UbLYB24g9KAnLYVmYybDGe6vL_iHrzdw%40mail.gmail.com.

[Henrik Lindberg]

The bug logged ended up being PUP-6336
It is indeed a bug, a bad regression caused by a series of surprising
details (which you can read about on the ticket
https://tickets.puppetlabs.com/browse/PUP-6336

There is a fix for this that is just merged, and it will be released in
Puppet 4.5.1 (which will be released much sooner because of this bug).

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/