On Sat, 9 Feb 2019 20:40:56 +0000 nodiscc <nodi...@gmail.com> wrote:
> We had a discussion on IRC on how to best fix this. At first there was an > attempt to use DaemonUser "vnstat" DaemonGroup "vnstat" and removing > User=vnstat from the systemd unit file. But even then you have to systemctl > restart vnstat for it to fix the db file permissions. So also manual. For the 1.x versions, the intent was that using DaemonUser "vnstat" + DaemonGroup "vnstat" and letting vnstatd start as root would fix the issue as the daemon would correct possible file and directory permissions issues by itself before switching to run as the configured user and group. There would anyway need to be another command executed after "vnstat -u -i foo" as the daemon doesn't automatically scan for new databases. The only thing that it does is that it tracks those files that were present during startup and if any gets removed then tracking of that interface is stopped. However, things change a little bit once the Debian package gets updated to include some 2.x version. As a result, there will be only one database file no matter how many interfaces are being tracked. That way, adding new interfaces for tracking even with the wrong user will not result in file permission issues with the database file. The '-u' parameter has been replaced with '--add' in order to remove the previous double role of '-u' / '--update'. This obviously also has the side effect of making some really old instructions for using vnstat partially invalid. > I think a good and simple fix is to install the /var/lib/vnstat/ directory > with sgid bit set. That way any file created there would have correct > permissions. See above. An upgrade to a 2.x version should solve the issue without requiring sgid bit being set among other corrections and improvements as documented in the CHANGES [1] file. [1] https://humdi.net/vnstat/CHANGES -- - Teemu Toivola
