In the munin architecture, the munin-master has to connect to the munin-node via a very simple protocol and plain TCP.
This has several advantages :
- Very simple to manage & install
- Optional SSL since 1.4 enabling secure communications
- Quite simple firewall rules.
It has also some disadvantages :
- A new listening service means a wider exposure
- The SSL option might add some administrative overhead (certificates management, ...)
- A native protocol isn't always covered by all firewall solutions
- Some organisations only authorize a few protocols to simplify audits (ex: only SSH & HTTPS)
Theses down points may be solved by encapsulation over SSH, but it can be a tedious task to maintain if the number of hosts increases.
Therefore 2.0 introduces the concept of a native SSH
transport. Its usage is dead simple : replace the address with an
ssh:// URL-like one.
The URL is quite self-explanatory as shown in the example below :
[old-style-host] address host.example.com [new-style-host] address ssh://email@example.com/path/to/stdio-enabled-node --params
Authentication should be done without password but via SSH keys. The
connection is from
If you use
munin-async, the user on the remote node might only
be a readonly one, since it only needs to read spooled data. This implies that
--spoolfetch and not
updates the spool repository.
Upcoming HTTP(S) transport in 3.0
And the sweetest part is that since all the work has been done for adding another transport, adding a CGI-based HTTP transport one is possible (and therefore done) for 3.0.