Resolved Plesk 18.0.32 will not show anything else but the default page

[kmpww]

Good evening!

I have now lost two days trying to figure out what in the world I'm doing wrong and I cannot for the life of me find the problem.

I have migrated, using the Plesk Migrator Extension from one Obsidisan to another Obsidian, now v. 18.0.32 on a different server.

The problem is, that ONLY in the preview window ALL web pages shows the correct data, but whenever I access the domains from a browser - even from a lynx on the Ubuntu 20.04 the Server is now running, it only shows the Plesk Default Webpage.

One could have thought, that the migration failed, but even a completely new web site subscription shows the same behaviour.

It would seem that also nginx is running in that scenario, yet, if I punch a hole in the firewall to access port 7080 directly, which is the port that's in the httpd config as the serving port for apache2, nothing changes.

I am totally lost. Any help solving this weird behaviour would be appreciated!

Thanks!

Kai

 

[IgorG]

Make sure that domains are in Active status but not Disabled or Suspended. In this case, visitors will see the web server's default page.

 

[kmpww]

Hello @IgorG,

thank you for your reply. All domains are set to active, just like they were on the source server from the migration.

Kai

 

[Bitpalast]

Are your DNS entries pointing to the correct new server IP address? Or do you need to update your domain registration with the new DNS server(s)?

 

[kmpww]

Hello @Peter Debik, yes they are. When using https://... The accessible admin page (or whatever this feature was called) of the correct server is displayed. If the DNS wasn't pointing to the correct server, it would point to old one, where the pages worked correctly.

The next thing I'll try is to deactivate said accessible admin page, hoping this changes something in the logic of the server components. Not very hopeful it changes anything but you gotta grab all the straws right?

Kai

 

[Bitpalast]

, yes they are. When using https://... The accessible admin page (or whatever this feature was called) of the correct server is displayed.

Please explain, don't understand what you mean.

If the DNS wasn't pointing to the correct server, it would point to old one, where the pages worked correctly.

Not necessarily. Entries could point to another address that is not associated with your server but is a Plesk instance. You might think you have the right IP address, but the request ends up on a totally different machine, which is also a Plesk instance, but redirects the request to the default page on that machine because it does not know the domain names.

Have you actually confirmed by traceroute that a request to a domain of the server ends up on your new server's IP address?

Have you verified that the IP address is correct, associated with that server and that the new server can be reached by that IP address? If a request for a virtual hosted domain cannot be processed by a virtual host, you would see the request in the general Nginx or Apache logs in /var/log. Can you see that request there? It's gotta show up somewhere. If it does not show up in the domain's log, it must show up in the general web server log(s).

Also check whether IPv4 and IPv6 have been configured correctly. Maybe only one was updated on migration, but not the other?

Do you have Nginx enabled?
# /usr/local/psa/admin/sbin/nginxmng -s
If so, did it start up properly or did it throw an error that for example it cannot bind to IPv6, only fo IPv4 or vice versa? Can it bind to both? Are you using both?

For testing purposes you could also consider to temporarily disable Nginx on the machine, so that for testing you only need to check Apache.
Enable # /usr/local/psa/admin/sbin/nginxmng -e
Disable # /usr/local/psa/admin/sbin/nginxmng -d

Also check if you are using a proxy service like Cloudflare and deactivate that or clear its cache. It might serve requests from a wrong source.

Also run
# /usr/local/psa/admin/sbin/httpdmng --reconfigure-all
to reconfigure all web server configuration files. Afterwards, descend into /var/www/vhosts/system/<some virtual host domain>/conf and check if the configuration files are really present. Look into one Apache configuration file to verify that it's been built correctly and is actually creating the virtual host of that domain you're checking. It is thinkable that due to custom configuration templates, the files are missing or do not have a proper content, e.g. are empty.

Then look into /etc/httpd/conf/plesk.conf.d/vhosts to verify that the symbolic link to the configuration file that you verified in the previous step for example is present.

Check if /etc/httpd/conf.d/zz010_psa_httpd.conf is present and contains these lines:

Include '/etc/httpd/conf/plesk.conf.d/server.conf'
IncludeOptional '/etc/httpd/conf/plesk.conf.d/webmails/*.conf'
IncludeOptional '/etc/httpd/conf/plesk.conf.d/vhosts/*.conf'
IncludeOptional '/etc/httpd/conf/plesk.conf.d/forwarding/*.conf'
IncludeOptional '/etc/httpd/conf/plesk.conf.d/wildcards/*.conf'

(If on your operating system Apache configuration is located in a different path, use that path instead.)

Restart Nginx and Apache, then try again if the virtual hosts became active.

 

[kmpww]

Also check whether IPv4 and IPv6 have been configured correctly. Maybe only one was updated on migration, but not the other?

*sic* it has been right before my eyes and I didn't even see it.

You were totally right, the source server only had IPv4, that's why the IPv6 address, that I was accessing the server on set idly in the plesk config and wasn't attached to any of the domains.

Sorry to have wasted your time, @Peter Debik, thank you very much for your help!