Recently I upgraded the servers in our multi-server ISPConfig setup, from 3.0.4.1 to 3.0.4.2 And now databases created via the remote API commands are created successfully, BUT the passwords appear wrong, and MySQL users cannot login. So all future databases created via our system (with remote API calls) no longer work. I tested this turning on debugging in ISPConfig, and created 2 databases, one directly via ISPConfig web interface (CP), and the second the remote API. 1st database from CP worked, 2nd from remote API failed (user could not log into MySQL). Password used in this test was: test123 Debug from standard web interface command: Code: Replicated from master: REPLACE INTO web_database (`database_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_id`,`type`,`database_name`,`database_use r`,`database_password`,`database_charset`,`remote_access`,`remote_ips`,`active`) VALUES ('386','1','24','riud','ru','','6','mysql','db_db2','fb_restaurant2','*676243218923905CF94CB52A3C9D3EB30CE8E20D','','n','','y') Debug from remote API command: Code: Replicated from master: REPLACE INTO web_database (`database_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_id`,`type`,`database_name`,`database_use r`,`database_password`,`database_charset`,`remote_access`,`remote_ips`,`active`) VALUES ('387','24','24','riud','riud','','6','mysql','db_db','fb_restaurant','cc03e747a6afbbcbf8be7668acfebee5','','n','','y') I can see the password values are completely different. Is this a bug with 3.0.4.2 remote API, or has the remote calls/code changed? Is this similar to the issue highlighted here: http://www.howtoforge.com/forums/showthread.php?p=272272
This has already been fixed in stable svn, please see bugtracker: http://bugtracker.ispconfig.org/index.php?do=details&task_id=1995
Thanks, rather than installing the full svn version, I downloaded a copy of the svn files, compared to stable, and found this file was the problem: interface/lib/classes/remoting_lib.inc.php So I copied the svn version of this file over my stable, and now sites_database_add works I presume when I next update ispconfig (using ispconfig_update.sh), the remoting_lib.inc.php file will be overwritten?
Hi, I'm using latest version 3.0.4.3, and I' facing the same problem. For some reason in my machine doesn't work even replacing the file interface/lib/classes/remoting_lib.inc.php with the latest svn trunk version. Can anyone let me know how to fix for this version? or send me the remoting_lib.inc.php that is working, perhaps? Thanks!
Adding databases with the api works fine in 3.0.4.3, so yourproblm must be something else. Please see ispconfig faq for debugging instructions.
I don't think it works as expected. When creating a db from the API it should grant permissions for the cli as well, right? If I create a database from the web interface, then I can log in from command line. If I create a database from the remote api, then I cannot log in from the command line (Access denied). BUT, if I create a database from the web interface, then delete it, and then create the same database from the remote api, then I can log in from the command line. It looks to me that is a grant permissions issue, or it is that a manual step when using the remote api?
The permissions depend on the parameters atht you pass to the sites_database_add function, so if access is granted or not depends on the parameters that your script passes to the function. Which exat paramaters and parameter array do you pass to the sites_database_add function of the remote api? You might also want to try the example script for the sites_database_add on your server and compare it with your own script.
PHP: $params = array( 'server_id' => 1, 'type' => 'mysql', 'database_name' => $database_name, 'database_user' => $database_username, 'database_password' => $database_password, 'database_charset' => '', 'remote_access' => 'y', 'remote_ips' => '', 'active' => 'y' ); $database_id = $remote_user->sites_database_add($session_id, $client_id, $params); Am I missing something?
I've just tested the remote api on afresh ispconfig 3.0.4.3 server again with the example scripts that ship with ispconfig and creating a database works fine and login to this database works too as well, so there is no problem with the api. I used this example script: Code: $client = new SoapClient(null, array('location' => $soap_location, 'uri' => $soap_uri, 'trace' => 1, 'exceptions' => 1)); try { if($session_id = $client->login($username,$password)) { echo 'Logged successfull. Session ID:'.$session_id.'<br />'; } //* Set the function parameters. $client_id = 1; $params = array( 'server_id' => 1, 'type' => 'mysql', 'database_name' => 'db_name2', 'database_user' => 'db_name2', 'database_password' => 'db_name2', 'database_charset' => 'UTF8', 'remote_access' => 'y', 'remote_ips' => '', 'active' => 'y' ); $database_id = $client->sites_database_add($session_id, $client_id, $params); echo "Database ID: ".$database_id."<br>"; if($client->logout($session_id)) { echo 'Logged out.<br />'; } } catch (SoapFault $e) { echo $client->__getLastResponse(); die('SOAP Error: '.$e->getMessage()); } ?>
You are right, the problem wasn't the api, for some reason ispconfig stopped communicating to mysql. It was working before that's why I thought the problem would be still in the api even after upgrading. I had to uninstall and install again ispconfig and everything worked fine. Thanks for your help!
Just a guess, maybe you changed the mysql root password without settings the new root password in /usr/local/ispconfig/server/lib/mysql_clientdb.conf too?