APS Database Access

Now that we've got a dedicated DB server added to our cluster, I've ironically got the reverse problem that I had previously.

The cluster uses shared storage for websites. That is, NFS shares mapped to /var/www on each node, so that they all access the same shared files under /var/www. And then the web server nodes are all mirrors of the shared storage, so that they have the same website settings via "dbispconfig".

(I used to have the DB server bundled on the shared storage node too, simply because we didn't, at that point, have enough nodes in the cluster and a few functions had to be crammed onto the same server. But our budget allowed for a new server in the cluster and so it's the dedicated DB server.)

The issue is that when I install an APS package - say, Wordpress - then it does install just fine.

Now that I've got a dedicated DB server, it recognises that this is "remote" and sets the "remote access" tick box automatically (my old problem, you see, was that, bundling the web and DB server on the same machine, it detected that they were the same machine and set it to "localhost", even though I needed it to be "remote access", so that all the other nodes could also access it).

But - here's the rub - it's then setting the "remote access IPs" to only the shared storage server (as that's the "master" web server, which all the other web server nodes are mirrors of). Basically, the same problem as previously, but now in reverse.

It's being too specific. Yes, the "master" web server should be in the remote IPs, but so should all the other web server nodes.

My workaround has been to go into the DB settings and, for the "remote IPs", manually change it to a slightly looser specification (e.g. 10.0.0.0/255.0.0.0) that covers all the nodes and then it works.

I appreciate that it's attempting to do the right thing, security-wise, and keeping the DB access as tight as possible. But this is too specific and doesn't work with a mirrored setup - as it's only including the "master" and leaving out the mirrors.

While I know how to fix it with my workaround there, I need it to be automatic, as other ISPConfig users of our cluster are getting clobbered with it and seeing "error connecting to database" errors.

And, in fairness, the APS package installer ought to be able to detect that we've got mirrored web servers from the ISPConfig settings and then either add all the web server IPs into the "remote access IPs" box or leave it blank for "any" (in my case, it would also be fine to use "any" as the cluster runs on its own private LAN - with a firewall machine up front that has the actual external IP address - but I appreciate that others might have different architectures where "any" would be the wrong choice and they need it to work like the former).

With the previous problem, I found the place in the PHP code to just hard-wire the IP address to what I needed. But this reverse problem is a bit more complicated to solve than that, as the value is dynamic and I've had no success in trying to dive down into the code to locate where I'd need to make the change (calls call other calls that call other calls, and I don't really know the ISPConfig source code intimately, so I just got quickly lost).

 

Will do.

Currently bogged down in other work taking the priority at the moment, but I'll need to get back to this and can devote my attentions to it.

 

Okay, I had a spare five minutes now and put the issue on the bug tracker.