1
munin (1.4.0-1) unstable; urgency=low
3
Move htmldir to /var/cache/munin/www. Note that we currently don't
4
have a proper upgrade mechanism in place. When upgrading from a
5
previous version of munin, you'll need to change /etc/munin/munin.conf
6
htmldir parameter, from /var/www/munin, to /var/cache/munin/www.
8
A new binary package: munin-java-plugins was added. This package contains
9
a java jmx (Java Management Extensions) plugin.
11
A new binary package: munin-common, was added. It contains code shared by
12
munin and munin-node. munin, munin-node packages now both depend on
15
munin-node-configure-snmp command is no longer available, use
16
munin-node-configure --snmp to configure snmp hosts.
18
If upgrading from 1.2.6, please review the
19
/usr/share/doc/munin/UPGRADING file as there is an issue with truncated
20
field names in plugins (especially with the df plugin), resulting
21
in loss of history, which can be fixed manually.
23
munin.conf has a "includedir" directive now, to include config file
26
-- Tom Feiner <feiner.tom@gmail.com> Fri, 04 Dec 2009 18:29:16 +0200
28
munin (1.2.6-2) unstable; urgency=low
30
* Build the binary package 'munin-plugins-extra' with user contributed
31
plugins (again) by default. Though previously this package was called
32
'munin-plugins-contrib'. It was renamed to avoid confusion about the term
33
'contrib' which is used in Debian with a different meaning.
35
-- Matthias Schmitz <matthias@sigxcpu.org> Tue, 01 Jul 2008 19:06:20 +0200
37
munin (1.2.5-1) unstable; urgency=low
39
* Thanks to Marc Haber the Debian build scripts are now able to build a
40
custom package called "munin-plugins-contrib", which will contain some
41
user-contributed plugins that aren't included in the "munin-node" package.
43
To enable the build of this package, the environment variable
44
DEB_BUILD_OPTIONS must contain the string "munin:build-contrib-pkg".
45
The following commands ought to do the trick for most users:
47
export DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS munin:build-contrib-pkg"
48
apt-get build-dep munin
49
apt-get --build source munin
50
dpkg --install munin-plugins-contrib_*_all.deb
52
It is not included in the Debian distribution. Bugs should therefore be
53
reported to the upstream bug tracker at <http://munin.projects.linpro.no/>.
55
-- Tore Anderson <tore@debian.org> Tue, 17 Oct 2006 14:39:05 +0200
57
munin (1.2.2-1) unstable; urgency=low
59
* The "contrib" plugins are not supported from upstream, and have therefore
60
been removed from the package. They have not been through a thorough QA
61
review, and could therefore contain security holes or simply not work as
64
The removed plugins are:
66
amavis apc_envunit_ apc_nis bind9 bind9_rndc courier_ dhcpd3
67
exim_mailqueue_alt files_ foldingathome foldingathome_rank
68
foldingathome_wu hddtemp2 hddtempd hddtemp i2c_fan i2c iostat_ios ipac-ng
69
mailman mailscanner mbmon_ mhttping named netopia nut_misc nut_volts
70
perdition pm3users_ pop_stats samba spamstats surfboard users
72
Most of these who turn out to be well-written and of general interest, will
73
likely make their way back into the package as auto or manual at a later
74
release. If you have been using any of these, you should consider aborting
75
the upgrade, and copy the plugins you use from /usr/share/munin/plugins/ to
76
/etc/munin/plugins/ (overwriting the symlink). That way, they will not be
77
touched during the upgrade.
79
You may also download them from <http://munin.sourceforge.net/>.
81
-- Tore Anderson <tore@debian.org> Sun, 13 Mar 2005 00:28:49 +0100
83
munin (1.2.0-1) unstable; urgency=low
85
* There are two major bugfixes in the 1.2.x series of Munin since 1.0.x that
86
could not be accomplished without introducing a risk of losing historical
87
data after upgrades. Or more precisely: no data will be lost, but the
88
exact name of the RRD file will change, so that the update process will
89
start collecting data into a new, emtpy, file, which in turn will be read
90
by munin-graph, and the final result is that the graph will appear to have
91
lost all data. The historical data will still be present in the old graph.
93
In the last two sections of this file I will attempt to detail how you can
94
minimize the data loss by carefully planning how to perform the upgrade.
96
* The infrastructure for sending warnings if values drop below or rise above
97
preset boundaries has been redesigned to improve flexibility, and are no
98
longer specific to NSCA/Nagios. The old nsca_* settings are still
99
recognized, and are automatically mapped into a contact with the name
100
"old-nagios". Hence the now deprecated munin.conf entries
103
nsca_server sloth.fud.no
104
nsca_config /etc/nsca.cf
106
would implicitly be converted to the entry
108
contact.old-nagios.command /bin/nsca sloth.fud.no -c /etc/nsca.cf -to 60
110
unless the latter was explicitly defined in /etc/munin/munin.conf, in which
111
case the deprecated entries would be ignored.
116
A number of plugins which in the 1.0.x series used the COUNTER data type
117
has now been changed to use the DERIVE type, with a minimum of 0. The
118
reason is to hinder RRDtool from misdetecting counter wraps when a service
119
or machine is restarted, which resulted in abnormal spikes in those graphs.
121
The munin-update component from the 1.2.x series are able to recognize that
122
a plugin has changed thusly, and will automatically copy all the historic
123
data from the old RRD file into the new one, ensuring a smooth transition.
124
However, the munin-update component from the 1.0.x series are not aware of
125
this, and will react to this data type change by starting to collect data
126
into a new, empty, RRD file.
128
The method to ensure a painless upgrade is simple:
130
Ensure that you upgrade the "munin" package BEFORE you upgrade the
131
==================================================================
132
"munin-node" package on any of the hosts it collects data from.
133
===============================================================
135
Should you however have already upgraded the packages in the wrong order,
136
you may salvage your graphs by manually change the data type in the old
137
RRD file, and afterwards rename it. For instance, you may have this RRD
138
file containing the "user" field from the "cpu" plugin of munin-node 1.0.x:
140
/var/lib/munin/fud.no/lust.fud.no-cpu-user-c.rrd
142
After upgrading to version 1.2.x of munin-node, this will have changed to:
144
/var/lib/munin/fud.no/lust.fud.no-cpu-user-d.rrd
146
If the "munin" package wasn't upgraded before "munin-node" one, you will
147
have both files, and the latter one will only contain the data gathered
148
since the upgrade of the "munin-node" package. In order to make the old
149
data reappear in the graph, you may do so using the following procedure:
151
cd /var/lib/munin/fud.no
152
rrdtool tune lust.fud.no-cpu-user-c.rrd -d 42:DERIVE
153
mv -f lust.fud.no-cpu-user-c.rrd lust.fud.no-cpu-user-d.rrd
155
You will have to repeat this process once for each field in each affected
156
plugin. Also remember to ensure that the "munin" system user have write
157
access to the resulting RRD file when you are finished. Be warned,
158
however, that by doing this you will lose all data collected since
159
munin-node was upgraded to version 1.2.x.
164
The 1.0.x series had rather nasty design flaw that caused field names
165
longer than 18 characters be truncated, removing any excessive characters
166
from the start of the field name. This led to a nasty bug; if a plugin
167
reported values for two fields, who both had long names where the last 18
168
charaters were the same, only one RRD file would be generated, and its
169
contents would be unpredictable. The 1.2.x series do not exhibit this
170
behaviour, and will store the entire field name as part of the RRD file
171
name. As this leads to the fact that a new, empty, file will be created
172
with the non-truncated field name, the graphs will appear to have been
175
To solve this you need to manually figure out which RRD files are affected,
176
and rename them so that they are called what the new version of Munin
177
expects them to. To figure out which files may be affected, you can
181
ls */*.rrd | awk '-F[/-]' '{if(length($4)==18) print}'
183
This will output one line for each file that may be affected, for instance:
185
fud.no/pride.fud.no-df-v_mapper_pride_usr-g.rrd
187
The three first strings separated by hyphens in the filename is the
188
interesting ones. The first is the host as named in /etc/munin/munin.conf,
189
the second is the plugin name, and the third is the possibly mangled field
190
name. I say "possibly", because any RRD files with a field name that is
191
exactly 18 characters long will also be reported, even though they are not
192
affected by the change. To figure out if the file is indeed affected, and
193
what the new name should be, you need to ask the host's Munin-node process.
195
First, you need to figure out the DNS hostname or IP address of the node,
196
unless you already know it. This information can be found in the file
197
/etc/munin/munin.conf, and will for this example look like this:
202
Next, connect to the host's Munin-node process:
204
telnet 127.0.0.1 munin
206
After receiving the welcoming "# munin node at pride.fud.no" banner, input:
210
"df" is of course the plugin name as found embedded in the RRD file name
211
above. You should now get the values reported by the plugin in return:
214
_dev_mapper_pride_usr.value 88
217
The field names are the strings before the periods. At this point the
218
correct field name is obvious - the truncated field name
219
"v_mapper_pride_usr" is the last 18 characters of "_dev_mapper_pride_usr",
220
so the latter must be the correct one. Now that you know that, you can
221
rename the RRD file so that the new version can find it:
223
cd /var/lib/munin/fud.no
224
mv pride.fud.no-df-v_mapper_pride_usr-g.rrd \
225
pride.fud.no-df-_dev_mapper_pride_usr-g.rrd
227
If you find no possible matches, it may be because the RRD file contains
228
data that are no longer collected, which could've happened in this example
229
if the filesystem in /dev/mapper/pride-usr was unmounted in the past.
230
To find out if that is the case, look at the time stamp of the file to
231
see when it was last modified. If that's a long time ago, chances are the
232
file isn't used anyway and can be left alone.
234
If you're really unfortunate, you may end up with multiple possibilities,
235
which could've happened in the example used here if both a device named
236
/udev/mapper/pride-usr and also one named /dev/mapper/pride-usr was mounted
237
simultaneously. If this is the case, you can't do anything but inspect the
238
relevant graph as created with Munin 1.0 to see if the field seems to
239
contain the correct data for at least one of the fields, and rename the RRD
240
accordingly. However, there is a possibility that the RRD will contain
241
useless data that isn't correct for either of the fields. In any case, you
242
won't be able to bring back correct data for both the fields, as it wasn't
243
collected properly to begin with.
245
You will have to repeat the process for every possibly affected RRD file,
246
after which you may safely upgrade your "munin" package.
248
-- Tore Anderson <tore@debian.org> Mon, 21 Feb 2005 00:16:25 +0100
added
removed
debian/munin.NEWS
