Cron provider deleting all entries from crontab?

[Kent]

While running Puppet on Solaris clients we seem to be losing our existing cron entries when using the cron resource provided from puppet. This does not happen all the time but often enough that it's becoming a problem.

This happens more often on zones than it does on the global zone itself.

At some point we go from having the standard crontab file with both the puppet owned entry and our other standard cron entries to just the puppet owned entry (along with it's header info) and nothing else.

This is on Solaris 10 (mostly update 6 or higher) on SPARC systems with Puppet 2.6.3 and the standard cron daemon installed by Solaris.

Below is the code that is being executed on the clients, the random number thing hashes a random start time based partially on the hostname and works properly per host.

Any help or info would be appreciated, thanks!

----PUPPET CODE FOR HOSTS---

class coresystems::cron {

    # Unique time in the range of 0-59 per node name..

    $minute = fqdn_rand(59)

    if $minute > 29

    {

        $minute2 = $minute - 30

    }

    else

    {

        $minute2 = $minute + 30

    }

    cron { "manual-puppet":

        command => "/usr/bin/puppet agent --onetime --no-daemonize --logdest syslog > /dev/null 2>&1",

        user => "root",

        hour => "*",

        minute => [$minute, $minute2],

        ensure => present,

    }

}

[Martin Englund]

Kent,

On Jan 3, 11:06 am, Kent <dri...@gmail.com> wrote:
> While running Puppet on Solaris clients we seem to be losing our existing
> cron entries when using the cron resource provided from puppet. This does
> not happen all the time but often enough that it's becoming a problem.
> This happens more often on zones than it does on the global zone itself.
>

I ran in to a similar problem some time ago:
<https://projects.puppetlabs.com/issues/1672>
but it has since been fixed. Do you have any additional debug output
to provide?

cheers,
/Martin

[Kent]

Ok that seems to be the problem but it's apparently still not fixed in 2.6.3 on Solaris.

I did figure out more on this issue, it seems that if you are managing a cron entry for a user that does not yet exist puppet nukes all the current entries for any cron jobs it's currently managing for existing users. Once all users exist everything works as expected.

Since the cronjob pre-fetch occurs before the user(s) get added it always happens the first time you run puppet on a new host and doesn't seem to keep a backup of the original crontab. 

Overview:

 1. Manage crontab entry for user 'root'

 2. Manage crontab entry for user 'monitor'

 3. Tell puppet to create user and group monitor first using the Require syntax on the cron service

 4. Puppet does a crontab prefetch and gets an error for the monitor user which does not yet exist

 5. Root's crontab get's cleaned out and only puppet entry exists now

 6. Monitor crontab get's created properly after puppet creates monitor user/group.

 7. Once all users exist that have managed cron jobs the problem stops happening for all users.

My debug output relevant to problem::

debug: Prefetching crontab resources for cron

debug: Executing 'crontab -l'

debug: Executing 'crontab -l'

err: Could not prefetch cron provider 'crontab': Could not read crontab for monitor: Invalid user: monitor

Actual code::

import "*"

class coresystems {

    include coresystems::base_users

    include coresystems::cron

    include coresystems::cron::monitor

}

class coresystems::base_users {

    user { 'monitor':

        uid      => '472',

        gid      => '472',

        home     => '/tmp',

        shell    => '/bin/bash',

        password => 'NP',

        ensure   => 'present',

        require  => Group['monitor'],

    }

    group { 'monitor':

        gid    => '472',

        ensure => 'present',

    }

}

class coresystems::cron {

    # Unique time in the range of 0-59 per node name..

    $minute = fqdn_rand(59)

    $puppet_binary = "/usr/bin/puppet"

    if $minute > 29

    {

        $minute2 = $minute - 30

    }

    else

    {

        $minute2 = $minute + 30

    }

    cron { "manual-puppet":

        command => "$puppet_binary agent --onetime --no-daemonize --logdest syslog > /dev/null 2>&1",

        user => "root",

        hour => "*",

        minute => [$minute, $minute2],

        ensure => present,

    }

}

class coresystems::cron::monitor {

    cron { "myjob":

        command => "/opt/bin/mon.pl",

        user    => "monitor",

        hour    => "*",

        minute  => [0,5,10,15,20,25,30,35,40,45,50,55],

        ensure  => present,

        require => User['monitor'],

    }

}

[Kent]

Just FYI to people looking at this thread I filled bug 5752 on
puppetlabs.com for this issue.
Hopefully it gets resolved soon or I can figure out a work around
because right now we have to stop using the cron provider for all
users.

-Kent

[Kent]

I fixed the problem in filetype.rb and included a patch on the bug id
at puppetlabs.com. Below is the same patch I submitted, this is tested
working on 2.6.3 and 2.6.4 for Solaris 10 with (in a zone or a
global).
The changes the crontab -l run to only run as root and ask for the
proper crontab, for whatever reason this exits cleanly now even if the
user doesn't exist. Puppet then can create the required user and
properly edits ALL of the crontab's in question without removing
anything from root's or other users crontabs.

This assumes puppet is running as root or as a user that can access
crontab executable as root.

Patch against ${RUBY_SITE_LIB_DIR}/puppet/util/filetype.rb
Example fix if your running ruby 1.8:
cd ${PREFIX}/lib/ruby/site_ruby/1.8/puppet/util/filetype.rb
patch < /tmp/filetype_new.rb

Puppet Debug output using '-l username' as root instead of the user in
question.

debug: Prefetching crontab resources for cron

debug: Executing 'crontab -l root'
debug: Executing 'crontab -l monitor'

PATCH:

--- filetype.rb Thu Dec 9 08:55:31 2010
+++ filetype_new.rb Tue Jan 4 11:32:11 2011
@@ -204,7 +204,7 @@
newfiletype(:suntab) do
# Read a specific @path's cron tab.
def read
- output = Puppet::Util.execute(%w{crontab -l}, :uid => @path)
+ output = Puppet::Util.execute(%W{crontab -l #{path} }, :uid =>
'root')
return "" if output.include?("can't open your crontab")
raise Puppet::Error, "User #{@path} not authorized to use
cron" if output.include?("you are not authorized to use cron")
return output

[John Warburton]

Thanks for identifying the problem Kent - I can confirm it here on our Sol 10 U9 puppet servers which require the puppet user with a crontab

Other servers without a user crontab requirement don't nuke root's crontab

I have updated bug 5752

Regards

John

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
John Warburton
Ph: 0417 299 600
Email: jwarb...@gmail.com