Multisite with seperate db’s

There are plugins to scale the database, but not so one blog is in one db each. Kind of defeats the point of running a network. ??

Hi andrea_r, thanks for getting back to me.

Do you know much about security in multisite setups? The reason we want seperate databases is to prevent the situation where one site is compromised and this brings down all the others on that box.

If seperate db’s are not possible then can you suggest another way we can prevent security breaches bringing down all our sites?

I know a little.

Things that bring down all the sites are more related to change to the code, not stuff in the database. All blogs/sites are served through one copy of the files. If you make a change to a file, it affects every single blog. make a mistake, you’ve brought down all of them.

But that’s more dealing with things like “don’t edit production code unless you know what you’re doing”. ??

If you’re running a network for others, they do not have the privileges to edit themes or plugins. They can’t install them either. Only the Super Admin can.

If you’re interested in security, then you’re probably vetting all themes and plugins before you add them to your site.

So, that takes care of anyone adding any code that can eventually access the database(s). (You will need to scale the dbs when you get bigger).

really though, mu has ben more secure that wp with the locking down of things. Your first line of defense is *always* securing the box the install is on.

The recent round of hacks targeted wordpress, but did not have anything to do with how secure WP is. Keep your OS up to date, for instance. Don’t use FTP, but use sftp instead. Keep secure passwords to your server (never log in as root, log in as a user, then su).

Short version, in my understanding, if someone’s breached your database, they’ve already breached the box.

Thanks again, I understand your comments.

With respect to the shared files of wordpress for multisite, can you recommend appropriate permissions and settings for the directory structure that would secure the files to ensure that our multisite users can not access each others file structure in any way? Obviously much of the important content is stored in the database but I believe some user specific files are also stored in the fiel structure.

many thanks
Ben

Yes, the user files are stored with the blog.dir directories. These URLs are rewritten on the user end. They never see the original file structure. They cannot access it from the backend.

You are running a mini version of wordpress.com.

The biggest change to security that you will see between the standalone and multisite modes is the kses filters. This strips out things like embeds, iframes, scripts, etc that are the primary problem with compromised sites.

Another vector is upload files. In the adminitration, the super admin has the ability to define allowed file types. So for instance, this can prevent users from uploading php scripts that can give them backdoor access to your server.

Another difference is that the theme editor isn’t available to users, so they can’t write custom php code into the themes. And along with this, themes and plugins can only be installed by the super admins. Malicious code hidden in themes is one of the other most common vectors of a compromised wordpress install.

As for database separation, it’s technically possible and there are some plugins to do multiple databases, but they are mostly designed for spreading out the load for large scale hosting performance more than security isolation. The principles could apply though but may require a custom plugin for doing database isolation.

Thanks guys, much appreciated.

I would argue there are reasons to want seperate database with multisite … the real advantage is only having one core wordpress install to deal with … but it’s nice to sometime have many small databases for each of your different blogs then one large database — allows you to set different database backup settings for different blogs and not have to always download one huge database for backups all the time. Plus, if you decide at one point to remove the one of your blogs from the network and make it a standalone install then you already have it’s own database.

What do you think about these thoughts Andrea_r? And is there now way to do multi database anyway?

.. but it’s nice to sometime have many small databases for each of your different blogs then one large database —

Not necessarily. each blog’s tables are numbered anyway, so you can always find the blog you want.

— allows you to set different database backup settings for different blogs and not have to always download one huge database for backups all the time.

Too much work, non efficient. ?? Why download? sftp them onto a backup server or Amazon s3.

Plus, if you decide at one point to remove the one of your blogs from the network and make it a standalone install then you already have it’s own database.

Except with multisite the user tables are still shared. So even if you separate out the dbs, you still need to go dig out the users.

I have one install with 5 or 6 *hundred* blogs on it. 16 databases. I can still find what I need when I need to. ??

For ten blogs, the work involved with scaling out the dbs is not worth any time saved having them separate. I think it just makes more work.

https://www.ads-software.com/extend/plugins/shardb/
https://www.ads-software.com/extend/plugins/hyperdb/

Still, I would appreciate if I could have one database per blog created in my WP 3.O MU, rather than having everything in one big database…
What config should I edit to do that ?
Thanks.

i would like to know if it is possible to have a separate database for each blog….if yes, than how?

I’m quoting the second post in this thread for you:

There are plugins to scale the database, but not so one blog is in one db each. Kind of defeats the point of running a network.

Here are the plugins:
https://www.ads-software.com/extend/plugins/shardb/
https://www.ads-software.com/extend/plugins/hyperdb/

And since the answer isn’t gonna change, I’m closing this.