HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Installation/Configuration (http://www.howtoforge.com/forums/forumdisplay.php?f=27)
-   -   Multiserver Database access (http://www.howtoforge.com/forums/showthread.php?t=46646)

Croydon 19th June 2010 19:54

Multiserver Database access
 
Hi folks :)

Scenario:
Multiserver setup, 1 database server, 1 webserver, 1 ispc mainhost with mailserver, dns and so on.
The webserver is not configured as a database server in ispc.
If a user creates a database now and disables remote access, will the ip of his assigned ispc web server(s) automatically added to the remote access ip list?
If not (and that's what I think it is like) he could not access the database from his web-scripts unless he enables remote access (with at least the web server's ip) himself, right?

So my question: Is this feature already on someone's to do list? Or maybe do you think it is not worth being integrated?
It would not be a small task I think as all web servers the client has websites on had to be taken into account at every database server the client has a database on. So privilegues would have to be updated on every database change and every website change.

till 19th June 2010 22:20

You can restrict the access to the database to the IP of the web server by entering the IP address of the webserver(s) that shall be able to access this database into the "Remote Access IP's" field.

For performance reasons, I recommend that you run the database locally on the same server then the websites. In that case, the sites can connect to mysql trogh a local server socket instaed of tcpip which is faster and need less resources.

Croydon 28th June 2010 11:01

Quote:

Originally Posted by till (Post 231607)
You can restrict the access to the database to the IP of the web server by entering the IP address of the webserver(s) that shall be able to access this database into the "Remote Access IP's" field.

;) Sure, I know. I implemented this.

Quote:

Originally Posted by till (Post 231607)
For performance reasons, I recommend that you run the database locally on the same server then the websites. In that case, the sites can connect to mysql trogh a local server socket instaed of tcpip which is faster and need less resources.

Agreed, but in this case one (or more) separate db server(s) is/are needed. So the question is if you think it would be a good idea to integrate into the core.
Maybe the clientdb plugin could have a hook that is called on every db / website update and automatically adds db rights for the web server(s)? In multiserver setup only - of course.

till 28th June 2010 11:53

Quote:

Maybe the clientdb plugin could have a hook that is called on every db / website update and automatically adds db rights for the web server(s)? In multiserver setup only - of course.
This is an option, but then we will have to add a selector for the website that this databse belongs to to the database form.

Croydon 28th June 2010 13:07

Quote:

Originally Posted by till (Post 232209)
This is an option, but then we will have to add a selector for the website that this databse belongs to to the database form.

Wouldn't it be a better solution to simply grant access to all webservers the owner of the db has websites on? So he can use a database from any website, no matter on which webserver in the farm it is.

till 28th June 2010 13:19

Thats possible but has some drawbacks. If the database server is not the master, then the mysql plugin is not able to lookup this information. In this case, the IP addresses can not be changed and no IP's can be added when e.g a website gets added as the event will never reach the database server. The only other solution will be to do it in the interface and write all IP addresses in the allowed IP field and enable the remote access checkbox by default. But then we do not win much over the current situation.

Croydon 28th June 2010 13:33

Ok, I'll try to think about this - maybe there is a solution.


All times are GMT +2. The time now is 16:08.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.