common: add missing keywords

In commit d2f9ce0cc14efd02cbab0ff1c736e0764104d771, a new keyword was
introduced : "global_timeout".

But it can't actually be specified in munin-node.conf.

This commit also adds "timeout" in the master and "spooldir" in the node
common: refactor the keywords to ease changes

Using one keyword per line, ordered alphabetically enables a very easy change
tracability
plugins: fix uninitialized $MUNIN::VERSION

Commit 733f01b1ad48c1e59f0804318a90615429f68e77 introduced a
specific user agent for munin plugins.

But it forgot to import the Munin::Plugin package.

Closes: D:717265
Merge branch 'fix/d/717265-use-uninit-val-const' into stable-2.0

Conflicts:
	plugins/node.d/nginx_request.in
	plugins/node.d/nginx_status.in
2.0.17
Substitute some @@ vars in generate files. Debian: #665688

This is a hacky solution to this problem as it uses a list of files to
substitue the variables in instead of fixing the root cause.
Merge pull request #122 from mattthias/stable-2.0

Substitute some @@ vars in generated files. Fixes Debian Bug #665688
Merge branch 'missing-configuration-keywords' into stable-2.0
plugins/open_files: fix overrided used.warn/crit

As reported by Helmut on IRC:

    < helmut> open_files from munin mainline contains both a "print_warning used"
              and a manual awk .. print used.warning
    < helmut> that can result in used.warning to be printed twice with different
              values
node/asyncd: fix a crash case

The asyncd would die() upon failure to open a new socket to the node when
--fork was not enabled.

This commit just emits a warning, and simply try again for the next plugin.
That way only a plugin fetch will fail, not the whole asyncd process.
node/asynd: avoid wake up each second
master: fix unexpected "warning limit" lines

Quoted from the ticket:

    Data sources specified as a negative value of another field default to a
    warning limit of 2. This results in an unexpected horizontal red line on
    some graphs. Cause is a small error originating from r3143

Thanks tpalfalv for the report and the patch !

Closes #910
master: avoid an endless loop in HTML generation

Safeguard to avoid any bigger loop than 100 nested levels. It protects against
application bugs in the parsing code.

Thx Christoph Biedl (debian.axhn@manchmal.in-ulm.de) for noticing
and for providing a patch

Closes: C:CVE-2013-6048
master: validate multigraph argument

Specially crafted input can lead to munin-html going into
an infinite loop, and OOM the host

Thx Christoph Biedl (debian.axhn@manchmal.in-ulm.de) for noticing
and for providing a patch
master: don't abort node collection on bad plugin

As noted by Christoph Biedl in the ticket :

Using "multigraph" as a multigraph service name is not accepted by
Munin::Master::Node. The check however dies (in config) or croaks (in fetch),
causing in the connection being dropped and no data gathered for that node.

That's a bit harsh, this commit lowers that situation to two error messages.

Note that impact is rather small as this affects the data for that node itself.
A malicious plugin still does harm, but if an evil guy is able to control which
plugins are run on a node, no longer collecting munin data for that one is not
one of the bigger concerns.

[ Thx Christoph for also providing the patch ]

Closes: #1397, C:CVE-2013-6359
p/ipmi_sensor_: fix the environ() usage

As Gabriel Filion reported on d:728840 :

----------------------------------------------------------------------
with version 2.0.6-4 of munin-plugins-extra, I get the following stack
trace when running the ipmi_sensor_ script:

    munin-run ipmi_sensor_u_degrees_c
    Traceback (most recent call last):
      File "/etc/munin/plugins/ipmi_sensor_u_degrees_c", line 73, in <module>
        CACHEDIR = os.environ['MUNIN_PLUGSTATE']
    NameError: name 'os' is not defined

it would seem the script imports different things for the os library
with "from os import xyz" but does not import the library directly. so
near the beginning when it tries to get a variable from then environment,
if crashes.
----------------------------------------------------------------------

Closes: D:728840
Merge branch 'fix-deb728840' into stable-2.0
Merge branch 'fix-sdo4745' into stable-2.0
ChangeLog: 2.0.18
master: fix failures on partial graph_order

As Christoph stated in #1395 :

	There are issues if graph_order does not cover _all_ fields.

	For graphs that include .negative, rrdgraph fails with a message like

	ERROR: Not a valid vname: crxdrop in line
	GPRINT:crxdrop:LAST:%6.2lf%s/\g

	Where rxdrop is the first field that was not mentioned in graph_order.
	This happens with the if_err_ plugin.

	For graphs without .negative, the order of the remaining fields is
	undefined. I'd expect them to be in the order of appearence as it is if
	there is no graph_order at all.

	The patch below always appends the field names in config order to any
	graph_order given. This results in duplicates in the internal state for
	graph_order but munin_get_field_order will eliminate them before graphing.

Closes: #1395