What is the "Path to MySQL shared libraries directory"? (I upgraded from 5.7 to 8)

I finally decided to upgrade from the stagnant MySQL 5.7 to the new MySQL 8 version on my inside the LAN server that only runs Webmin.

Almost all is well. I manage the databases mostly with phpMyAdmin, and that’s working fine. During the config part of the upgrade I decided to not use the new password encryption until later on. That may have helped the upgrade go smoother.

If I try to access the database with the Webmin interface, I can’t do it, all I see is the image below, and I don’t understand the error message:
DBI connect failed : Lost connection to MySQL server at 'reading authorization packet', system error: 95


.

Naturally, I poked around the :10000/config.cgi?mysql&xnavigation=1 page to see what was different. I noticed the Path to MySQL shared libraries directory had /usr/local/mysql/lib in it and that folder no longer exists. Switching the radio-button to None for that option doesn’t change anything that I can see. I don’t know how to discover where the upgrade put shared libraries and thinking I was doing the right thing, I ran sudo apt-get install libmysqlclient21 because that’s supposed to be the MySQL 8 community versions shared library installer.

The rest of the settings seemed valid. Though it’s been a real lifesaver for me in the past, I can live without this Webmin Servers interface working, but it seems like were collectively overdue to start upgrading our database versions.

I saw something significant while trying to debug where in the source documentation conveys a message about having the mysql user possessing a home directory in /ust/local/mysql so maybe we are heading in to a lot of minor changes?

https://dev.mysql.com/doc/refman/8.0/en/data-directory-initialization.html

Okay, looks like the latest version of Webmin didn’t cure the problem.

I have to disagree with you there. I see you’re running Ubuntu 16.04 LTS which is a Grade A tested release. When you upgraded to MySQL 8 you basically made your installation an untested configuration. If there’s a reason you need a newer MySQL I think it’s better to move to a newer Ubuntu release that’s tested, supported and contains the MySQL release you require. That way the community (or the devs if they can spare the time) can easily reproduce what you’re dealing with.

That being said, I wouldn’t keep my hopes up for a virtualmin release to fix this issue unless it also happens in Ubuntu 20.04 which ships with MySQL 8.

1 Like

@WNYmathGuy, I’ve recreated an Ubuntu 16.04 server with vagrant and upgraded to MySQL 8 using Oracle’s official repository. In the apt config I chose to install the package maintainers version of my.cnf due to the 5.7 version containing incompatible options which trips up configuration scripts in the apt packages.

After the upgrade the MySQL module works without any problem. Both with the older “mysql_native_password” auth method and the newer “caching_sha2_password” method it works without a hitch. I’ve also checked if the Path to MySQL shared libraries directory option in Webmin and it contains the same non existent path on my system, so that’s a dead end.

Hopefully this helps you narrow down the problem.

Thanks. Like most things. Fresh install works fine. Years of upgrades and changes, who the hell knows what’s going to work. On my virtualmin managed server with Ubuntu 18.04 I have MariaDB and I upgraded that to 10.5.4 without any big problems.

I wonder if I put a copy of the file a fresh install makes into the right place if it would fix the problem.

It’s not expected to. If you change where MySQL is installed, you have to configure Webmin to know about those locations (at least my.cnf and the start/stop commands need to be right, etc.). That’s not optional and not something we can know how to guide you on…I don’t know where your new files live.

But, this specific error actually looks like DBI is having trouble communicating with MySQL. You may need to upgrade the Perl MySQL DBI module to be compatible with your new MySQL version, or disable Webmin using DBI (I’m not sure if that’s configurable…it may just use it if it’s available ,which is normally preferable as it can be faster). I don’t know. This is somewhat dangerous territory.

Anyway, I really don’t recommend randomly replacing important packages unless you really know what you’re doing and plan ahead (with good backups, in particular). A database upgrade can be pretty dramatic. Webmin and Virtualmin will support it, most likely (though I think there were still some changes in MySQL 8.0 that were causing issues for folks in Virtualmin up until recently…maybe they’ve been fixed), but a lot of things might have to change or be upgraded to accommodate it in other areas (your apps, libraries that communicate with MySQL, etc.).

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.