In a larger scale implementations of munin, it may be suitable to let a node register itself with the polling server, when the munin-node is installed.
Examples here may be if configuration is distributed with rdist/cfengine to n (n 20..100) servers, that installs the node and bootstraps it's plugins.
A "master-node" -configuration item in /etc/munin/munin-node.conf gives host+port -number towards one of the polling servers.
A shared secret may also be sent along, to be a first defence against unconfigured / rouge clients registering themselves.
- the server needs to listen for the, as of now, unspecified protocol, on given port/ip.
- the server needs to be able to autogenerate a munin.conf file. The munin.conf -configparser should be extended with a "include" -statement, so that auto and manually configuration can be differed more easily. (ie. /etc/munin/munin.conf-selfregistered is included in /etc/munin/munin.conf when the munin collector starts)
the quick and so very dirty solution:
- let /etc/init.d/munin-node do: echo "secret hostname --fqdn" 1>/dev/tcp/masternode.localdomain/60010 when called with 'start' argument. This works on linux, others may vary.
- let inetd on masternode.localdomain spawn of a server at 60010 which generates munin.conf when a new node registers.
Janl notes: this is a good idea. But we'd probably want to add a way to give the admin control of which systems are actually polled before they are ever polled - otherwise this could too easily be mis-used. Perhaps a "add node" commandline or web interface? - or building on this suggestion "approve node" and a checkbox list.
Janl notes: There has been a call for nodes capable of pushing data back to the server instead of being polled. Logical extention of this?