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
master: lazy create PNG in cron

As Christoph Biedl reported :

    In cron mode, munin-graph not only creates graphs for all services but even
    does not take into acount that the bigger scale graphs (week, month, year)
    may be skipped for some time.

    This puts even more load onto the system than cron graphing does anyway. Is
    there a specific reason for that? Especially since the code for freshness
    check is already partially there?

Closes: #1394
Merge branch 'fix-1394' into stable-2.0
Merge branch 'fix-1395' into stable-2.0
ChangeLog: 2.0.19