Puppet users - Jan 2011 - Cron provider deleting all entries from crontab?

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,
    }
}

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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''],
    }
}

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

On Jan 3, 2:12 pm, Kent <dri...@gmail.com> wrote:
> 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.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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



On Jan 4, 10:07 am, Kent <dri...@gmail.com> wrote:
> 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
>
> On Jan 3, 2:12 pm, Kent <dri...@gmail.com> wrote:
>
>
>
> > 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.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

On 5 January 2011 03:07, Kent <drizit@gmail.com> wrote:
> 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
>
> On Jan 3, 2:12 pm, Kent <dri...@gmail.com> wrote:
> > 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.
>
> --
> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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: jwarburton@gmail.com

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.