Hello Laurence, thank you for sharing your thoughts!
On Tue, 7 Jan 2020 08:54:23 +0000 Laurence Parry <greenrea...@gmail.com> wrote: > [..] > The [df*] section in the plugins.conf file (aka plugins-conf/munin-node) > could contain a comment regarding this situation. That's the first place I > went to look, to see if it was being excluded. good point! I will add such a comment, if we stick to the current default for "ProtectHome". > (The README.Debian file is *not* in /etc/munin - nor apparently referenced by > it or the manual. There is an /etc/munin/plugin-conf/README but it does not > reference /usr/share/doc/munin-node (not even to mention the > README.PluginConfiguration that is there.) I added a comment there, now. > It would also be good to give the actual specific contents to type after > `systemctl edit munin-node`, i.e. > [Service] > ProtectHome=read-only I will add this, if we stick to the current setting. > But really, these are workarounds. Having a separate disk as /home is a > standard configuration offered by the Debian installer and so I think the > default install of munin-node should support monitoring it. Perhaps it > could detect the situation on install and offer you the option to apply the > above override to address this particular issue? I will definitely add a debconf question for this setting. Today we dicussed the issue again during our weekly IRC meeting: http://meetbot.debian.net/munin/2020/munin.2020-01-08-19.32.log.html Some voices were raised for the "read-only" approach suggested above. I am split between privacy and security, but leaning slightly towards "read-only", too. Anyway: a debconf question would certainly turn the current annoyance of a silent configuration change into an informed decision. We just need to decide which default we pick. Maybe we could use the result of 'mount | grep -q "\s/home"' as the default? (I am not sure, whether I really like this dynamic behaviour) Cheers, Lars
