I moved the master and slave server to new IP addresses. The slave server is a mail server. If I add a mailbox in the ispconfig interface, only the red circle is lit that the action is being performed and will never go out. Finally, the monitoring section is not up-to-date information about the slave server, there is old information before the change. But the mailbox is actually added to the slave server. Only the ispconfig interface doesn't recognize it. Log says nothing . Database connection from both sides works. Where to look for a problem?
https://www.howtoforge.com/community/threads/please-read-before-posting.58408/ http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ Did you change IP addresses on all hosts in /etc/hosts file and other places where it appears?
128/5000 ISPConfig test script did not find any error the same Debugging of ISPConfig 3 server is also error free. Yes hosts I edited.
That is strange if the red circle stays on top. Are you sure you did turn on debugging and ran the server script on the server that has the error?
The output on the master server looks like this: Code: 13.12.2019-21:20 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 13.12.2019-21:20 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. On the slave server: Code: 13.12.2019-21:23 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. Yes, the red circle is still at the top, but the requested action on the server is done correctly. I think it will be some bug right in the interface.
Quite unlikely. The more likely reason is that the permissions of the ispcsrv* user of that slave server in the master database are incorrect so that the finished transaction can not be reported back as finished to the master. Do an ispconfig update on the slave and choose to reconfigure permissions in master database when the updater asks. Another possibility is that the red dot is for a different transaction on another server.
Thank you very much! It was really a database permission. The slave server did not have permission to edit the updated field in the server table on master database. I do not know how it could happen that this permission itself reset. Anyway, everything works fine now. EDIT: Just add that ispconfig update on the slave and reconfigure permissions in the master database did not help and I had to grant permissions manually.