• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.

Plesk Multi Server preview

Status
Not open for further replies.
Hello,

any suggestions about this error:

Code:
Attempt: 1
[2016-10-07T16:38:52+02:00] DEBUG Begin init procedure
[2016-10-07T16:38:52+02:00] DEBUG Init procedure finished
[2016-10-07T16:38:57+02:00] DEBUG Task has no prerequisite task
[2016-10-07T16:38:57+02:00] DEBUG Run
[2016-10-07T16:38:57+02:00] DEBUG Deploy service node
[2016-10-07T16:38:58+02:00] ERR Deployer is not specified: Class is not specified

during new Subscription provisioning?

Thanks
 
@korsar and @custer

A very rough manual has been provided

It's likely yes, but we can't guarantee this since we don't perform testing of such case.
We are going to support CentOS 7, Ubuntu 14.04/16.04, Debian 8.
https://docs.plesk.com/en-US/17.0/multi-server-guide/installing-plesk-multi-server.77106/

but I noticed that there is no information (at all) with respect to the proper settings of IP addresses.

As far as I can see right now, the following applies

- the extension is not really able to deal with internal IPs (read: IPs in an internal network, of the form 10.0.0.x or similar)
- the extension requires a public IP, but will not use that when an Onyx instance is on an internal network
- some issues with public and internal IPs exist: for instance, using the management node to change a dedicated IP to a shared IP on the slave node will not result in a change when trying to create a new subscription (the process contains the IP value "dedicated", which should be "shared" after the change on the slave node. Settings seem to be sticky and only the removal of the node and re-assignment of the node will resolve this "sticky value" issue.)

I would like to ask you to provide some information about this particular topic, which is very relevant for the Multi Server extension.

After all, a "master/slave" setup is often accompanied by an internal network.

By the way, there are some issues with page refreshing: at first, this seemed to be a problem associated with the extension, but it is more common (also on other pages).

Regards........
 
A very rough manual has been provided

@trialotto manual is in progress right now, this one is a draft. Multi Server is not released yet, as you can see in Extensions catalog.

As far as I can see right now, the following applies

- the extension is not really able to deal with internal IPs (read: IPs in an internal network, of the form 10.0.0.x or similar)
- the extension requires a public IP, but will not use that when an Onyx instance is on an internal network
- some issues with public and internal IPs exist: for instance, using the management node to change a dedicated IP to a shared IP on the slave node will not result in a change when trying to create a new subscription (the process contains the IP value "dedicated", which should be "shared" after the change on the slave node. Settings seem to be sticky and only the removal of the node and re-assignment of the node will resolve this "sticky value" issue.)

I would like to ask you to provide some information about this particular topic, which is very relevant for the Multi Server extension.

After all, a "master/slave" setup is often accompanied by an internal network.
Regarding internal and public IPs. Could you describe your expectations?
IP, which is used for service node registration is public since it's used for navigation between panels installed to management node (panel to provide central management experience) and service node (panel to manage a particular subscription). You possibly want to protect API communication between management and service node, but all communications are performed via usual Plesk API gate, which is exposed on a public IP for every Plesk instance.
 
@korsar,

The best safeguard for API communications is present with an internal network, connecting the master and service nodes only.

A public IP can then be added to the internal network, (only) allowing access to the Onyx panels from the outside.

The problem with the Multi Server extension is that it (at least in a lot of situations) does not work with internal IPs (for instance 10.0.0.x) or public IPs.

There are some things that I found remarkable: the extension is

- resolving the internal IP to the correct (internal) FQDN (with the internal FQDN being equal to the hostname)
- connecting to the service node with both the internal and public IP

and it really seems to be the case that the Onyx master node wants (read: requires) a matching (public) FQDN hostname, resolvable through (public) DNS.

I suppose that the bottleneck is related to the way FQDN hostnames are associated with (internal or public) IPs.

This also makes another problem relevant: the way in which Plesk (in general) changes the hostname (it makes a mess of /etc/hosts when changing the hostname via the Plesk Panel and that is something new, since this issue was not really present in the past).

In short, there is some additional work to do.

Nevertheless, all of the above is something that you can experience for yourself, in one of my Onyx labs.

Just start a conversation, if you want to look for yourself (and also in the case that you want to await some additional testing with alternative hostnames).

Regards!
 
So, another vote for a small connector daemon here, keeping the Plesk Panel on the management node only. The most ideal setup I like is where service nodes only contain the services I want them to serve. So, say, if a node is a webserver, only a webserver (and MySQL if chosen) is installed on the node. No panel, the panel port can be closed. Everything regarding configuration happens within the management node.

In such a setup it's easy to keep the management channel within the private network. I agree this is more service-orchestration oriented, but I'm still convinced it's the best way security, performance and flexibility-wise.

Edit: I just saw CloudLinux isn't supported for Multi Server. Is this a limit of CloudLinux or Plesk? Or will CL eventually be supported in the (near?) future?
 
Last edited:
Status
Not open for further replies.
Back
Top