www-misc/monitorix/monitorix-3.5.1.ebuild pkg_postinst set the owner of /var/lib/${PN}/imgs to the fixed user monitorix:monitorix . Due to the USE flag httpd and that monitorix can be used with apache or lighthttpd maybe can be useful to have an apache and lighthttpd USE flag that set the owner of /var/lib/${PN}/imgs to apache or lighthttpd user. What do you think ? Reproducible: Always
(In reply to marco from comment #0) > www-misc/monitorix/monitorix-3.5.1.ebuild > > pkg_postinst set the owner of /var/lib/${PN}/imgs to the fixed user > monitorix:monitorix . > > Due to the USE flag httpd and that monitorix can be used with apache or > lighthttpd maybe can be useful to have an apache and lighthttpd USE flag > that set the owner of /var/lib/${PN}/imgs to apache or lighthttpd user. > > What do you think ? Sounds like a bad idea if you're going to need USE flags for every last virtual/hpptd. It would be better to use something like webapp.eclass in the first place, or just leave it as is and trust that the user will make the necessary local changes.
Ok but monitorix is not a pure webapp cause it is a daemon that collects data and it has only a cgi to display the graphs. Let the users apply the local changes is not a good solution cause for every update you must modify the /var/lib/monitorix/imgs directory .
Created attachment 387298 [details] Shabang fix Relative to this bug https://bugs.gentoo.org/show_bug.cgi?id=524966
Created attachment 387300 [details] Entry in /etc/conf.d/
Created attachment 387302 [details] Ebuild
Hi , i propose these changes in monitorix to fix this bug and https://bugs.gentoo.org/show_bug.cgi?id=524966 . - The new ebuild add the installation of an /etc/conf.d/monitorix and some output with elog. - The new init script add a ceckpath that fix the permissions of /var/lib/monitorix/imgs according to the entry in the /etc/conf.d/monitorix . With this conf the ownership of /var/lib/monitorix/imgs is monitorix:monitorix but it is editable by the user if is using apache , lighthttpd or others webservers.
This issue should be fixed on version 3.8.1-r1 and higher. Instead of adding more configuration items I've decided to just prompt the warning via elog message. Upon the user's chown command, I've seen that several reinstallations or upgrades or the package doesn't overwrite that chown, so this should fix the issue without the need of adding more files to the package.