On Thursday, November 21, 2013 10:15:52 AM UTC-6, Andy Parker wrote: > > On Wed, Nov 20, 2013 at 3:09 PM, Felix Frank > <[email protected]<javascript:> > > wrote: > >> Hi, >> >> I've been looking at the redmine ticket in [1], which basically asks for >> the ability to purge crontab entries from *all* users' crontabs. As is, >> puppet will purge only from such crontab files that contain entries that >> are explicitly managed. >> >> > 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 :) > > >> There is a similar request for ssh_authorized_keys, which is just about >> at the top of the highly voted issues (see [2]). >> >>
There are indeed similarities here with Ssh_authorized_key, but also some important differences. Consider that Ssh_authorized_key can manage any file as a keystore (see the 'target' parameter). As such, it is flatly impossible for Puppet to reliably determine from which files it must purge keys to zap them all without collateral damage. Puppet could be conservative by only purging from files having the standard name, but if Ssh_authorized_key.target has any use in the first place then a conservative purge would miss some keys in some environments. I think it would be worse to provide a key purging feature that doesn't do the full job than to omit key purging altogether. I think a more feasible reference model for key purging is the one provided by recursively-managed Files. Essentially, there is a container (a File resource) that establishes the scope of the purge. There is not currently a suitable container type for authorized keys, but one could certainly be created, say Ssh_authorized_keyfile or Ssh_authorized_keys. > For crontab, I cobbled together a patch (see [1]), but I'm loath to go >> so far as to add tests and open a pull request, because I'm not sure >> that the idea of changing the crontab provider in this way is sound. The >> approach is simply to add each account found in /etc/passwd to the >> target list of the provider. >> >> 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? > For the purge=>true use case, parsing all available crontabs honors the >> principle of least surprise. In other cases though, the opposite may be >> true (but then, I can't think of any examples off the top of my head). >> > Part of the issue there is that the Cron resource's 'target' parameter is effectively part of a Cron resource's identifier. Puppet must take the target into account as it matches existing resources to declared ones to make either purging or ordinary Cron resource management work correctly. On second thought, though, I guess match failures are not harmful for purging; they just turn resource updates into (remove, add) pairs in that case. And they may not be a new phenomenon for managed Cron resources. > Point in case, there are unit tests that break when applying the patch: >> >> 1) Puppet::Type::Cron::ProviderCrontab.instances on linux should be >> empty if user has no crontab >> 2) Puppet::Type::Cron::ProviderCrontab.instances on linux should be >> empty if user is not present >> >> I'm not sure how vital it is to keep those around (i.e., what breaks >> along with these assumptions?) >> > I'm not sure whether anything breaks, but surely those particular tests fly directly in the face of the change described. It may be that they simply are rendered incorrect. If the change is acceptable then the corresponding rules under the revised behavior would be more like: 1) On Linux, if a user has no crontab then Puppet::Type::Cron::ProviderCrontab.instances should contain no instances having that user as their target 2) The target of every element of Puppet::Type::Cron::ProviderCrontab.instances should be an existing system user. John -- 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/b4ed62ae-ec39-4d10-835b-e36bb91b061f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
