Skip to content

File paths that accept blanks are not allowing blanks #2621

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tbilan opened this issue Apr 5, 2019 · 19 comments
Closed

File paths that accept blanks are not allowing blanks #2621

tbilan opened this issue Apr 5, 2019 · 19 comments
Assignees
Labels
installer Installation issue resolved A fixed issue

Comments

@tbilan
Copy link

tbilan commented Apr 5, 2019

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

image

@netniV netniV changed the title Cacti installer fails if default values have an error even if subsequently fixed Installation fails to continue when path defaults generate an error even if user overrides are correct Apr 5, 2019
@netniV
Copy link
Member

netniV commented Apr 5, 2019

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
Copy link

fhanzlik commented Apr 9, 2019

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

@netniV
Copy link
Member

netniV commented Apr 10, 2019

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

@fhanzlik
Copy link

fhanzlik commented Apr 10, 2019 via email

@netniV
Copy link
Member

netniV commented Apr 11, 2019

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

@netniV netniV self-assigned this Apr 11, 2019
@Givo29
Copy link
Contributor

Givo29 commented Apr 12, 2019

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
Copy link

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
Copy link

KnoAll commented Apr 12, 2019

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

@netniV
Copy link
Member

netniV commented Apr 15, 2019

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
Copy link

joea24 commented Apr 22, 2019

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
Copy link

yosshiki commented Apr 23, 2019

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
Copy link
Contributor

Related #2600

@joea24
Copy link

joea24 commented Apr 23, 2019

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
Copy link

KnoAll commented Apr 25, 2019

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

@netniV
Copy link
Member

netniV commented Apr 26, 2019

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
Copy link

KnoAll commented Apr 26, 2019

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

@lbiffle
Copy link

lbiffle commented Apr 26, 2019 via email

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Apr 29, 2019
Funny enough, the previous commit coincided with my own work on a
package upgrade. It brought a few bits and bobs I had been missing,
and my work closes a few of its gaps.

In detail:

INSTALL - set CACTI_USER and APACHE_GROUP properly

MESSAGES - mention newer PHPs' php.d, while updating the extension list
           mention <Cacti/cacti#2621> setup problem

Makefile - add mandatory dependencies: php-{json,zlib,mbstring,posix}
           add patched files to 'paths' substitution

files/httpd-cacti.conf - convert to Apache 2.4 ACL syntax

patches/ - comments, CACTI_LOGDIR substitution

Minor touch-ups everywhere - I am sure there is more to do.

The result pkglints, builds, installs, configures (taking the above
#2621 into account), and runs.
@cigamit cigamit added the installer Installation issue label May 5, 2019
@cigamit
Copy link
Member

cigamit commented May 18, 2019

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.

@cigamit cigamit added the resolved A fixed issue label May 18, 2019
@lbiffle
Copy link

lbiffle commented May 18, 2019 via email

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue May 19, 2019
Funny enough, the previous commit coincided with my own work on a
package upgrade. It brought a few bits and bobs I had been missing,
and my work closes a few of its gaps.

In detail:

INSTALL - set CACTI_USER and APACHE_GROUP properly

MESSAGES - mention newer PHPs' php.d, while updating the extension list
           mention <Cacti/cacti#2621> setup problem

Makefile - add mandatory dependencies: php-{json,zlib,mbstring,posix}
           add patched files to 'paths' substitution

files/httpd-cacti.conf - convert to Apache 2.4 ACL syntax

patches/ - comments, CACTI_LOGDIR substitution

Minor touch-ups everywhere - I am sure there is more to do.

The result pkglints, builds, installs, configures (taking the above
#2621 into account), and runs.
@netniV netniV changed the title Installation fails to continue when path defaults generate an error even if user overrides are correct File paths that accept blanks are not allowing blanks Jun 2, 2019
@netniV netniV closed this as completed in 3b5f1f2 Jun 2, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
installer Installation issue resolved A fixed issue
Projects
None yet
Development

No branches or pull requests

10 participants