[SOLVED] Ubuntu 22.04 breaks ispconfig_update.sh --force with mysql password error

I have had an up-to-date 3.2.9 installation (master/slave) with Ubuntu 20.04.
1) I updated the master server to Ubuntu 22.04 and run ispconfig_update.sh --force -> everything went fine
2) I updated a slave server (DNS server) to Ubuntu 22.04. So far so good.
3) I run ispconfig_update.sh --force and end up with the errors below. I have tested with the same credentials a manual mysql connection from that host and it works just fine.

In addition to that, I can see in /var/log/ispconfig/cron.log the following warning:

I thought maybe some issue with the installed PHP version, but couldn't see any issue with the php packages:

Code:

dpkg -l "php*" |grep ii
ii  php-bz2            2:8.1+92ubuntu1  all          bzip2 module for PHP [default]
ii  php-cli            2:8.1+92ubuntu1  all          command-line interpreter for the PHP scripting language (default)
ii  php-common         2:92ubuntu1      all          Common files for PHP packages
ii  php-curl           2:8.1+92ubuntu1  all          CURL module for PHP [default]
ii  php-mbstring       2:8.1+92ubuntu1  all          MBSTRING module for PHP [default]
ii  php-mysql          2:8.1+92ubuntu1  all          MySQL module for PHP [default]
ii  php-soap           2:8.1+92ubuntu1  all          SOAP module for PHP [default]
ii  php-xml            2:8.1+92ubuntu1  all          DOM, SimpleXML, WDDX, XML, and XSL module for PHP [default]
ii  php-zip            2:8.1+92ubuntu1  all          Zip module for PHP [default]
ii  php8.1-bz2         8.1.2-1ubuntu2.9 amd64        bzip2 module for PHP
ii  php8.1-cli         8.1.2-1ubuntu2.9 amd64        command-line interpreter for the PHP scripting language
ii  php8.1-common      8.1.2-1ubuntu2.9 amd64        documentation, examples and common module for PHP
ii  php8.1-curl        8.1.2-1ubuntu2.9 amd64        CURL module for PHP
ii  php8.1-mbstring    8.1.2-1ubuntu2.9 amd64        MBSTRING module for PHP
ii  php8.1-mysql       8.1.2-1ubuntu2.9 amd64        MySQL module for PHP
ii  php8.1-opcache     8.1.2-1ubuntu2.9 amd64        Zend OpCache module for PHP
ii  php8.1-readline    8.1.2-1ubuntu2.9 amd64        readline module for PHP
ii  php8.1-soap        8.1.2-1ubuntu2.9 amd64        SOAP module for PHP
ii  php8.1-xml         8.1.2-1ubuntu2.9 amd64        DOM, SimpleXML, XML, and XSL module for PHP
ii  php8.1-zip         8.1.2-1ubuntu2.9 amd64        Zip module for PHP

How can I debug the problem? Thanks.

 

Thanks @till The password in /usr/local/ispconfig/server/lib/mysql_clientdb.conf matches the mysql root password of the local host. I've tested it by using mysql dbispconfig -u root -h localhost -p on the local host (and the password is the same as in /etc/mysql/debian.cnf) ... and why/how should have that password been changed as I never touched it :-(

 

So all is working now?
Did you check the file and password on the slave server, too?

 

The state is stil the same -> the slave server works fine, but i wanted to re-run ispconfig_update.sh --force after the upgrade to Ubuntu 22.04 and there it get the above errors.
when running ispconfig_update.sh --force I enter the master sql server root password (as I always did on any run of ispconfig_update.sh when upgrading ISPconfig).

 

No, I am not mixing it up
I was always only using the sql root password of the master with ispconfig_update.sh
As written, when I run (on the slave) mysql -h localhost -u root -p and use the password from /usr/local/ispconfig/server/lib/mysql_clientdb.conf (which is the same as in /etc/mysql/debian.cnf) i can connect successfully to the slaves (local) sql server.
(and the slave server is successfully getting updates from the master server...)

 

1) I have downloaded https://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz and unpacked it in /tmp
2) I have run php update.php from within the install directory
3) I got the same error.
I added some echo statements before L106 to see all the variables. I see that the password that is used for the check is the one I entered for the master sql server and NOT the slave sql password from /usr/local/ispconfig/server/lib/mysql_clientdb.conf ?!

For testing purposes I changed the hostname (localhostXX) in the mysql_clientdb.conf -> not even the changed hostname gets reflected in check command.
When I tried to change in addition the username (rootXX) the update.php script fails somewhere earlier in a check:

Code:

Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]: no
PHP Fatal error:  Uncaught mysqli_sql_exception: Access denied for user 'rootXX'@'localhost' (using password: YES) in /tmp/ispconfig3_install/install/update.php:258

Looks for me more like a bug as I never did any changes to the ispconfig files.

 

My fault, it is not using the master sql password, but the correct slave password.

Nevertheless, the issue was/is still there. So I had a look at the mysqlcheck command as the "normal" mysql command works fine with the same username & password and the warning message "WARNING: Forcing protocol to TCP due to option specification. Please explicitly state intended protocol." was suspicious.

Code:

mysqlcheck -h localhost -u root -pXXXX -P3306 dbispconfig

throws the error as seen. But if I do NOT use the port number, so that mysqlcheck uses the socket connection, it works just fine:

Code:

mysqlcheck -h localhost -u root -pXXXX dbispconfig

It seems that the behaviour of the -P option in mysqlcheck has changed with the newer version. man page from mysqlcheck Ubuntu 20.04 (mysqlcheck Ver 2.7.4-MariaDB Distrib 10.3.37-MariaDB, for debian-linux-gnu (x86_64)):

Code:

--port=port_num, -P port_num
           The TCP/IP port number to use for the connection.

Where in Ubuntu 22.04 (mysqlcheck Ver 2.7.4-MariaDB Distrib 10.6.11-MariaDB, for debian-linux-gnu (x86_64)):

Code:

--port=port_num, -P port_num
           The TCP/IP port number to use for the connection.  Forces --protocol=tcp when specified on the command line without other connection properties

Weird thing: If I run on an Ubuntu 20.04 ispconfig slave server the mysqlcheck WITH --protocol=tcp it works. And both sql servers are listengin ONLY on 127.0.0.1:3306

As I have no port variable in /usr/local/ispconfig/server/lib/mysql_clientdb.conf it should be reflected for the mysqlcheck command and not using 3306 by default.
Btw, when using the mysql command and providing the port number, it doesn't work neither.
WORKS: mysql -h localhost -u root -p dbispconfig
DOES NOT WORK: mysql -h localhost -u root -p -P3306 dbispconfig
(and I assume it is also related on how the permissions for the user are set in mysql).

After removing the port argument on the mysqlcheck command and in update.php on the "Check command line mysql login" mysql command, the update.php works okay, i just the warning due to an undefined array key "ufw":

Code:

Checking ISPConfig database .. OK
Starting incremental database update.
Loading SQL patch file: /tmp/ispconfig3_install/install/sql/incremental/upd_dev_collection.sql
Reconfigure Permissions in master database? (yes,no) [no]:

PHP Warning:  Undefined array key "ufw" in /tmp/ispconfig3_install/install/update.php on line 366
PHP Warning:  Trying to access array offset on value of type null in /tmp/ispconfig3_install/install/update.php on line 366
Service 'db_server' has been detected (currently disabled) do you want to enable and configure it?  (yes,no) [no]:

Reconfigure Services? (yes,no,selected) [yes]:

Configuring BIND
Configuring AppArmor
PHP Warning:  Undefined array key "ufw" in /tmp/ispconfig3_install/install/update.php on line 522
PHP Warning:  Trying to access array offset on value of type null in /tmp/ispconfig3_install/install/update.php on line 522
Configuring Bastille Firewall
PHP Warning:  Trying to access array offset on value of type null in /tmp/ispconfig3_install/install/lib/installer_base.lib.php on line 2558
PHP Deprecated:  trim(): Passing null to parameter #1 ($string) of type string is deprecated in /tmp/ispconfig3_install/install/lib/installer_base.lib.php on line 2558
PHP Warning:  Trying to access array offset on value of type null in /tmp/ispconfig3_install/install/lib/installer_base.lib.php on line 2558
PHP Deprecated:  trim(): Passing null to parameter #1 ($string) of type string is deprecated in /tmp/ispconfig3_install/install/lib/installer_base.lib.php on line 2558
Configuring Database
Updating ISPConfig
Do you want to create SSL certs for your server? (y,n) [y]: n

PHP Deprecated:  explode(): Passing null to parameter #2 ($string) of type string is deprecated in /tmp/ispconfig3_install/install/lib/installer_base.lib.php
on line 55
PHP Warning:  Undefined array key "ufw" in /usr/local/ispconfig/server/plugins-available/firewall_plugin.inc.php on line 41
PHP Warning:  Trying to access array offset on value of type null in /usr/local/ispconfig/server/plugins-available/firewall_plugin.inc.php on line 41
Reconfigure Crontab? (yes,no) [yes]:

Updating Crontab
Restarting services ...
PHP Warning:  Undefined array key "ufw" in /tmp/ispconfig3_install/install/update.php on line 659
PHP Warning:  Trying to access array offset on value of type null in /tmp/ispconfig3_install/install/update.php on line 659
Update finished.
[\CODE]

 

Thanks @till
So that means that in config.inc.php I shall change $conf['db_port'] to '' ?
As it worked until now and the original setup was made years ago, I don't know when/if the port number was set explicitly.

 

I was just digging into the sql permissions and found the problem:
on the slave server i see
GRANT ALL PRIVILEGES ON *.* TO `root`@`localhost` IDENTIFIED VIA unix_socket
Interesting:

• master server does not have that identified clause
• slave servers
  • nameserver: this is the server that I did the upgrade and that has the clause
  • mailserver: still on Ubuntu 20.04 -> doesnt have it
  • webserver: still on Ubuntu 20.04 -> HAS it.

really weird. No idea why the different grants for the root user. Obviously the changed behavior of the mysql/mysqlcheck --port parameter is the cause why it stopped working after the Ubuntu upgrade as now the TCP connection is being used on the localhost too instead of the socket.
I will fix the permissions of the root user and see if it works.

 

Updating the permission to have IDENTIFIED VIA unix_socket removed fixes the problem.
Thanks for your help @till

 

I will upgrade the other two slave servers to Ubuntu 22.04 and see if I run into any other issues