[1.2.0 Beta 4] Spike Kill not working / missing file

[RadekHvizdos]

Installed fresh 1.2.0 Beta 4 on Debian Buster from Debian repository, Spike Kill functionality is not working. Clicking on dry run generates an error message:

The issue is maybe related to incorrect paths:

root@buster:/usr/share/cacti/site# ls -la /usr/share/cacti/site/cli/removespikes.php
ls: cannot access '/usr/share/cacti/site/cli/removespikes.php': No such file or directory
root@buster:/usr/share/cacti/site# ls -la /usr/share/cacti/site/cli
ls: cannot access '/usr/share/cacti/site/cli': No such file or directory

But even after I created some symlinks, I can't get this functionality to work:

testing /usr/share/cacti/site/spikekill.php

root@buster:/usr/share/cacti/site# ls -la cli removespikes.php
lrwxrwxrwx 1 root root  1 Dec 16 15:52 cli -> .
lrwxrwxrwx 1 root root 13 Dec 16 15:55 removespikes.php -> spikekill.php

testing /usr/share/cacti/cli/removespikes.php

root@buster:/usr/share/cacti/site# ls -la cli
lrwxrwxrwx 1 root root 6 Dec 18 21:17 cli -> ../cli

I am not sure how this functionality is supposed to work, or if this is a bug in the Debian package. Please let me know if I should raise this up with them.

[cigamit]

That appears to be a packaging bug. Please open a bug on debian.org

[RadekHvizdos]

Reported to debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916814

[netniV]

I think that would normally be one for @paulgevers but from what I can see, it looks like a symbolic link is being created in place of the actual file.

[netniV]

OK, so I just downloaded the experimental package from http://ftp.us.debian.org/debian/pool/main/c/cacti/cacti_1.2.0~beta4+ds1-1_all.deb and listed it's contents:

-rwxr-xr-x root/root     43771 2018-12-02 19:51 ./usr/share/cacti/cli/removespikes.php
-rw-r--r-- root/root      4081 2018-11-28 00:26 ./usr/share/cacti/site/spikekill.php

Since we already know that cacti/cli is a symlink to the directory called cli in the same folder as cacti's folder, then we know that cacti/cli/removespikes.php exists. This makes me wonder if it's an SELinux or apache configuration issue with attempting to run a CLI script directly from Apache itself.

[cigamit]

Definitely a packaging issue be it SeLinux or the presence of the file.

[paulgevers]

There is no link from /usr/share/cacti/site/cli to /usr/share/cacti/cli as that would defeat the purpose of separating cli from site. In Debian we package the cli in a directory that is not reachable by the http daemon as a security measure (I think, this is from before I became involved in maintaining Cacti in Debian). If the cli scripts are now called from the site scripts, in my very humble opinion, it shouldn't be in the cli directory.

Unless in the current view of the Cacti Maintainers, there is no destinction between cli and the other directories. If that is the case, I'll just have to remove the split between cli and the rest.

[netniV]

Thanks for the input Paul. Leave this with us to discuss and we will come back to you.

[netniV]

@paulgevers @jayslovak

This appears to be a long standing bug caused by the moving of the CLI directory to a different location for security purposes. For the most part, this is purely a packaging issue that produces the following (and has ever since the split was introduced long ago):

• Spike killing when triggered via the GUI will fail
• Installer will fail to convert tables or import packages
• Plugins will fail to add graphs (hmib/microtik)

This is a Debian/Ubuntu specific issue so I don't think we should hold up the release purely for this but we should be able to address it in the future by converting various functions to become API's rather than CLI's.

However, any third party plugins which rely on the CLI's to perform actions for them, will continue to fail unless identified and a corrective course of action decided.

If you have any thoughts on this, let me know.

[RadekHvizdos]

I have also experienced issues with the upgrade script, which is probably related to this issue.

My only suggestion is to undo the separation of cli and site in debian until this can be addressed by implementing proper APIs as @netniV has suggested.

[paulgevers]

@jayslovak please note that Debian has been splitting this since as far back as 2009. (Debian bug 483556). As such, I'll not just blindly abandoning that.

[netniV]

Hi @paulgevers,

Each of the shell scripts has a check to ensure they are not accessible directly from the web but can be run through the software. Therefore, to me , the alleged risk is no different whether the folder is up a level or not since the site should be able to run them.

In fact, that change has probably broken cacti in Debian for a long while but has not been noticed (unless the package has been manually patching each exec)

[netniV]

I think part of the reason this would not have been noticed is because the installation package actually runs the template package imports, not the web-based installer. Additionally, the places that use the exec() function to run a CLI script would be infrequently called on most systems.

[cigamit]

We can convert removespikes.php to a class. It had not been done in the past as this tool also works outside of Cacti. I guess one of the blessings of GitHub, is that if someone still wants an old non-class based version, they can always go back and get one.

[cigamit]

This has been resolved here: #2241