• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Understanding Webspaces

Chris Buckley

Basic Pleskian
Hi,

Using Plesk 11.0.9, and having a little trouble understanding webspaces.

We're a web design company, and we currently have an old server running Plesk 8.6, and we host around 120 different domains, most of which are for different customers. So we probably have 100 different customers.

What we've done so far is create a different webspace for each customer. Is this the right way to go about it?

I can't see what would be a better solution, as for example each webspace has to have an associated domain, so it wouldn't make sense to limit the webspaces such as:

- Admin Sites (5-10 of our own sites)
- Customer Sites (90 + sites)
- Dave B's Sites (Dave has 5 sites himself).

I can't find a definitive guide to how to manage webspaces properly. Are we doing this fine as we are currently?

Chris.
 
Further to my question above. The fact that you have to give a webspace a domain name instead of just a generic name sort of limits the approach with webspaces.

For example if we did create a webspace for a large bunch of customers, we would have to pick a certain domain, or just a random first domain, right? In which case the name wouldn't make any sense.

Chris.
 
Hi,

You can think of webspaces as of multi-domain environment isolated to a single system user. Within the webspace, different sites can access each other - as they are in the same folder and run under the same system user.

We recommend that a customer gets a webspace and all sites of a customer are put into this webspace.

Putting different customers into one webspace might not be very good idea - as hijacking one site may impact others.

Regards
 
Hi Sergey,

Ok so the approach that we're using at the moment is correct, to create a different webspace for each customer we have?

Chris
 
BTW, it does look like "Webspaces" name was confusing to you. If there were different name would it be less confusing? i.e. in some other systems it would be "Account". Would "Account" be more descriptive?
 
I assume its basically the same as "Clients" as in Plesk 8.6 that we're currently using on an older server, right? But yes I think Webspaces is a bit confusing.
 
Well, "Clients" are still available and named as "Customers". A "Client" can have one "Webspace" or more. I.e. one webspace may be for production site and another webspace for staging (test) site.
 
OK I see. We managed Plesk in power-user mode, so don't see Customers. Is this only available when you switch to the other mode?

Previously using Plesk 8.x and 9.x we did setup Clients such as "Our own sites", "Customer X's Sites", "Customer Y's Sites", and this worked quite well.

The webspace method doesn't quite suit us though as just feels more convoluted.
 
Yes, "Clients" are available when you switch mode. We ask for preferred mode on first login.
 
create separate client in customer section. You can add different domains under same client easily. so You can provide your client their own login details to access their own domain section.
 
I think the thing that confused me was in the "Add Domain" process, you end up needing to either "Create a New ... mumble mumble can't read it all" text which is pre-populated in the field used to also select an existing webspace, but if you take the default, it creates a new webspace using the new domain name of the domain you are adding. I somehow failed to realize that I could select from a list of existing webspaces here and as a result, I ended up with a new webspace associated to each new domain I added. I think that the default behavior - combined with the partially obscurred interface - may be contributing to the confusion.
 
I think the thing that confused me was in the "Add Domain" process, you end up needing to either "Create a New ... mumble mumble can't read it all" text which is pre-populated in the field used to also select an existing webspace, but if you take the default, it creates a new webspace using the new domain name of the domain you are adding. I somehow failed to realize that I could select from a list of existing webspaces here and as a result, I ended up with a new webspace associated to each new domain I added. I think that the default behavior - combined with the partially obscurred interface - may be contributing to the confusion.
I timed-out trying to edit this reply. The additional point was that the text field is correctly populated with "Create a new webspace" but it isn't clear why you should, so the default action is to go ahead and create one for the user if they don't choose an existing webspace, and not only that, but to use the new domain name for the name of the webspace. As a result, the default is to have a new webspace for each new domain - each named the same as the new domain name, so it creates a very confusing pattern.
 
The webspaces feature seems like an interesting grouping feature, along with the subscription grouping feature. If only there was an easy way to modify the webspace name and maybe regroup the domains into new webspaces later, then it might not be as big of a problem.
 
Its also means that if one website in a webspace is compromised then all sites in that webspace are accessible to that hacker. For the sake of a few etra config files, I think it best to keep one site per webspace.
 
I am now starting over - creating one webspace per domain. I think the bigger issue now is trying to negotiate Let's Encrypt Certificates with each domain and associated webspace, but I suppose this issue would belong in a separated thread.
 
If you're managing DNS from the Plesk server (and Id recommend you do this, for many reasons) then LE SSL installs are easy.
 
I was not realizing that I could fix the SSL by simply choosing the domain from the Websites & Domains list, and then clicking on the domain's "SSL/TLS Certificate" field, and then (the part I was missing before), you need to know to scroll all the way to the bottom and then chose the "Let's Encrypt" in the little tiny fonts.
 
If you're managing DNS from the Plesk server (and Id recommend you do this, for many reasons) then LE SSL installs are easy.
In my case, all of my IONOS hosted domains are external because I run a domain reselling service with another vendor whose name I won't badmouth here for obvious reasons (bad karma), since their webhosting setup kind of sucks. It also happens that I am upgrading all of my domains from one contract to another, so in my case, I had to build out the new sites one at a time - copying the files over and setting them up with proper permissions and owners, etc. then - when everything was ready - change the domain IP in the A records, making sure it resolved (this happened fairly quick actually) followed by running the Let's Encrypt as a last step. I doubt that Plesk would have been able to do all of that for me, but I suppose anything is possible.
 
and then (the part I was missing before), you need to know to scroll all the way to the bottom and then chose the "Let's Encrypt" in the little tiny fonts.
This is only the case when additional, commercial certificate providers were installed. In that case these are listed first, then as a last entry Let's Encrypt is also offered. When you remove the commercial providers from your "Extensions", you'll only see Let's Encrypt, and that is presented very clearly.
 
Back
Top