On Mon, Jun 29, 2009 at 9:10 AM, Jason Hueske<schwi...@gmail.com> wrote: > > 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.
Yes. You'd lose the current ability of the pkgdmg provider to install multiple pkgs from a single dmg though. > > 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.. It collates information together from both the old style "/Library/Receipts" for bundled packages and the new style sqlite db for flat packages. It's still a very young project, but I really do feel that a Puppet Munki provider could give us something really quite wonderful on the Mac platform. > > 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. >> >> > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
