Cacti: File paths that accept blanks are not allowing blanks

[tbilan]

Details are from this forum post: https://forums.cacti.net/viewtopic.php?f=21&t=59727

I have a fresh install of 1.2.3 on CentOS 7.

During the install I make it to Critical Binary Locations. It's not accepting a blank "Cacti Log Path". When I hit next to proceed it doesn't and states at the top:
WARNING: One or more paths appear to be incorrect, unable to proceed

Screenshot provided.

When I put the path in it still fails so it's pretty much locked up at this point.

I did a fresh install a few weeks ago of 1.2.2 but didn't run into this issue.

My cacti is installed at /usr/share/cacti

I tried these locations:
/usr/share/cacti
/usr/share/cacti/log
/usr/share/cacti/log/cacti.log

They all failed.

In the /usr/share/cacti/log directory is the cacti.log file that was created by cacti and had data in it so the path exists and is valid.

I have selinux permanently disabled.

[root@localhost cacti]# getenforce
Disabled

I did a wipe and reload from scratch.
1.2.4 develop has the issue
1.2.3 release has the issue
1.2.2 release doesn't have the issue and works fine

I used identical settings for all 3 tests.

Thanks,
Tom

install-complete.zip

[netniV]

So, from the log file I can see the following:

• When first starting, it was saying that there are missing modules and the path to rrdtool is not found whilst the cactilog path is not found/writable

• You then accepted the EULA in American English, and hit next. (Modules problem has gone)

• You received a list of recommendations and all OK but the mysql performance had some minor warnings

• You were then presented with a list of file locations with two issues:

  • rrdtool defaulted to /usr/local/bin/ but was not found

  • the cactilog path was empty

    (should have default but I think someone broke that functionality to fix another issue)

• You then sent back the following list:

  • php_binary: "\/bin\/php"
  • rrdtool: "\/opt\/rrdtool-1.7.2\/bin\/rrdtool"
  • snmpwalk: "\/bin\/snmpwalk"
  • snmpget: "\/bin\/snmpget"
  • snmpbulkwalk: "\/bin\/snmpbulkwalk"
  • snmpgetnext: "\/bin\/snmpgetnext"
  • snmptrap: "\/bin\/snmptrap"
  • spine: "\/usr\/local\/spine\/bin\/spine"
  • spine_config: ""
  • cactilog: "\/usr\/share\/cacti\/log\/cacti.log"
  • stderrlog: "\/usr\/share\/cacti\/log\/cacti_stderr.log"

  • sendmail_path: "\/sbin\/sendmail"

    The system checked the default path values, found a problem, then checked your updated values and found no problems. However, because the default values caused an error, the stepError was set to the current page, and thus blocked the update from continuing.

This last part is a bug, I'll get a fix going which isn't going to be easy due to the nature of the error handling. If I clear the stepError (because we had a problem with defaults but it's fixed in the user parameters), that doesn't mean higher steps didn't also have a problem so I think I'm going to have to adjust the installer to use an array and find the lowest that actually has a problem instead.

[fhanzlik]

Same problem with fresh v1.2.3 install on Fedora 29/x86_64.

[netniV]

That's interesting as I did an install of Fedora 29 without issue. You must have had different defaults selected to me.

[fhanzlik]

On Wed, 10 Apr 2019 01:28:35 -0700
Mark Brugnoli-Vinten [e-mail] wrote:

That's interesting as I did an install of Fedora 29 without issue. You
must have had different defaults selected to me.

In my case it was installation from official Fedora repo package (not
from https://www.cacti.net/downloads/cacti-1.2.3.tar.gz).
In my case boxes 'Spine Config File Path' and 'Cacti Log Path' was empty
with red cross next to second (exactly as tbilan's screenshot).

At end I solve this by downloading older 1.2.2 package from Fedora koji
(
https://kojipkgs.fedoraproject.org//packages/cacti/1.2.2/1.fc29/noarch/cacti-1.2.2-1.fc29.noarch.rpm
) and downgrade cacti. Then it was possible complete web installlation.

At end I update cacti to 1.2.3 (from repo, 'dnf update cacti').

Franta Hanzlik

[netniV]

I see, I will have to give that a go.

[Givo29]

I had this problem too when upgrading cacti. The way i resolved it was by creating log files in /var/log/cacti/cacti.log and /var/www/cacti/log/cacti.log then pointing it to there.

[fhanzlik]

In my case, when web installation get stuck, I found that /var/log/cacti/cacti.log was already there.
Your second, /var/www/cacti/log/cacti.log, IMO isn't present at all on Fedora GNU/Linux systems.

[KnoAll]

I ran into this problem yesterday on a new install on a clean Raspian Strech OS.

[netniV]

I will get to the bottom of this, this week. Unfortunately, there have been a few major issues with clients of the day job that have had to take priority.

[joea24]

Same issue on Debian 9. Verified path is in the database, stuck at this point of the install. Log folder and file are created with permissions. Thanks in advance.

[yosshiki]

Same issue on CentOS7.6-1810/ cacti-1.2.3.
・selinux disabled
・path_cacti.log : /usr/share/cacti/log/cacti.log permission 777
( select * from cacti.settings where name like 'path%'; )
・I changed install_step, install_next and install_prev,but I failed.

Finally I found that via VPN I was prohibited to access, so I changed /etc/httpd/conf.d/cacti.conf and I realized that I could go to next page(page 6). I have no idea why I succeeded.

[pautiina]

Related https://github.com/Cacti/cacti/issues/2600

[joea24]

After reading #2600 as suggested by pautiina, I powered on the server again, and went to make the change, only to find that the install would now succeed using /var/www/html/log/cacti.log as the path.

[KnoAll]

I had just run into this same error when in chrome. rebooting server did not change anything, but jumping to firefox worked.

[netniV]

You simple switched browsers and it was OK? That suggests a javascript failure then because it should be blocking it the same on all browers, more testing required!

[KnoAll]

It appears so. Other than the reboot I didn't change anything.

[lbiffle]

I also switched to see, and I’m past the logjam, and moving on. Thanks KnoAll.

Sent from my iPad

On Apr 26, 2019, at 6:59 AM, KnoAll [e-mail] wrote:

It appears so. Other than the reboot I didn't change anything.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[cigamit]

I just tried to re-produce this one on the latest develop and can not reproduce. Used the exact steps. So, I'm going to mark this one resolved.

[lbiffle]

Cool. It works now with Chrome browser? That’s great.

Sent from my iPad

On May 18, 2019, at 11:37 AM, Jimmy Conner [e-mail] wrote:

I just tried to re-produce this one on the latest develop and can not reproduce. Used the exact steps. So, I'm going to mark this one resolved.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.