Skip to content

README.md

Latest commit

 

History

History
116 lines (85 loc) · 3.87 KB

README.md

File metadata and controls

116 lines (85 loc) · 3.87 KB

Install on Demand

Provides the ability to install software based on the requirements of a user.

Technical Design (google doc)

Operation

GPII Start

  • IoD server is detected using mDNS (or configured server, or local datasource)
  • Package list is taken from the IoD server.
  • Installation information about packages that GPII has installed but not removed, is loaded (if any).
    • These packages are uninstalled.

Key-in

Current implementation is a hack which uses a launch handler to invoke gpii.iod.requirePackage.

The stages of installation:

  • Get the package info from the server.
  • requirePackage finds a suitable gpii.iod.packageInstaller for the type package.
  • Package file is downloaded from the URI in the package info.
  • The installer component installs the package:
    • chocolatey: Windows service is instructed to run choco install.
  • Installation info is stored to disk to survive reboot.
  • Package file is removed.

Key-out

  • If the key-out is due to another user logging in, then wait for the next key-out.
  • The installer component uninstalls the package.
    • chocolatey: Windows service is instructed to run choco uninstall.
  • If successful, installation info file is removed.
  • If failed, the package is uninstalled when GPII starts again.

Parts

gpii.iod

The install on demand component.

gpii.iod.packages

gpii.iod.packageInstaller

Base component of the package installers, which perform the work that's specific to the type of package being installed. Implementations will probably be found in the OS-specific repository.

This performs the initialise->cleanup pipeline.

gpii.iod.packageDataSource

The package data source.

Packages

Packages consist of a packageInfo json file, and the package file. Support can be provided for different types of packages, however chocolatey already does a good job at wrapping other installer types.

/**
 * @typedef {Object} packageInfo
 * @property {string} name - The package name.
 * @property {string} url - The package location (optional, to override the IoD server with an external location).
 * @property {string} filename - The package filename.
 * @property {string} packageType - Type of installer to use.
 * @property {string} hash - The signed hash of the package.
 */
packageInfo = {
    name: "some-package",
    url: "https://iod-server.example.com/some-package",
    filename: "some-package.1.0.0.nupkg",
    packageType: "chocolatey"
};

Multi-lingual packages

Multiple languages can be supported in a single package, like so:

{
    "name": "another-package",
    "url": "https://example.com/default-language",
    "languages": {
        "en-GB": {
            "url": "https://example.com/real-english"
        },
        "es": {
            "url": "https://example.com/general-spanish"
        },
        "es-ES": {
            "url": "https://example.com/spain-spanish"
        },
        "es-MX": {
            "url": "https://example.com/mexican-spanish"
        }
    }
}

When a package is requested, a language may be specified. The package can contain a languages field which contains the language-specific fields for each supported language, which over-write the fields in the root.

In the example above, all languages shall use the root values unless the requested language is British English, in that case the en-GB block is used, or any type of Spanish. Spanish from Spain or Mexico would use the block that specific to those countries (es-ES or es-MX), any other Spanish dialect will use the generic es block.

IoD Server

Using the development config, GPII will provide package data from testData/installOnDemand.

But, if it detects a running instance of the server stegru/gpii-iod somewhere on the network then that will be used instead.