Issue #5079 has been updated by Sandor Szücs.
Nigel Kersten wrote: > 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. Thanks that you clarified this. > 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. Ok. I should mention that I care about Mobile Accounts and maybe PHDs in the future. Also I am interested in mixing MCX settings in dslocal with remote MCX via LDAP (AD/OD) entries. > > 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. Maybe error handling can be improved even more, but that should decide that have deeper knowledge in the source base than me. For me it is more obvious to use something like Puppet::Error then to define an own for this provider. Also counting with grep and wc showed 90 uses of Puppet::Error and 44 other (Puppet::DevError, ArgumentError and raise with default which is using RuntimeError). > 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? Thanks I hoped there are useful. Last week I sent the patch to the list via rake task, so you can comment inline. All the best, Sandor ---------------------------------------- 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.
