.pkg installer and FUT/FEU bug/feature??

[frank6502]

Hi everyone,
I have a problem that I don't quite understand and hope that someone can shed some light on.

AFAIK FUT/FEU are only functional with a dmg installer and not with a package.
Therefore, the boxes to choose FUT/FEU are greyed out when dealing with a package. Right?

BUT, when I right-click the package, I am given the possibility to activate or deactivate FUT/FEU.

Furthermore I found out that changing this setting in fact does have an effect:

I was trying to roll out an Acrobat Pro update, but it never worked, showing me the following error in the log:

Now, when I change the FEU setting to ON, it works:

I would really like to understand what I am missing/not understanding about the whole concept of FUT/FEU being only for .dmg installers.

What would be the proper solution to the initial problem of the package trying to install to "base path /" ?

Thanks in advance!

Best,
Frank

[talkingmoose]

A long time ago in this galaxy...

Casper only supported DMG packages. It didn't natively support Apple's PKG installer files. Jamf made DMGs work by using Mac OS X's built-in command line tools to connect to a file server, mount the DMG and use the equivalent of a ditto command to copy files from the mounted disk image to the Mac. (The ditto command has a nice feature that lets you create sub-folders as needed without having to explicitly make them.)

Jamf created the FUT and FEU features. So long as the DMG was built correctly and the administrator specified FUT and FEU for the DMG, Jamf would ditto files recursively to existing user folders (FEU) or ditto them to the User Template folder (FUT).

Then Casper gained support for Apple PKG installers. PKG installers use Apple's command line tool "installer" to install packages. Part of its magic was it understood what scripts were in a PKG and could run those as part of installation.

The two types of installations use two different toolsets to accomplish similar things. Apple's installer tool can copy files onto the computer and then the person making the package can create a postinstall script to move them into user folders or the User Template folder. But it doesn't understand the concept of FUT and FEU. Similarly, DMGs don't understand the concept of scripts and can't support them.

[frank6502]

Thank you for that explanation, but that does not explain the behavior I am experiencing.
Especially not that I am able to choose FEU with a package and that it does have an effect...

[talkingmoose]

What you're seeing is an appearance issue. Yes, those items should be dimmed when you're right-clicking on PKGs. Being able to choose them may lead you to believe they'll work, but they won't.

[frank6502]

Well, maybe it is not supposed to make a difference, but when between two attempts of installing a piece of software only one component is changed, then that really does lead me to believe that said component made a difference. In one case it installs, in the other it doesn't. I repeated that process a few times, just to be sure. Please look at my screenshots...
Thx!

[frank6502]

I'm happy to provide further log files and such!

[were_wulff]

@frank6502

This is a known issue that we have filed under PI-004562.

The options are available when they should not be (they should be greyed out) and, as you're seeing, it can cause errors if they're selected/used.

If you have not already, and would like to open a Support case to have attached to PI-004562, please get in touch with Support either by giving them a call, sending an e-mail to support@jamf.com, or using the My Support section of Jamf Nation.

Thanks!
Were Wulff
Jamf Customer Experience

[mjhersh]

How was your policy set up? How did you trigger it for your two tests? I'm wondering if this behavior is not so much due to FUT/FEU, but rather the way you triggered the policy in your two tests.

I've seen that error (or what I believe is the English equivalent, at least) with a few packages, and I've found that it will succeed or fail depending on how the policy is triggered. Specifically, if I open Terminal and type sudo jamf policy, it will succeed, but if I wait for the client to run its natural check-in, it will fail. This is because when you run it from Terminal, even though it runs as root, it's running from within a user context, with at least some of the user's environment variables set. On the other hand, the natural check-in runs from a system-level LaunchDaemon, which has no association with the active user context. If a pkg runs scripts that rely on a logged-in user environment, then boom, you get inconsistent behavior. Ditto for policies set to run on startup. (And ditto for almost anything using osascript.)

The workaround I use for these problem packages is that I create two policies to deploy them:

1. An installer policy with a custom trigger, let's call it weirdworkaround
2. A kickoff policy set to recurring check-in/startup/whatever, with sudo jamf policy -event weirdworkaround entered under Files and Processed > Execute Command.

This two-policy dance installs successfully even on natural check-in or startup, whereas installing the package directly with a single policy would not.

This is just a guess based on the error message. Hope it helps.