# Three Python scripts that answer macOS questions neither the catalog nor the updater answers well

> A small, deliberately unfashionable repository of macOS admin utilities, with no releases, no topics, and a README that tells you when to go use someone else's fork instead.

**munki/macadmin-scripts** — Scripts of possible interest to macOS admins

- Repository: https://github.com/munki/macadmin-scripts
- Stars: 2,453 · Forks: 522
- Language: Python
- License: NOASSERTION
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/munki-macadmin-scripts

## Two tools and a supporting script, in a repository with no releases

The repository is titled macadmin-scripts and described on GitHub as scripts of possible interest to macOS admins. The tree contains three Python files and a docs directory: `getmacosipsws.py`, `installinstallmacos.py` and `munki_bundle_pkg_finder.py`.

The README documents two of the three in detail. `getmacosipsws.py` is described as a quick and dirty tool to download the macOS IPSW files currently advertised by Apple in a specific feed URL on mesu.apple.com. IPSW files are the restore images Apple ships for putting a Mac back to a known state, so this is the tool you reach for when you need a specific macOS version available for imaging rather than whatever the catalog currently offers.

`installinstallmacos.py` is the more involved one. It creates disk images containing macOS Installer applications that are available through Apple's softwareupdate catalogs, and the documented way to see what it can do is its own help output:

```bash
python ./installinstallmacos.py --help
```

`munki_bundle_pkg_finder.py` is present in the tree and absent from the README's descriptions. If you are here for Munki work, that filename is the whole documentation. GitHub reports 2,450 stars and 522 forks, which is a lot of interest for three scripts, and 8 open issues. There are no releases at all, so there is nothing to download and no version to pin: you clone and you run the source.

## The README sits in a Munki org but will not promise it is Munki

The repository lives under the munki organisation and is named macadmin-scripts. The README's second line is where the tension shows: some scripts that might be of use to macOS admins, might be related to Munki, might not.

That hedge is not false modesty. Only one of the three scripts touches Munki at all, and it is the undocumented one. `getmacosipsws.py` and `installinstallmacos.py` have nothing to do with package management; they deal in Apple restore images and installer applications. So the Munki connection is real but partial, and the README is telling you not to assume the repository is a Munki component.

There is a second reason for the hedge that is worth understanding. The repository sits under the organisation of a well known macOS package management tool, and anyone evaluating it for corporate use will ask whether it is a supported Munki component with a compatibility promise attached. The README declines to answer that, and the absence of releases, topics and continuous integration metadata is consistent with the decline. Treat it as a personal utility set maintained by someone whose day job involves Munki, not as part of Munki's supported surface.

GitHub reports the language as Python and the pushed date as 2026-09-16, so the scripts are still being touched.

## The license field says nothing while the tree holds a LICENSE.md

GitHub reports the license for this repository as NOASSERTION, which is what the API returns when it cannot classify the license text automatically. The tree, meanwhile, contains a LICENSE.md at the root.

Both statements are true at once and they point in opposite directions if you take either in isolation. NOASSERTION means no machine-readable grant is available to tooling: some automated license scanners, some corporate compliance pipelines and some package-adjacent workflows will treat this repository as having unknown terms. The presence of LICENSE.md means there is a human-readable document that likely does state terms.

The practical instruction is simple: open LICENSE.md and read it, then make your own decision. Do not let an automated tool make that decision for you, and do not assume the absence of a classified license means the absence of a license. If your organisation has a policy about licensing provenance for code you vendor or redistribute, this is exactly the repository where that policy will catch something, so resolve it by reading the file rather than by reading the metadata field.

There is a related detail in the README worth noting even though it is a typo: it states that in macOS 12.3 Apple stopped providing Python as part of macOS, spelled with a missing letter. The substance is the part that matters operationally. You must bring your own Python interpreter, and the README warns that you may also need to install additional Python modules. Since there are no dependency manifests in the tree to check, you find out what a script needs by running it.

## You can only build the installer for the Mac you are standing at

The most important paragraph in this README is the one about hardware, and it is easy to skim past. Because the tool uses Apple's installer, any install check or volume check scripts are run. The consequence is stated directly: you can only use this tool to create a disk image containing the versions of macOS that will run on the exact machine you are running the script on.

The example makes it concrete. To create a disk image containing version 10.13.6 that runs on 2018 MacBook Pros, you must run the script on a 2018 MacBook Pro and choose the proper version. The README then explains why, in the most practical sentence in the repository: forked OS build numbers are typically four digits, so build 17G2208 was correct for 2018 MacBook Pros, while 17G65 was correct for all other Macs supporting High Sierra.

That is a real constraint, not a workaround you can engineer around. If you attempt an incompatible version you get an error along these lines:

```
Making empty sparseimage...
installer: Error - ERROR_B14B14D9B7
Command '['/usr/sbin/installer', '-pkg', './content/downloads/07/20/091-95774/awldiototubemmsbocipx0ic9lj2kcu0pt/091-95774.English.dist', '-target', '/private/tmp/dmg.Hf0PHy']' returned non-zero exit status 1
Product installation failed.
```

The fix the README gives is to use a compatible Mac or select a different build. There is also a documented escape hatch: the InstallationCheck script in versions of the macOS installer to date skips its checks and returns success when run on a virtual machine, so you may have success running the script in a VM. If `/usr/bin/installer` returns errors during the process, the README points you at `/var/log/install.log` for clues, which is the right place to look before changing anything.

## Run it from /Users/Shared, or privacy protections will get in the way

There is a short note headed as important for Catalina and later, and it is the kind of warning that saves an afternoon. macOS privacy protections might interfere with the operation of this tool if you run it from Desktop, Documents, Downloads or other directories protected in Catalina or later. The suggested working space is `/Users/Shared`, or a subdirectory of it.

The mechanism is familiar to anyone who has scripted macOS since Mojave. Scripts, downloads and generated disk images all touch locations that now require an explicit grant, and a process without that grant can fail in ways that look like a bug in the tool. Moving the working directory is a five second fix that the README tells you about, which is more than most tools bother to do.

The same section recommends using a VM as a way to sidestep the hardware compatibility constraint described earlier. Combined with the `/Users/Shared` advice, the pattern for using this tool successfully is: run it inside a virtual machine, from an unprotected directory, on hardware matching the macOS version you are trying to build. Each of those three conditions comes straight from the README, and each one corresponds to a different failure you would otherwise debug from scratch.

The README also says the tool assembles Install macOS applications by downloading the packages from Apple's softwareupdate servers and then installing them into a new empty disk image. That two stage shape explains why it needs both network access and a large amount of scratch space.

## The README points you to a fork the moment you outgrow it

The last section of the README is titled alternate implementations, and it names Graham Pugh, describes that fork as having a lot more features and bells and whistles, and gives the repository URL. It tells you to check it out if your needs are not met by this tool.

That is worth weighing carefully, because it tells you something about the scope of the original. `installinstallmacos.py` here does one thing: build a disk image containing an installer for a version that will run on the current hardware. If you need multiple architectures in one image, unattended deployment metadata, custom package injection, or support for macOS versions whose checks do not behave the way the ones described here do, then this is the wrong tool and the README is telling you so in advance.

The fork also sits next to the other piece of evidence about intent. The upstream repository has 522 forks, a number that suggests people have already made their own versions for their own constraints. A tool with this shape, where the hard part is Apple's installer behaviour rather than the code in the repository, invites forking by design.

So the decision procedure is short. If you need to build a macOS installer disk image for the Mac in front of you, run the script from `/Users/Shared` or a VM. If you need anything beyond that, read the alternate implementation first. And since there are no releases here, keep a copy of whatever you run, because the only upgrade path is pulling the source again.

## Conclusion

This repository earns its place by being specific about what it cannot do. It does not run on anything but macOS, it does not ship prebuilt disk images, and the one tool that looks like a general installer builder is constrained by Apple's own install check scripts to the hardware you happen to be sitting at. What it does offer is the source for three jobs that are otherwise awkward: enumerate the IPSW builds Apple still advertises, assemble an Install macOS application from softwareupdate catalogs, and locate package files inside Munki bundles. GitHub reports the license as NOASSERTION even though the tree contains a LICENSE.md, so read that file before reuse. Treat the scripts as code you run yourself rather than as a product: there are no releases, so there is no upgrade path, and the README itself points you to a fork with more features when you outgrow these.

## FAQ

### How do I execute a script on a Mac?

For these scripts, open a terminal in the repository directory and run the file with Python 3, for example `python3 ./installinstallmacos.py --help` to see the options first. The README notes that since macOS 12.3 Apple no longer provides Python, so you need to install your own interpreter, and you may need additional Python modules since there are no dependency manifests to check against.

### What does installinstallmacos.py do?

It creates disk images containing macOS Installer applications available through Apple's softwareupdate catalogs. It downloads the packages from Apple's servers and installs them into a new empty disk image. Because it uses Apple's installer, install and volume check scripts run, so you can only build an image for a macOS version that will run on the exact machine you run the script on.

### What is getmacosipsws.py for?

It downloads the macOS IPSW restore images that Apple currently advertises in a feed on mesu.apple.com. The README describes it as a quick and dirty tool, which is a fair warning about how much polish to expect.

### Can I install macOS 10.13.6 on any Mac with installinstallmacos.py?

No. You must run the script on hardware that the target version supports, because Apple's install check scripts run during the build. The README's example is to build 10.13.6 for 2018 MacBook Pros by running the script on a 2018 MacBook Pro and choosing the right four digit build, and it notes that the installer skips its checks inside a virtual machine.

## Sources

- [Issues](https://github.com/munki/macadmin-scripts/issues)
- [munki/macadmin-scripts on GitHub](https://github.com/munki/macadmin-scripts)
- [README](https://github.com/munki/macadmin-scripts/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/munki-macadmin-scripts