On 11/25/2013 05:29 PM, John Bollinger wrote: > > Do all relevant cron implementations support cron.d? Solaris? BSD / > OSX? All Linux distros that matter? Etc? I don't know, but I am > doubtful.
That's a good point in favor of the continued fixing of crontab provider bugs. > I guess I cannot see the value of purging entries _that puppet did > not > install in the first place_. I mean, there are lots of odd jobs > that I > get puppet to perform by getting it to execute a bit of shell code, > and "nuke all crontab data for this user" seems to fit :-) > > > > I don't understand that. I mean, I know that one can work around > Puppet's limitations as to what cron jobs it can and can't manage, but > inasmuch as it is stipulated that Puppet's built-in cron support is > not sufficient, I don't understand why it should not seen as valuable > to enhance Puppet's cron support. > > Even if the only enhancement is support for global purge, that would > provide something that you can only approximate with Exec, unless > possibly you use a lot more than just "a bit" of shell code. That is, > you cannot easily and reliably avoid your Exec removing cron jobs that > are under management. Yes, Puppet might then recreate such jobs in > the same run, but the result is not equivalent if any other resource > listens for events from those Cron resources. I'm glad this discussion is not taking place on the users list, because the workarounds proposed here are dangerous in their own way, as manifested in this report: https://projects.puppetlabs.com/issues/10063 As an aside: Is Nigel Kersten on a longer (or permanent) leave of absence? Whom can I troll with this kind of issue now? On 11/21/2013 05:15 PM, Andy Parker wrote: > I can understand the desire, but it seems like a very dangerous thing, > maybe making it available but not immediately present would be a good > way of doing it? We have the resources type that could be extended or > there could be another crontab type created to purge. > > I'm not certain about either of these, but thought I'd chime in with > those suggestions :) Thanks, Andy. I wasn't really specific - apologies. The purge mechanism that users expect does in fact rely on the resources type. Users want to resources { "cron": purge => true } and (on systems that default to the crontab provider, i.e. currently all *nixes) expect crontabs to be cleared, all of them. Yes, it's dangerous, but may be acceptable to some (e.g., I have long been operating with a similar semantics for sudoers entries, which is potentially even more dangerous). > > What about systems that use other user databases, either instead of or > > in addition to /etc/password? For example, LDAP or NIS or even winbind? ... > 2. Add logic to enumerate actual crontabs. This would be somewhat ugly, > because it's quite different from the current paradigm of "work with > usernames only and access the crontab files through the crontab interface". I've put some more thought into this and I think this general approach should be pursued after all. My initial sketch is flawed in two ways: 1. As John pointed out, Etc.passwd cannot reliably expected to yield all applicable users. 2. Blindly adding targets to a Parsedfile provider feels like a dirty hack. Instead, I will go ahead and try to allow the crontab provider to facilitate the generation of additional cron resources by scanning the file system. This will require some platform specific code for detecting crontab files depending on the environment. I feel that this would be an acceptable thing to do, because a similar logic already selects the correct crontab (1) interface to use. Thanks for all your feedback so far. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/529A4B56.90008%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/groups/opt_out.
