• 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

Issue Problems with two sites, different IP's - same suscription/space

Jose Isla

Basic Pleskian
Server operating system version
Almalinux 9
Plesk version and microupdate number
Plesk Obsidian 18.0.58 Upgrade 2
We have a server with Plesk Web Admin Edition licensed with two sites:

1st Front of the public part of the client, with public IP.
2nd Back and management of the company with a private IP that is only accessible through IPSec VLAN.

These two scenarios must be communicated since the Back needs to connect to the Front's DB and other issues such as an internal file manager.

By forcing Plesk to have sites from the same subscription or space with the same IP. This is not unfeasible.

Right now we manually change the ngnix.conf file manually to change the IP to the Back, but of course with any change or restart it is rebuilt and puts the same IP to the Front and Back.

We have tried moving the Back to a new subscription or space and YES we can have a different IP, but we ran into the problem that different subscriptions or spaces DO NOT communicate with each other. What is the solution?... this same scenario in cPanel if possible.
Sorry for this long text but we don't know what to do anymore.

Thank you all!
 
You may not have gotten an answer, because the scenario is hard to understand and likely some special configuration that is unsupported.
 
Thanks for the response!
Basically the main problem is being able to access the files in read/write mode from a subscription/space different from the other (because each subscription/space) has a different IP.
Can it be solved using symbolic links?
 
It does not only use different IPs, it also uses different user accounts. No, I do not believe that you can find any feasible solution for it. Instead I suggest reviewing why a complicated setup like that has been considered in the first place. What is the business case that you can neither address the real server that servers the content directly, nor have the data on the server that is exposed to the Internet?
 
The argument is very simple:
The BO that is in another subscription/space is the client management application that is protected by an IPSec VLAN connection and has a private IP assigned. It needs to be this way because it should not be exposed to the general public on the Internet, only to users in the client organization.
That BO, apart from containing, let's say, the FO CMS, has the company's internal management application. That is why it should not be visible on the Internet.
Apologies if we have not explained ourselves well.

thank you!
 
Back
Top