Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
allow only external database servers and hide local server
- Thread starter iMadalin
- Start date
iMadalin
New Pleskian
Thank you for the reply, but by setting just that, a client can still choose the localhost database server.
My intention is to allow them to choose any of the external servers only and don't force them to only a single server.
Scenario is that multiple MySQL servers are offered using different versions. Some really want a recent version and some want an older version.
I will test on a trial by deleting the entries from the DatabaseServers table.
@iMadalin,
I am pretty sure that a custom extension would serve your purpose best: serving of (multiple) external servers, without showing the local ones.
It is just a suggestion.
Anyway, I am rather curious with respect to the solution you will find (and I am also curious about your initiative to offer remote database server, keep me posted!)
Regards...
I am pretty sure that a custom extension would serve your purpose best: serving of (multiple) external servers, without showing the local ones.
It is just a suggestion.
Anyway, I am rather curious with respect to the solution you will find (and I am also curious about your initiative to offer remote database server, keep me posted!)
Regards...
iMadalin
New Pleskian
@trialotto
Looks like by removing the entry from the table gives the result I want. As Plesk's code is encrypted I don't know if Plesk has any internal component that really needs that entry.
I also think that Plesk installer should offer the possibility to specify the database server to be used at installation and if it to be used as the first database for clients; if not a second one should be mandatory to be specified.
Then in the panel at the DB interface, a checkbox to select if a server is visible to clients or not would be great (as a PHP developer I know that is really easy to implement
).
I'll make a suggestion on Uservoice about this.
Looks like by removing the entry from the table gives the result I want. As Plesk's code is encrypted I don't know if Plesk has any internal component that really needs that entry.
I also think that Plesk installer should offer the possibility to specify the database server to be used at installation and if it to be used as the first database for clients; if not a second one should be mandatory to be specified.
Then in the panel at the DB interface, a checkbox to select if a server is visible to clients or not would be great (as a PHP developer I know that is really easy to implement
).I'll make a suggestion on Uservoice about this.
Bad idea. Consequences are unpredictable. At least upgrade of Horde or something else may be fault.
iMadalin
New Pleskian
@IgorG
Maybe for who uses Horde, but it should not be tied by that and there is nothing in Horde's code that specifies that if used in Plesk it will force you to expose the localhost database to Clients...
(Plesk should manage it's own things separate from clients options to maximize stability, security and performance).
I've posted the idea on Uservoice and hope many others would agree with it for the reasons of increased security, performance and easier scalability.
https://plesk.uservoice.com/forums/...428371-hide-show-database-servers-for-clients
Maybe for who uses Horde, but it should not be tied by that and there is nothing in Horde's code that specifies that if used in Plesk it will force you to expose the localhost database to Clients...
(Plesk should manage it's own things separate from clients options to maximize stability, security and performance).
I've posted the idea on Uservoice and hope many others would agree with it for the reasons of increased security, performance and easier scalability.
https://plesk.uservoice.com/forums/...428371-hide-show-database-servers-for-clients
@iMadalin
You stated
and I can mention that it is possible to switch databases (without any problem), after the first installation has been succesful.
For instance, one can use the PostgreSQL server to contain the main databases for Plesk, it works like a charm.
In short, there is no need to actually have this option at installation time (and I strongly advice against that too).
A separate database does not make any sense: the main databases for Plesk are sufficient and decrease "database overhead", no performance penalties in the current setup.
A separate database server could only make sense if it is hosted on a specialized (HA/fail-over) database cluster:
- using a single external non-cluster database server will increase the "database overhead" and decrease security levels (both as opposed to using the localhost database server)
- using a single locally hosted (additional) non-cluster database server (besides the original Plesk database server) is "too much of the same thing", with a penalty on performance
In short, a separate database or even a database server often does not make any sense at all, unless you are clusterizing databases, which often requires external servers.
In conclusion, I would strongly advice to "not re-invent the wheel", i.e. the focus should not be on changing the inherent database structure of Plesk: if and only if required, you should focus on adding external database servers that serve a specific purpose, such as creating HA/Fail-over possibilities.
And the creation of HA/fail-over database servers for Plesk is already difficult enough, be aware of the formidable project you are starting (and have to maintain, when succesful).
Hope the above explanation helps a little bit in your preparations.
Regards...
You stated
and I can mention that it is possible to switch databases (without any problem), after the first installation has been succesful.
For instance, one can use the PostgreSQL server to contain the main databases for Plesk, it works like a charm.
In short, there is no need to actually have this option at installation time (and I strongly advice against that too).
A separate database does not make any sense: the main databases for Plesk are sufficient and decrease "database overhead", no performance penalties in the current setup.
A separate database server could only make sense if it is hosted on a specialized (HA/fail-over) database cluster:
- using a single external non-cluster database server will increase the "database overhead" and decrease security levels (both as opposed to using the localhost database server)
- using a single locally hosted (additional) non-cluster database server (besides the original Plesk database server) is "too much of the same thing", with a penalty on performance
In short, a separate database or even a database server often does not make any sense at all, unless you are clusterizing databases, which often requires external servers.
In conclusion, I would strongly advice to "not re-invent the wheel", i.e. the focus should not be on changing the inherent database structure of Plesk: if and only if required, you should focus on adding external database servers that serve a specific purpose, such as creating HA/Fail-over possibilities.
And the creation of HA/fail-over database servers for Plesk is already difficult enough, be aware of the formidable project you are starting (and have to maintain, when succesful).
Hope the above explanation helps a little bit in your preparations.
Regards...
iMadalin
New Pleskian
@trialotto
I agree with all you mentioned.
My idea on the start of the post was just how to hide databases from the Clients so they can choose to setup a new database only to the ones that they would be allowed in that moment.
I agree with all you mentioned.
My idea on the start of the post was just how to hide databases from the Clients so they can choose to setup a new database only to the ones that they would be allowed in that moment.
@iMadalin
You stated
and I am pretty sure that that is what Igor was trying to say with
In essence, Igor is saying that
- you (sysadmin) can determine the database server, (and)
- customers can create a database in that database server, specificied by you,
and that only leaves the "hiding part" of your wish: you aim to hide some databases from the view of your customers.
Ehm, if I am not mistaken, your customers (assigned to a subscription and therefore a domain) only can view the databases on that domain.
How come that you want to hide some databases (if any should be hidden)?
Regards....
You stated
and I am pretty sure that that is what Igor was trying to say with
In essence, Igor is saying that
- you (sysadmin) can determine the database server, (and)
- customers can create a database in that database server, specificied by you,
and that only leaves the "hiding part" of your wish: you aim to hide some databases from the view of your customers.
Ehm, if I am not mistaken, your customers (assigned to a subscription and therefore a domain) only can view the databases on that domain.
How come that you want to hide some databases (if any should be hidden)?
Regards....
iMadalin
New Pleskian
@trialotto
Database Servers, not databases.
Do you know how for example Rackspace Sites service works?
When you create a website you can assign a database to it (more after completing the wizard) and you get to choose any DB Server from a list you are allowed that moment.
That list is based on the least used database servers (got the info from a friend that works there).
What I want to do, is to set the list of allowed Database Servers and manage it as I think best.
I don't want to force users to a single Database server as I am offering 3 Database servers at this moment: one with MySQL 5.5, another one with MySQL 5.6 and another one with MySQL 5.7. In the near future even MariaDB 5.5, 10 and 10.1 as I have been asked if it would be possible.
Through the clients there are some that want 5.5, some want 5.7. I really like to offer them this, as they can also change PHP version as desire (5.4, 5.5, 5.6 or 7.0).
But I don't want any database on the localhost (as I want it strictly to be used by Plesk for all it needs and I like to keep some things separated).
Database Servers, not databases.
Do you know how for example Rackspace Sites service works?
When you create a website you can assign a database to it (more after completing the wizard) and you get to choose any DB Server from a list you are allowed that moment.
That list is based on the least used database servers (got the info from a friend that works there).
What I want to do, is to set the list of allowed Database Servers and manage it as I think best.
I don't want to force users to a single Database server as I am offering 3 Database servers at this moment: one with MySQL 5.5, another one with MySQL 5.6 and another one with MySQL 5.7. In the near future even MariaDB 5.5, 10 and 10.1 as I have been asked if it would be possible.
Through the clients there are some that want 5.5, some want 5.7. I really like to offer them this, as they can also change PHP version as desire (5.4, 5.5, 5.6 or 7.0).
But I don't want any database on the localhost (as I want it strictly to be used by Plesk for all it needs and I like to keep some things separated).
@iMadalin,
Well, in that case: again, you should consider to create an extension.
By the way, RackSpace cannot be compared to a Plesk environment, in no way imaginable.
If you consider to offer existing database SERVERS, you should be aware that you would be EITHER having existing (up and running) database servers OR some scripting to launch new database server (scripts like Chef for multiple servers to launch, or even a multiple of Docker containers on one physical server).
In both methods, you would need a scalable and flexible server infrastructure with a lot of maintenance OR minimal maintenance, in the case of a public cloud (this should suit best).
Whatever you try to do, the scalable/flexible server infrastructure is OUTSIDE the Plesk environment (clustered or non-clustered Plesk instances).
In short, the Plesk environment is only there for the sake of hosting and some custom scripts should be added to "make the connections" to before mentioned server infrastructure.
This is the reason why an extension would be best. Keeps it simple, as far as "simple" applies in your goals.
By the way, I am not certain why you want to create multiple database servers, if the Plesk server is a stand-alone machine (for each instance).
Really, try to focus on the clustering of multiple Plesk instance on multiple servers, each of them running one Plesk instance and multiple local mysql based database servers (with one of the other servers functioning as a mirror/slave of the respective database server).
And, if you know somebody at RackSpace, they can really help you with such a (low cost and HA) setup.
However, note that RackSpace has some issues, when it comes to database hosting (i.e. their cloud infrastructure is not the best in the business, it is not yet mature, when compared to the platforms of Google, Amazon and Microsoft).
Finally, note that you will spend a lot of time and effort to something that (on the one hand) can be easily obtained in a simple cloud environment, but (on the other hand) is not really a good solution in practice, for many reasons (one of them being that you re-invent the wheel).
You can believe me, I am running multiple clustered database servers, they are really a pain-in-the-%&$.
Moreover, there is nothing a mysql server can do and a nosql cannot (or even better, a static (structured) storage augmented with nosql and cache).
My advice: keep it simple, try to add an external mysql server first and TEST connection possibilities (with Plesk) AND TEST scalability of the mysql server (that will fail miserably).
Regards....
Well, in that case: again, you should consider to create an extension.
By the way, RackSpace cannot be compared to a Plesk environment, in no way imaginable.
If you consider to offer existing database SERVERS, you should be aware that you would be EITHER having existing (up and running) database servers OR some scripting to launch new database server (scripts like Chef for multiple servers to launch, or even a multiple of Docker containers on one physical server).
In both methods, you would need a scalable and flexible server infrastructure with a lot of maintenance OR minimal maintenance, in the case of a public cloud (this should suit best).
Whatever you try to do, the scalable/flexible server infrastructure is OUTSIDE the Plesk environment (clustered or non-clustered Plesk instances).
In short, the Plesk environment is only there for the sake of hosting and some custom scripts should be added to "make the connections" to before mentioned server infrastructure.
This is the reason why an extension would be best. Keeps it simple, as far as "simple" applies in your goals.
By the way, I am not certain why you want to create multiple database servers, if the Plesk server is a stand-alone machine (for each instance).
Really, try to focus on the clustering of multiple Plesk instance on multiple servers, each of them running one Plesk instance and multiple local mysql based database servers (with one of the other servers functioning as a mirror/slave of the respective database server).
And, if you know somebody at RackSpace, they can really help you with such a (low cost and HA) setup.
However, note that RackSpace has some issues, when it comes to database hosting (i.e. their cloud infrastructure is not the best in the business, it is not yet mature, when compared to the platforms of Google, Amazon and Microsoft).
Finally, note that you will spend a lot of time and effort to something that (on the one hand) can be easily obtained in a simple cloud environment, but (on the other hand) is not really a good solution in practice, for many reasons (one of them being that you re-invent the wheel).
You can believe me, I am running multiple clustered database servers, they are really a pain-in-the-%&$.
Moreover, there is nothing a mysql server can do and a nosql cannot (or even better, a static (structured) storage augmented with nosql and cache).
My advice: keep it simple, try to add an external mysql server first and TEST connection possibilities (with Plesk) AND TEST scalability of the mysql server (that will fail miserably).
Regards....
Similar threads
