Hello,
Am Sat, 16 Feb 2019 16:33:53 +0100 schrieb Marc Donges <marc.don...@gmail.com>: > I think to make this less awkward two things would be nice: > > - a option to allow monitoring of /home without editing a non-conffile in > /lib (How is this even done properly? I just edited the service file to > find the cause of my problem, but I suppose it will be overwritten on every > update. Is there a nice way to do this?) By accident I stumbled upon "systemctl edit munin-node". This will open up an empty editor. Here you can add the following: [Service] ProtectHome = read-only This will create a file /etc/systemd/system/munin-node.service.d/override.conf with the above content and in turn override the settings of the system-wide service file. > - a way to alert the admin of the possibly unintended configuration: > df-plugin activated + ProtectHome + Separate /home > Can the df* plugin itself detect the situation and then make a log entry? > That would have severely cut down the time it took me to find this. I took a quick look at it. Here the plugin within the environment simply does not notice that /home is not accessible: it will simply be missing in the output by "df -h". Thus we cannot emit a warning in this case. Or does someone have an idea how to identify such an issue? (and how we should report it) Given that the "ProtectHome" setting allows the "read-only" value, I propose that we should pick this one instead of "yes". I think, we are mainly trying to protect the user from badly written plugins that mess up something with their cleanup procedure and accidentally erase relevant files. "read-only" would prevent this problem. The different problem of munin plugins spying on users on purpose would indeed justify "yes". But I tend to think, that everything is lost anyway, if a user runs random malicious code on his host. What do you think? Cheers, Lars
