Have asked this question on Ask OpenStack, but few views and no responses.
I'm trying to use the SqlAlchemy (basically MySQL) driver and have found that the password the driver attempts to use is set to ''. This is the password for the driver used by the reporting API, not collection.
I assume this is a default set somewhere, but I can't find it. Have looked through the config and setup files, and tried to find where the CFG object is created, and even traced through with the debugger.
The reason I know it's a password problem is because when the MySQL password is set to something other than '', the driver encounters a MySQL authentication error. When I set the database password (in MySQL for root user) to empty, the driver can authenticate.
My localrc has MYSQL_PASSWORD set to 'password', but the driver can't authenticate when MySQL uses that password.
Anyone know where to set this password for the driver?
I found it, the file ceilometer/storage/__init__.py contains a struct called STORAGE_OPTS. Adding a similar entry to the array will cause it to use the DB of your choice:
cfg.StrOpt('database_connection',
default='mysql://root:password#localhost:3306',
help='Database connection string',
),
Related
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.
I'm trying to open a connection to a db via the DriverManager. When I use the getConnection(url, properties) function it works fine, however when I try to append the username and password (something like jdbc:mysql:address;user=user;password=password) to the url and call getConnection(url) I get the following error
Access denied for user ''#'localhost' to database 'db_aux_linux64_mysql;user=user;password=password'
So while it was able to find the db, it is trying to pass in an empty string as the user argument (and probably the password as well) for some reason. Any ideas on why this might be?
You're using the wrong url syntax, try this:
Connection conn = DriverManager.getConnection("jdbc:mysql://hostname/dbname?user=user&password=password");
Note: Don't forget to add your database name after your hostname -- the error message you are getting is indicating that the jdbc driver is looking for a database that is literally named "db_aux_linux64_mysql;user=user;password=password".
Alternatively, you can just use the DriverManager.getConnection(url, uname, pass) as suggested in the comments, then you don't need to remember the url syntax for your jdbc driver (and your code will be more portable since each jdbc driver is subject to having different url syntax).
Source: Mysql doc seciton 6.1
I've had a good search around but not yet found an answer that allows me to rectify this problem.
I'm trying to connect from MS Access to a MySQL 5.2 database on a remote server.
I've set up a user account which has select, insert, update, delete privileges on the table in question. However, when I try to connect with this account, I get:
Connection Failed [HY000][MySQL][ODBC 5.2(w) Driver] Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)
When I try to access with the root account, the connection works, which makes me wonder why it's returning an authentication protocol error, since the same driver is being used - all that's changing is the account used - so surely is passing the password via the same authentication protocol? Why would one username/password combination return a protocol error but not another?
It seems this error is very common, but I haven't yet found a response that gives a clear solution. Can you help?
The problem here was due to two concurrent issues.
On the remote server, the global setting OLD_PASSWORDS was set to 1 - meaning that passwords were being hashed in the pre-4.1 method.
the root account had been encoded in the newer hashing method despite the global setting (presumably it had been entered before this parameter was set), meaning that it was being granted access via the ODBC connection because the new hashing was beign recognised.
The global setting caused the PASSWORD() function in MySQL to hash any entered value in the old method instead of the new method as it was supposed to.
I assumed that the DBA had set OLD_PASSWORDS to 1 for a good reason so as a solution I used
Set session old_passwords=0;
set password for 'user'#'%' = password('mypassword');
Using the password() function had not worked previously because the global setting OLD_PASSWORDS=1 caused it to use the same hashing as the OLD_PASSWORD() function. The session setting allowed it to produce the correct password.
"When I installed 5.1.12 instead, I had no problems"
Ditto! Just successfully authenticated into MySQL using ODBC driver version 5.1.12. I have NO idea why MySQL doesn't provide a better way to handle this error w/ its newer drivers, but i can confirm that using ODBC driver 5.1.12 DOES work.
Here is a link to the 5.1.12 ODBC driver installation page.
http://dev.mysql.com/downloads/file.php?id=411741
I was getting the same error message, while my co-worker was not having any problems. I was trying to use MySQL ODBC driver 5.1.13 (the latest GA version available) and she had 5.1.12. When I installed 5.1.12 instead, I had no problems.
I'm trying to connect to a mySQL database at http://bluesql.net, but when I try to connect, it gives this error:
Connect Error (2000) mysqlnd cannot connect to MySQL 4.1+ using old authentication
I've looked into this, and it has to do with some old password scheme used before MySQL 4.1. Newer versions have the option to use old passwords, which I've read may cause this problem.
I'm running php 5.3, and connecting with mySQLi (new mysqli(...)). I'm hoping I can do something in the code to connect to the DB at bluesql.net - clearly I don't control how their database is set up. Downgrading php versions isn't an option.
Anyone have any ideas?
edit: This only applies if you are in control of the MySQL server... if you're not take a look at Mysql password hashing method old vs new
First check with the SQL query
SHOW VARIABLES LIKE 'old_passwords'
(in the MySQL command line client, HeidiSQL or whatever front end you like) whether the server is set to use the old password schema by default. If this returns old_passwords,Off you just happen to have old password entries in the user table. The MySQL server will use the old authentication routine for these accounts. You can simply set a new password for the account and the new routine will be used.
You can check which routine will be used by taking a look at the mysql.user table (with an account that has access to that table)
SELECT `User`, `Host`, Length(`Password`) FROM mysql.user
This will return 16 for accounts with old passwords and 41 for accounts with new passwords (and 0 for accounts with no password at all, you might want to take care of those as well).
Either use the user management tools of the MySQL front end (if there are any) or
SET PASSWORD FOR 'User'#'Host'=PASSWORD('yourpassword');
FLUSH Privileges;
(replace User and Host with the values you got from the previous query.) Then check the length of the password again. It should be 41 now and your client (e.g. mysqlnd) should be able to connect to the server.
see also the MySQL documentation:
* http://dev.mysql.com/doc/refman/5.0/en/old-client.html
* http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html
* http://dev.mysql.com/doc/refman/5.0/en/set-password.html
If you do not have control of the server
I just had this issue, and was able to work around it.
First, connect to the MySQL database with an older client that doesn't mind old_passwords. Connect using the user that your script will be using.
Run these queries:
SET SESSION old_passwords=FALSE;
SET PASSWORD = PASSWORD('[your password]');
In your PHP script, change your mysql_connect function to include the client flag 1:
define('CLIENT_LONG_PASSWORD', 1);
mysql_connect('[your server]', '[your username]', '[your password]', false, CLIENT_LONG_PASSWORD);
This allowed me to connect successfully.
Edit: as per Garland Pope's comment, it may not be necessary to set CLIENT_LONG_PASSWORD manually any more in your PHP code as of PHP 5.4!
Edit: courtesy of Antonio Bonifati, a PHP script to run the queries for you:
<?php const DB = [ 'host' => '...', # localhost may not work on some hosting
'user' => '...',
'pwd' => '...', ];
if (!mysql_connect(DB['host'], DB['user'], DB['pwd'])) {
die(mysql_error());
} if (!mysql_query($query = 'SET SESSION old_passwords=FALSE')) {
die($query);
} if (!mysql_query($query = "SET PASSWORD = PASSWORD('" . DB['pwd'] . "')")) {
die($query);
}
echo "Excellent, mysqli will now work";
?>
you can do these line on your mysql query browser or something
SET old_passwords = 0;
UPDATE mysql.user SET Password = PASSWORD('testpass') WHERE User = 'testuser' limit 1;
SELECT LENGTH(Password) FROM mysql.user WHERE User = 'testuser';
FLUSH PRIVILEGES;
note:your username and password
after that it should able to work. I just solved mine too
On OSX, I used MacPorts to address the same problem when connecting to my siteground database. Siteground appears to be using 5.0.77mm0.1-log, but creating a new user account didn't fix the problem. This is what did
sudo port install php5-mysql -mysqlnd +mysql5
This downgrades the mysql driver that php will use.
Had the same issue, but executing the queries alone will not help. To fix this I did the following,
Set old_passwords=0 in my.cnf file
Restart mysql
Login to mysql as root user
Execute FLUSH PRIVILEGES;
If you do not have Administrator access to the MySQL Server configuration (i.e. you are using a hosting service), then there are 2 options to get this to work:
1) Request that the old_passwords option be set to false on the MySQL server
2) Downgrade PHP to 5.2.2 until option 1 occurs.
From what I've been able to find, the issue seems to be with how the MySQL account passwords are stored and if the 'old_passwords' setting is set to true. This causes a compatibility issue between MySQL and newer versions of PHP (5.3+) where PHP attempts to connect using a 41-character hash but the MySQL server is still storing account passwords using a 16-character hash.
This incompatibility was brought about by the changing of the hashing method used in MySQL 4.1 which allows for both short and long hash lengths (Scenario 2 on this page from the MySQL site: http://dev.mysql.com/doc/refman/5.5/en/password-hashing.html) and the inclusion of the MySQL Native Driver in PHP 5.3 (backwards compatibility issue documented on bullet 7 of this page from the PHP documentation: http://www.php.net/manual/en/migration53.incompatible.php).
IF,
You are using a shared hosting, and don't have root access.
you are getting the said error while connecting to a remote database ie: not localhost.
and your using Xampp.
and the code is running fine on live server, but the issue is only on your development machine running xampp.
Then,
It is highly recommended that you install xampp 1.7.0 . Download Link
Note: This is not a solution to the above problem, but a FIX which would allow you to continue with your development.
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.