Hello we updated our servers to 3.0.4.5 and we have problem with edit mailbox user. Password change doesnt work. We are changing in standard way via admin and mailbox edit form. After submit form with new password interface said save, but any changes. Password still old one. Any other changes as forwarder, mail copy, autorespond etc. work without problem, only change password doesnt work. We have setup with two servers: Server 1: www, dns, mysql Server 2: mail, dns I tried find some errors in logs but nothings on both servers. I tried mysql permissons too, but all settings is good without errors. Where can be problem? We need fix it, its very big problem!
See FAQ for instructions on how to debug a ispconfig server: http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ You have to run the server.sh script on the slave in debug mode.
I tried it and nothings in log, here is output: master: 04.06.2012-12:35 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 04.06.2012-12:35 - DEBUG - No Updated records found, starting only the core. 04.06.2012-12:35 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. slave: 04.06.2012-12:49 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 04.06.2012-12:49 - DEBUG - No Updated records found, starting only the core. 04.06.2012-12:49 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
Still same, only new one, but its another problem with OpenVz. FATAL: Error inserting ip_tables (/lib/modules/2.6.32-7-pve/kernel/net/ipv4/netfilter/ip_tables.ko): Operation not permitted
And you areareally sure that you disabled (commented out) the server.sh cronjob in the root crontab of the slave server as described in the FAQ?
Yes, cron is commented and disabled, but still only: 04.06.2012-14:56 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 04.06.2012-14:56 - DEBUG - No Updated records found, starting only the core. 04.06.2012-14:56 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
I tried look to the database after update and in database on master server in table mail_user is password changed. I will try look to the slave mysql, maybe some problem in synchronization between servers. But in mysql log on slave is all without problem.
The server.sh script is the synchronisation script of the dbispconfig databases on master and slave, so you should see the sync when you run it manually. Please note that only ispconfig can sync the records between the local database of the master and the local database of the slave, if you installed any other kind of sync, then the system will fail to update its records. Which guide did you use to install the servers?
Servers is installed about 2 years ago, many versions before worked without problem, after update to 3.0.4.5 has this problem. I tried revert this containers on my localmachine to version 3.0.4.4 and everything work like a charm, so problem must be in somethings new in 3.0.4.5. Servers is installed with this tutorial http://www.howtoforge.com/installin...tabase-servers-on-debian-5.0-with-ispconfig-3 we have only changes in server roles. We have only two servers. I tried SELECT on slave and there is old password, problem must be in synchronization. But permissions are granted, any error in mysql on bot servers. Is somethings new in the synchronization or installer??
Thats ok. As lng as you do not use mysql replication between the servers there should be no problem. No, there had been no changes in the last release in these parts of the software. The last few releases are all bugfix releases without any changes in the way the software works. Just one guess, have you accessed the ispconfig mysql database manually with phpmyadmin and deleted any records? E.f. if you deletd records from sys_datalog table manually or emptied that table on the master or slave, then replication will fail as the server looses the entry point fro replication.
There must be problem, tables on master and slave is different. On master has table a lot of rows but in slave is empty. How can I start replication process? Can I copy this table to slave?
The updaer does not delete values from this table, so either the database table was corrupted or someone deleted records manually or truncated the table. To fix that, edit the table "server" on the master, there you find a record for the slave server, this record has a column "updated". The value in updated is the last ID from sys_datalog that has been processed. You can set the value either to the latest ID in sys_datalog to process all future changes or you set it to a older ID of you want the slave to re-process changes from the last days.
I changed values to old one, now Í see old jobs in queue. In master DB sys_datalog I see pending, but in slave database is sys_datalog still empty. I will try wait for cron. Now I must go to the meeting, I will see tomorrow morning and I will write result. Thanks for help.
Hi, I tried some things with DB and here is results: 1. After change column updated - nothing 2. After change updated on slave - nothing 3. Update ispconfig from svn - now work So I made change column updated on both servers, I deleted lock in temp and I performed update to svn version. After this slave began with replication, but queue on master was stoped and slave worked, so I performed update from svn on master too and after this everything worked like a charm. With version 3.0.4.5 stable system looks like cron didnt work and queue was stoped, after update every job in queue started and now its all clean and everything work. I tested cron too and cron worked without problem. I dont know where is problem and what was a right solution. Evening I will try update on localhost not production and I will see. Thank you very much for some hints.
Error in 3.0.4.5 I tested install 3.0.4.5 on testing containers and here is the problem. If I comment cron and perform server.sh manually with debug I got this this message in debug: Fatal error: Call to undefined method plugins::registerAction() in /usr/local/ispconfig/server/plugins-available/backup_plugin.inc.php on line 54
You downgraded a ispconfig svn version (currently ispconfig 3.0.5 prerelease) to a stable version (currently 3.0.4.5) and this causes your problems. Downgrades are not possible as the database structure and libraries of the svn version are newer then the ones of the stable version.
Yes there is a problem, yesterday a tried some tests and on master I performed downgrade and I deleted missing plugin and some other files, then I performed new install 3.0.4.5 and now it work, on slave is SVN version. Now work both servers.
In a multiserver setup, all servers should run the same ispconfig version. Using stable on master and svn on slave might lead to problems like data replication failures as the database structure and code differs, so that the master si now not sending all data that is needed by the slave to work properly (missing fields, changed field values etc). I recommend that you either downgrade the slave too or upgrade both servers to svn.
Yes everything now work, only slave with downgrade made problems. I wanna try same steps on slave tis night. I will response my results here.
