Inode Ltd

Creating icons for Nagios

By default, the statusmap of Nagios does not include any useful icons for your equipment. There are some icon collections on http://www.monitoringexchange.org/, and a handy set can be installed with the nagios-images package.

However, there will come a time when you want your own customised icons, and information on how to produce them is hard to come by. The status map is assembled as nagios starts with the GD library, and therefore the recommended format for icons is .gd2, but strictly speaking that’s an intermediate format and most tools don’t give you any options to create them.

Start by creating an SVG files in Inkscape. Make the icon around 40×40 pixels; this small size won’t matter at all while editing in Inkscape, as vectors scale very well! Avoid using black — the next steps in the toolchain will treat black as transparent. Instead use a blackish colour, such as #010101.

Just before saving the file, go to “Document Properties” and set the page size to fit the selected icon.

When the SVG file is ready, save it. We’re finished with Inkscape now, and now we drop to the command-line to use rsvg-convert from the librsvg2-bin package. By default this will create a PNG file, which we can use as the Nagios icon_image. Then we use netpbm tools to grab the transparent part of the PNG, and write out a GD2 image

$ rsvg-convert example.svg > example.png
$ pngtopnm example.png | pnmtopng -transparent =rgb:00/00/00 2>/dev/null | pngtogd2 /proc/self/fd/0 example.gd2 0 1

The pngtogd2 command comes from libgd-tools, and is slightly annoying in that it won’t take STDIN … so we fake it using /proc/self/fd/0. The “0 1″ parameters set the chunk size and format, and are cargo-culted from the web and Nagios documentation. The black areas in the PNG are marked in GD2 as being transparent.

So now you can create nice Nagios icons easily. I’ll be publishing a set of basic icons and their source SVG files on code.inode.co.nz soon.

Posted in Technology | No Comments »

Organising Nagios config files

Nagios is great, but I still get annoyed with the standard configuration setup. Hosts, Hostgroups, Services … whenever you add a new host, there are a lot of places to touch to get it configured properly.

Most customers think of their network in terms of “hosts” — they add a physical host, they run services on that host, they want to monitor that host. So how can we reduce the amount of config work to be done?

I’ve started to play with a scheme I’m calling ‘capabilities’. A capability is a combination of a hostgroup and a service definition, both with the same name. Here’s the “ssh” capability :-

### SSH {{{
define hostgroup{
    hostgroup_name      ssh
    alias               Hosts with ssh on TCP:22
}
define service{
    hostgroup_name      ssh
    service_description ssh
    check_command       check_ssh
    use                 service.template
}
# }}} ssh

All I have to do in order to have checks against this capability is to add the host to the hostgroup ’ssh’, and I can do this directly from the host object itself …

define host{
    host_name       benjamin
    alias           Mail Server
    address         10.11.12.13
    use             host.template
    hostgroups      ssh,smtp
}

No messing around with specifying this host anywhere else, all the references it needs in order to exist are in one file, and so are the complete set of references to the service checks that will be performed.

Now admittedly, this does add extra hostgroups to the CGI interface, and if you are using that on a regular basis you may not appreciate the extra clutter. However, for the sorts of thing I’m doing, it’s more important to be able to quickly and accurately describe a host & associated checks.

Posted in Technology | No Comments »

The hacker emblem

One small piece of HTML and one small piece of CSS.

<pre class="hacker"> .<br/>..:</pre>

pre.hacker {
     letter-spacing: -2px;
     line-height: 6px;
     font-size: 10px;
     text-align: center;
}

Job done.

 .
..:

Posted in Technology | No Comments »

userpkg — installing users from packages

If you’re looking after handfuls of computers belonging to armfuls of different companies, you end up going through hoops trying to get your own user(s) installed each time you want access to a new machine.

userpkg aims to make this simpler, by using Debian package management.

Once userpkg is installed on a machine, you can introduce your new admin users as packages. userpkg will take care of choosing an available username, generating a new password, installing ssh keys and setting up sudo rights.

If you have set up your own private repository, you can now automatically upgrade ssh keys across the population of customer machines …

The initial public release of userpkg can be found at http://userpkg.inode.co.nz/. It’s feature-limited at this stage, but will grow; faster if people suggest things to me!

Posted in News, Technology | No Comments »

When is a bash script too big?

I quite like writing shell scripts, I’ve been doing it for years and often when I start to address an automation question I naturally start to think in terms of “automating the command-lines”.

However, some problems very rapidly run out of bash’s ability (or often, out of its readability). Bash and the associated tools I often use (grep, cut, sed, awk, sort and so on) are very line-oriented; it’s difficult to get them to make decisions based on any part of the input except the current line and any summary history you’re building up.

So, one reason to switch to a different language is where you need to grok a whole set of structured files in one go. For this I often go to perl, and read files directly into a hash of hashes (of hashes of …). Then I can walk through that structure in any order, rather than having to touch the input files again. It may eat memory, but these are only scripts we’re talking about, not programs.

Another reason to switch is less obvious, but as soon as you try to make your bash script look like it’s written in some “proper” functional language, you’re into a losing battle. For me, this generally happens around the 250+ lines mark; if the script is that long, it’s going to have a lot of structure. Bash can do functions, but it’s difficult trying to make variables act like they’re scoping properly, and as for passing parameters that might end up being executed … well, that becomes painful. You have to construct the original calling parameters with levels of quoting that explicitly need to know how much dereferencing they’re going to encounter.

An example; I have a script here that makes a lot of changes to important files, so I thought it would be a good idea to be able to log each command invocation. So in the main code, instead of saying “rm file“, I’d say “log-cmd rm file“. The log-cmd function could keep track of verboseness … and the associated debugmsg function would only produce output if a debug setting were true, too …

debugmsg() {
    if $DEBUG
    then printf -- "$*\n" >&2
    fi
}

log-cmd() {
    if $VERBOSE
    then
        printf "log-cmd executing $*\n" >&2
    fi
    if $NOEXEC
    then
        debugmsg "Execution of '$*' blocked by no-exec flag -n"
    else
        debugmsg "$($*)"
    fi
}

All that looks pretty reasonable, and indeed it works just fine with a simple invocation such as log-cmd ls -l … but when you start to want to redirect that output somewhere you’re fighting hard against bash …

log-cmd ls -l > outputfile creates outputfile OK … but it’s empty, because the redirection was interpreted by bash as being separate to the call to log-cmd. And log-cmd doesn’t return any data …

log-cmd "ls -l > output" just breaks hard, with ls complaining that there’s no file called “>” … because bash is now not helping to interpret the command-line.

At this point, stop trying to fight against bash, go and grab perl, python or perhaps ruby, and do the job properly! Because if you want this sort of feature, you probably need others … and while bash is capable of getting the job done, there are far too many mistakes to be made on the way.

Posted in Technology | No Comments »