LAMP app version with multiple mysql databases without need for custom app

[ccfu]

I am aware that it is possible to create a custom app to enable more than one mysql database, but I would really like to see a LAMP app with this function as standard. Or is there a reason I am overlooking why this would not be desirable?

[girish]

@ccfu is it common for apps to want multiple databases? Can you tell us a bit more about your use case? In app store, only one app uses this feature - phabricator.

[ccfu]

@girish
I honestly don't know how common this is, but we do have some use cases for this, yes. For example Wordpress with CiviCrm - CiviCrm is installed as a Wordpress plugin but uses its own database. This is my current reason for needing this. They may also be situations where a LAMP app is installed on a domain or subdomain, another, app is intentionally installed in a subfolder and both need a database.

Maybe I have misunderstood the way access to databases in LAMP app works though. Am I correct in saying that one app cannot access a database set up in another (LAMP) app? If that is not the case then maybe there is no necessity to have multiple databases and a LAMP app could be used simply to host the additional database?

[humptydumpty]

@girish I have a PHP 5.6 app that installs on a subdomain and has its own database (B2B) and there's a second database for another part of the app that's geared for B2C. I haven't installed it on my Cloudron server yet because if I'm not mistaken, the current LAMP stack supports PHP 7.4 only so I'm still hosting that elsewhere but we're trying to get the app updated soon.

[fbartels]

In both those cases you can most likely use another table prefix. While this is not really common for backend type of applications, the last time I looked into php based stuff it still was very common (owncloud/nextcloud uses oc_ for example).

[humptydumpty]

@fbartels Thanks for the tip. I'll pass it along to the developer who will be updating my app.

[ccfu]

@fbartels That is a good solution when it is desirable that the tables reside in the same database, but not always an option for data integrity and data security reasons.

[marcusquinn]

@fbartels Agreed, table prefixes are conventional, and tools like phpMyAdmin have workflows that accommodate for them when importing/exporting.

Only reason I could think to use separate DBs would be quite extreme security access separation or optimisation separation, doesn't sound like the case here tho.

[nebulon]

Also maybe performance considerations might be a reason to want to have distinct databases, but that would also not apply in the Cloudron case, given that the mysql server instance is anyways shared.

[ccfu]

@nebulon @marcusquinn
Optimisation indeed shouldn't really be an issue with Cloudron, but security considerations certainly apply in the case of a CRM (or indeed any situation where personal data is being stored and connected to other applications). Admittedly this is probably a minority requirement.

Can one app connect to the databse of another app? If so, the 'issue' can of course be resolved by having the second database in a separate LAMP app.

[nebulon]

By default the databases provided from the shared mysql addon can only be accessed with the credentials issued to the app. Those credentials may change at any time during an update, so that makes it kinda inconvenient to put the credentials in other apps to "share" a database.

Also if both applications have connections to both databases, I am not sure how this helps in isolation much.

[ccfu]

@nebulon
OK, thanks, I think I can work with this with a bit of a rethink. I guess I am used to hosting platforms with different architectures and shared mysql instances being separate from the applications.

A true isolation is of course not possible with a shared instance, though it depends a bit on the applications.

[girish]

I think in theory we could isolate app containers to access only a specific db by restricting based on IP (which MySQL supports). MySQL already has an IP based rate limit for logins, this is why we haven't implemented it. Meaning, an app trying to guess another app's db credentials won't get very far.