"jamf installer" vs "apple installer"

[yellow]

We have a piece of software that is behaving strangely and the developers are wondering if it's the way that Casper installs the packages. I'm fairly certain that this is not the case. I suspect the casper installer and the apple installer are one and the same. I don't think JAMF would recreate the wheel when Apple already has an installer built-into OS X. Wouldn't JAMF just leverage the built-in OS installer tool? However, before I go back to the devs and tell them they're barking up the wrong tree, I want to be (more) sure that I know what I'm talking about.

I looked through the documentation and the KB, but can't really find anything concrete. Anyone already been through this and have an answer?

Thanks for any info anyone has!

[alexjdale]

I don't think you can write your own installer that installs PKGs, actually. I've never heard of anything like that. It should be leveraging the installer command.

[rtrouton]

@yellow,

JAMF is using Apple's installer command line tool to install installer packages that are not Casper-built .dmg files:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/installer.8.htm...

It's been my experience that JAMF prefers to rely on Apple's provided tools whenever possible.

[dpertschi]

JAMF uses the OS X Installer.

Just open Console and you can monitor the install.log and see it happening.

[bentoms]

The only 2 things I can thing that may be different:

1. Installing from a network share: some packages do not support it, so cache & install from cached
2. User account: The JAMF binary installs as root, which may cause issues if the PKG wants to install files in another users directory

What errors are you seeing?

[yellow]

OK, that's what I figured and what was logical to me, but wanted to at least run it by someone else. Now I can ask the devs what they're smoking! :)

[mm2270]

I sincerely doubt that JAMF is using anything other than Apple's built in installer command line binary. I haven't done this test, or can't recall doing it, but my guess is if you ran a policy from Terminal in verbose mode and as it hit the package installation stage did something like:

ps axc | grep "installer"

It would show that "installer" is one of the active processes.

What's more likely is that the installer may be poorly designed and may require someone logged in double clicking it to work correctly. Since Casper will be running the install as root, it may be running into an issue. Maybe the install asks for some kind of interaction for example.

I don't know how much you want to poke at this, or if you just want to throw this back at the dev to figure out, but if you want, you can usually see what's going on in a pkg by dragging it into Composer and converting it to a Source. Most times the files being installed and scripts show up and you can examine them.
Just be aware that when converting to Source, any scripts in the package run against your Mac, not into a temporary DMG like the payload. At least that's how it used to work. I'm not sure if recent versions of Composer changed that. If the scripts do anything weird like delete an existing application, it would likely do that against your Mac too.

EDIT: I got word that version 9.0 and up of Composer no longer runs scripts against your host machine when converting a package to source as the older 8.x version used to, which is good to hear. That was always a slightly dangerous function if you weren't certain what scripts, if any, in the package might be doing.

[yellow]

@mm2270][/url wrote:

What's more likely is that the installer may be poorly designed and may require someone logged in double clicking it to work correctly.

I know this to be the case. But I have to make sure that all my ducks are in a row before I can convince them that their product is less than...

@bentoms][/url wrote:

What errors are you seeing?

No errors.. as noted above, their software is.. not good.. It just plan doesn't work for some unknown reasons too often. There's never a failure for the installer, as as OS X is concerned, the .mpkg installs correct every time whether via GUI double-click, via command line, or via JAMF binary. What happens after that is the issue. I can't really go into details, but they want to say that it's the way we install it that is the issue and we know that it's got nothing to do with that.

But thanks all for responding. I feel much better in going back to them and telling them to look in another direction and we won't be embarking upon this wild goose chase no matter how much they might want to.

[bentoms]

@yellow without more information we cannot 100% say what the issue is.

[yellow]

The issue is their piece of &*^$@# OS X version of their software. Developed in the Tiger era of OS X and never updated. I suspect they've been able to pass this off to other institutions, but we've been asking a lot of questions which has them scrambling.

[acdesigntech]

it can't be any worse than Adobe's craptacular installer. That one doesn't work right half the time either :P