munki repo move and AUTOPKGR

[Allan Porter]

Hi,

I recently moved my working munki repo to a new server and it appears to be working but my autopkgr recipes don't download the newest apps etc. 

Error: Munki repo not available at /share/technologyteam/munki_repo.

I'm using autopkgr 1.5 and was planning on upgrading it but i thought that I might want to get recipes working first.   

Can I just run #munkiimport - - configure to set the new repo and Auto PKGR will know? Or is there a setting somewhere in autopkgr to point to the new repo?

Any advice is appreciated.

Thank you,

Allan

[Elliot Jordan]

Hi Allan,

It sounds like you need to update the MUNKI_REPO setting in the AutoPkg preferences:

https://github.com/autopkg/autopkg/wiki/Getting-Started#optional-configure-for-use-with-munki

Note that this setting can also be adjusted from within AutoPkgr:

https://github.com/lindegroup/autopkgr/wiki/Munki

If that doesn't work, take AutoPkgr out of the equation and run a few recipes using `autopkg` in Terminal to see whether the output contains helpful messages.

Elliot

--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autopkg-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/85e92ad9-8d75-4361-9d6d-a1e83db47bb1n%40googlegroups.com.

[Allan Porter]

Thanks for pointing me in the right direction.  I will try those things.   

Another question: I have two munki_repos, one is production while the other is dev; they are on two different servers and I want to continue using the working repo.  So far I've been managing my working repo with AUTOPKGR and MunkiAdmin on my laptop but I want to move them to an iMac so I can migrate/work on the dev environment from my laptop; I feel like I want to manage them separately so I don't create a nightmare.    What's the best way to move AUTOPKG and configs to iMac without breaking my current repo?  Is it as easy as selecting the same Repo Clones and recipes on my iMac? 

Hope I'm making sense.

Thanks for the advice.

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/CADefdwiOJsXzsYszhXbYM697ShYA_Rj%2BLg%2Bn_L42nArwJM-wxg%40mail.gmail.com.

--

Allan Porter

RE-1 Technology Department

District Office Carbondale

(970) 384-6021

[Elliot Jordan]

Hi Allan,

I addressed your migration question in the other thread, but I wanted to circle back on the idea of separate "production" and "development" Munki repos.

One question that occurs to me: What is the desired purpose of having the two Munki repos? Is it because you're still learning Munki and want a bomb range of sorts to make sure changes don't blow up on the fleet? Or is it because you're having a subset of your users test early versions of software that will eventually be offered to all?

If a bomb range is what you're after, then it follows that all changes you make in your development environment, if they behave as expected, will be eventually applied to your production environment. Configuring this could look like this:

1. Make the change on your Mac's local Munki repo, use rsync (or aws sync, or whatever tool fits best) to sync the change to your development Munki repo.
2. Point a small number of Macs to the development repo using the SoftwareRepoURL key in an MDM config profile. Test and verify that the change is successful.
3. Once you're satisfied, use the same sync tool to apply the change to your production Munki repo.

If your Munki repository is in Git, you could automate this process such that your "main" or "master" branch is synced with your production Munki server, while your "development" branch is synced with the development Munki server. The synchronization could be triggered by CI/CD (from your GitLab/GitHub instance), or it could be a LaunchAgent or cron job if you don't use CI/CD. This requires you to avoid merge conflicts between the two branches, but that should be made easier because all the commits are going in one direction (development → production).

If phased software testing is your goal, then I'd recommend leveraging Munki's manifests and catalogs instead of managing two separate repositories. Testers' machines would use manifests that pull from one or more "testing" catalogs, and the general population would pull only from the "stable" catalog. Shea Craig and I discussed a few examples of phased testing approaches at the 2016 PSU MacAdmins conference, and you can watch the recording here.

Elliot

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/CAO4_c-6npBvcAc3MY0XAHuQdcZSv3yG29z9pSWpY83wFpq52rA%40mail.gmail.com.