MUNIN-GET(1p) User Contributed Perl Documentation MUNIN-GET(1p) 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 License GPLv3+ perl v5.38.2 2024-05-20 MUNIN-GET(1p)