(Not actually a puppet problem, but could cause some surprise and consternation.) This is on Debian Squeeze with puppet 2.6.2. A quick note in the documentation would assist users:
http://docs.puppetlabs.com/references/stable/type.html#cron http://docs.puppetlabs.com/references/stable/type.html#user Something like "changes to a user's numeric userid will not change the numeric userid of that user's cron jobs, breaking them at the next crond restart". In short: root@cwd:/var/spool/cron/crontabs# ls -l total 4 -rw------- 1 test1 crontab 542 Oct 17 16:37 test1 root@cwd:/var/spool/cron/crontabs# usermod -u 6000 test1 root@cwd:/var/spool/cron/crontabs# ls -l total 4 -rw------- 1 5001 crontab 542 Oct 17 16:37 test1 The cron jobs for user test1 will continue to run until the cron daemon is restarted, at which point they will never run again. The file must be owned by the userid it is named as. This is a long-standing issue/design choice with usermod: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=33748 A quick puppet manifest that demonstrates this is as follows. For the second run increment '$number'. Wait until /tmp/date is changed, then restart crond. Notice how /tmp/date never changes again. ---------- $username = 'test1' $number = '5000' group { $username: gid => $number, ensure => present, } user { $username: uid => $number, gid => $number, shell => '/bin/bash', comment => "Test user,,,", home => "/home/$name", managehome => false, require => Group[$username], ensure => present, } cron { $username: command => "date > /tmp/date", user => $username, ensure => present, require => User[$username], } ---------- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
