I'm running a six server cluster including 3 dns servers. After many years of running on VMware I've started to make the move to openstack. The least risky start was to convert my 2nd dns slave which was successful in that I have a working server that appears not to be giving any errors. I opened the firewall to dns and ssh and I can query the server externally. I made a change to a DNS record (namely the one that points to itself because it's external IP necessarily had to change) to test it updates, and it doesn't. I changed all the hosts files to also point to it, still no joy. I queried the database and dns_rr table is not being updated, and of course the bind zone file is consistent with the database. (wrong) It's counterpart slave dns server I haven't moved still works perfectly. Before I go converting anymore VMs in the cluster is there a diagnostic technique someone can point me to to check why it isn't updating? I'm running debian buster and currently on Ispconfig 3.2.2.
Having followed the first part of this and noting some config issues with my webserver, I saved some changes. It appears to write to a file /etc/apache2/sites-available/apps.vhost This breaks apache with reference to LISTEN 8081 ###################################################### # This virtual host contains the configuration # for the ISPConfig apps vhost ###################################################### Listen 8081 # NameVirtualHost *:8081 <VirtualHost _default_:8081> ServerAdmin webmaster@localhost Any Ideas what is causing this? I can comment out the Listen directive and apache will start again, but any changes and the file is rewritten and it breaks again
Check with ISPConfig manual the "MySQL root user records in the master database for every slave server hostname and IP address." It is on page 28 in my copy.
I had already been into phpmyadmin and changed the IP. The manual refers to "root" not "ispcsrv11" as user, also the IP is a gateway not the slave dns server IP. First I gave it the servers IP now I'm trying the gateway, or do I add both? I'm looking for the right command to run on the master to give the correct privileges to, in this case "ispcsvr11"
I found this old discussion: https://www.howtoforge.com/communit...oblem-with-database-server.73355/#post-345246
To update permissions of the ispcsrv* users, do an ispconfig update on the affected slave server and choose to reconfigure permissions in master database during update.
Please note this slave is on a different network. The IP the DNS record for this server is different to what mysql sees queries coming in from. Do both IP's now need to be in the master?
Did you configure the hostnames of the master and alls slave servers in the /etc/hosts files of all nodes as described in the multiserver guides? That's required and the DNS records do not matter then.
the moved server is also not having update status read by the master. ns3 is updated and on ispconfig 3.2.4
Please share the content of /etc/apache2/apache2.conf for this problem. What is the output of Code: /usr/local/ispconfig/server/server.sh
root@ns3:~# crontab -e No modification made root@ns3:~# /usr/local/ispconfig/server/server.sh 10.05.2021-20:05 - DEBUG - Calling function 'os_update' from plugin 'software_update_plugin' raised by action 'os_update'. 10.05.2021-20:05 - DEBUG - Execeuted Debian / Ubuntu update 10.05.2021-20:05 - WARNING - Falsche Anfrage / Wrong QuerySQL-Query = UPDATE sys_remoteaction SET action_state = 'ok' WHERE action_id = '44' -> 1142 (UPDATE command denied to user 'ispcsrv11'@'xxx.xxx.xxx.xxx' for table 'sys_remoteaction') 10.05.2021-20:05 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished server.php. I had done a reconfigure permissions on upgrading the moved server when upgrading it to 3.2.4 which I thought would fix this. What are ispcsrvXX users suposed to have as permissions?
Repeated the upgrade and still the permissions failure for update by ispcsrv11@gatewayip <--Note this is not the ip of the server.
root@ns3:~# /usr/local/ispconfig/server/server.sh 10.05.2021-20:40 - DEBUG - Calling function 'os_update' from plugin 'software_update_plugin' raised by action 'os_update'. 10.05.2021-20:40 - DEBUG - Execeuted Debian / Ubuntu update 10.05.2021-20:40 - WARNING - Falsche Anfrage / Wrong QuerySQL-Query = UPDATE sys_remoteaction SET action_state = 'ok' WHERE action_id = '45' -> 1142 (UPDATE command denied to user 'ispcsrv11'@'xxx.xxx.xxx.xxx' for table 'sys_remoteaction') 10.05.2021-20:40 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished server.php. root@ns3:~# To test the ability of the slave to do a remote OS update I initiate from the console to test.
