-
Notifications
You must be signed in to change notification settings - Fork 12
Receipts
A receipt is a d3 package that's been installed on a computer.
d3 keeps track of what's installed by maintaining a set of receipts on the local disk. These receipts are separate from the JSS package receipts, and also different from the Apple package receipt system available via pkgutil
. A d3 receipt stores all info needed to work with the package after installation.
Working with receipts on a managed computer is done with the d3 command-line utitlity, the client-side d3 tool.
Admins can generate reports about receipts on computers using d3admin
Like packages, receipts have a status. Their status is tied to that of the package with the same edition and is updated at sync time if the package's status has changed.
Receipts who's editions are newer than the currently live package for their basename have the status 'pilot'.
A live receipt indicates that the item installed is the currently default edition of that basename for general deployment.
A deprecated receipt means that a newer edition of the basename has been made live on the server. This computer will get that newer edition at the next sync, unless the deprecated receipt is frozen.
If a piloted receipt becomes skipped, it will be updated during a sync unless it is frozen.
A missing receipt is one where either...
- The matching package is also missing
or
- The matching package is no longer in d3.
In either case, the receipt can't be uninstalled using the normal process (which uses jamf uninstall
). Instead, if the package was a .pkg, the receipt will use it's Apple package-id, as stored in the OS's installer receipt database, to delete all the files installed by the .pkg.
If that fails, or if the package was a .dmg, the d3 receipt can be removed using the --force option with d3
.
During a d3 sync
, the receipts on the local machine are updated to match their packages on the server. Here's what gets updated:
Sometimes you might want a computer to stay on a specific edition of a basename, and not get any updates if a new one becomes live. That can be accompished by 'freezing' the receipt with d3 freeze <basename>
. To immediately freeze a receipt upon installation, use d3 install <basename|edition> --freeze
.
Once frozen, that basename is skipped during the update part of d3 sync
, so no other edition of the basename will ever be automatically installed.
There are three ways to 'unfreeze' a receipt:
d3 thaw <basename>
- manually install any edition of the basename (note if you install a pilot, it'll be in pilot and still won't auto update)
- uninstalling the receipt
Admins will sometimes need to see collective info about what receipts are on what computers. This is done using d3admin's report function. Here are some examples:
-
d3admin report portland
lists all receipts on the computer 'portland' -
d3admin report portland --status pilot
lists all pilot receipts on portland -
d3admin report portland --frozen
lists all frozen receipts on portland -
d3admin report testingd3
lists all computers with any edition of the basename 'testingd3' -
d3admin report testingd3 --frozen
lists all computers with any edition of testingd3 frozen -
d3admin report testingd3 --status pilot --status skipped
lists all computers with any pilot OR skipped editions of testingd3 -
d3admin report testingd3 --computer
list all receipts on the computer named 'testingd3', ignoring any basename 'testingd3' (forces the target to be interpreted as a computer, not a basename, in case you have both)
The data for these reports is Casper's inventory data, so it's only as up-to-date as the most recent recon for a computer. That date is shown in the lists in the "as_of" column.
Some of the receipt data, such as who installed it, when it was installed, and whether it is frozen, isn't available from the regular Casper inventory data. To get that, you'll have to use an extension attribute as described in the Confuration section