munin-get(1p) · carta

Name

munin-get - a simple tool for managing plugins from remote repositories

Features

The small management tool "munin-get" supports the following actions:

clone one or more git repositories containing munin plugins

multiple remote repositories can be used

list all found plugins (including change timestamp and description)

"install" a plugin (by default to: /var/lib/munin/munin-get-plugins)

"enable" a plugin (create a symlink to /etc/munin/plugins/)

upgrade plugins (and review changes before)

The primary purpose of this tool is the simplification of the process of using plugins from munin's contrib repository.

Usage

All actions except "install", "enable" and "disable" can be run as a regular user. Please note that the non-privileged commands use directories relative to $HOME by default (can be overridden). Thus sudo or a similar tool should be used for gaining privileges. Of course, everything can also be done as root.

The separate "install" step works around potential problems with systemd hardening flags or other security policies, which may prevent files in /root/ or below /home/ from being accessed by the "munin-node" service process.

Examples

Discover, inspect, install, enable and test a plugin

    munin-get update
    munin-get list
    munin-get search throughput
    munin-get doc contrib/traffic
    munin-get install contrib/traffic
    munin-get enable contrib/traffic
    munin-run traffic
    service munin-node restart   # for systemd: systemctl restart munin-node

Review and apply changes from the upstream repository

    munin-get update
    munin-get list-upgradeable
    munin-get diff-upgradeable
    munin-get upgrade

Add custom 3rd party git repositories

    munin-get add-repository foo http://example.org/repos/munin-plugins.git
    munin-get add-repository bar http://example.org/repos/munin-stuff.git branch-tested plugins/
    munin-get update

Internals

Repositories are cloned below ~/.cache/munin/munin-get/repositories (see REPOSITORY_CACHE_BASE_DIR).

Manual changes in the cloned repositories should be avoided.

The separate "install" and "enable" procedure is necessary due to possible process namespace / hardening features enabled for "munin-node". Thus the target of the symlink is located in a path that can be expected to be usable even for a restricted "munin-node" process.

Additionally the separate "install" location allows the manual review of upstream changes before applying these locally.

Author

Lars Kruse <[email protected]>

License

  GPLv3+