The provided database host, username, and/or password is invalid

So deployment was straight forward but now I’m stuck in the installer.

The provided database host, username, and/or password is invalid, and a connection to the database could not be established. Please enter a valid host, username and password

image

The db (empty) and user with full access to that db were created by our deployment script.
mysql and suitecrm are running on same box.

On the same server, connecting to mysql using same details over commandline works fine:

root@suitecrm:/opt/apps# mysql --host=localhost --port=3306 --user=suitecrm --password suitecrm
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 183
Server version: 8.0.23-0ubuntu0.20.04.1 (Ubuntu)

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> \s
--------------
mysql  Ver 8.0.23-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

Connection id:		183
Current database:	suitecrm
Current user:		suitecrm@localhost
SSL:			Not in use
Current pager:		stdout
Using outfile:		''
Using delimiter:	;
Server version:		8.0.23-0ubuntu0.20.04.1 (Ubuntu)
Protocol version:	10
Connection:		Localhost via UNIX socket
Server characterset:	utf8mb4
Db     characterset:	utf8mb4
Client characterset:	utf8mb4
Conn.  characterset:	utf8mb4
UNIX socket:		/var/run/mysqld/mysqld.sock
Binary data as:		Hexadecimal
Uptime:			1 hour 43 min 44 sec

Threads: 2  Questions: 9513  Slow queries: 0  Opens: 356  Flush tables: 3  Open tables: 274  Queries per second avg: 1.528
--------------

mysql>

It looks like using localhost led to mysql using the socket instead of tcp/ip. Trying again with 127.0.0.1…

root@suitecrm:/opt/apps# mysql --host=127.0.0.1 --port=3306 --user=suitecrm --password suitecrm
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 191
Server version: 8.0.23-0ubuntu0.20.04.1 (Ubuntu)

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> \s
--------------
mysql  Ver 8.0.23-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

Connection id:		191
Current database:	suitecrm
Current user:		suitecrm@localhost
SSL:			Cipher in use is TLS_AES_256_GCM_SHA384
Current pager:		stdout
Using outfile:		''
Using delimiter:	;
Server version:		8.0.23-0ubuntu0.20.04.1 (Ubuntu)
Protocol version:	10
Connection:		127.0.0.1 via TCP/IP
Server characterset:	utf8mb4
Db     characterset:	utf8mb4
Client characterset:	utf8mb4
Conn.  characterset:	utf8mb4
TCP port:		3306
Binary data as:		Hexadecimal
Uptime:			1 hour 44 min 46 sec

Threads: 2  Questions: 9539  Slow queries: 0  Opens: 361  Flush tables: 3  Open tables: 279  Queries per second avg: 1.517
--------------

mysql>

I’ve tried giving suitecrm localhost, localhost:3306, 127.0.0.1, etc…no luck.

Conclusions…

  • credentials, dbname, username are all correct
  • mysql is running on port 3306 and open to network connections
  • suitecrm doesn’t connect but doesn’t provide any further details on what the problem is. The error message is not particularly helpful at narrowing down the problem.

Any ideas? Nothing useful in php, nginx or mysql error logs. The suitecrm install.log has the same useless message as in the UI. Am I missing something obvious?

1 Like

I’m starting to suspect that SuiteCRM requires I provide a user that has administration access to mysqld and not just the designated db? Of course if that is the case the error message should be different (more specific and helpful about the permissions issue).

This would be a lot simpler if I could just provision a config file and skip the installer.

Still hoping I am just missing something obvious and being dumb but I’ve been checking/rechecking for the last hour and don’t see it.

I believe your versión of MySQL is not compatible with SuiteCRM.

Check here for more info: https://docs.suitecrm.com/admin/compatibility-matrix/

Good spot, thanks. I had checked the compat matrix on other stuff but forgot to double-check mysql version.

mysql-5.7 doesn’t appear to be set for long term support. Oracle doesn’t even provide 5.7 packages for Ubuntu 20.04 LTS (http://repo.mysql.com/apt/ubuntu/dists/focal/).

It looks like the main compat issue with mysql8 was fixed (https://github.com/salesagility/SuiteCRM/issues/6046) in 7.11.16 (https://github.com/salesagility/SuiteCRM/commit/d4a8dcebbcfead5fac57a9a6dbd4777ce94c932a).

Ubuntu 16 is EOL so a lot of people on 16 are moving to 20 LTS and skipping 18 LTS.
FWIW Ubuntu 18 LTS does still get mysql5.7 packages (http://repo.mysql.com/apt/ubuntu/dists/bionic/).

Given the main issue with mysql8 was fixed already and people reported install running fine with the patch…and that the error message doesn’t say anything about a SQL error. Sounds more like a connection or auth error…but no detail provided.

I think the error message could be much more specific to be helpful (auth error vs connection refused/timeout vs SQL error).

I enabled general logging on mysql and tried the suitecrm install again.

mysql> SET global general_log_file = '/var/log/mysql/query.log';
mysql> SET global general_log = 1;
$ tail -f -n0 /var/log/mysql/query.log
2021-03-17T09:15:33.612622Z	 1112 Connect	suitecrm@localhost on  using Socket

So it appears the installer is connecting but not doing anything else.

For comparison I connected from commandline and intentionally gave the wrong password to see what a failed login in the log looked like.

root@suitecrm:~# mysql --host=localhost --port=3306 --user=suitecrm --password suitecrm
Enter password:
ERROR 1045 (28000): Access denied for user 'suitecrm'@'localhost' (using password: YES)

The log from my failed login attempt…

2021-03-17T09:18:07.437701Z	 1120 Connect	suitecrm@localhost on suitecrm using Socket
2021-03-17T09:18:07.437836Z	 1120 Connect	Access denied for user 'suitecrm'@'localhost' (using password: YES)

So connect looks the same as installer. However Auth error is in log for my failed attempt but not for the SuiteCRM installer. Conclusion: connection/auth is working for installer.

Are queries being logged?

Next I ran a dumb query from the command line to see how this would look in the log.

root@suitecrm:~# mysql --host=localhost --port=3306 --user=suitecrm --password suitecrm
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1121
Server version: 8.0.23-0ubuntu0.20.04.1 (Ubuntu)

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SELECT foo FROM bar;
ERROR 1146 (42S02): Table 'suitecrm.bar' doesn't exist
mysql> \q
Bye
2021-03-17T09:21:21.843079Z	 1121 Connect	suitecrm@localhost on suitecrm using Socket
2021-03-17T09:21:21.845766Z	 1121 Query	show databases
2021-03-17T09:21:21.846979Z	 1121 Query	show tables
2021-03-17T09:21:21.848399Z	 1121 Query	select @@version_comment limit 1
2021-03-17T09:21:47.359597Z	 1121 Query	SELECT foo FROM bar
2021-03-17T09:21:57.846411Z	 1121 Quit

You can see that after the successful connect, the queries are indeed logged.
The SuiteCRM install does connect, does not have any auth error and no queries or other activity are logged for the SuiteCRM installer’s connection.

Summary

Installer definitely connects. No AUTH error in log.
There is not a SQL error (no queries are being run by installer).
There is probably some internal SuiteCRM error…perhaps unhappy with the reported mysql version or something.
Unfortunately the SuiteCRM error message is not helpful and appears misleading/incorrect as there is not a connection or auth problem with the database (according to the logs).

1 Like

Have you tried the silent installer?

There’s a Robo task to install without GUI

Thanks for the tip. This is what I looked for first as this is a scripted install but didn’t see anything in the docs.

I found your 2019 post googling for “silent installer”. Is that the best documentation on this or did I miss it in the main docs (or just need to read the source)?

Thanks.

I haven’t used this, and I don’t really know the state of it. It’s possible that there is a silent upgrader, but not a silent installer? And maybe one is a separate PHP, the other is packaged as a Robo task? I’m really not sure.

I think looking at the code is the best option, since the Docs might very well be out of sync.

Another advice, if going through the UI is to try a simpler password in SuiteCRM and MySQL. Avoid weird characters. There’s an infamous bug with over-zealous string cleaning that breaks some passwords.

Okay. In the robo dir there is not an obvious installer.

This blog post is from 2016, so likely out of date (config changes, etc).

It appears to use a pre-configed/templated config file combined with some special installer query string options to do an unattended install. Feels pretty hacky as it looks like you might need to use curl to make a GET request to tell the php install script to do a CLI install. As this isn’t well documented it may or may not even be supported anymore…so as you say I would need to get into the code…at which point I probably just try to track down the install db code that is failing with incorrect error message.

Another advice, if going through the UI is to try a simpler password in SuiteCRM and MySQL. Avoid weird characters. There’s an infamous bug with over-zealous string cleaning that breaks some passwords.

Yeah as a developer, I don’t trust developers and have run into that exact bug many times. I use long generated passwords (no dictionary) but generally just alphanumeric (62^pwlength) as this should be more than enough to discourage brute force attacks unless the app doesn’t do any sort of rate limiting of login attempts on an IP address basis. I have run into some apps that silently truncate passwords to some number of characters…another fun bug. Trying to figure out what the password you just set doesn’t let you login…and you delete one character at a time off the end until magically you can login.

Anyway that shouldn’t be the problem here. I verified in chrome dev tools that the correct data was being passed on the XHR to the installer… and if it wasn’t I would have seen an AUTH error in the mysql log above.

“Clicking Next” on the install page where I get the error creates a XHR post to install.php?sugar_body_only=1&storeConfig=1 with all form data.
This returns 200 with no body/errors.

Then the client side triggers another XHR post to install.php with less form data than the previous XHR and checkDBSettings: true

image

This call returns 200 but with errors in body.

<p><b>Please fix the following errors before proceeding:</b></p><ul><li class="error">The provided database host, username, and/or password is invalid, and a connection to the database could not be established. Please enter a valid host, username and password</li></ul></div>

This second XHR is handled here: install.php#L354

And this is the line where the error is coming from:
install/checkDBSettings.php#L140
include/database/MysqliManager.php#L296

mysqli_connect returns the db instance or false in error case. Getting false is not particularly useful to determine why it is failing.

You should enable error reporting for mysqli before attempting to make a connection

Tell mysqli to throw errors so we know what is going on. Add the following line at include/database/MysqliManager.php#L315.

@mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Now in the error log we see the following…

2021/03/17 12:21:36 [error] 95950#95950: *450 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught mysqli_sql_exception: The server requested authentication method unknown to the client in /opt/apps/suitecrm/include/database/MysqliManager.php:326
Stack trace:
#0 /opt/apps/suitecrm/include/database/MysqliManager.php(326): mysqli_connect('localhost', 'suitecrm', 'password-redacted', '', '')
#1 /opt/apps/suitecrm/install/checkDBSettings.php(140): MysqliManager->connect(Array, false)
#2 /opt/apps/suitecrm/install.php(363): checkDBSettings()
#3 {main}
  thrown in /opt/apps/suitecrm/include/database/MysqliManager.php on line 326" while reading response header from upstream, client: XX.XX.XX.XX, server: crm.example.com, request: "POST /install.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php-fpm.sock:", host: "crm.example.com", referrer: "https://crm.example.com/install.php"

Okay, so probably a Mysql 8 related issue. Now that we know what the underlying problem is it is easy to resolve. When I create the suitecrm mysql db user I need to make sure and set their auth type to password.

It would be great if SuiteCRM was having mysqli throw errors so that they could be caught and more useful error messages could be displayed (or at least logged) so users don’t need to go learn the code base and insert random logging statements to figure out why something isn’t working (a very basic auth config problem in this case).

Totally agree with you that getting those error messages would be nice! No point in hiding that.

I haven’t seen any recent progress in the ability to use MySQL 8. Current wisdom is that it’s not worth trying, creates multiple problems. Of course, it won’t go forward until somebody actually uses it and drills through all the problems until it works…

Well the mysql auth_plugin could be something other than mysql_native_password also in mysql-5.7. This error would occur anytime mysql was configured to use an auth_plugin that was not supported by php’s mysqli. Of course you won’t know this is the problem unless you hack the SuiteCRM code to expose the underlying mysql error. So yeah, would be good to expose technical error messages…especially during install since the installing user is presumably an “admin” and technical. At the very least they should end up in the logs.

The good news is that once I figured out this was the issue and changed the auth_plugin for that user, the install went without a hitch (mysql-8.0 on Ubuntu 20.04 LTS).

Logging in and everything looks fine so far other than the following message which could be related to mysql-8:

PHP message: PHP Notice:  Array to string conversion in /opt/apps/suitecrm/include/database/DBManager.php on line 887

That code is:

                $sql .= "*/\n";
                $sql .= "/* VARDEF - $name -  ROW";
                foreach ($value as $rKey => $rValue) {
                    $sql .= "[$rKey] => '$rValue'  ";       // line 887
                }
                $sql .= "*/\n";

…php lang warning I think and not mysql-8 related.

I haven’t seen any recent progress in the ability to use MySQL 8. Current wisdom is that it’s not worth trying, creates multiple problems

As far as I read, it seems like the issue with mysql-8 was about new keywords/reserved words that were colliding with some Suite/Sugar naming conventions…but that was patched a couple minor versions ago (I linked to the issue/commit earlier).

The other issue I discovered is just that mysql-8 changed the default auth_plugin to one that mysqli doesn’t support. But that is a common DB edge-case and just not well handled by the SuiteCRM db code…and not specific to mysql-8.

Is there any documentation or github issue that lists current known problems with mysql-8 or is it mostly just that it is unknown whether there are other problems because no one has tried to use it yet? If there are a bunch of known issues, then good to know. If not, I am not particularly concerned now that the key/reserved word issue is resolved.

Thanks for all the help!

(as an aside, you might be interested in seeing what I made to improve logging in SuiteCRM: unmerged PR, Documentation preview - but that doesn’t have anything related to mysqli logging).

I don’t think there’s a place on Github where all the MySQL 8.0 issues are tracked together. Might be interesting to create one, similar to this one for PHP 7.4.

If you are feeling brave about MySQL 8.0, please do go ahead and try it. Who knows, after an issue or two solved, it might prove to be a working solution.

I don’t think there’s a place on Github where all the MySQL 8.0 issues are tracked together.

Okay, sounds like there aren’t a bunch of known issues off the top of your head…so that is a good sign that perhaps it is just untested rather than having issues.

We are just testing anyway (whether Suite is interesting alternative to other CRM/project options we are looking at). First step was automating the deploy (most of it anyway). Next step is evaluating how well SuiteCRM supports various potential use-cases and work flows.

But if I run into any mysql-8 issues I will report back. If we use it for a while and don’t have any issues I will try to remember to report that as well.

I just trashed the server since I had been hacking debug statements into the code everywhere and will re-deploy from scratch now on a fresh Ubuntu 20 VM to double-check all my installer issues are now resolved.

Have a great day and thanks again for jumping in to help.

1 Like

@pgr MySQL 8.0 is not supported but I’ve been testing it for many months now and haven’t run into errors that I couldn’t code around. Specifically, since the keyword issues were resolved, I’m only modifying the MySQL settings to turn off (remove) ‘ONLY_FULL_GROUP_BY’ in the SQL_MODE variable and editing some code (…\include\database\DBManager.php) to ignore “Int” datatype length errors during QR&R. I don’t recommend 8 to anyone yet but someone has to test it so I figure why not me…)

1 Like

That is
:cool:

Do you think you can put together a PR with changes needed to make us compatible?

Hi @mcom, summing up…

Sounds like after your months of testing, the only issues with suitecrm and mysql 8 are the following…

  • db errors are not caught/logged so troubleshooting connection issues is difficult.
  • If providing an existing mysql user to suitecrm, make sure auth_plugin on mysql side for that user is mysql_native_password…because some other types are not supported by the mysqli php-mysql connector.
  • ONLY_FULL_GROUP_BY needs to be turned off in SQL_MODE variable
  • DBManager needs to ignore Int datatype length errors during QR&R

Can you elaborate a bit more on the last two? Are they SuiteCRM or mysqli compatibility issues with changes in mysql8? Is the solution changing SQL config on PHP side or changing mode/config on the mysql side?

I guess QR&R is Quick-Repair-and-Rebuild…so wondering why errors specifically come up during this process.

But good to know that after months of testing you have those two issues to report.

The QR&R checks the database described by the vardefs (that’s in PHP) to the one actually existing in the DB manager, and it syncs the database to the vardefs. So it creates and executes queries changing tables and indexes.

FWIW, my test install is running against mysql8.

I did not make any changes to DBManager related to Int types.
I also did not do anything with ONLY_FULL_GROUP_BY.

I just ran a QR&R after installing a language pack, no errors or anything visible.

So I am not really sure what the problem cases are with the issue with Int type and ONLY_FULL_GROUP_BY (ie under what conditions does the problem present itself…or better yet, what is the underlying/root cause of the problem).

@mattp The explanation of the ONLY_FULL_GROUP_BY switch is explained here. Basically starting in MySQL 5.7.5, the default is enabled. While you can just disable it by removing the option from the MySQL server settings, the better long term solution would be to rewrite the offending queries. This would not only remove the error on default installs but could potentially prevent a source of incorrect data which is why I believe the MySQL folks want it enabled by default. In any case, I have not spent any time hunting down the specific queries but I’ll try to look into that if I can get a chance. The INT issue is as pgr explained above. The only time I see it popping an error up is during the Quick Repair and Rebuild. Without a code modification you will get persistent SQL errors listed in the lower screen that get reported every time you do a QR&R. You could safely ignore them if you knew they were only caused by the reported INT length but a regular user is going to think the manual syncing of the vardefs keeps failing when it really worked. This is all caused by a change starting in MySQL 8.0.17 where it no longer reports the (display) length of an INT as 11. More on this can be found here. This is the relevant part:

Display width specification for integer data types was deprecated in MySQL 8.0.17, and now statements that include data type definitions in their output no longer show the display width for integer types…

My modification just ignores the sync error if it was caused by an INT length validation failure. Now if any SuiteCRM code or 3rd party add-in depended on the reported (display) length of an INT then it could possibly get messed up but I haven’t run into any problems. I’ll need to do some more testing on the upgrade process to make sure it doesn’t use different db validation code.

I’d love to find a complete list of outstanding MySQL 8 issues so I don’t miss something I didn’t know about… I did do a search for a “list” of MySQL 8 issues but didn’t come up with anything. I wonder if SuiteCRM 8 will be able to use MySQL 8 out of the box or if it too uses similar dbmanager code.