So along these lines, there are two things I've been thinking about to improve package distribution with Puppet.
a) Add a parameter called something like "creates" that would be an array of files and/or directories that a given package is expected to create. If any of these are missing, Puppet reinstalls the package, regardless of the state of the marker file. b) Work on a "munki" provider. "Munki" is a project a friend of mine Greg Neagle has been working on to produce a good third party pkg based repository system for OS X. http://code.google.com/p/munki/ Munki "knows" whether a given package is installed, flat or bundle based, so it could be used to solve this problem. The primary problem we have with the pkgdmg provider is that there is no necessary relationship between the dmg name and the pkg bundle identifier, and the marker file is based upon the former, whereas the package receipt is based upon the latter. Unless we changed the pkgdmg provider to mount every single dmg and inspect the contents (bad idea) Puppet has no visibility to the pkg contained within the dmg. On Mon, Jun 29, 2009 at 7:27 AM, Udo Waechter<udo.waech...@uni-osnabrueck.de> wrote: > Hi Gary, > > On 29.06.2009, at 14:12, Gary Larizza wrote: > >> >> Hi All, >> >> I'm successfully using pkg_deploy to deploy DMG-encapsulated packages >> on Mac Clients. My question would be - since Puppet is essentially >> used to define a "state" that the computer is in, what would be the >> best way to maintain a "state" after deploying a package? >> > > pkg_deploy is only a convenience/wrapper define around the package-type. > Since OS X does not really have something like a package-management, you can > really only install stuff. > The package-type does mark a successfull installation of a package by > creating a > /var/db/.puppet_[pkg|app]dmg_<packagename> > > Thats it. You can remove that file by hand, then puppet thinks it did not > install the package and reinstalls it again. > Another trick (what we do), is to simply increase the version number of the > package. One could also call it: rename the package. (OfficeX-2008.1.dmg -> > OfficeX-2008.2.dmg) > >> For example, if you deployed a package to install Microsoft Office, >> you would probably ensure that the Microsoft Office directory (as well >> as the individual .Apps) was Present. If the directory WASN'T present >> (someone deleted it, for example), is there a way to call pkg_deploy >> again to re-deploy the package, or would you have to keep the >> Microsoft Office directory structure on the Puppetmaster server >> (inside your module/files directory, for example) in order for it to >> send the directory structure down to the damaged client? >> > I think that copying recursive directory data in huge amounts will crash > your puppetmaster, even with only one client. (Hints: xmlrpc and > file-serving) > >> In that vein (and a separate question), how does puppet know that >> pkg_deploy has been run and that the DMG-encapsulated package has been >> run/installed? It doesn't call pkg_deploy on subsequent catalog >> checks by the client - so it's not bringing down the DMG again and >> attempting an install. Is there some sort of "receipt" that it checks >> - or does it actually USE the Receipts directory to monitor >> installation? >> > no, see above. > >> I know I'm trying to use Puppet to maintain staff and lab computers - >> which is somewhat unconventional, but it stands up to the >> implementation! Thanks for all your help and support! > > > uh? Why do you thinkg this is unconventional? Puppet manages computers. What > these computers are used for is irrelevant :) > We do manage some macs (laptops and workstations) with puppet and everything > works fine. Package managment does require quite a lot of time, but that is > not puppet's fault. > > Have fun, > udo. > > -- > :: udo waechter - r...@zoide.net :: N 52º16'30.5" E 8º3'10.1" > :: genuine input for your ears: http://auriculabovinari.de > :: your eyes: http://ezag.zoide.net > :: your brain: http://zoide.net > > > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
