Description of problem: I selected a Cacti graph and clicked on the icon on the right (of the graph) to remove spikes. I selected 'Dry Run StdDev' Cacti showed a popup that the account did not have write access to the RRA file. Version-Release number of selected component (if applicable): cacti-1.1.7-1.el7.noarch (updated this morning from 1.1.6 via EPEL testing repository) How reproducible: Easy to reproduce for any graph showing the remove spikes icon. Occurs every time. Steps to Reproduce: 1. Follow the steps described above. 2. 3. Actual results: Cacti shows a popup that the account does not have write access to the RRA file. Expected results: The 'removespikes' program should show a window that lists the relevant RRA data. It will also mention that this is a dry run. Additional info: I have already sent a pull request to the Cacti developers modifying the removespikes.php to state what account doesn't have access. It is 'apache'. SELinux also throws an AVC denial, and audit2allow indicates that setting the 'httpd_unified' boolean should avoid the problem. I'll report the AVC to RedHat bugzilla under a different bug number. (Setting the boolean avoids the AVC, but Cacti still shows the same popup.) I ran the following commands and found that it resolved the problem: chmod 775 /var/lib/cacti/rra chgrp apache /var/lib/cacti/rra (so /var/lib/cacti/rra is now owned by 'cacti:apache') find /var/lib/cacti/rra -type f -exec chmod 664 {} \; find /var/lib/cacti/rra -type f -exec chgrp apache {} \; I then repeated the above sequence of commands for the '/var/lib/cacti/rra/archive' directory. On our old Cacti 0.8.8b server there was also a '/var/lib/cacti/rra/backup' directory. This too may need changing (it doesn't exist on our 1.1.7 server).
Does it also affect cacti-1.1.6-2.el7.noarch or only the latest cacti-1.1.7-1.el7.noarch package? Is this your upstream pull request? https://github.com/Cacti/cacti/pull/729 Maybe we can backport it downstream. But I think we should wait for upstream.
Yes, it will affect the 1.1.6 version too. Yes, that is my pull request. I'll take a look at cigamits comments and modify the code accordingly. The pull request itself though just modifies the error message (from Cacti) to include the userid. It does nothing in itself to resolve the problem.
Okay, but this should be fixed by upstream. Fedora and Fedora-EPEL is close to upstream.
(Sorry, didn't realise that this was still open.) Just checked with cacti version 1.1.38, and the problem still exists. Cacti is installed by yum/dnf, and looking at the RPM SPEC file I would say that this is a packaging issue and not an upstream one. The SPEC file shows: ========= %{__install} -d -m 0755 rra/ %{buildroot}/%{_localstatedir}/lib/%{name}/rra/ ... %attr(-,cacti,root) %{_localstatedir}/lib/%{name}/rra/ ========= The first line should surely set the mode as 775, and the second line set the ownership as 'cacti,apache'? (Similar to the 'log' directory entries.)
(In reply to John Horne from comment #4) > The first line should surely set the mode as 775, and the second line set > the ownership as 'cacti,apache'? (Similar to the 'log' directory entries.) Does it work for you if you change the ownership to cacti:apache? # chown -R cacti:apache /var/lib/cacti/rra If yes, I will change %attr(-,cacti,root) %{_localstatedir}/lib/%{name}/rra/ to %attr(-,cacti,apache) %{_localstatedir}/lib/%{name}/rra/ in the spec file.
No, it did not work (as you need the permissions changed too). Looking into this further, it seems I got it working by changing things on specific rrd files. However, what is wanted is for this to all be taken care of during installation, and whenever anyone creates new graphs or deletes old ones. The '/var/lib/cacti/rra' directory needs access by both the cacti and apache users. So I ran 'chown cacti:apache /var/lib/cacti/rra'. However, files within the directory also need to be modifiable/deleted by the apache user. So I ran 'chmod 2775 /var/lib/cacti/rra'. This sets the setgid bit, and new files then pick up the ownership of 'cacti:apache'. However, the files still have permissions of 644. They need to be writeable/deletable by both cacti and apache. So I ran 'setfacl -d -m g::rwx rra'. Now if I manually create a file within the 'rra' directory it has permissions 664 and ownership 'cacti:apache'. However, for some reason if I get cacti to create a new graph, the ownership is correct, but the permissions are still 644. Since apache does not have write access to the rrd file, we again cannot remove the spikes from the graph. I am now stumped with this. I can of course modify all the existing rrd files ownership and permissions to get things working, but this would have to be repeated every time a new graph is created.
cacti-1.1.38-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f08103496d
cacti-1.1.38-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f08103496d
(In reply to Fedora Update System from comment #8) > cacti-1.1.38-3.el7 has been pushed to the Fedora EPEL 7 testing repository. > If problems still persist, please make note of it in this bug report. Sorry, but I think 1.1.38-3 made things worse. By changing /var/lib/cacti/rra ownership to apache:apache, it means that the 'cacti' user cannot create new graphs. (I tested this - no new graph created (no error anywhere either). When changed back to cacti:apache the graph was immediately created.) If I can I'll take a further look at comment 6, and why the new graphs are created by cacti itself with mode 644, as this seems to be the last stumbling block.
(In reply to John Horne from comment #9) > (In reply to Fedora Update System from comment #8) > > cacti-1.1.38-3.el7 has been pushed to the Fedora EPEL 7 testing repository. > > If problems still persist, please make note of it in this bug report. > > Sorry, but I think 1.1.38-3 made things worse. By changing > /var/lib/cacti/rra ownership to apache:apache, it means that the 'cacti' > user cannot create new graphs. (I tested this - no new graph created (no > error anywhere either). When changed back to cacti:apache the graph was > immediately created.) > > If I can I'll take a further look at comment 6, and why the new graphs are > created by cacti itself with mode 644, as this seems to be the last > stumbling block. Please note: With the latest cacti update we don't need the cacti user. It's intended to run the poller as apache user. Please check your /etc/cron.d/cacti settings. It should be: */5 * * * * apache /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1 I have tested this change in different environments and it works as expected. No problem to create new rra graphs.
You are correct. My test setup was at fault. I have retested with 1.1.38-3, and it works as expected. I had no problem creating new graphs, and removing spikes worked too.
cacti-1.1.38-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.