I updated all my servers in test system to debian buster an the to the new ispconfig p3, had to install mbstring Everything works fine So I went to update to update my production system admin server (just admin and primary dns) from stretch to buster and two others from jessie to stretch. Did not check everything but it looks good. The I did the p3 update master first, no problem, ispconfig shows new version. then I updated the other servers from p2 to p3, ispconfig monitor shows had no change. I know sometimes I have to wait a little bit. So I rechecked this morning, no change even, monitor shows the updated OS versions as before, but not the updated ispconfig. I went to search, found that on the master netstat -tap shows multiple TIME_WAIT from the slaves and the slave shows multiple TIME_WAIT to the master. all server are on the same private subnet 10.10.1.x, /etc/host is correct shows all servers. Did not change any IP configuration. Every server can be accessed via SSH. The servers themself web, mail, dns work fine. mysql -u root -p -h masterserver_name on slave works fine I helpless, no idea wher to look. Rainer
The procedure is always the same and I explained it many timed here in the forum, so you might want to use the search function to search for similar threads. 1) Test the mysql connection from master to slave using the mysql command with the dbmaster details from config.inc.php file. 2) Use the ispconfig debug mode: https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/
to 1) conection not allowed used credentials from /usr/local/ispconfig/server/lib/config.inc.php to2) no errors on master the screen output looks fine, cannot switch on debug on slave, without no output, can i switch on debug manually on slave? Tried to con with credentials from /usr/local/ispconfig/server/lib/config.inc.php from slave to master, denied too Rainer
Ok, so you now know what the issue is. When the mysql user is not allowed to connect from slave to master, then the whole setup can not work. Use phpmyadmin on the master to check the affected ispcsrv* users to see if they are correct regarding IP addresses, hostnames etc.
Sorry, had the wrong user name connecting the master from the slave. with the correct name connection to master is ok. Rainer
Ok, and what about debug mode? enable it for the slave on the master, run server.sh as root on slave and post the result.
That is the problem the slave does not get the debug mode, as even if the mysql conncetion works <code> mysql -u ispcsrv22 -h admin.gerdakloos.de -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 4291 Server version: 10.3.22-MariaDB-0+deb10u1 Debian 10 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> </code> there is o communication. The red point on top in ispconfig does not count down as it does when the changes are done Rainer
Please run the command: php -v on the slave and post the result. The php version that is shown must be php 7.3for Debian 10. And you did not post the result of server.sh yet.
PHP 7.3.11-1~deb10u1 (cli) (built: Oct 26 2019 14:14:18) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.11-1~deb10u1, Copyright (c) 1999-2018, by Zend Technologies Remember on my testsystem which had a similar configuration everything went fine. same on master. but the slaves with debian stretch do not work too any more aber p3
Ok, PHP version is fine. Your issue is not related to p3, p3 is the exact same code as p2, ist 2 lines in the ispconfig interface login code were changed. Still no server.sh output posted by you...
servers.sh got an empty result earlier no i cot a very lang result <code> 24.02.2020-14:40 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 24.02.2020-14:40 - DEBUG - Found 2 changes, starting update process. 24.02.2020-14:40 - DEBUG - Replicated from master: REPLACE INTO `server` (`server_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_name`,`mail_server`,`web_server`,`dns_server`,`file_server`,`db_server`,`vserver_server`,`proxy_server`,`firewall_server`,`xmpp_server`,`config`,`updated`,`mirror_server_id`,`dbversion`,`active`) VALUES ('22','1','1','riud','riud','r','http1.muekno.de','0','1','0','1','1','0','0','0','0','[global]\nwebserver=apache\nmailserver=postfix\ndnsserver=mydns\n\n[server]\nauto_network... tls, dialback, disco, discoitems, version, uptime, time, ping, admin_adhoc, admin_telnet, bosh, posix, announce, offline, webpresence, mam, stream_management, message_carbons\nxmpp_port_http=5290\nxmpp_port_https=5291\nxmpp_port_pastebin=5292\nxmpp_port_bosh=5280\n\n','5548','0','88','1') 24.02.2020-14:40 - DEBUG - Calling function 'server_ip' from plugin 'apache2_plugin' raised by event 'server_update'. 24.02.2020-14:40 - DEBUG - safe_exec cmd: which 'apache2ctl' 2> /dev/null - return code: 0 24.02.2020-14:40 - DEBUG - Writing the conf file: /etc/apache2/sites-available/ispconfig.conf 24.02.2020-14:40 - DEBUG - Calling function 'update' from plugin 'apps_vhost_plugin' raised by event 'server_update'. 24.02.2020-14:40 - DEBUG - safe_exec cmd: which 'apache2ctl' 2> /dev/null - return code: 0 24.02.2020-14:40 - DEBUG - Calling function 'update' from plugin 'network_settings_plugin' raised by event 'server_update'. 24.02.2020-14:40 - DEBUG - Network configuration disabled in server settings. 24.02.2020-14:40 - DEBUG - Processed datalog_id 5551 24.02.2020-14:40 - DEBUG - Replicated from master: REPLACE INTO `server` (`server_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_name`,`mail_server`,`web_server`,`dns_server`,`file_server`,`db_server`,`vserver_server`,.... posix, announce, offline, webpresence, mam, stream_management, message_carbons\nxmpp_port_http=5290\nxmpp_port_https=5291\nxmpp_port_pastebin=5292\nxmpp_port_bosh=5280\n\n','5548','0','88','1') 24.02.2020-14:40 - DEBUG - Calling function 'server_ip' from plugin 'apache2_plugin' raised by event 'server_update'. 24.02.2020-14:40 - DEBUG - safe_exec cmd: which 'apache2ctl' 2> /dev/null - return code: 0 24.02.2020-14:40 - DEBUG - Writing the conf file: /etc/apache2/sites-available/ispconfig.conf 24.02.2020-14:40 - DEBUG - Calling function 'update' from plugin 'apps_vhost_plugin' raised by event 'server_update'. 24.02.2020-14:40 - DEBUG - safe_exec cmd: which 'apache2ctl' 2> /dev/null - return code: 0 24.02.2020-14:40 - DEBUG - Calling function 'update' from plugin 'network_settings_plugin' raised by event 'server_update'. 24.02.2020-14:40 - DEBUG - Network configuration disabled in server settings. 24.02.2020-14:40 - DEBUG - Processed datalog_id 5552 24.02.2020-14:40 - DEBUG - Calling function 'restartHttpd' from module 'web_module'. 24.02.2020-14:40 - DEBUG - Restarting httpd: systemctl restart apache2.service 24.02.2020-14:40 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. </code>
next try root@http1:~# /usr/local/ispconfig/server/server.sh 24.02.2020-14:47 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 24.02.2020-14:47 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. but information on master about that slave always not updated, nor for otherslaves
Ok, the above result means that the changes have been processed for this slave successfully, so the number of pending items must be lower now. And enabling debug mode was successful too for this node btw. No test your other failing nodes in the same way.
each slave can connect the master with ispcsrv?? an the correspondig password. each server.sh output look ssimilar, very log first time short next time. reenabled crotab, still no up to date information in monitor on master. pending requests on master go away. still TIME_WAIT in netstat on slave and on master to every slave
If pending requests are gone away, then the connection is working again. The update information will prbaably get updated in a few hours, so just wait now.
