Last updated at 2019-03-13 14:25:48 by ouit0354
Differences between revisions 2 and 3
Revision 2 as of 2015-07-24 13:20:53
Size: 5719
Editor: ouit0354
Comment:
Revision 3 as of 2015-07-24 13:59:49
Size: 3656
Editor: ouit0354
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
This will create a recipe at {{{/srv/autopkg/RecipeOverrides/<RecipeName>.munki.recipe}}} which you must then edit.

The following standards should be observed:

 * Unless overriding for specific reasons (e.g. to get a broken download working) all Input keys/values you are not overriding relating to a URL (DOWNLOAD_URL, SPARKLE_FEED_URL etc.) should be removed, in case this changes in the parent recipe.
 * {{{<key>Identifier</key>}}} should begin with {{{uk.ac.ox.orchard.}}} and not {{{local.}}}
 * {{{<key>NAME</key>}}} should be the name of the app with spaces expressed as underscores.
 * {{{<key>MUNKI_REPO_SUBDIR</key>}}} should be set to {{{<string>%NAME%</string>}}} (except when grouping logical collections of apps e.g. Adobe Creative Cloud or MS Office installer and its updates in which case it should be {{{<string>Name_Of_Collection</string>}}}
 * {{{<key>MUNKI_CATEGORY</key>}}} - if it exists - should have its string value set to one of the categories listed [[#|here]
 * For the {{{<key>pkginfo</key>}}} dict that autopkg passes to munki:
  * Change the string value of the {{{<key>category</key>}}} to unstable. New applications should always go into the unstable Munki catalog at first. After they have been running for a while, this can be changed to stage directly to testing.
  * If you have not set MUNKI_CATEGORY you can set it here with e.g.:
  {{{
  ...
  <key>category</key>
  <string>Design and Media</string>
  ...
}}}
  * If it's missing, add a {{{<key>description</key>}}} and a string value describing the app (this will appear to users in the Orchard Software Centre)
  * If {{{<key>display_name</key>}}} is set to {{{<string>%NAME%</string>}}} and you changed the value of {{{<key>NAME</key>}}} above, you will doubtless want to change this to a more readable display name for users.
  * Scripts to be run by munki when installing/removing this app should be added to the pkginfo dict. Create a {{{<key>preinstall_script</key>}}} or {{{<key>postinstall_script</key>}}} and add the HTML escaped script inside the corresponding {{{<string></string>}}} tags.
   * The command {{{$ sed 's/&(?!amp;)/\&amp;/g; s/</\&lt;/g; s/>/\&gt;/g;' <filename>}}} is very useful for escaping scripts on the command line.
This will create a recipe at {{{/srv/autopkg/RecipeOverrides/<RecipeName>.munki.recipe}}} which you must then edit according to the standards set out [[Infrastructure/autopkg/OverrideStandards|here]]

Orchard autopkg Infrastructure

Orchard's autopkg configuration is hosted on a Mac Pro with a large local storage array.

The buildhost has a local user 'autopkg' whose $HOME is in /srv/autopkg/. Because autopkg does not work well in multi-user environments (each user would need the same set of recipe repos imported and cannot share preferences), the autopkg user has all the defaults set necessary to build our software set, and it is necessary to switch to this user by prefixing $ sudo -u autopkg to issue any autopkg commands.

Overriding existing recipes

All recipes should be overridden locally, even if you have written a recipe yourself. Recipes should be written for the wider autopkg community and any local standards/customisations should be done in an override.

The directory /srv/autopkg/RecipeOverrides/ is a git clone of the ox-it orchard-recipe-overrides repo on Github /!\ N.B. this repository is currently private, although we hope to make it public once certain sensitive information has been removed.

Once you have written a recipe, or imported a recipe repo containing a munki recipe you would like to use, you should issue

$ sudo -u autopkg autopkg make-override <RecipeName>.munki

This will create a recipe at /srv/autopkg/RecipeOverrides/<RecipeName>.munki.recipe which you must then edit according to the standards set out here

Testing your override

To test your override issue $ sudo -u autopkg run -vv <RecipeName>.munki. You should see your app downloaded, optionally packaged, and then imported into Munki with a useful version number, along with the input and output of each processor step. If anything goes wrong with this process you will probably want to delete the package and associated pkginfo from the munki repo before making changes and trying again.

Note this only imports the item into the Munki catalogs and to have it appear in Orchard Software Centre it must be added to a manifest. See the Munki page for more info.

Committing changes to repo

When you are satisfied with your edits, add the file to the next commit by issuing $ git add <filename> and then commit it to the repository with $ git commit -m "Commit message". Once you have finished creating or editing recipes you should then push them upstream with $ git push origin master which will prompt you for your github username and password.

Auto-building of Recipes

Automatic runs of building the software set are done via a LaunchDaemon /Library/LaunchDaemons/uk.ac.ox.autopkg-rebuild.plist which runs the script /srv/autopkg/bin/autopkg-rebuild.sh at 8pm each night. This goes through the files in /srv/autopkg/BuildRecipes and performs autopkg run on each filename. In order to add your newly created override to the build run, you should create a symlink to the override e.g.:

$ cd /srv/autopkg/BuildRecipes
$ sudo -u autopkg ln -s ../RecipeOverrides/<RecipeName> .

autopkg-build.sh logs to syslog so to check on its output you can $ grep autopkg-build /var/log/system.log. Errors are also emailed to NSMS. All errors of an unknown cause should be investigated.

Conversely, if you want to stop automatically building a recipe, delete the symlink. To see what is available in RecipeOverrides but not being run from BuildRecipes you can do $ diff -r /srv/autopkg/BuildRecipes /srv/autopkg/RecipeOverrides


Orchard is a close co-operation of