Replies: 5 comments
-
Going back through to verify I didn't miss any steps....looking at https://www.azerothcore.org/wiki/common-errors I do see a similar, but not exact error message. I have enabled the SQL logging options in worldserver.conf, but get no additional error logs in the log folder. I also checked /var/log/mysql/error.log , but nothing in there about failed logins or connections. Only showing service up/down events. I've also seen a few articles online that mention where MySQL will try to force localhost/127.0.0.1 connections to Unix sockets instead of TCP/IP - thought maybe if that were the case it was also automatically failing back to local user. But, I'm able to connect to the DB using the server's LAN IP (e.g. 10.1.1.204) with the acore user just fine from MySQL Workbench. Made sure to test by using the local LAN IP in the authserver.conf DB connection string, but it still attempts to connect as the local console user running the ./autherserver instead of the connection string inside the authserver.conf |
Beta Was this translation helpful? Give feedback.
-
Does not appear related to Ubuntu 22.04 or OpenSSL3 - went back and started a new install on Ubuntu 20.04 with OpenSSL 1.1.1 and having same issue where the AuthServer is trying to connect to a (not named?) MySQL instance with local linux user, not using the connection string inside authserver.conf |
Beta Was this translation helpful? Give feedback.
-
Tested with MariaDB, same results. The error provided is very similar to what would be shown when running mysql from the terminal without specifying a username to connect as (so it implies your current terminal user). I can't imagine something like database connection strings have broken in a recent release, but seems like it's just not building the connection correctly.
Versus when the mysql command is told to use a specific username, it then prompts for password, such as
|
Beta Was this translation helpful? Give feedback.
-
Cause: Special characters in the MySQL user account password. Workaround: Change the special characters being used in the MySQL account password. I originally had a "#" and a "&" in the MySQL user account being used. This account would login OK from the command line and even MySQL Workbench. Replacing the # and & with ? and ^, now authserver and worldserver launch correctly. Seems to be something with how ACore is pulling in those SQL connection strings from the .conf file so they are not being passed to MySQL correctly (since the characters themselves appear to be valid as password characters within MySQL itself). Converting this to an issue. Not sure if a fix can be applied or there is already a known issue for certain special characters being used by ACore (I haven't been able to find reference to this yet). |
Beta Was this translation helpful? Give feedback.
-
Closing discussion, issue has been opened: #15415 |
Beta Was this translation helpful? Give feedback.
-
Greetings everyone -
Have tried a few different cores over the years and this time around going with AC for the first time (Ubuntu-based). Have everything cloned, built, extracted, configured, etc. but running into something I haven't seen before.
The default "acore" database user has been given a new password in MySQL, and can successfully login manually with the new password using
mysql -u acore -p
authserver.conf and worldserver.conf are updated with the new password:
LoginDatabaseInfo = "127.0.0.1;3306;acore;<updated password>;acore_auth"
However, when launching ./authserver or ./worldserver (still first time), it errors with
indicating it is trying to login to MySQL as my linux console user, not the "acore" database user as defined in the .conf files. Is there a setting I missed somewhere that tells the startup scripts to use the DB user instead of local console user?
The above output is on console, then also the same message is in the Auth.log. I do also have a DBErrors.log file generated, but it is empty (no info is written to it).
Thanks in advance!
Edit: Also confirmed it wasn't something weird about MySQL thinking it was a remote connection rather than local. Configured the bind-address on MySQL to allow all local connections, and I can connect OK to the DB from another PC using MySQL Workbench and the "acore" user. Even after allowing remote connections to MySQL, the authserver and worldserver still are attempting to use the local linux console user to login instead of the values in the .conf files.
Beta Was this translation helpful? Give feedback.
All reactions