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.
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.
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
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.
Lars Kruse <email@example.com>