The potential for a mac-repository functionality is exactly what led me to puppet in the first place, so that is very interesting to hear. I will be keeping my eye on the munkie!
It seems that flat packages would not suffer from the identifier problem that you have with Tiger pkgs/dmgs because they don't have to be monkeyed with for distribution, so the pkgdmg problem would at least be moot moving forward with newer systems. Does munkie "know" which packages are installed by looking at the receipts/bom db? If so, leveraging that would seem to make a lot of sense for "legacy" packages.. Jason On Jun 29, 2009, at 10:40 AM, Nigel Kersten wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
