Why ispconfig_update.sh chooses to use root@'public_ip' instead of root@localhost?

Hi,
First of all thank you for this great product. I can't stress enough how many times it helped me do some things quickly and reliably. So thank you
Next, I'm trying to update ispconfig on one of my machines where the update script shows these errors:

Code:

>> Update 

Operating System: Debian 11.0 (Bullseye) or compatible

This application will update ISPConfig 3 on your server.

Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]: no

Checking MariaDB version 10.5.21 .. OK
PHP Warning:  mysqli_connect(): (HY000/1130): Host 'x.y.w.z' is not allowed to connect to this MariaDB server in /tmp/update_runner.sh.ttuaVYm3Mc/install/lib/mysql.lib.php on line 112
PHP Warning:  mysqli_query() expects parameter 1 to be mysqli, bool given in /tmp/update_runner.sh.ttuaVYm3Mc/install/lib/mysql.lib.php on line 113
Checking ISPConfig database ..

What makes the update script want to use the public ip of that machine instead of simply root@localhost to connect to db?
Thank you all for any tips.
Cheers

 

Thank you till. Your answer led me in the right direction, eventually manually running the script update_runner.sh from /tmp in order to figure out what was going on. It turned out that mariadb on the master server wasn't properly resolving reverse hostname for that particular slave server. Quite weird, considering PTR record is fine... Anyway, I've encountered suggestions to turn off hostname lookups (skip-name-resolve) through PTR dns records to avoid having dependencies on dns while using mariadb. Do you have any opinion on this subject perhaps?

Thank you once again for your help.
Cheers

 

Sure, here it is (host1 and host2 are hostnames for this slave server):

Code:

127.0.0.1       localhost
#127.0.1.1      host1.example.com host2.example.com

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I've commented out 127.0.1.1 but got the same error, which later turned out was generated from master server db, not accepting sql connection from slave, using user root@IP_of_slave...