I'm guessing it's because the Go library is using the equivalent of

pkgbuild --ownership preserve

instead of

pkgbuild --ownership recommended

... a simple flag to switch

Looks like this is a new one, @Shawn Maddock! I'll loop the team in. The installer package should be generated in the same location where the command was run, though I suspect I may not have quite understood what you were looking for, so just let me know if that's the case.

Yeah it's generating fine, but the metadata in the installer package are incorrect

Gotcha. I wasn't sure if you were also looking for the installer locally, so I wanted to be sure.

I tried both.

root

resulted in permissions that were more correct, but still not right. lol

That's fun. I'll hopefully have an update (or more questions) shortly!

Happy to provide more info!

Was the package also generated on MacOS?

It was

What are you using to scan for these conflicts? And is everything running properly?

There are a number of tools, the screenshot is from a Mac application called "Suspicious Package". And no, the reason I brought it up is when we attempt to deploy the installer via our software management tool, it does not install correctly (the files are placed on the endpoints but the devices never check into fleet, even after a reboot)

I don't believe that anything has changed with permissions recently and the consensus seems to be that this likely wouldn't cause that behavior, so it may be unrelated. What software management tool are you using? Anything interesting in the Orbit logs on your hosts? You can find those at

/private/var/log/orbit/orbit.std{out|err}.log

.

Well, we just deployed a rebuilt package which is working on all devices. Let me see if any of them still have the old logs.

Good deal. Did you change the permissions on the new package, or was it the same build process?

No I extracted the payload from the

fleetctl

-built installer and used

pkgbuild

to create a new installer.

If you'd be down for testing out that original installer again on a host or two to see what shows up in the logs, that would be awesome. That way, we can (hopefully) see whether the issue was related. We haven't seen other reports of issues yet, but we've got the permissions conflicts on our radar and are keeping an eye out.

Lemme spin up a VM

We're testing it with Munki as well, but it's always helpful to get data straight from the source :)

Thanks! Just wrapping up my VM testing

Go ahead and Submit your PR for the main branch and tag me (@ksatter) and I'll take it from there 🙂 I'll also get that documentation updated.

And done!

Fantastic, thanks so much!