Personal Workflow Blog

To content | To menu | To search

Tag - ssh

Entries feed

Monday, 12 July 2010

Waiting for Munin 2.0 - Native SSH transport

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 :

  1. Very simple to manage & install
  2. Optional SSL since 1.4 enabling secure communications
  3. Quite simple firewall rules.

It has also some disadvantages :

  1. A new listening service means a wider exposure
  2. The SSL option might add some administrative overhead (certificates management, ...)
  3. A native protocol isn't always covered by all firewall solutions
  4. Some organisations only authorize a few protocols to simplify audits (ex: only SSH & HTTPS)

Native SSH

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 node still has to be modified to communicate with stdin/stdout instead of a network socket. For now, only pmmn and munin-async are able to provide such a node.


The URL is quite self-explanatory as shown in the example below :


    address ssh:// --params

Installation notes

Authentication should be done without password but via SSH keys. The connection is from munin-user@host-munin to munin-node-user@remote-node.

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 you use --spoolfetch and not --vectorfetch that 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.

Thursday, 26 November 2009

Native SSH transport for Munin

Update: This page is obsolete, since it has been merged in the 2.0 version of Munin. The syntax is a little bit different, but the idea is the same.

I blogged about the munin monitoring system a while ago.

The fact the Munin team did quite a remarkable job in cleaning up the 1.2 code for the 1.4 release enabled me to add a native SSH transport for Munin, and made be able to get rid of all SSH tunnels.

Continue reading...

Friday, 11 September 2009

Sychronize clock between hosts with SSH

NTP is very handy for server clock synchronisation, but it can be cumbersome to deploy.

Sometimes you just need to do a one-shot clock synchronisation, so you use the standard date command. But there isn't a flag to easily copy a setting to another.

From a remote host

Quite easy :

# date `ssh remoteuser@remotehost date +%m%d%H%M%Y.%S`

To a remote host

It's also very easy[1] :

# ssh root@remotehost date `date +%m%d%H%M%Y.%S`


[1] Yes, I do know that logging remotely as root is a security pitfall...

Tuesday, 4 November 2008

A Poor Man's Munin Node to Monitor "Hostile" UNIX Servers

Munin is a nice monitoring system. Simple but quite effective. It's main selling point is the UNIX-esque simplicity of the architecture. You can just create a new plugin in a matter of minutes to monitor whatever you can imagine.

There is even a comprehensive collection of plugins ready to use (admittedly of various quality).

Various platform are supported

Usually the main issue is the MuninNode, an agent (daemon) that runs on the server to be monitored, since it is responsible of translating the request of the munin server (the one with the graphs) to the various plugins, build-ins or external. The ease of installing this agent depends on the OS and the access you have on the server :


For Windows you can install munin-node-win32.

Unix (with root access)

For Unix when you are root, usually there is a package ready to install in your distribution, or from the source.

Others (Hostile servers)

On hostile servers, you don't usually have a root access and no easy acces to a compiler.

I wrote pmmn (Poor Man's Munin Node), a little vanilla Perl script that emulates the core functionality of the real munin-node script, but without having to install many Perl CPAN modules.

It has also a nice functionality : it is possible to communicate via stdin/stdout instead of a TCP port. This way it is very easy to monitor hosts that are behind a firewall without opening (and monitoring) many tunnels.

Installation of pmmn

Suppose you have access to the server via a supervision user (let's say supusr). Installation of pmmn is quite easy : just copy the files somewhere on the disk where you have access, for example (/home/supusr).

TCP installation

Just launch the server with -p 4949 and declare it in the munin.conf file on your munin-server. This solution is quite equivalent to a regular munin-node installation.

Tunnel installation

Same as the TCP, but you have to create a TCP tunnel via SSH to be able to reach the munin-node.

Inetd+SSH installation

It is a mix between port forwarding via inetd and the Tunnel-based previously discussed.

You first have to established a key-based SSH authentication without passphrase (you will not be there to type it) from supusr on the inet server (usually the munin-node one) to the user supusr on the server to be monitored.

For example, to monitor server1 and server2, in the file /etc/inetd.conf, you have to add lines :

7001   stream  tcp     nowait  supusr /usr/bin/ssh -- supusr@server1 /home/suprusr/pmmn/
7002   stream  tcp     nowait  supusr /usr/bin/ssh -- supusr@server2 /home/suprusr/pmmn/

Then, in the munin.conf file of the MuninServer, you just have to declare the new nodes :

    address localhost
    port 7001
    address localhost
    port 7002

The MuninServer will now set up a stdin/stdout SSH tunnel transparently and launch the pmmn server when needed. You are now free to write plugins like if a real munin-node where installed. The only restriction is that y ou don't have a root access, so you are limited in the information you may collect.