Fresh install of 1.2.3 is stuck at Critical Binary Locations

[tbilan]

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.

Thanks,
Tom

[netniV]

You need to enter a valid log path location. It does look like there is a bug there though because it is defaulting to blank for some reason, that should be <cacti dir>/log/cacti.log

I did a fresh install on Fedora 29 at the weekend and did not run into this issue myself.

[tbilan]

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'll blow away the system and reinstall from scratch. Maybe I'll get different results. If it fails I'll do another fresh OS install and pull 1.2.2 and see what happens with that version.

[netniV]

Fedora 29 has SELinux enabled by default, make sure you adjust the contexts so that http_context_rw is against the log directory.

[tbilan]

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.

I can youtube me attack clicking the next button when all the checkboxes are green and it still fails if it helps. Let me know.

[netniV]

Code: Select all

replace into settings values ('log_install', '3')

Run the above code, then email me the log/install-complete.log

When we are done debugging, you'll want to run the above command again but this time replace the 3 with a 0.

[tbilan]

It's short so I posted it here.

1.2.4
[2019-04-03 21:15:59] [ language info ] getLanguage(): en-US
[2019-04-03 21:15:59] [ theme info ] getTheme(): modern
[2019-04-03 21:15:59] [ theme info ] Checking theme: modern
[2019-04-03 21:15:59] [ templates info ] setTemplates(): Updating templates
[2019-04-03 21:15:59] [ automation info ] getProfile() returns with 1
[2019-04-03 21:15:59] [ automation info ] setProfile(1) returns with 1
[2019-04-03 21:15:59] [ automation info ] getAutomationMode() returns '1'
[2019-04-03 21:15:59] [ automation info ] setAutomationMode(1) returns with 1
[2019-04-03 21:15:59] [ automation info ] setAutomationOverride() returns with
[2019-04-03 21:15:59] [ automation info ] getAutomationRange() returns '192.168.1.0/24'
[2019-04-03 21:15:59] [ automation info ] setAutomationRange(192.168.1.0/24) returns with 192.168.1.0/24
[2019-04-03 21:15:59] [ errors info ] addError(Paths, path_cactilog, Resource is not writable)
[2019-04-03 21:15:59] [ rrdversion info ] getRRDVersion(): 1.7.2
[2019-04-03 21:15:59] [ rrdversion info ] sanitizeRRDVersion() - returning 1.7.2
[2019-04-03 21:15:59] [ rrdversion info ] sanitizeRRDVersion() - returning 1.7.2
I see the "Resource is not writable" message. I chmod 777 the log directory and 777 the log files in the directory, including cacti.log, and that didn't help. I restarted the apache daemon just in case but still didn't help.

1.2.2
[2019-04-03 21:25:25] [ templates info ] setTemplates(): Updating templates
[2019-04-03 21:25:25] [ automation info ] getProfile() returns with 1
[2019-04-03 21:25:25] [ automation info ] setProfile(1) returns with 1
[2019-04-03 21:25:25] [ automation info ] getAutomationMode() returns '1'
[2019-04-03 21:25:25] [ automation info ] setAutomationMode(1) returns with 1
[2019-04-03 21:25:25] [ automation info ] setAutomationOverride() returns with
[2019-04-03 21:25:25] [ automation info ] getAutomationRange() returns '192.168.1.0/24'
[2019-04-03 21:25:25] [ automation info ] setAutomationRange(192.168.1.0/24) returns with 192.168.1.0/24
[2019-04-03 21:25:25] [ rrdversion info ] getRRDVersion(): 1.7.2
[2019-04-03 21:25:25] [ rrdversion info ] sanitizeRRDVersion() - returning 1.7.2
[2019-04-03 21:25:25] [ rrdversion info ] sanitizeRRDVersion() - returning 1.3.0

Doesn't error out and proceeds as normal.

selinux is still disabled.

[netniV]

OK, up the number from 3 to 5, remove all log/install-*.log and then repeat the process. The log file will be a lot larger this time.

The is_resource_writable() function has not changed between the two versions, so hopefully the debug level info will hopefully give us more insight.

[tbilan]

See attached.

This was from 1.2.4 develop

[lbiffle]

On FreeBSD 11.2, 1st cacti install, and stuck here, too. Logs are updating. Should I await a fix, or use another version. Prefer to be up to date. Thanks -Les

[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 am wondering if there is already an open tracker for it, but if not feel free to go create on and 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 but it's fixed in an update, that doesn't mean higher steps didn't also have a problem.

[netniV]

On FreeBSD 11.2, 1st cacti install, and stuck here, too. Logs are updating. Should I await a fix, or use another version. Prefer to be up to date. Thanks -Les

I will try and get a fresh FreeBSD going next week. I've got a busy family weekend so not likely to be doing too much on cacti.

[netniV]

You should both be able to bypass this problem, if you update the settings table with the correct paths. It's a workaround, let me know if it helps.

Code: Select all

REPLACE INTO settings VALUES ('path_<name>', '<path>')

Replace <name> with the bold name I listed above and <path> with the full path that you would normally use on the command line.

[krpennock]

I just wanted to chime in that I am encountering the same issue on Raspbian/stretch. The suggested SQL is still showing blank for 'Cacti Log Path' after running the SQL suggested. If I run a select on said table the value appears to be set.

[netniV]

OK, I was hoping it may have worked but I guess I'll have to get something sorted tomorrow.