Tom Feiner <[email protected]> writes:
> Thanks for the quick reply. I'd be happy to write the patch either in
> the postinst or munin-node-configure.
A patch would be welcome.
> I'll have a look at munin-node-configure from the 1.3 trunk to see how
> much it has changed to see if it's sensible to try and backport
> it. (if not we can always do it in the postinst).
I'd say postinst would be the place for a nice quick-n-dirty hack. :)
Most of the things in trunk (but not necessarily yet in branches/1.3)
has been completely rewritten using a Munin perl module hierarchy. The
plugin autoconfiguration methods have also changed to the better, where
these problems should not occur. There seems to be a lot of activity on
munin now that people are back from their summer vacations. :)
In the munin-node postinst, we should be able to ignore the exit status
of munin-node-configure, and check the lines in the output file, and
send all lines with "^ln foo bar" to the shell. That's a quick and
dirty hack. Not pretty, but I think it'll bypass the problem, which is
that configuration in postinst stops if munin-node-configure exits
non-zero.
> You mention that we should log the errors from plugins that fail their
> autoconf. Where should this be logged into? Currently the postinst
> simply echo's the errors to STDOUT.
I'm not sure. I like having logs, and I like having them at predictable
locations.
I certainly don't want to clutter the dpkg output with it, it'll
probably just be ignored on upgrade.
Munin and munin-node creates a /var/log/munin directory, perhaps
creating /var/log/munin/munin-node-configure.log is a good idea, and
send STDOUT and STDERR there? That would be a place I'd look for logs,
if something went wrong.
--
Stig Sandbeck Mathisen
ooo, shiny!
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
