Hi John, thanks for your elaborate-as-always insights and comments.
Ere we digress too much, I saw fit to move the ssh centric bits to a new thread over on the users' list. > 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? That's an excellent point. I see two ways to deal with this. 1. "Somehow" take advantage of the available slew of user providers, most (all?) of which support enumerating the available users. We would probably need to generate user resources. To get from there to cron resources, the user type would likely need to generate additional (cron) resources. Stuffing the transaction with otherwise useless (and likely unwanted) user resources seems wasteful and dangerous, though. I don't see the cron type making direct use of the user providers to get at the list of users. 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". Alternatives? Thoughts? (This apple appears more rotten the deeper we cut.) > > > 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. That would likely work out fine indeed. Since crontabs are manipulated through crontab(1) anyway, it seems unlikely that we will be able to purge without determining *some* username to a given crontab entry, and the chances for getting that name wrong seem slim to me. > 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. Well, yes, that would make sense. Concerning the question how vital those tests might be: I dug around the history a bit. Turns out those tests are fairly recent. Stefan Schulte added them during the liberation of the BSD special schedule syntax. (Good times.) Stefan, any thoughts on repurposing these if we decide to go through with this? Barring a response, my gut says that at least this part likely poses no problems. Best regards, 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/528E938B.7090703%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/groups/opt_out.
