Closed eduardomozart closed 2 months ago
This will have to be confirmed. @netniV, any comments on this one?
The timezone should always be defined even if it is different. And likewise, this means having access to the timezone table
I can confirm this behaviour
The installer is trying to connect over to the Main poller instead of dipping into the local mysql database to get the time zone names
Okay, I think it's fixed. @bmfmancini is testing.
Confirmed fixed
So the expected behavior is to use the remote DB for local timezone? My question is that it seems that on a newer Remote Poller instance setup this check still will not be initially made with the fix provided, as the Remote Poller config is made after the pre-checks PHP/DB phase where we select if it will be a local or remote poller Cacti instance.
Describe the bug
The DB requirements are checked against the local database only, but the Remote Poller also requires access to "mysql.time_zone_name" table but this isn't checked during Remote Poller installation. It happens because the DB check stage happens before the Remote Poller configuration OR the Cacti itself should be updated to use only the local DB 'mysql.time_zone_name' table instead of relying on the DB remote one.
To Reproduce
Steps to reproduce the behavior:
Go to Cacti Web Installer.
Click on 'Next', check the DB requirements.
See error if upgrading an existing Remote Poller instance without "mysql.time_zone_name" 'SELECT' access or the local one should be used instead or Cacti should always use the local "mysql.time_zone_name" table instead of relying on the remote (Main Poller) one.
Expected behavior
The "mysql.time_zone_name" 'SELECT' access should be checked on a later stage during Remote Poller first install.
Screenshots
None.
Desktop (please complete the following information)
OS: Windows Server 2012
Browser Chrome
Version 109
Additional context
None.