Home

Awesome

Munki-Staging update - 16-04-2024

Please note we are no longer developing or maintaining this repo. Please consider alternatives to this script should you wish to utilise the munki staging process.

Thanks,

Orchard Team

Introduction

This is a script that utilises a Trello board to manage the promotion of Munki items through development to production and then, if desired to archival. You can use any number of steps between development and production, but by default the script will expect 3 Munki Catalogs:

and this introduction will focus on this example. Taking these catalogs as a basis, you would create 5 Trello boards:

When items are moved into production, they are (by default) moved to a dated list, so you can have a history of when items were placed into production. One list will be made per day. However, you can turn off this behaviour if you wish. This dated behaviour can also be enabled on development and production.

Usage

Setup

It is recommended that this script is run under a service Trello account rather than a real persons, so you can separate the changes made by the script from normal users. This user will need to have access to the Trello board you're using. You will need to know the board ID - the board ID is the part after /b and before the name of your board (with a URL or https://trello.com/b/AbCdEfGh/my-trello-board, AbCdEfGh would be the board ID.)

You will need an API key. Make note of the key and then head over to Trello's instructions for creating a user token. Choose how long you want to issue to token for - using the value of 'never' will stop the token from expiring. The only required option is read and write access to the Trello account. The name can be anything you like, it's how you will identify the token in future.

https://trello.com/1/authorize?key=substitutewithyourapplicationkey&name=munki-trello&expiration=never&response_type=token&scope=read,write

You will be given a 64 character string that you will need to take note of.

You will also need to install the trello module:

$ sudo easy_install trello

Running the script

You can run the script manually on a machine that has the Munki makecatalogs command installed (this will run on OS X or Linux, Windows isn't tested). Note that unlike the upstream version, there is no Docker setup.

In order to get the maximum flexibility from the script, you will need to use a configuration file; however most options for the development, testing and production setup above are available on the command line.

Note that if you use a configuration file you will need to specify a Munki repository section; this is because using the configuration file allows more than one repository to be used, overriding the default option from the command line.

Example

$ python munki-staging.py --boardid 12345 --key myverylongkey --token myevenlongertoken --repo-path /Volumes/my-repo

Command line Options

Configuration file

You can give all of the command line options in a configuration file, which will be read first. The default configuration file locations are: /etc/munki-staging/munki-staging.cfg ./munki-staging.cfg and these will always be checked. You can also add an extra config file location by using the --config command line option.

N.B. Configuration files will be processed before command line options, and not all configuration items have a command line equivalent.

Configuration files will be read in the order:

  1. /etc/munki-staging/munki-staging.cfg
  2. ./munki-staging.cfg
  3. the configuration file give on the command line

All configuration files that exist and are readable will be processed; if a file is missing or unreadable it will not be processed and will not cause an error. Configuration file sections found in multiple sections will be folded together, with duplicated settings taking the latest value found. Details of the processing are give in the section below.

Options on the command line will be used in preference to those in the configuration file. An example configuration file is in munki-staging.cfg-template.

The configuration file has several sections:

Note that if you use a configuration file you must provide at least the sections:

The [main] section

The main section contains global configuration items; the data about the Trello board, the path to makecatalogs and the date_format to be used.

The full options are:

Note that the script requires that boardid, key and `token are set either in the configuration file or on the command line.

In the configuration file, these values should be the unquoted tokens from trello; if there are quotes present at the start and end of these three options they will be stripped.

As an example, a minimal main configuration is below; N.B. the values have been randomly generated, so are NOT valid for trello.

[main]
boardid=ua6oor0oL
key=cf3e10a51fd05ef4a1944c7ccd713aa6
token=6b8a8177589e02994c5183a881b6c91f6709f6dcc6711591c05eb3def190e04e

The [rssfeeds] section

If present, this section configures the output of RSSFeeds of packages in each catalog, that you can publish so that people know which version of a package is in a catalog, and when the software available changes.

In order to use RSSfeeds you will need to install:

$ sudo easy_install PyRSS2Gen

You will also need to configure the following; there are no defaults:

As an example, a complete RSS Feed configuration is:

[rssfeeds]
rssdir=/srv/www/site.orchard.ox.ac.uk/htdocs/rssfeeds
rss_link_template=https://site.orchard.ox.ac.uk/packages/%(name)s
guid_link_template=https://site.orchard.ox.ac.uk/packages/%(name)s/%(version)s
catalog_link_template=https://site.orchard.ox.ac.uk/catalogs/%(catalog)s
description_template='Software packages in Orchard %(catalog)s catalog'
icon_url_template=https://site.orchard.ox.ac.uk/munki/%(icon_path)s

The Munki catalog sections [munki_catalog_<name>]

The Munki catalog sections contain information about different Munki catalogs and their related Trello lists. This information includes any configuration of autostaging, and the setting of due dates.

The name in the section title is not used, but it is suggested that this follow the name of the Munki catalog, as this will aid readability of the configuration file.

The full options are:

Note that the stage_days parameter can be overridden in individual pkgsinfo files on a per-package basis; see the section on autostaging for more details.

The Munki repository sections [munki_catalog_<name>]

These sections document the Munki repository or repositories that packages live in. You will require at least one repository. However, you can have as may repositories as you would like; an use case for this is to have a 'main' repository and a 'retired' repository, and migrate older versions of packages into the 'retired' repository, which could be on slower storage.

There is one required parameter:

Auto stating schedule sections ([schedule]) and/or [schedule_<name>])

These sections allows you to control when autostaging happens.

NOTE You need to install dateutil in order to use this; if you do not install this python module, the schedule section will be ignored.

Clearly, if you have not configured autostaging, then these sections will have no effect.

If autostaging is configured, by default, staging will happen every time the script is run, if packages meet the criteria to be staged.

If you add the optional section [schedule], then autostaging will only happen if the script is running in one of the periods defined.

If you add the optional section [schedule_<name>], then autostaging for the catalog `<name> will only happen if the script is running in one of the periods defined in this section.

Note: if you define both [schedule] and [schedule_<name>], the global section takes precedence: staging will only happen if you are in a period defined in both the global section [schedule] and the catalog section [schedule_<name>].

The optional parameters have the format:

where <Day of the week> is the long name of the day of the week in the current locale and time periods are start time-end time where each time is specified by HH:MM. For example, to only stage on Monday to Thursday between 09:00 and 17:00 you have the section:

[schedule]
Monday=09:00-17:00
Tuesday=09:00-17:00
Wednesday=09:00-17:00
Thursday=09:00-17:00

Note: specifying an empty section will turn off staging.

Configuration file processing

As we mentioned in the section introduction, munki-staging will attempt to read the configuration files in the following order: 0. /etc/munki-staging/munki-staging.cfg 0. ./munki-staging.cfg 0. the configuration file give on the command line

Files not present, or not readable will be ignored and no error will be given in these cases. If a file is present and readable it will be processed, with later configuration adding to (in the case of a [section]) or replacing (in the case of a setting=value) earlier ones.

As an example of configuration file processing, imagine we have the configuration file in /etc/munki-staging/munki-staging.cfg and no other configuration files. The file /etc/munki-staging/munki-staging.cfg contains the line:

[example_section]
value_one=1
value_two=2

munki-staging would then run with the configuration:

    example_section.value_one   = 1
    example_section.value_two   = 1

If the two configuration files /etc/munki-staging/munki-staging.cfg and ./munki-staging.cfg were present and readable with /etc/munki-staging/munki-staging.cfg as above and ./munki-staging.cfg containing:

[example_section]
value_three=3
value_four=4

munki-staging would then run with the configuration:

    example_section.value_one   = 1
    example_section.value_two   = 2
    example_section.value_three = 3
    example_section.value_four  = 4

Finally, if there was a configuration file on the command line, say --config extra.cfg, with the two other files present as above and extra.cfg containing:

[example_section]
value_one=100

munki-staging would then run with the configuration:

    example_section.value_one   = 100
    example_section.value_two   = 2
    example_section.value_three = 3
    example_section.value_four  = 4

Autostaging

As described above, you can turn on autostaging on a per-trello list basis. A package will auto stage if all of the following are true:

Thus if you have 3 catalogs:

then in order to stage packages into production you need to turn on auto staging for testing. In order to stage packages into testing, you need to turn on autostaging for development.

Staging Speed

If you use autostaging, you will need to set the number of days in which a package get staged. This is set on the Munki catalog using the stage_days setting for all packages in a catalog. However, there may be some packages that you wish to stage faster than the default (e.g. a security release).

For this reason, there is a feature to allow you to change the staging days on a per-package basis. To do this you will need to edit the pkgsinfo file for the package, adding a munki_staging key which has a dictionary value. Within this dictionary you can set a stage_days parameter which overrides the default number of days.

For example, to stage a package with 1 days worth of testing you would add the following to the pkginfo file:

       <key>munki_staging</key>
       <dict>
               <key>stage_days</key>
               <string>1</string>
       </dict>

This would then override the setting for the catalog, if autostaging is enabled.

In order to help with this, there is a python script that you can use to set the number of staging days for a package; this script munkistaging-pkgsinfo.py in the bin directory can be run as below to set the staging days or to remove this key from the plist file. For example, to set the staging days to be 1 day (as in the above pkgsinfo file) you would run:

$ python bin/munkistaging-pkgsinfo.py --stagedays 1 /path/to/pkgsinfo/file

To remove this (note that setting stagedays to 0 means that the package will staged at the next run), you would run:

$ python bin/munkistaging-pkgsinfo.py --removestagedays /path/to/pkgsinfo/file

The full usage is:

$ munkistaging-pkgsinfo.py [--stagedays <n>] [--removestagedays] <pkgsinfo_file>+

where

If run without an argument will report on the number of staging days that are configured within each of the pkgsinfo files listed.

NB The munki staging configuration file is not read by this helper file.

Troubleshooting

I'm seeing items that won't move to the next stage no matter how often I move them.

Make sure the combination of name and version is unique. For speed, the initial ingest of Munki data is done via your all catalog rather than traversing your pkgsinfo files. If you have two pkgsinfo files that have the same version / name combination as anther, this script won't touch anything after the first. Once the duplicate(s) have been removed, the item will be promoted to the next stage.

Copyright

Copyright (c) 2015 University of Oxford

This is based on an original script by Graham Gilbert graham@grahamgilbert.com with significant rewriting by the Unix Services Team within IT Services, University of Oxford.