@ahrasis You're frequently much too quick to critize and dismiss. This was not a hijaack, I was providing an example of a scenario that controllably reproduces the symptoms that Thom describes. I use WordPress extensively and found what I thought was the same issue before installing it in the sites alphabetically around the problem site and with no other apparent cache issues. @Th0m said "Seems like the logged in WP user was coincidence." A linked similar issue was resolved with a reboot. I said I rebooted and can still reproduce the issue. I am not crossing HTTP/HTTPS. And this is not a custom-conf. I am using the software as designed using fields providing in configuration screens and according to the documentation. This allows me to confirm the existing docs and to make notes for new ones. I gladly accept that the two issues that I relate are not the same as Thom's: incorrect document root and cross-site execution. I also gladly accept when I have made errors. Nevertheless I am having these issues in a default environment. I have verified a defect in docroot assignment, and I offered this information about apache serving the wrong vhost in a thread that the OP titled "apache serving the wrong vhost". Really! Leave the attitude at the door.
@TonyG : What Ahrasis wrote is correct, in that the problem you describe is not related to the problem @Th0m has in this thread. It may not be obvious the problems are different, but still the situation you described should not be in this thread. Besides, the problem you describe is discussed about weekly in this forum.
Thanks @Taleman - I've noticed that issue has been discussed frequently and due to the volume thought there was a general trend. I will look more closely at the other threads - only so much time for all of us. My only objection here to the dismissive attitude. Otherwise we're all on the same page. I will do my homework and certainly always try to keep posts pertinent and properly researched.
This can be achieved by unticking the checkbox "HTTP NameVirtualHost" in the IP settings here: System > Server IP.
I know But as a lot of users make a mistake, maybe we should add a warning message or something like that.
Maybe we should add the IP addresses there without HTTP NameVirtualHost enabled at install time? -- update -- Just had a look at the code, we'll just have to change line 496 in installer_base.lib.php from: "y", to "n",
Sure, would be a good addition in my opinion I guess most users will never have to select an IP instead of * and it will probably prevent many support posts.
@Taleman, thanks a lot. I really appreciate your words. Anyone can read that I didn't criticize or dismiss @TonyG summarily but I simply believed his problems and answers are different in my point of view; and I did try provide answers for him as well as for @cremos following after him, which IMHO should be in different threads, but doesn't really matter now. I did also note in his post about seemingly recurring problem is the LE broken renewal config for a domain where I did recently response to one in a similar problem before in other thread but I am not sure how did this happen (since previously we did have this problem with certbot on this but was later resolved). Hopefully, the LE FAQ help and it won't occur again or we might need to revisit to see what is the real cause.
[Solved] Hello, a colleague spent the weekend on the same problem and we just found the solution after a long evening of research. I have seen this subject on several threads so I leave this message to help future unfortunate ISPC admins, because at first glance it's unintelligible. It is in fact an anomaly with the chroot of php-fpm as proposed above. I didn't have time to do a bug analysis but the /tmp configuration of each website that should be relative to the chroot is in fact absolute and the temporary data of all the websites with php-fpm cross each other. If you enable php-fpm chrooting and you use for example the Wordpress CMS on several websites, their database access credentials will get mixed up and you'll get 500 errors or redirections to other websites. You can see the difference in the php-fpm configurations, the temporary folder paths are not in the client directory but just /tmp. To return to normal, you must disable the "Default chrooted PHP-FPM" option in "PHP settings" and uncheck the same option in each website php-fpm advanced settings. (you can list the concerned websites with: grep "= /tmp" /etc/php/*/fpm/pool.d/*)
I suppose it's possible, but I've never known WP to store db credentials in temp files - what you describe sounds like a share php opcache, not shared temp files. I'll definitely check in to the shared tmp concern though, thank you for reporting that.
I did confirm the tmp folder is not shared by php scripts with chroot php-fpm, the env vars are correctly set to /tmp and that is within the chroot jail, not the system /tmp. It might not hurt to also explicitly set sys_temp_dir in each website conf, but it should end up using the setting from env vars. Two other settings on my system (debian10, php 7.3) use /tmp only and do not update to be site specific, soap.wsdl_cache_dir and opcache.lockfile_path. I'd suspect it's the opcache, which makes sense as the file path for scripts are always different per site without chroot, but will collide (eg. always reads /web/index.php or /web/wp-config.php, etc.) with chroot. What are actual filenames are you seeing show up in /tmp, @Tupolef? Try setting opcache.validate_root=1 in php.ini for php-fpm and see if that fixes it. If not, try opcache.use_cwd=1 and opcache.file_cache_consistency_checks=1, though I don't know if those will help in chroot or not (and might default to those settings in debian anyways).
Also looks like the HOME env var should be set per-site, right now I see eg.: Code: HOME /var/www/clients/client1/web20/./home/web20
