Hello all. Mostly a "pseudo-bugreport" or, iow, what to expect if you don't use a db on the same server that hosts ISPConfig. Since I'm installing a new home server with virtualization, I decided to try having a separate MariaDB Galera cluster as backend for ISPConfig. So I installed the 3 DB nodes with no problems: cluster is working as 3 masters and writes gets replicated. As expected. Instructions at https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/ . Then I followed the perfect server guide for Jessie+Apache+ISPC31. And the problems started. The first problem: ISPConfig creates its own user and DB, but then can't acces the db. That's because the generated ACL is wrong ('ispconfig'@'localhost' instead of 'ispconfig'@'%', IIRC). Fixed that, the mail system spits out a lot of errors, since it can't connect to the db. Obviously, since there's no server at localhost! Fixing that is harder (w/o modifying the code) since that would require to re-apply config patches every time ISPConfig modifies and rewrites the files. Even worse, even the ACL for DB users created from the control panel is wrong, preventing connections from hosted sites and requiring manual intervention every time a new user is created. And, last, the monitor sees the DB as 'down' even if the cluster is working. Again, it's not at localhost as expeted... This one can be worked around by I hope these "glitches" can be fixed before finalizing ISPC31. After that, I'd only miss an easy way to handle connections to the DB cluster (mysql-proxy? mysql-router? couldn't make 'em work to remap a connection to localhost:3306 to a random db-N... but note that this addition could make some ACL issues harder: the client connects to localhost, but the ACL on the server sees a connection from a different machine!).