Documentation made easier

MUNIN-GET

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−node/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 <devel@sumpfralle.de>

License

GPLv3+