Puppet

Does a second run work? Does waiting for the filetimeout period or specifying filetimeout=0 change the situation?

Second run does not work. (nor third, fourth…) Waiting for filetimeout and/or setting filetimeout=0 also doesn’t fix.

No, definitely not! Nothing I can find will cause Puppet to update those files.

No, definitely not! Nothing will cause Puppet to update those files.

Also note ticket 5460 — perhaps related?

I really want to double check this as it doesn’t make a whole lot of sense.

You’re absolutely positive that stopping the whole server process, and restarting it does not pick up the changes?

I am 100% positive. I know this because I have restarted the server 4-5 times since we made the changes and they STILL haven’t been picked up. I’ve confirmed this in 2.6.4 and 2.6.3, and it’s not just me — 2 of my staff have also encountered the same issue.

I can’t get this to work in 0.25.5 either.

nigel@debvm1:~/pkgs/0.25.5$ rm -Rf /tmp/file_test/
nigel@debvm1:~/pkgs/0.25.5$ puppet --version
0.25.5
nigel@debvm1:~/pkgs/0.25.5$ cat /tmp/test.pp 
file { "/tmp/file_test":
  ensure   => directory,
  recurse  => true,
  checksum => mtime,
  mode     => 644,
  notify   => Exec["tar"],
}

exec { "/bin/tar -cf - /tmp/file_test > /dev/null": 
  alias       => "tar",
  refreshonly => true,
}
nigel@debvm1:~/pkgs/0.25.5$ puppet -v /tmp/test.pp 
info: Applying configuration version '1292304870'
notice: //File[/tmp/file_test]/ensure: created
info: //File[/tmp/file_test]: Scheduling refresh of Exec[/bin/tar -cf - /tmp/file_test > /dev/null]
notice: //Exec[/bin/tar -cf - /tmp/file_test > /dev/null]: Triggering 'refresh' from 1 dependencies
nigel@debvm1:~/pkgs/0.25.5$ puppet -v /tmp/test.pp 
info: Applying configuration version '1292304876'
nigel@debvm1:~/pkgs/0.25.5$ mkdir /tmp/file_test/{1,2,3,4,5,6}
nigel@debvm1:~/pkgs/0.25.5$ puppet -v /tmp/test.pp 
info: Applying configuration version '1292304893'

Are you positive the example in the bug report originally worked?

Reproduced with a server but not standalone.

I haven’t tried the original poster’s example. Mine was much more straightfoward —

file { "/etc/httpd/conf.d":
ensure  => directory,
recurse => true,
owner   => root,
group   => root,
mode    => 644,
source  => "puppet:///modules/mod-redirs/conf.d",
require => Package[ "httpd" ],
notify  => Class[ "apache::service" ]
}

If I add a file inside the dir, it’ll be distributed. If I delete a file from the target on the client, it will be re-distributed. But if I modify the contents of a file on the puppet server, no matter how many runs I do, even if I restart the puppetmaster, those changes are not propagated.

This definitely worked in 0.25.5, because we have several critical classes that depend on it and are updated frequently. I received the first complaint about the problem around 15 minutes after upgrading to 2.6.

-Eric

Yep. Let me clarify the bug a little Eric. I spent some time with gniks on IRC last night reproducing the issue.

It looks like this functionality was never available with standalone manifests, only with a puppet server.

The cases where it does work under 0.25.x and 2.6.x are:

• Add file to the source directory, notify correctly fires.
• Add file to the target directory and turn “purge => true” on, notify correctly fires.

The case where it works under 0.25.x and not under 2.6.x is:

• Add file to the target directory with “purge => false” or unset, notify fires under 0.25.x but not under 2.6.x

Nigel Kersten wrote:

I can’t get this to work in 0.25.5 either.

[…]

Are you positive the example in the bug report originally worked?

I have always used puppet in a client/server setup and never in production as standalone. I only resorted to standalone to provide an example.

So, I cannot be sure it previously worked w/ puppet but I am positive it did work w/ puppetd/puppetmaster prior to 2.6.

Yep. See the newer update where I managed to replicate this using client/server on 0.25.x and that it doesn’t work under 2.6.x.

The bug is around the notify firing, but from talking to the people who wrote the code, this wasn’t intended behavior, which is why it stopped working.

Lets reboot and start with the higher level description of what you need to achieve and we’ll see what we can do.

Nigel Kersten wrote:

The original bug around the notify was unintended behavior in 0.25.x. If you can describe your needs at a higher level, we can probably come up with an alternative.

I have been using puppet to notify on local file changes recursively for forever and every version prior to 2.6 has done it. Are you saying that it shouldn’t have?

One example, and the one that alerted me to the problem in the first place, is my dansguardian module.

class dansguardian {
  package { "dansguardian": ensure => "2.10.1.1-1.el5";
            "rl":           ensure => installed;
  }

  service { "dansguardian": enable => true, ensure => running,
              require => [ File["/etc/dansguardian/dansguardian.conf"],
                           Service["squid"],
                           Service["clamd.dansguardian"]
                         ]
  }

  file { "/etc/dansguardian/dansguardian.conf":
           source  => [ "${fserver}/modules/dansguardian/dansguardian.conf.${domain_0}", "${fserver}/modules/dansguardian/dansguardian.conf" ],
           require => Package["dansguardian"],
           notify  => Service["dansguardian"];

         "/etc/dansguardian/contentscanners/clamdscan.conf":
           source  => [ "${fserver}/modules/dansguardian/clamdscan.conf.${domain_0}", "${fserver}/modules/dansguardian/clamdscan.conf" ],
           require => Package["dansguardian"],
           notify  => Service["dansguardian"];

         "/opt/dansguardian/lists/blacklists":
           ensure => directory, recurse => true, checksum => mtime, mode => 644, notify => Exec["install_dansguardian_lists"],
           require => Exec["/etc/cron.hourly/rsync_dansguardian_blacklists.sh 1"];

         "/etc/dansguardian/lists/phraselists":
           ensure => directory, recurse => true, checksum => mtime, mode => 644,
           ignore => "*.processed", notify => Service["dansguardian"];

         "/usr/sbin/install_dansguardian_lists.sh": source => "${fserver}/modules/dansguardian/install_dansguardian_lists.sh", mode => 750;

         "/etc/cron.hourly/rsync_dansguardian_blacklists.sh": source => "${fserver}/modules/dansguardian/rsync_dansguardian_blacklists.cron", mode => 750, require => Package["rl"] ];
  }

  exec { "/usr/sbin/install_dansguardian_lists.sh /opt/dansguardian/lists/blacklists":
           refreshonly => true, alias => "install_dansguardian_lists",
           require => [ File["/usr/sbin/install_dansguardian_lists.sh"], Package["rl", "rsync"] ],
           notify => Service["dansguardian"];

         # --- this is a one time primer.
         "/etc/cron.hourly/rsync_dansguardian_blacklists.sh 1":
           creates => "/etc/dansguardian/lists/blacklists/white",
           require => [ File["/etc/cron.hourly/rsync_dansguardian_blacklists.sh"], Package["rsync"] ],
           notify  => Exec["install_dansguardian_lists"];
  }
}

So, the idea here is that cron and File[“/etc/cron.hourly/rsync_dansguardian_blacklists.sh”] maintain the sorted blacklists in “/opt/dansguardian/lists/blacklists” from a central rsync repo and puppet checksums (mtime) all files recursively in “/opt/dansguardian/lists/blacklists” and on any change it notifies Exec[“install_dansguardian_lists”] which inturn shuffles the blacklists, dansguardian prefers unsorted lists, and installs then in “/etc/dansguardian/lists/blacklists” and notifies Service[“dansguardian”].

$ du -sh /opt/dansguardian/lists/blacklists/
35M     /opt/dansguardian/lists/blacklists/

$ find /opt/dansguardian/lists/blacklists -type f | wc -l
82

cron and File[“/etc/cron.hourly/rsync_dansguardian_blacklists.sh”] also maintain lists in “/etc/dansguardian/lists/phraselists” and puppet should notify Service[“dansguardian”] on any changes there too.

I hope that is all clear as I have chopped the class down to only include to important stuff.

Ben – wrote:

Nigel Kersten wrote:

The original bug around the notify was unintended behavior in 0.25.x. If you can describe your needs at a higher level, we can probably come up with an alternative.

I have been using puppet to notify on local file changes recursively for forever and every version prior to 2.6 has done it. Are you saying that it shouldn’t have?

All I’m saying is that the feedback I’ve gotten from developers is that this wasn’t ever intended behavior. Whether it should or shouldn’t have is undefined :)

I’ll have a closer look at your higher level description soon. Thank you for providing it.

Same thing here. I’ve tested the reported manifest on 2.7.10 and the behavior is the same: nothing happens. I was coding a very similar manifest.