During install/upgrade, database tests are not performed correctly

[eschoeller]

I'm running through new installs on two remote pollers I'm spinning up.

All of the "test connection" checks pass, but the installer bombs out at the end with this in the log:

2019/10/27 21:58:52 - INSTALL: always: Installation was started at 2019-10-28 03:57:47, completed at 2019-10-28 03:58:52
2019/10/27 21:58:52 - INSTALL: always: Failed to connect database
2019/10/27 21:58:52 - INSTALL: always: Finished INSTALL Process for v1.2.7 

The main cacti server has dozens of these in it's mysql log:

2019-10-27 22:01:07 83390 [Warning] Access denied for user 'apache'@'xyz.colorado.edu' (using password: YES)
2019-10-27 22:01:07 83390 [Warning] Access denied for user 'apache'@'xyz.colorado.edu' (using password: YES)
2019-10-27 22:01:07 83390 [Warning] Access denied for user 'apache'@'xyz.colorado.edu' (using password: YES)
2019-10-27 22:01:07 83390 [Warning] Access denied for user 'apache'@'xyz.colorado.edu' (using password: YES

Clearly I have messed up my GRANT directives on the main data collector's database (it's very confusing to get these right in a remote poller setup). But regardless, whatever the "test connection" functions are doing earlier in the installer, they aren't fully verifying that the connection actually works and then the installer bombs out at a complete dead-end. the only way back is to dump the remote poller database and start the installer all over again.

[netniV]

I will have to see what the test connection is doing. More than likely, it's only checking local database connectivity.

[eschoeller]

I watched communication between the remote data collector and the main data collector during the install. There was lots of traffic from the remote collector to the main data collector's mysql database. Every time I hit "Test Connection" I saw this traffic. But then, in the end, the database connection was still reported as a failure. So, I guess perhaps it's checking to make sure it can hit the database port, but not actually logging in during the test?

[eschoeller]

Or perhaps I was seeing the login errors on the main collector's database during each one of these checks ... and the remote collector wasn't verifying that it was actually successfully logging in. I can't recall now.

[cigamit]

@eschoeller, I have not forgotten you. Just so busy. I'm working a few hours today. Marking unverified to the time being.

[cigamit]

This is resolved now.