Apple released a series of software updates (1/22/19) that caused a stir in the #reposado channel, and is hopefully just a temporary issue. Thanks to everyone in the channel for quickly identifying and figuring out a workaround for this issue!
Long story short, the paths to same Apple update product ID were listed differently in the 10.13 and 10.14 sucatalogs. As a result, repo_sync got really confused! The end result on a 10.14 Mac would be that a newly available product ID was visible, but unable to be downloaded. Here is the workaround (MacAdmins Slack).
If you’re not in the MacAdmins Slack (join!), you’ll need to reorder the sucatalogs such that 10.14 is above 10.13. See the reposado docs.
If you had followed my previous Docker & reposado writeup, a fix has already been issued to the sphen/reposado docker image to address this. Thanks, @sphen!
I can personally confirm that Mojave machines now correctly download and install the applicable updates from reposado.
Snipe-IT is an awesome open-source asset management solution for IT and technology departments. While we haven’t yet implemented this system for our internal team, we recently showcased it to another non-IT department with the hope of moving their existing asset inventory to it given its large support and development base, custom fields and fieldsets around asset types, an easy check-out system (which can be assigned to users, locations, and other assets), as well as the fact that it’s free for those who self-host. Ultimately, we hoped we could expand this to other departments as well. Since we would like build more than one instance for each department, we had a number of implementation requirements …
- Be able to build and host multiple instances of Snipe-IT on a single host
- Maintain persistent data for the databases and Snipe-IT instances
- Efficiently upgrade each instance as stable Snipe-IT and/or database releases were made available
- Avoid having to specify unique ports to navigate to each Snipe-IT instance with multiple instances running on the one host (ex.
Given the above requirements, we determined we could accomplish this most efficiently by building a CentOS 7 virtual machine running Docker. This meant we needed:
- A database container with persistent storage for each Snipe-IT instance
- A Snipe-IT container with persistent storage pointed to each database container
- A reverse proxy container to handle the routing received to the host running Docker to the applicable Snipe-IT container
While the Snipe-IT Docker documentation on this process is good and addresses the process of setting up the necessary database and snipe-it containers, as well as the basic requirements to create a reverse proxy, there wasn’t a streamlined guide covering this process from start to finish. Even if you don’t plan on implementing more than one instance of Snipe-IT, or aren’t all that familiar with Docker, you’ll likely still find this guide helpful.
To implement this, we completed the following:
- Setup & configured our host
- Installed Docker
- Pulled the necessary Docker images
- Created the necessary Docker
env files to define the various variables used by each Docker container
- Create the DNS records to point the desired FQDNs for each Snipe-IT instance to the Docker host
- Built the reverse proxy container
- Built the database container
- Built the Snipe-IT container and defined additional environment variables for the reverse proxy container
- Completed the Snipe-IT Pre-Flight process for each instance
- Completed Snipe-IT base settings configuration
- Add branding
- Configure LDAP Connection & Sync Users
- Configure Slack notifications
- (Optional) Import inventory assets and/or asset history
See past the jump for more info.
For one reason or another, configuration profiles will fail to install on macOS devices. Within the Jamf Pro web interface, you’ll see all these failures in the “Failed” column within computer Configuration Profiles.
Jamf provides two manual ways of clearing these failures:
- Going to the individual device record, clicking the “Management” tab, and selecting the “Cancel All” button adjacent to the Failed Commands list.
- Running an inventory search, clicking the “Action” button, and choosing to clear management commands.
- This process is illustrated, here.
The problem with both of these methods is that it requires you to keep your eye on all of your profiles to monitor any failures and then clear them manually, either for all your machines or for a filtered subset.
Thankfully, Jamf has a
commandflush API to remove all failed MDM commands given a device’s JSS ID. I had no prior API experience, but a fellow Mac admin was kind enough to share a script with me. A big thanks to @neilmartin83!
Since our machines update inventory once every day, I opted to modify the shared script to be used in an extension attribute. This way we could both identify and clear any failed commands in one step, rather than having to create a separate policy for handling the removal.
See below the jump for more information.