On Tue, Nov 18, 2008 at 8:00 PM, Crawford Kyle <[EMAIL PROTECTED]> wrote: > > > On Nov 18, 2008, at 11:17 AM, Nigel Kersten wrote: > >> >> On Mon, Nov 17, 2008 at 8:33 PM, Crawford Kyle <[EMAIL PROTECTED]> >> wrote: >>> >>> >>> On Nov 15, 2008, at 8:46 PM, Nigel Kersten wrote: >>> >>>> so I'm particularly interested to hear what the >>>> major conceptual stumbling blocks were for getting started so that >>>> we >>>> make sure we're smoothing that path out. >>> >>> Terminology, type/provider development, and best practices. >>> >>> How to selectively include classes when you aren't using nodes. >>> >>> The whole client side cert generation using uuidgen. >>> >>> Puppet is a lot to grok at once. I think the approach of starting >>> small and just managing something simple as you have recommended is a >>> good way to start and an eye opener to puppet's power. >>> >>> Learning file and exec are important for getting things done since >>> some of the resources aren't fully implemented yet for Mac. >>> >>> Kyle >> >> >> Much appreciated Kyle. >> >> What resources do you currently have to model with file and exec that >> you'd like to see native types for? >> >> I'm working on the launchd service type and an /etc/authorization db >> type at the moment, and have some spare time over the next 2 weeks >> while my family is overseas.... > > > defaults/plists: the mac-defaults type doesn't do nesting and array > checking well. I use exec with PlistBuddy, for some things but I > don't like it. I started looking into CFPreferences via RubyCocoa, > but didn't have time to get very far. Is there a Ruby module as good > as python's plistlib?
Depends what you mean by "as good as" :) If you're running a recent Facter, you have 'facter/util/plist' which is close to equivalent to plistilb. Both have the problem of not being able to parse binary format plists. You can get around this by using not CFPreferences, but Foundation to instantiate dictionaries from plists, which works with both xml and binary1. The other option is PlistBuddy, but if you have 10.4 clients it isn't in a predictable location by default. I'm a bit torn on this. It would be useful to have a generic plist module I suppose, but what is it that you're doing that you wanted nested values and arrays for ? It almost seems better to model those individually if they're complex? > > mcx: not sure what I want here yet: currently we push a computer > account using a template based on a custom fact of whether it is a > laptop or desktop and computer group plists as files. I'd rather > implement more mcx at the group level, but because of apple's > restriction of only applying mcx to a single group, that isn't > practical. You know you can nest groups though, and then MCX flows through? We do direct twiddling of a localhost computer account too. I'm not sure where this should be done, but am meaning to look at whether the host type could perhaps support it. > > group membership: I implemented some simple membership checking in > directoryservice.rb, which was all commented out for 10.5 so it wasn't > doing anything. groups just calls `groups` and splits it into an > array. and membership is changed using dseditgroup. I didn't bother > submitting this since it is not very clean and I thought we were > moving to using RubyCocoa bridge to talk directly to the APIs rather > than shell commands, but maybe that is more of a long-term goal. I think Puppet needs to support 10.4 out of the box at this stage imho. It's still widely in use, and so unless people are willing to install RubyCocoa to get this stuff working... maybe it's not an option yet. I need to look at groups again actually. Thanks for reminding me. > > passwords: currently we distribute the hash file, but will change to > your new method > > launchd: I know you are working on this for services. Do we also need > this for all of the other capabilities of launchd (agents, contexts, > schedules)? perhaps the "cron" type should be renamed something more > generic like "jobs" and include these other capabilities like > WatchPaths, etc. Currently I have this, which is everything working apart from autorequire. http://github.com/nigelkersten/puppet/commit/7466c0bde497b02a729772c392a9c378686fb252 That will get done today. It covers the primary LaunchDaemons and LaunchAgents. Would you really like to be able to model a launchd job completely in puppet? It can be quite a complicated format which would result in hideous manifests I think. currently that patch above just manages whether the job is enabled at boot and the current state. Once it autorequires the appropriate file it should end up being quite flexible. > > user accounts, computer accounts, and other directoryservice record > types : currently we just push plists, we may want to manage just > certain properties of the account, we may want to augment the > accounts. I supposed we could use an improved mac-defaults for > managing anything in plist format, including dslocal, but again I > thought we were moving to using APIs rather than manipulating the > datastore. Yep, so users should be fine soon, computers I'm still unsure about. Then when you're talking about MCX policy, where do you define that so you can also automatically require the appropriate object for it to be attached to? Having DirectoryServices handle so much stuff in OS X is a bit of a problem for where to model all this in Puppet. > > AD plugin: I currently just exec dsconfigad to turn on/off mobile > accounts based on the laptop fact. This is just stored in a plist > though, so the plist manipulation would potentially work except > DirectoryService would need to be killed -9 to prevent it from > overwriting the direct change to the config file. Maybe services need > different methods for restarting themselves (notify with signal => -9) > > Packages: I generally don't like Apple's package installer system, nor > software update for lots of reasons so we don't use them, but when I > did look into some of the package providers, they didn't check the > receipts database and/or relied on tracking what was already installed > in a text file. We still use radmind for most of our machines. I've > yet to take the time to somehow integrate puppet with radmind. I've > already built a system for managing radmind, but I'm thinking some of > that could be implemented with puppet. I do need to figure out some > way of patching the machines not managed by radmind or just bring them > into radmind until there is a better package story. I'm actually talking to Greg Neagle at the moment about building a framework for third party pkg repositories, and then eventually have a puppet package provider so we can just do stuff like: package { "python": provider => pkgrepo, # or something ensure => latest, } > > the authorization db work sounds great. I'm sure we will use that. > > I expect we will be relying on Puppet more and more over the coming > months to implement our new self-induced security compliance > requirements and hopefully I'll have time to delve deeper into puppet > and be of more help. > > Enjoy your free time. I know how that is, though I'm sure you miss > them too. cheers :) -- Nigel Kersten Systems Administrator Tech Lead - MacOps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
