It then spends 6 days in the autopkg catalog on top of the two weeks it spends in the rest of the release pipeline, for a total of almost 3 weeks.īecause not all vendors will release their patches once a week the night before your AutoPkg runs, you will end up with certain applications spending longer in the release pipeline than other applications, creating inconsistency in how quickly some apps are patched compared to others. In the worst-case scenario, a patch definition gets released and imported into the autopkg catalog on the morning after this task is carried out. It will have spent two weeks in the pipeline before it made it to endpoints. It will then be promoted to staging, and a week later to production, having spent less than 24 hours in the autopkg catalog. In the best case scenario, a patch definition is released and imported into the autopkg catalog on the morning that this task is carried out. Software is fed into the autopkg catalog by nightly AutoPkg runs, and every week, an administrator promotes software from staging to production, and from autopkg to staging. The problem ⌗Ĭonsider a Munki implementation with 3 catalogs: autopkg, staging, and production. Lots of implementations of Munki rely on promoting patch definitions through catalogs manually (perhaps every week, two weeks, or monthly), but this can lead to delays between patches being released, and patches reaching production.ĭepending on how vendor release days line up with your own promotion days, some software will make it through this pipeline faster than others. Munki is an amazing software management solution for macOS that, paired with AutoPkg, can be fed with patch definitions for software automatically.īut, once those patch definitions are in your Munki repo, how do you get them rolled out to your endpoints?
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |