Issue #5079 has been updated by Nigel Kersten. Status changed from Unreviewed to Investigating Assignee set to Nigel Kersten
That's not quite true Sandor. I actually tech-edited that book with Greg and Edward, so I'm reasonably familiar with the contents :) The suggestion in that book is that you shouldn't use /Computers/localhost because it conflicts with caching. The problem only exists with Computer objects named 'localhost'. The problems aren't that severe, but they can confuse people, thus the suggestion in that book. I agree we should *support* DSLocal nodes other than the default, because people are starting to do more experimentation with secondary DSLocal nodes, but there is nothing wrong with doing all your management in the default local domain. Yes, you'll have trouble managing the entire MCX dump for a given object if that object is also managed via remote MCX, but that problem only exists for Mobile Accounts, and is not an argument for not doing any MCX management, but that we should be shipping a simpler provider that allows you to set individual keys, rather than the entire MCX blob. I wrote the macauthorization provider, and I'm not entirely convinced that my error approach in it was better than Jeff's in the MCX one, so I wouldn't take it as gospel. We've seen a couple of useful patches from you, is there any chance we could get you to follow the development lifecycle and mail this to the dev-list for discussion? http://projects.puppetlabs.com/projects/puppet/wiki/Development_Development_Lifecycle I'm more than happy to give you a hand with this, as I have a strong personal interest in improving all our Mac providers, and would love to see more active involvement from community members. ---------------------------------------- Refactor #5079: MCX content provider https://projects.puppetlabs.com/issues/5079 Author: Sandor Szücs Status: Investigating Priority: Normal Assignee: Nigel Kersten Category: OSX Target version: Affected Puppet version: Branch: I refactored the MCX content provider to enhance code readability. This is the first step to understand the current implementation. I would like to add a best practice dslocal solution pointed out by the authors of "Enterprise Mac Managed Preferences". They wrote that you should not use /Local/Default as DB, because it is also used as local cache. They further said that you should add an own DB to circumvent ping-pong overwrites between central managed MCX and dslocal managed MCX. The patch includes a small change within the spec file, because the error handling should be more conform to other puppet providers. Instead to raise MCXContentProviderException I choose to raise Puppet::Error, because macauthorization provider does the same. I hope that is the right Error handling. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
