I've set up a very basic LAMP setup on an ec2 server, all good it seems to work.
However i've seen for some queries a failure to connect to the mysql server with the following error:
[07-Jul-2013 20:15:41 Australia/Sydney] PHP Warning: mysql_real_escape_string(): Access denied for user 'ec2-user'#'localhost' (using password: NO) in /var/www/html/mycobber/class/sql/SqlQuery.class.php on line 40
[07-Jul-2013 20:15:41 Australia/Sydney] PHP Warning: mysql_real_escape_string(): A link to the server could not be established in /var/www/html/xxx/xxxx/sql/SqlQuery.class.php on line 40
the thing i dont' understand is the fact that in no location in my mysql connection configuration does it specify the user ec2-user. this is the default user when I log onto the unix server. I've set up a separate account to actually run all my processes, i dont' even use the es2-user.
I've looked online and can't see anything to explain this. does anyone have an idea what's going on here. it's not all the time
Your can't call mysql_real_escape_string without having opened a connection with mysql_connect first.
Quoting from the documentation:
A MySQL connection is required before using mysql_real_escape_string() otherwise an error of level E_WARNING is generated, and FALSE is returned.
The error message refers to your default username # localhost because you haven't opened a connection with specific credentials yet - it doesn't know what account details to use.
Related
I am using the following DBD::mysql statement to connect to a MySQL database:
use DBI;
# Connect to the database.
my $dbh = DBI->connect("DBI:mysql:database=test;host=localhost",
"usr", "usr's password",
{'RaiseError' => 1});
Is there a way to check if MySQL service is running, before trying to connect to the database? What if the database is running on a remote server?
If you want a solution to check if the service is running without attempting to connect to it, you could use some Perl package to check the process table (works locally only), or check that the MySQL port (3306 by default) has a process listening to it.
I'm not sure what the purpose of this check is, because even if the service is running, the next thing you'll probably want to do is open a DB connection. Opening a DB connection is a quick and easy thing to do, and it has good error reporting if it doesn't work. So your intention to check that the service is running first is just unnecessary overhead.
I would just try to connect as you are doing. This is the most direct way of checking that the service is running, and it works both locally and remotely.
If there's an error, catch the error and interpret the error message. It'll be error 2002 (for localhost) or 2003 (for TCP/IP, whether it's the same host or a remote host).
These errors are mostly reliable. But there could be red herrings, for example if the service is running on a remote host, but your client host can't reach it because of firewalls or routing issues.
If you get an error 1045 (Access Denied), at least you know the service is running and you can reach it, the problem is only that your user & password are incorrect, or you tried to access a schema you don't have privilege to use.
My Ansible/Rundeck host is an Ubuntu 20.04 LTS system. I installed Ansible to tinker and then installed Rundeck. Once I was able to get the two talking and working properly (in my mind), I thought it would be best to move Rundeck to a production level DB engine instead of H2. I installed MySQL on the same host and setup the DB and the DB user as directed in the Rundeck docs. I then modified the RD properties file as the same document instructs but I keep getting a failure to connect to the database.
First it was this error:
WARN internal.JdbcEnvironmentInitiator - HHH000341: Could not obtain connection metadata : Could not connect to address=(host=10.10.140.23)(port=3306)(type=master) : Socket fail to connect to host:10.10.140.23, port:3306. Connection refused (Connection refused)
So then I researched the issue and it suggested to validate the user account in MySQL, grants, access, etc. - It all works from a command line testing in MySQL.
I read in one of my searches that some people had luck with removing the useSSL=false or setting it to true. That led to my next error of:
WARN internal.JdbcEnvironmentInitiator - HHH000341: Could not obtain connection metadata : Could not connect to address=(host=localhost)(port=3306)(type=master) : RSA public key is not available client side (option serverRsaPublicKeyFile)
During my research on this error, I read that I needed to add a property to allow the retrieval of the RSA keys, and I did but it didn't change a thing.
I then downloaded the Oracle MySQL jdbc driver and placed it in the var/lib/rundeck/lib folder and changed the driver class name in the properties file and then I received my next error of
WARN internal.JdbcEnvironmentInitiator - HHH000341: Could not obtain connection metadata : Could not connect to address=(host=127.0.0.1)(port=3306)(type=master) : (conn=355) Access denied for user 'sa'#'localhost' (using password: YES)
Current charset is UTF-8. If password has been set using other charset, consider using option 'passwordCharacterEncoding'
when I attempted to run Rundeck.
At this point I am back on H2 and I am too much of a Linux novice to understand what the issue may be. Can anyone kindly point me in a direction that helps as the Rundeck docks for using a MySQL DB seem to either be old or missing some content as a lot of the searches I have made on trying to resolve the issue directs me to perform things slight differently or all new commands that the Rundeck docs don't even mention.
I've fixed same issue stopping the Rundeck instance, later adding the following config on the rundeck-config.properties file (at /etc/rundeck path, check this):
# works with allowPublicKeyRetrieval=true
dataSource.url = jdbc:mysql://mysql_server_ip/rundeck?autoReconnect=true&useSSL=false&allowPublicKeyRetrieval=true
dataSource.username=rundeckuser
dataSource.password=your_password
dataSource.driverClassName=com.mysql.cj.jdbc.Driver
# to store projects on backend
rundeck.projectsStorageType=db
Next, flushing the connections on the database side with mysqladmin flush-hosts -u root -p.
Now, starting your Rundeck service, you can check that is using MySQL 8 as a data source for your projects.
EDIT: On the MySQL side, make sure that you've created the user properly, I followed these steps:
CREATE DATABASE rundeck;
CREATE USER 'rundeckuser'#'%' IDENTIFIED BY 'P4ssw0rd';
GRANT ALL PRIVILEGES ON rundeck.* TO 'rundeckuser'#'%';
exit;
Also check how MySQL 8 is storing the user's passwords.
After reading multiple questions of users with problems like:
forgot password
installed multiple instances of MySQL
forgot to start MySQL
etc. etc
I started to consider if it is actually possible to conclude from the error page if MySQL is running at all?
Questions with the same type of answers:
mysql said: Cannot connect: invalid settings. xampp
phpMyAdmin - can't connect - invalid setings - ever since I added a root password - locked out
MySQL Says: Cannot connect: invalid settings
But does the error page actually say this is a mysql server response or it couldn't connect (server isn't running for instance)
Take the following code:
<?php
//Step1
$db = mysqli_connect('localhost','username','password','database_name')
or die('Error connecting to MySQL server.');
?>
If one of the inputs is incorrect you will get the error:
Error connecting to MySQL server.
This could be modified into a nice looking error message (as the image above).
So does the error actually prove that MySQL is running or not?
I found a video of a walkthrough on how to fix this error. In the video you can see the servers are running. I was pretty curious about this whole issue.
Link to Youtube:
https://www.youtube.com/watch?v=8fK_DYvosA8
I'm assuming if that's how it worked for the video, that's how it works in general. I'm working off the idea that something can't give you an error message unless it's running.
Sort of. phpMyAdmin generally returns the error message that it gets from MySQL, so for instance if the isn't a MySQL daemon listening on on the TCP/IP protocol, phpMyAdmin shows:
#2003 - Can't connect to MySQL server on '127.0.0.1' (111) — The server is not responding.
For an incorrect username or password, the error message is:
#1045 - Access denied for user 'root'#'localhost' (using password: YES)
"Invalid settings" usually means you have conflicting directives or incorrect information in one of your configuration statements. Without seeing your config.inc.php it's difficult to guess what's wrong here, but this also can mean something went wrong between the PHP library itself and MySQL.
The rejected connection message you posted can also have several causes.
Basically, to directly answer your question, you often can tell based on the error message returned by MySQL or the PHP library (which is the message phpMyAdmin shows). "Can't connect" means phpMyAdmin couldn't get any response from the MySQL daemon, which could have several causes but most often means MySQL isn't running. Most of the other error messages mean it's running but there was a problem connecting. Generally the error message contains some information about why.
I'm running a local copy of WordPress on XAMPP/WinXP for development, but would like to maintain a connection to the remote database. I keep getting "Error establishing database connection" no matter what I try.
On the same PC, I can connect to the remote mySQL DB using any number of mySQL clients, and on the mySQL side, the both the user and the database are set to accept incoming requests from any wildcard domain. I can also easily ping the remote database server from my PC (though I don't know how to do it from WITHIN XAMPP).
Is XAMPP its own little universe that can't reach through to the outside world? Or is there something I'm clearly overlooking that's not letting me connect?
Errors
Warning: mysql_connect() [function.mysql-connect]: Premature end of data (mysqlnd_wireprotocol.c:553) in C:\xampp\htdocs\dbtest.php on line 5
Warning: mysql_connect() [function.mysql-connect]: OK packet 1 bytes shorter than expected in C:\xampp\htdocs\dbtest.php on line 5
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication
Edit
Thanks to #Michael for suggesting I just create a simple connection script so I can get better insight into the actual error that's being thrown. This revealed that it had to do with the old_password setting in mySQL. See my Answer below for a full description of how to resolve this issue.
Here's the test script I put inside my xampp\htdocs folder and tested out:
<?php
$mysqli = new mysqli('my.server.address', 'user_name', 'password', 'database_name');
if ($mysqli->connect_error){
die ("Connect error: " . $mysqli->connect_error );
}
I'm not really clear on why this became an issue on my XAMPP installation, since I'm also running PHP 5.3.x on the server's local box and wasn't experiencing those issues there. However, it has to do with my mySQL server running in "old password" encryption mode. Newer versions of PHP won't allow those kinds of connections, so you need to update your mySQL server to use the newer password encryption. Here are the steps, assuming you have control over the mySQL server. If you don't, that falls out of the scope of my knowledge.
locate the configuration file for the mysql server called my.cnf. I found mine at /etc/my.cnf. You can edit it with sudo nano /etc/my.cnf
Look for a line that says old_passwords=1 and change that to old_passwords=0. You have now told the server that the next time it is run, and it is asked to encrypt a password using the PASSWORD() command, it use the new 41-character encryption rather than the 16-character 'old' style encryption
Now you have to restart your mysql server / service. YMMV, but on Fedora that was easily done with sudo service mysqld restart. Check your OS' instructions for restarting the mysql daemon or service
Now we have to actually edit our user table within mysql. So open up an interactive shell to mysql (on the server you can type mysql -uYourRootUsername -pYourRootPassword)
Change to the mysql database. This is the database that holds all the good stuff for server operation and authentication. You must have root access to work with this database. If you get an 'access denied' you're SOL. Sorry. use mysql; will switch to that database
Now we want to update the user that was giving you grief. Ultimately you'll probably want to update all your users, but for now, we're just focusing on the user that threw the error. update user set Password=password('YOUR_PASSWORD') where User='YOUR_USERNAME';
Now you just need to tell mysql to use the new password for authentication when that user attempts to connect. flush privileges;.
You should be good to go!
I have a Perl script that gets data from a MySQL database on one server (let's call it server1), does stuff with it and writes it out to another database on another server (server2). Both servers are remote to the server that runs the Perl script.
I can connect to the DB on server1 OK, but when I try to connect to the DB on server2, using the same DBI method, I get an error. Here, as command-line Perl, is the bit that's causing the error:
perl -MDBI -e 'DBI->connect("DBI:mysql:myDB:server2.whatever.co.uk","myuser","mypassword") or die DBI->errstr;'
And here's the error message:
DBI connect('myDB:server2.whatever.co.uk','myuser',...) failed: Client does not support authentication protocol requested by server; consider upgrading MySQL client at -e line 1
Client does not support authentication protocol requested by server; consider upgrading MySQL client at -e line 1.
I do not have root access so I can't upgrade MySQL and I can't change the password to use the old password hashing algorithm, which is the solution suggested in lots of places.
Ideas anyone?
The database may be set up to accept connections only from within a certain set of addresses, as a security measure. So if you're trying to access a prod database from a home laptop (for example), it may reject you, even if you have the proper credentials. Try accessing it from a place where it's known to work using another technology -- for example, if you have a website that accesses it already, go to wherever apache/tomcat is running, and try the perl there. If it works, that's the issue. You can also proactively check on the database settings.
OK, in the absence of an alternative, I got someone with root access to server2 to do the fix that's published elsewhere:
Connect to MySQL as the MySQL root user, then:
mysql> use mysql;
mysql> SET PASSWORD FOR 'username'#'hostname' = OLD_PASSWORD('password');
mysql> FLUSH PRIVILEGES;
Replacing 'username', 'hostname' and 'password' with appropriate values.
So what I'm saying here is, it seems like if you don't have root access to upgrade MySQL or to change the password to use the old password hashing algorithm, then the only solution is to find someone who does who can make the change for you.