"The following changes are not yet populated to all servers:" not going away

Discussion in 'General' started by SilkBC, Oct 14, 2023.

  1. SilkBC

    SilkBC Member

    Hello,
    After making some changes to some sites, the "The following changes are not yet populated to all servers:" blinking icon will not go away. The Job Queue is empty. The changes I made appear to be working, so I think it is just a matter of the "alert" not being able to be clear for some reason.

    How do I make this go away?

    Thanks! :)
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    The alert is directly coupled with a query for pending changes, so there must be changes that were not applied. Is this maybe a multiserver system where one of the ndoes has not been removed correctly or is currently offline?
     
  3. SilkBC

    SilkBC Member

    It is a multi-node system, consisting of just two nodes: a control panel server and a web server (hosting MySQL databases as well).

    Both nodes are online and reachable.

    Clicking in the alert shows me:

    datalog_status_i_client: 1
    datalog_status_u_client: 1
    datalog_status_i_sys_group: 1
     
  4. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

  5. SilkBC

    SilkBC Member

    Debug level logging was already enabled. No errors are showing up in the System-Log

    Here is what running server.sh manually on the web server node outputs:

    15.10.2023-10:53 - DEBUG [plugins.inc:155] - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'.
    15.10.2023-10:53 - DEBUG [server:217] - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
    finished server.php.

    (which is the same output I see in "System-Log" in the Control Panel)

    There don't *appear* to be any errors...?
     
  6. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Go through these steps on both servers please.
     
  7. SilkBC

    SilkBC Member

    OK, that was a bit more enlightening. Here is the running of '/usr/local/ispconfig/server/server.sh' on the control panel server::

    15.10.2023-14:29 - WARNING - There is already a lockfile set, but no process running with this pid (17999). Continuing.
    Database connection failed Database connection failed Database connection failed Database connection failed Database connection failed Zugriff auf Datenbankserver fehlgeschlagen! / Database server not accessible! PHP Fatal error: Uncaught Error: Call to a member function testConnection() on bool in /usr/local/ispconfig/server/server.php:64
    Stack trace:
    #0 {main}
    thrown in /usr/local/ispconfig/server/server.php on line 64
    Database connection failed Database connection failed Database connection failed Database connection failed Database connection failed Zugriff auf Datenbankserver fehlgeschlagen! / Database server not accessible!

    So something is wrong with the connection to the database. What is the best way to go about resolving that?
     
  8. SilkBC

    SilkBC Member

    I am able to log in MySQL on the control panel server with the info in the '/usr/local/ispconfig/interface/lib/config.inc.php' file, so it does not appear to be an issue with the database credentials.

    I can log in via both 'localhost' and '127.0.0.1'
     
    Last edited: Oct 16, 2023
  9. remkoh

    remkoh Active Member HowtoForge Supporter

    I've had the same error recently.

    I assume server.php is using a hostname for the sql server to connect to?

    That hostname isn't resolving to the ip that you are expecting, hence there's no user with the host/ip in sql that server.php is expecting and therefor can't connect.
     
  10. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    You need to be able to login to the master with the credentials set for the master db in config.inc.php (in /usr/local/ispconfig/server/lib/config.inc.php on the slave, not /usr/local/ispconfig/interface/lib/config.inc.php)
     
  11. SilkBC

    SilkBC Member

    OK, I was not able to connect via the MySQL client from the slave (web server node) to the master (control panel node) with the "master database" credentials in '/usr/local/ispconfig/server/lib/config.inc.php' (from the slave node). I ran the "GRANT ALL PRIVILEGES" command on the master node's MySQL to allow connections from the slave's IP, and I can now connect with the MySQL client from the slave to the master with the "master database" credentials.

    Hrm, some helpful information might be that I recently changed the IP addresses of the master and slave nodes, as we moved them (VMs) to a different datacenter. Sorry, should have mentioned that. When I changed the IPs, I followed the steps from another post and updated the info in the Control Panel GUI and /etc/hosts

    Running '/usr/local/ispconfig/server/server.sh' on the master node still gives an error being able to connect to the database:

    --- START ---
    Database connection failed Database connection failed Database connection failed Database connection failed Database connection failed Zugriff auf Datenbankserver fehlgeschlagen! / Database server not accessible! PHP Fatal error: Uncaught Error: Call to a member function testConnection() on bool in /usr/local/ispconfig/server/server.php:64
    Stack trace:
    #0 {main}
    thrown in /usr/local/ispconfig/server/server.php on line 64
    Database connection failed Database connection failed Database connection failed
    --- END ---

    Here is line 64+ from '/usr/local/ispconfig/server/server.php':

    --- START ---
    if ($app->dbmaster->testConnection()) {
    $server_db_record = $app->dbmaster->queryOneRecord("SELECT * FROM server WHERE server_id = ?", $conf['server_id']);

    if(!is_array($server_db_record)) die('Unable to load the server configuration from database.');
    --- END ---
     
  12. SilkBC

    SilkBC Member

    OK, so just found something interesting: the '/usr/local/ispconfig/server/lib/config.inc.php' have different info for the "master DB"

    On the master node, 'dbmaster_port' and 'dbmaster_user' are blank, whereas those values are set in the slave node's file. But more interestingly, the dbmaster_password' value on both nodes are different. I suspect I need to change one to the other, but am not sure which? My gut tells me I should update the slave node to match the value on the master node?
     
  13. SilkBC

    SilkBC Member

    OK, so that was a red herring. I checked the 'config.inc.php' files in question on the original VMs in the "old" datacenter, and the different passwords I am currently seeing are on the originals as well.
     
  14. SilkBC

    SilkBC Member

    Is there something in the 'dbispconfig' database itself that allows connections?

    I did some testing on the original VMs, and I am able to connect with the MySQL client to the master DB from the slave node with the credentials in '/usr/local/ispconfig/server/lib/config.inc.php' without having to have done anyting on the master node's MySQL.

    If there is something in the 'dbispconfig' database itself that is allowing the access, which table is it? I can manually update the value.
     
  15. till

    till Super Moderator Staff Member ISPConfig Developer

    Check config.inc.php on master, the following lines must be empty on the master:

    Code:
    $conf['dbmaster_host']                  = '';
    $conf['dbmaster_port']                  = '';
    $conf['dbmaster_user']                  = '';
    as the master does not connect to a master server. If they are not empty, then empty them. Only slave nodes have these settings for the master connection.
     
  16. SilkBC

    SilkBC Member

    Those are indeed empty pn the master node.
     
  17. till

    till Super Moderator Staff Member ISPConfig Developer

    That's indeed the reason for your problem. if users in mysql are not adjusted correctly to match the new IP's or if the hosts file on master or slave is not adjusted, then mysql connections from nodes might fail and will cause the processing of config changes to halt as ISPConfig is unable to connect to its databases.

    That's correct and as it should be, so do not copy any data from master to slave or vice versa. The master login section must be empty on master as the master does not connect to a master, he is the master. And the password you see there on the master is not the password that the slave connects with. The slave connects against mysql with a mysql user and mysql password, it does not connects against any password from ISPConfig.

    no

    That's how the ISPConfig installer sets things up at install time.

    At the moment, the slave server works again but you get an error on master only?
     
    Th0m likes this.
  18. SilkBC

    SilkBC Member

    Yes. When I run '/usr/local/ispconfig/server/server.sh' manually on the master, I get the database connection issue. When I run that same file on the slave, there is no error and ends with "finished server.php."

    On the master, I can connect to the dbispconfig database on it with the credentials in '/usr/local/ispconfig/server/lib/config.inc.php'. I am also able to connect to the dbispconfig database on the slave from the master using the credentials in '/usr/local/ispconfig/server/lib/config.inc.php' on the slave.

    I am puzzled as to what database connection it is unable to make.
     
    Last edited: Oct 18, 2023
  19. SilkBC

    SilkBC Member

    So using the MySQL client, if I am able to connect to the dbispconfig database on the master node FROM the master node using the credentials in '/usr/local/ispconfig/server/lib/config.php.inc' (on the master node), what would cause the error of not being able to connect to the database when running the '/usr/local/ispconfig/server/server.sh' file (though technically it is the running of '/usr/local/ispconfig/server/server.php' that is running into the error)
     
  20. till

    till Super Moderator Staff Member ISPConfig Developer

    Please try to empty all dbmaster_* config fields in /usr/local/ispconfig/server/lib/config.inc.php on the master and check if this solves the problem, leave only the login details for the connection on localhost intact. Make a backup of the file before you alter it.
     

Share This Page