Difference between revisions of "BXadmin:Munki"

From CCGB
Jump to: navigation, search
 
Line 8: Line 8:
 
* '''Andy:''' for *most* things, you can run makepkginfo against a .pkg, .mkpkg, or .dmg and it'll just work
 
* '''Andy:''' for *most* things, you can run makepkginfo against a .pkg, .mkpkg, or .dmg and it'll just work
 
* '''Andy:''' poke around in pkgs and pkgsinfo and you'll see the directory and naming structure I was using
 
* '''Andy:''' poke around in pkgs and pkgsinfo and you'll see the directory and naming structure I was using
* '''Editor's note:''' At this point, you need to release the '''web.sites.admin.munki''' and '''depot.sw.macos''' volumes.
+
* '''Andy:''' when you generate a new .plist file for a package, run makecatalogs . at the top of the munki directory, then put the package name in the testing manifest. ''['''Editor's note:''' At this point, you need to release the '''web.sites.admin.munki''' and '''depot.sw.macos''' volumes.]'' Run /usr/local/munki/managedsoftwareupdate -vv --id=testing
* '''Andy:''' when you generate a new .plist file for a package, run makecatalogs . at the top of the munki directory, then put the package name in the testing manifest. Run /usr/local/munki/managedsoftwareupdate -vv --id=testing
 
 
* '''Andy:''' then  /usr/local/munki/managedsoftwareupdate -vv --id=testing --installonly
 
* '''Andy:''' then  /usr/local/munki/managedsoftwareupdate -vv --id=testing --installonly
 
* '''Andy:''' if everything works, list the package name in the production manifest, change testing to production at the top of the .plist file under pkgsinfo/, and re-run makecatalogs (which just combines all the individual .plist files into production.plist, testing.plist, etc)
 
* '''Andy:''' if everything works, list the package name in the production manifest, change testing to production at the top of the .plist file under pkgsinfo/, and re-run makecatalogs (which just combines all the individual .plist files into production.plist, testing.plist, etc)
* '''Andy:''' I think that's it
+
* '''Andy:''' I think that's it ''['''Editor's note:''' Release '''web.sites.admin.munki''' again.]''
 
* '''Andy:''' mukiimport can be used to import a .app or a .[m]pkg that are just directories
 
* '''Andy:''' mukiimport can be used to import a .app or a .[m]pkg that are just directories
 
* '''Andy:''' munkiimport creates an appropriately sized .dmg. munki can only download single files, not directories
 
* '''Andy:''' munkiimport creates an appropriately sized .dmg. munki can only download single files, not directories

Latest revision as of 14:26, 3 February 2012

Managing software

  • Nate: how do you manage munki packages?
  • Andy: go into /afs/bx.psu.edu/service/web/sites/admin.bx.psu.edu/htroot/munki
  • Andy: in there, you'll see pkgs (symlink or mountpoint for depot.sw.macos)
  • Andy: and pkgsinfo, catalogs, manifests
  • Andy: jump onto an OSX machine. You'll find /usr/local/munki/[makepkginfo|munkiimport|makecatalogs]
  • Andy: for *most* things, you can run makepkginfo against a .pkg, .mkpkg, or .dmg and it'll just work
  • Andy: poke around in pkgs and pkgsinfo and you'll see the directory and naming structure I was using
  • Andy: when you generate a new .plist file for a package, run makecatalogs . at the top of the munki directory, then put the package name in the testing manifest. [Editor's note: At this point, you need to release the web.sites.admin.munki and depot.sw.macos volumes.] Run /usr/local/munki/managedsoftwareupdate -vv --id=testing
  • Andy: then /usr/local/munki/managedsoftwareupdate -vv --id=testing --installonly
  • Andy: if everything works, list the package name in the production manifest, change testing to production at the top of the .plist file under pkgsinfo/, and re-run makecatalogs (which just combines all the individual .plist files into production.plist, testing.plist, etc)
  • Andy: I think that's it [Editor's note: Release web.sites.admin.munki again.]
  • Andy: mukiimport can be used to import a .app or a .[m]pkg that are just directories
  • Andy: munkiimport creates an appropriately sized .dmg. munki can only download single files, not directories


Downgrade software

As an example, R-2.13.0 broke the GUI on at least Leopard PPC. Munki won't downgrade something like this because the installed version number will be higher than what's in the repository.

To trick munki into installing an older version of the package, we need some other installs check that will fail for the installed version. In the case of R, we can specify an md5sum that must match for one of the R libraries (the binaries will be different on ppc vs x86) in addition to the receipts:

        <key>installs</key>
        <array>
                <dict>
                        <key>md5checksum</key>
                        <string>6031c93de224ebe8f0470ac446847a2e</string>
                        <key>path</key>
                        <string>/Library/Frameworks/R.framework/Libraries/libR.dylib</string>
                        <key>type</key>
                        <string>file</string>
                </dict>
        </array>
        <key>receipts</key>
        <array>
                <dict>
                        <key>installed_size</key>
                        <integer>5452</integer>
                        <key>packageid</key>
                        <string>org.r-project.R.Leopard.GUI.pkg</string>
                        <key>version</key>
                        <string>1.35</string>
                </dict>
                <dict>
                        <key>installed_size</key>
                        <integer>106896</integer>
                        <key>packageid</key>
                        <string>org.r-project.R.Leopard.fw.pkg</string>
                        <key>version</key>
                        <string>201254585</string>
                </dict>
                <dict>
                        <key>installed_size</key>
                        <integer>5208</integer>
                        <key>packageid</key>
                        <string>org.r-project.R.Leopard.GUI64.pkg</string>
                        <key>version</key>
                        <string>1.35</string>
                </dict>
        </array>