Can you have a locally hosted Munki repo with links to CDN downloads?

[kai.h...@gmail.com]

Is there any straightforward way I can host a Munki repository locally but have the download links point to a CDN?

For example, I'd like to host a Munki repository for a few of my clients. I've only got an internet connection with 100 Mbs upload speeds however, which is fine for serving up plist and xml files, but struggles when multiple endpoints are downloading 1GB+ installers at the same time.

It would be great if I could host all of the metadata on my own machine, but have the actual download links point to the original urls on the relevant vendor's CDN (verified, of course, by the installer item hash)

This way, I still control what is deployed, and allow non-admin users to use the self-service features to install apps and updates, but I'm not providing the bandwidth for bulk downloads – the Munki client would download the installer item directly from the vendor at full speed via their CDN.

I guess my question is:

Can the installer_item_location be a full URL, or does it always have to be relative to the Munki host? 

[Gregory Neagle]

https://github.com/munki/munki/wiki/Supported-Pkginfo-Keys

Look at PackageCompleteURL

I caution that if you put vendor-controlled URLs there you are almost certainly looking at a lot of pain and suffering, as vendors can change their URLs and the files _at_ their URLs at any time.

For example, if your Munki repo had a GoogleChrome item, with a PackageCompleteURL of "https://dl.google.com/chrome/mac/universal/stable/GGRO/googlechrome.dmg”, that’s going to break _very_ quickly, as that URL will return the latest version of Google Chrome.

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/6a71afac-c8c8-48df-8cf7-47ee482a61fcn%40googlegroups.com.

[Alan]

One of the main advantages of Munki is that you can control your repo (including what versions you deliver), and you know the download link will work, because you own the hosting.

If you want clients to just fetch stuff from the vendor directly, you may want to look into Installomator: https://github.com/Installomator/Installomator

To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/54C3E9C1-5F79-43A3-A70E-D57E7BD7B85D%40mac.com.

[kai.h...@gmail.com]

Thanks Alan and Greg. As always, I appreciate the outstanding level of support there is around Munki.

@Alan – Yes, I'm familiar with Installomator, and I do leverage it's capabilities for onboarding workstations that aren't in a managed environment with Munki and MDM.

@Greg – I understand the risks in the asset that a URL points to can change, and the key will be for me to find a static link to the specific version of the installer I want to push out instead of the "give me the latest version" link on the product download page.

I understand there is an element of risk in not hosting my own downloads, in that the vendor's downloads may not be as consistent as my own static hosting. This risk can be mitigated by providing the direct download link to the asset in the CDN, rather than the shortened link from the product download page – e.g. for Microsoft Office, instead of using the url https://go.microsoft.com/fwlink/?linkid=525133 which will always fetch the latest version of the package, I would instead use https://res.public.onecdn.static.microsoft/mro1cdnstorage/C1297A47-86C4-4C1F-97FA-950631F94777/MacAutoupdate/Microsoft_365_and_Office_16.106.26020821_Installer.pkg which is the resolved link to the specific installer.

As an additional layer of security/confirmation, I would download the installer myself and ensure that the checksum in the pkginfo matches that of the download from the CDN.

The main risk I would then face is not that the version would unexpectedly change, but when new versions are released, the vendor may remove the previous version from their CDN.

Cheers,

Kai