Howdy, I'm still fiddling with the install of my two-server cluster. There's supposed to be one mail and one web server, the former has the ISPConfig control panel installed and is working fine as far as I can see. However, in trying to debug why the other one won't join properly, I found the mail server's /var/log/ispconfig/ispconfig.log is filling up with "03.07.2012-17:40 - ERROR - MySQL is down! Rescue will not help!" messages. from the cron job The web interface works and I can log on to MySQL using the mysql client and the credentials from /usr/local/ispconfig/interface/lib/config.inc.php, so I'm at a loss why any part of ISPConfig would not be able to connect. It would be interesting to get a backtrace for this, so unless someone can can tell me already what I'm doing wrong, maybe PHP can be coaxed to produce an execution log or something?
Aargh, I found it! This was my first thought too but thanks for making me check again. Just for the archives: As MySQL doesn't support listening on more than one socket it's either one interface or all of them. But especially in the light of recent DB-root exploits I didn't want to open it to the wild wild web, only to the internal management network that connects the vservers. So I put in an iptables rule: Code: iptables -A INPUT --protocol tcp --dport 3306 '!' --in-interface eth1 -j REJECT And forgot about the lo interface. But when ispconfig didn't work, I tested with the mysql client: Code: mysql -hlocalhost -Ddbispconfig -uispconfig -pXXXXX That worked fine. Turns out mysql silently falls back to unix domain sockets if a connection to localhost fails---which is only visible if you use "prompt \p" to show the currently used port or socket or with netstat. m( MySQL, I hate you!
