Apache serving wrong vhost

Discussion in 'Installation/Configuration' started by Th0m, Nov 13, 2020.

  1. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Saw the same behaviour as described in https://www.howtoforge.com/community/threads/apache-jumping-between-virtual-hosts.85551/
    Apache sometimes served a different website than requested. All websites have SSL enabled with a valid certificate and all use the IP address of the server (* is not used and disabled).
    Sometimes it results in a error 404, but when it serves a wordpress site, the browser gets a 301 redirect to the real site, which is problematic as this is stored as permanent redirect.
    [email protected]:/home/user# ps -aux | grep apache
    root     11142  0.0  0.5  33520 20932 ?        Ss   15:17   0:00 /usr/sbin/apache2 -k start
    www-data 11144  0.0  0.2  30420  8364 ?        S    15:17   0:00 /usr/sbin/apache2 -k start
    www-data 11171  0.1  0.6 1541644 27288 ?       Sl   15:17   0:00 /usr/sbin/apache2 -k start
    www-data 11172  0.0  0.6 1541780 26032 ?       Sl   15:17   0:00 /usr/sbin/apache2 -k start
    root     11481  0.0  0.0   6144   888 pts/0    S+   15:20   0:00 grep apache
    Does anyone have a idea what's wrong?
  2. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    It might be worth nothing that it seems these issues started happening after I started using PHP-FPM in chroot mode, but not sure why that would/could cause this...
  3. ahrasis

    ahrasis Well-Known Member

    As I read in here before, it seems like several apache2 processes are running at the same time and killing them was said to be resolving. However, I did read elsewhere that one should not kill them as it is normal for apache2 to run several processes at the same time, so restarting is a better approach.

    That's said, I would agree that the best could checking your config for apache2 as mentioned here.
  4. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    I have read that, everything is fine (in mpm_event.conf though, I have mpm_prefork disabled because I use http2)
  5. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    I have only seen/heard about this behaviour when the user was logged in to Wordpress and then viewing the site. No problems reported for "normal" clients so far. Just noting...
  6. ahrasis

    ahrasis Well-Known Member

    Strange. Are you suggesting that WP or its plugin has a bug or some sort of malicious code that can affect apache2 on the server side?
  7. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    No, but just sharing everything I know :)
    Really weird problem.
  8. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Another update... Sometimes a website suddenly gives a error 404, and sometimes it shows the other website and redirects. Seems like the logged in WP user was coincidence.

    Again, this is happening since I enabled chrooted PHP-FPM for all sites. It happens on random moments. Weird...
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    Maybe the chrooted php instances have some issues with the opcaches. I've seen similar problems years ago when the opcache php is using is messed up in a way that several sites use the same opcache. Not sure if that's possible in this case, just an idea.
    ahrasis and Jesse Norell like this.
  10. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    That could be it! This got me searching for this specific issue and I found several issues and a bug report: https://bugs.php.net/bug.php?id=69090
    But it should be fixed....
    Related aswell:

    For now, I have set all sites to FastCGI and everything seems to work fine again. I don't want to mess around with a live webserver (again), but would prefer using chrooted PHP-FPM. Any idea if there's a fix?
  11. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Probably disable php opcache for your chroot ph-fpm version, or try a different one.
    ahrasis likes this.
  12. TonyG

    TonyG Active Member

    TL;DR: When a SSL cert fails to gen, it will start to look like there are cross-site issues.

    I noticed my certs were not working correctly, where going to a subdomain returned an error that the cert was invalid, and it was using the root domain cert. So I regenerated certs for the root domains, then regenerated certs for all subdomains. I did this simply by clicking the LE SSL checkbox in Sites, waiting, setting the Redirect for HTTP/HTTPS, waiting, then testing. Everything was working.
    Just now I created a new subdomain (all vhost) . It properly created the folder under the domain root. On going to this subdomain (HTTP, not SSL yet), it warned about the cert but showed the recently created cert for a subdomain under a different domain.
    Restarting apache2 did not help. Neither did an OS update+restart.

    The issue is that it didn't create the <VirtualHost *:443> node in the .vhost file for the new subdomain. So it used the 443/SSL specs for the next site alphabetically in the enabled list. I see now that I had closed the public firewall, letsencrypt.log shows a failure, ispconfig.log reflects that failure - explaining why .vhost wasn't updated.

    Again, in summary, something in the configuration allows a fall-through condition. The Apache config files are read in sequence, hostAA:80 gets processed, and when the directives for hostAA:443 aren't found, it falls-through to hostBB:443.

    Apache bug? Issue in the directives generated by ISPC? I dunno. Back to you guys. HTH
  13. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Is sounds like default apache (and nginx) behavior.
  14. TonyG

    TonyG Active Member

    I'm also seeing that the .vhost file is simply not correct for the latest subdomain, though it is for all others.
    I don't use /var/www for domains. Web config is:

    Website path: /var/www/clouds/cloud_[client_id]/site_[website_id]
    Symlinks: /var/www/sites/by_name/[website_domain]:/var/www/clouds/cloud_[client_id]/sites/[website_domain]

    But the .vhost file for this problem subdomain shows "<Directory /var/www/sub.example.tld/sub>". That's not a valid path/link.
    Deleting and recreating the subdomain/vhost does not result in the correct .vhost details. So far this is 100% reproducible with the same sub.example.tld.

    As I was reproducing this, note that I have not deleted the LE certs, this error shows in the ISPConfig log:
    The following renewal configurations were invalid: /etc/letsencrypt/renewal/sub.example.tld.conf
    It was fine before. LE didn't re-issue the existing cert. The folder verified as reachable, firewall is open.

    To ensure this is seen as on-topic, I was getting different results in HTTP and HTTPS, now it's not even redirecting. I'm just not seeing what I expect - and to me this seems to be similar to what @Th0m is reporting - and it seems to me like there's other similar buzz in the forums here lately. Something is up.

  15. ahrasis

    ahrasis Well-Known Member

    1. @TonyG, try not hijacking a thread because from my point of view you totally have different problems and need different answers. @Th0m specifically mentioned that this thread of his and one other he linked in here is about WP.

    2. I believe what is said by @Jesse Norell is clear and that is why we do not mixed http and https sites in one server. This is really common, just need correct comprehension and never a problem.

    2. You can try using conf-custom (as @till explained it here) to resolve your path customization issues since what and how you prefer to do are not ISPConfig default vhost settings.

    3. To determine your letsencrypt real issues and solve them properly you will need to do what the sticky letsencrypt FAQ told you to do.

    4. In any event, if your renewal conf is broken, you can either (1) fix it manually which would not be difficult if you have proper backup; or (2) delete the whole LE path for the problematic domain(s) (rm -rf /etc/letsencrypt/*/domain.tld*) and then request new certs for it.
    cremos likes this.
  16. cremos

    cremos Member

    Debian 10 (Buster)
    Ispconfig 3.1.15p2
    Apache2 2.4.38
    PHP-FPM 7.4.11
    I just noticed a similar malfunction with http and https vhosts namely:
    1 / creation of an example space site1.ac-amiens.fr with:
    - <VirtualHost>
    - DocumentRoot /var/www /clients /client8 /web81/web
    - ServerName site1.ac-amiens.fr
    - The http vhost activated

    ps -aux | grep fpm | grep web81
    web81 12836 0.0 0.1 290016 15796? S 08:01 0:00 php-fpm: pool web81
    web81 12837 0.0 0.1 290016 15796? S 08:01 0:00 php-fpm: pool web81

    less /etc/php/7.4/fpm/pool.d/web81.conf
    php_admin_value[open_basedir] = /var/www/clients/client8/web81/web:/var/www/clients/client8/web81/private:/var/www/clients/client8/web81/tmp:/var/www/site1.ac-amiens.fr/web:/srv/www/site1.ac-amiens.fr/web:/usr/share/php5:/usr/share/php:/tmp:/

    When I display the site site1.ac-amiens.fr I arrive on the default page of another space "site2.ac-amiens.fr"
    site2.ac-amiens.fr vhost
    - DocumentRoot /var/www /clients/client1 /web11/dev
    - ServerName site2.ac-amiens.fr

    this displays the PHP info which is in /var/www /site2.ac-amiens.fr/dev/phpinfo.php
    the root document is not the correct one, it should show that of site1.ac-amiens.fr but not that of site2.ac-amiens.fr
    $ _SERVER ['TMP'] /var/www/clients/client1/web11/tmp
    $ _SERVER ['HOSTNAME'] no value
    $ _SERVER ['USER'] web11
    $ _SERVER ['HOME'] /var/www/clients/client1/web11
    $ _SERVER ['SCRIPT_NAME'] /phpinfo.php
    $ _SERVER ['REQUEST_URI'] /phpinfo.php
    $ _SERVER ['QUERY_STRING'] no value
    $ _SERVER ['REMOTE_PORT'] 43126
    $ _SERVER ['SCRIPT_FILENAME'] /var/www/clients/client1/web11/dev/phpinfo.php
    $ _SERVER ['SERVER_ADMIN'] [email protected]
    $ _SERVER ['CONTEXT_DOCUMENT_ROOT'] /var/www/clients/client1/web11/dev
    $ _SERVER ['CONTEXT_PREFIX'] no value
    $ _SERVER ['REQUEST_SCHEME'] https
    $ _SERVER ['DOCUMENT_ROOT'] /var/www/clients/client1/web11/dev
    $ _SERVER ['SERVER_PORT'] 443
    $ _SERVER ['HTTP_HOST'] site1.ac-amiens.fr
    $ _SERVER ['SERVER_NAME'] site1.ac-amiens.fr
    $ _SERVER ['SERVER_SIGNATURE'] <address> Apache / 2.4.38 (Debian) Server at site1.domain Port 443 </address>
    $ _SERVER ['HTTP_X_FORWARDED_SERVER'] site1.ac-amiens.fr
    $ _SERVER ['HTTP_X_FORWARDED_HOST'] site1.ac-amiens.fr

    Thank you in advance for your feedback.
    El Musul Crémos
    Last edited: Nov 17, 2020
  17. ahrasis

    ahrasis Well-Known Member

    I am not sure whether yours are related, but as said above, do not mix http and https in a server. Redirect from http to https is fine but all sites must have https enabled. Further in your case you should also check whether there is a mixture of * and ip address as that could be causing problems too, since site1.ac-amiens.fr is using ip address.
    cremos likes this.
  18. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    This is not the problem here. I already noted that in my original post. What you describe is default behaviour of Apache and broadly discussed in several forum posts and in some comments above ^. So it's not related to the problem I am having.

    What ISPConfig could do to fix this is not allow setting a IP if * is set for a web and vice versa, and always enable SSL with a self signed cert. But I don't think that's necessary.
  19. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter


    does ispconfig/wordpress actually take you to another site when this happens?, or does the browser url show the correct site you're trying to view but the content is from another one of your hosted sites?
    i believe i've seen this before when using php-fpm, on ispconfig 3.0.* with xcache or opcache enabled (no chrooted websites)
    it seemed like all the sites used the same cache and when two different wordpress sites used the same stub for a page, it would load it from the cache, even though the cached version is for a different site.
    disabling the cache fixed the issue.
    i've re-installed everything since then (migration to another datacentre location) and don't remember doing anything to disable php caching, either server-wide or to specific sites, and have not noticed the issue re-appearing. i've not noticed it in any testing on ubuntu20.04/ispconfig3.2 either.
    not done much testing with chrooting individual sites though.
    maybe now caching includes the full filepath of the original site/php file in the cached entity (metadata?) in some way, and with chrooted sites, it's basically just starting with /web for everything so there's nothing to discriminate between identical stubs from different sites in the cache?
    just guessing here...
  20. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    The correct url is shown, but changes because wordpress uses one main url and redirects all others that go to that web. I think the cache sometimes uses the wp-config website A and sometimes of website B for the same site, and that causes the issue. It might be that /web is the issue... but I'm not sure what would be a good way to fix it while leaving opcache enabled.

Share This Page