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-us...@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.
