Hello, I have a problem. I am running in the following setup: 2 servers * Debian Squeeze * ISPConfig 3.0.4.6 Installed through the perfect server manual. When I update a password for a site database this change is added to the jobqueue. When the jobqueue is empty I try to login to the database and get an error 1045. When I try to logon with the old password this works. It seems to be only a problem with the databases which reside on the slave server. On the master server I have no problems... What can be the problem and how can I fix this? Regards, Bas Steelooper
Did this setup work before or is it a new setup, so this is the first database that you added to the slave server? Which tutorial did you use to install your server?
Hello Til, The setup is about 6 month old, and was working when we set it up. It seems that in one of the updates something went wrong. I used the perfect server for debian squeeze. The strange thing is dat only the mysql is not updated.. I hope you can help me. regards, bas steelooper
I did some tracing in the updates. If I update a record on the master server for a MySQL user it appears to change in the master database. It appears in the job-queue, and disappears again. In the slave database I don't see an update in the password for the web_database table. These are not in sync at the moment Also in the mysql database I don't see an update for the password, but I think that the script gets it from the web_database and that has different data Hope this helps in troubleshooting and fixing this issue for me.
Please enable debugging for the slave server in the ispconfig controlpanel of the master server, then run the server.sh script on the slave and post the output that you get on the shell. http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/
After enabling debug run the server.sh Code: root:~# /usr/local/ispconfig/server/server.sh 07.09.2012-09:30 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 07.09.2012-09:30 - DEBUG - No Updated records found, starting only the core. /usr/bin/fail2ban-client /sbin/iptables /sbin/ip6tables 07.09.2012-09:30 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. Changed a database pw and run the script again Code: root:~# /usr/local/ispconfig/server/server.sh 07.09.2012-09:33 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 07.09.2012-09:33 - DEBUG - Found 1 changes, starting update process. 07.09.2012-09:33 - DEBUG - 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_user`,`database_password`,`database_charset`,`remote_access`,`remote_ips`,`active`) VALUES ('27','11','9','riud','ru','','3','mysql','<REMOVED>','<REMOVED>','<REMOVED>','','n','','y') 07.09.2012-09:33 - DEBUG - Calling function 'db_update' from plugin 'mysql_clientdb_plugin' raised by event 'database_update'. 07.09.2012-09:33 - DEBUG - Changing MySQL user password for: c8gesignit 07.09.2012-09:33 - DEBUG - Processed datalog_id 1725 07.09.2012-09:33 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished.
The database doesn't reflect any change... It seems if the command is executed, but not against the database.... but that is strange since other parts are updated (FTP for instance) only the web_database table not. Also I see that one of the passwords is still plain text... I entered on installation P@ssw0rd as the password, and that is readable (not encrypted) in the database..
