+7We want to upload Xcode (packaged and 14GB in sixe) as part of our Patching Policy and wondering if there is a limit on the size of the PKG you can upload to Jamf Pro (cloud based instance).
I've found a few posts in the past on this issue but never a concrete answer....
Also, does anyone know the total amount of storage you can use with an instance of Jamf Pro? I'd like to know as we have quite a few PKG's on there already that are fairly large.
Best answer by AJPinto
The .pkg format has a soft limit of 10GB, anything beyond that is extremely unreliable. You can use a .dmg if you need a package larger than 10GB. I recommend against packaging xcode, deploy it with VPP, or let users get it from apples developer site directly themselves. Apple really needs to improve xcodes deployment options, it either needs to be smaller (like a stub installer) or they need to improve the AppStore deployment speed for that stupidly large app.
For the questions on your storage limitation I recommend opening a ticket with JAMF. That is down to your subscription level and any additional cloud storage servers you have. JAMF Recommends that you dont upload any single file larger than 20GB due to limitations placed by the server hosts. You can also have an onprem storage server setup and ignore pretty much all the storage limitations and restrictions.
+26The .pkg format has a soft limit of 10GB, anything beyond that is extremely unreliable. You can use a .dmg if you need a package larger than 10GB. I recommend against packaging xcode, deploy it with VPP, or let users get it from apples developer site directly themselves. Apple really needs to improve xcodes deployment options, it either needs to be smaller (like a stub installer) or they need to improve the AppStore deployment speed for that stupidly large app.
For the questions on your storage limitation I recommend opening a ticket with JAMF. That is down to your subscription level and any additional cloud storage servers you have. JAMF Recommends that you dont upload any single file larger than 20GB due to limitations placed by the server hosts. You can also have an onprem storage server setup and ignore pretty much all the storage limitations and restrictions.
+7The .pkg format has a soft limit of 10GB, anything beyond that is extremely unreliable. You can use a .dmg if you need a package larger than 10GB. I recommend against packaging xcode, deploy it with VPP, or let users get it from apples developer site directly themselves. Apple really needs to improve xcodes deployment options, it either needs to be smaller (like a stub installer) or they need to improve the AppStore deployment speed for that stupidly large app.
For the questions on your storage limitation I recommend opening a ticket with JAMF. That is down to your subscription level and any additional cloud storage servers you have. JAMF Recommends that you dont upload any single file larger than 20GB due to limitations placed by the server hosts. You can also have an onprem storage server setup and ignore pretty much all the storage limitations and restrictions.
Thanks for the reply, agree with everything you say. The amount of end users who call about Xcode being "stuck" during installing is crazy - what we wanted to try and do is update it via Patch Management to the latest version...
We do deploy via VPP but as above, users click, click, click in Self Service and each click after the first produces an error in Self Service (in Jamf logs it's called a Duplicate Request). We've put a Notification in saying please be patient, but as we all know end users are anything but patient :-)
+26Thanks for the reply, agree with everything you say. The amount of end users who call about Xcode being "stuck" during installing is crazy - what we wanted to try and do is update it via Patch Management to the latest version...
We do deploy via VPP but as above, users click, click, click in Self Service and each click after the first produces an error in Self Service (in Jamf logs it's called a Duplicate Request). We've put a Notification in saying please be patient, but as we all know end users are anything but patient :-)
Ya, I tell people click the button once and check on it tomorrow. What happens is they click the button more than once, so you get the duplicate request errors. The original install is still in flight. It is ridiculous that the VPP install of xcode can take upwards of 12hrs (normally just an hour or so but still).
For my more needy users I have xcode set to auto install. We have a software request process (legal and securitys choice not mine) so when someone requests xcode we can sit on the request until the application installs before we ever tell the user the request was approved. Again we just do this for the needy, clicky people. Everyone else gets to selfservice it.
+25@Utilizator A quibble on @AJPinto 's comment of an 10GB limit for .pkg file - it really depends on your minimum supported version of macOS. If you're packaging for Monterey or later, and calling pkgbuild directly to build your .pkg, then you can use the new --large-payload option (see https://scriptingosx.com/2021/10/save-up-to-25-pkg-file-size-with-this-weird-monterey-trick/).
And if you do find yourself needing to deal with a large .pkg the https://github.com/kc9wwh/pkgChunker script from @kc9wwh will conveniently carve it up and create self re-assembling smaller packages which makes deployment from a JCDS easy. Just be sure to save the script from that repo instead of download and running the release version that's posted.
@Utilizator A quibble on @AJPinto 's comment of an 10GB limit for .pkg file - it really depends on your minimum supported version of macOS. If you're packaging for Monterey or later, and calling pkgbuild directly to build your .pkg, then you can use the new --large-payload option (see https://scriptingosx.com/2021/10/save-up-to-25-pkg-file-size-with-this-weird-monterey-trick/).
And if you do find yourself needing to deal with a large .pkg the https://github.com/kc9wwh/pkgChunker script from @kc9wwh will conveniently carve it up and create self re-assembling smaller packages which makes deployment from a JCDS easy. Just be sure to save the script from that repo instead of download and running the release version that's posted.
Plgchunker? That’s actually awesome.
I package up Logic Pro X libraries for mass deployment 80GBs. This would certainly take out a heap of the faff.
good shout!
@Utilizator A quibble on @AJPinto 's comment of an 10GB limit for .pkg file - it really depends on your minimum supported version of macOS. If you're packaging for Monterey or later, and calling pkgbuild directly to build your .pkg, then you can use the new --large-payload option (see https://scriptingosx.com/2021/10/save-up-to-25-pkg-file-size-with-this-weird-monterey-trick/).
And if you do find yourself needing to deal with a large .pkg the https://github.com/kc9wwh/pkgChunker script from @kc9wwh will conveniently carve it up and create self re-assembling smaller packages which makes deployment from a JCDS easy. Just be sure to save the script from that repo instead of download and running the release version that's posted.
So just to clarify:
I’d create a 80gb PKG in composer and pass it through this?
What sort of child PkG file sizes are we talking about?
Would I script a bunch of installer -pkg /location /path, or will it deploy the files direct from the JAMF policy?
Furthermore, what’s the difference between the term ‘flat PKG’ and presumably a non-flat PKG :D
Is a flat PKG a self-composed PKG, and non-flat a vendor supplied one?
(Just curious as I do package up Adobe Apps individually because of the DP struggle)
+26So just to clarify:
I’d create a 80gb PKG in composer and pass it through this?
What sort of child PkG file sizes are we talking about?
Would I script a bunch of installer -pkg /location /path, or will it deploy the files direct from the JAMF policy?
Furthermore, what’s the difference between the term ‘flat PKG’ and presumably a non-flat PKG :D
Is a flat PKG a self-composed PKG, and non-flat a vendor supplied one?
(Just curious as I do package up Adobe Apps individually because of the DP struggle)
Not to get too deep in to how packages work. I would use a .dmg package for something that is 80gb, though that is REALLY large for something that you would want to deploy.
As far as Adobe, you cannot package Adobe. You need to use Adobe's admin console. Select the apps you want (Creative Cloud is mandatory), and have Adobe build the package for you. Adobe "packages" go out as zip files. Just upload the zip file unadulterated in to JAMF Admin (or directly to the web console).
+25So just to clarify:
I’d create a 80gb PKG in composer and pass it through this?
What sort of child PkG file sizes are we talking about?
Would I script a bunch of installer -pkg /location /path, or will it deploy the files direct from the JAMF policy?
Furthermore, what’s the difference between the term ‘flat PKG’ and presumably a non-flat PKG :D
Is a flat PKG a self-composed PKG, and non-flat a vendor supplied one?
(Just curious as I do package up Adobe Apps individually because of the DP struggle)
@Qwheel There is no option to modify the parameters that Composer uses to call pkgbuild, so you're currently stuck with the 8GB limit using it. You'd have to manually call pkgbuild, or use http://s.sudre.free.fr/Software/Packages/about.html which I believe allows you to tweak the options it passes to pkgbuild.
However...
I would _not_ recommend creating a single giant Adobe installer package. You're better off sticking with the individual installers, but PkgChunker won't help with those as it only works with flat packages.
+25Not to get too deep in to how packages work. I would use a .dmg package for something that is 80gb, though that is REALLY large for something that you would want to deploy.
As far as Adobe, you cannot package Adobe. You need to use Adobe's admin console. Select the apps you want (Creative Cloud is mandatory), and have Adobe build the package for you. Adobe "packages" go out as zip files. Just upload the zip file unadulterated in to JAMF Admin (or directly to the web console).
Please don't use a .dmg. Or as I like to say it, Friends don't let friends use .dmg "installers".
A .pkg installer is (normally) completely standalone, and can be used outside of Jamf Pro if needed. The .dmg output of Composer is not an "installer", but a specially formatted disk image which can only be deployed via Jamf Pro. Well technically you could write a script to do what the Jamf binary does when a policy deploys a .dmg, but if you were going to do that you'd probably have created a .pkg in the first place.
And for anyone _really_ curious about packaging for macOS, https://scriptingosx.com/packaging-for-apple-administrators/ is an excellent resource, as is the Scripting OS X web site (for posts specific to packaging use this link: https://scriptingosx.com/category/packaging/ )
+26Please don't use a .dmg. Or as I like to say it, Friends don't let friends use .dmg "installers".
A .pkg installer is (normally) completely standalone, and can be used outside of Jamf Pro if needed. The .dmg output of Composer is not an "installer", but a specially formatted disk image which can only be deployed via Jamf Pro. Well technically you could write a script to do what the Jamf binary does when a policy deploys a .dmg, but if you were going to do that you'd probably have created a .pkg in the first place.
And for anyone _really_ curious about packaging for macOS, https://scriptingosx.com/packaging-for-apple-administrators/ is an excellent resource, as is the Scripting OS X web site (for posts specific to packaging use this link: https://scriptingosx.com/category/packaging/ )
.pkg’s are deprecated, but still supported (sorta). .dmg packages are the modern .pkg’s. There is no reason to not to use a dmg when a pkg is not sufficient. You can also deploy dmg’s without JAMF, JAMF just bundles the scripting needed to use them in to the “install”. By and large I use pkg’s myself, but when something is over 10gb I use dmg’s. I usually cache the dmg and do everything with scripts, but that is just me.
+25.pkg’s are deprecated, but still supported (sorta). .dmg packages are the modern .pkg’s. There is no reason to not to use a dmg when a pkg is not sufficient. You can also deploy dmg’s without JAMF, JAMF just bundles the scripting needed to use them in to the “install”. By and large I use pkg’s myself, but when something is over 10gb I use dmg’s. I usually cache the dmg and do everything with scripts, but that is just me.
@AJPinto I believe you're 180 degrees out of phase with reality on a .dmg being the new .pkg, and .pkgs being deprecated, but if you can provide a reference I'd love to take a look.
While a .dmg "installer" doesn't require Jamf Pro, it's much less useful if not being deployed via Jamf Pro because you also have to supplying a companion script with the .dmg to copy the files the image contains to the proper location on a machine, and get the user to run that script.
A .pkg on the other hand can have self contained scripts and the Installer app built in to macOS automatically runs those when the .pkg is opened whether that's done via Jamf Pro or a user manually opening it.
There's no question that .pkgs and .dmgs created by Composer and deployed via Jamf Pro have similar functionality, and for users that don't (yet) have much scripting experience a .dmg makes the Fill Existing User and Fill User Template options much easier than a .pkg. Ultimately however a .pkg offers much more flexibility when it comes to installing things, and if you have to use a script in conjunction with a .dmg installer you might as well have have created a .pkg in the first place.
@Qwheel There is no option to modify the parameters that Composer uses to call pkgbuild, so you're currently stuck with the 8GB limit using it. You'd have to manually call pkgbuild, or use http://s.sudre.free.fr/Software/Packages/about.html which I believe allows you to tweak the options it passes to pkgbuild.
However...
I would _not_ recommend creating a single giant Adobe installer package. You're better off sticking with the individual installers, but PkgChunker won't help with those as it only works with flat packages.
I'm not aware of any limitations with Composer itself.
I've just done a quick test of pkgChunker.
I had to install the pkgChunker binary from the link provided.
I then had to run this script to get it work.
https://raw.githubusercontent.com/kc9wwh/pkgChunker/master/pkgChunker
I grabbed 13GB of Logic Sound libraries and dumped them into Composer. It spat out a flat PKG.
I then ran
sudo bash /Users/home/Desktop/text.sh -p /Users/home/Desktop/Alchemy\\ Samples.pkg -o /Users/home/Desktop/ChunkedAnd it created one 7.34gb PKG and another 5.42gb PKG. Happy days.
Naturally, grabbing even more directories will take more time, but as a proof of concept, it looks to do what I need it to do.
I've used Composers snapshots in the past to get a rough idea of where Logic libraries are getting dumped. Using it again, I'll use a fast iMac and dump them all into a big parent PKG and then chunk it down afterwards (I previously micromanaged each manually produced PKG to be less than 6GB).
I guess the next step is to upload these puppies and check JAMF deploys the libraries as expected :)
Not to get too deep in to how packages work. I would use a .dmg package for something that is 80gb, though that is REALLY large for something that you would want to deploy.
As far as Adobe, you cannot package Adobe. You need to use Adobe's admin console. Select the apps you want (Creative Cloud is mandatory), and have Adobe build the package for you. Adobe "packages" go out as zip files. Just upload the zip file unadulterated in to JAMF Admin (or directly to the web console).
I'm familiar with the Adobe admin console.
Yr 1 with JAMF we managed to get the full Adobe Suite up onto our DPs but every year following became a massive struggle with it constantly failing. I chalk it down to just dumb luck we got the whole suite up there, or the JAMF DP 6-8GB 'limit' isn't actually a limit, it's more that the system get's flakier as you upload bigger files.
I decided to move to individual apps because I needed the packaging process to run smoother.
I now run a post image script that checks if each app is installed and push out each individual app by trigger.
if [ -x /Applications/Adobe\\ Premiere\\ Pro\\ 2022/Adobe\\ Premiere\\ Pro\\ 2022.app ]; then
echo PRM exists
echo ""
else
sudo jamf policy -trigger premierepro
echo ""
sleep 10
fiRegarding the 'just upload the unadultarated .ZIP' note. I would suggest not doing this. I've tried with that mentality the past couple of years and there's always 3 or 4 applications that download but don't deploy the application. In this instance, I have to go back to the .zip, expand it, and upload it's containing .PKG.
I would advise its worth going the extra step and uploading the contained PKG instead if you really want certainty (I speculate it's an issue with the 'Universal' installers from the admin console.)
@AJPinto I believe you're 180 degrees out of phase with reality on a .dmg being the new .pkg, and .pkgs being deprecated, but if you can provide a reference I'd love to take a look.
While a .dmg "installer" doesn't require Jamf Pro, it's much less useful if not being deployed via Jamf Pro because you also have to supplying a companion script with the .dmg to copy the files the image contains to the proper location on a machine, and get the user to run that script.
A .pkg on the other hand can have self contained scripts and the Installer app built in to macOS automatically runs those when the .pkg is opened whether that's done via Jamf Pro or a user manually opening it.
There's no question that .pkgs and .dmgs created by Composer and deployed via Jamf Pro have similar functionality, and for users that don't (yet) have much scripting experience a .dmg makes the Fill Existing User and Fill User Template options much easier than a .pkg. Ultimately however a .pkg offers much more flexibility when it comes to installing things, and if you have to use a script in conjunction with a .dmg installer you might as well have have created a .pkg in the first place.
DMGs work fine. I used to upload "install macOS etc" via a self made DMG from DUtility. You just have to specify the destination for JAMF to dump the contained folders into within 'Target drive' payload (i.e Change it from '/', to '/Applications').
Our JAMF engineer from Academia suggested to not use DMGs, nor use FUT etc. Flat PKGs work for 99% of our needs and assure we manage file permissions on deployments. If a script is required for an installation, there's a large probability it would be required for both a DMG and PKG anyway.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.