[bitfolk] Re: Help with Apache serving incorrect VirtualHost DocumentRoot

Hi Andy, Thanks for taking a look. Comments and answers to your questions inline below. Many thanks, Paul +44 (0) 773 996 2121 From: Andy Smith via BitFolk Users &lt;users(a)mailman.bitfolk.com&gt; Date: Saturday, 9 July 2022 at 12:56 To: users(a)mailman.bitfolk.com &lt;users(a)mailman.bitfolk.com&gt; Cc: Andy Smith &lt;andy(a)bitfolk.com&gt; Subject: [bitfolk] Re: Help with Apache serving incorrect VirtualHost DocumentRoot Hi Paul, I'm not an expert at this but I did notice some things. On Sat, Jul 09, 2022 at 10:31:41AM +0000, Paul Lewis via BitFolk Users wrote: Just reducing this to an example of behaviour you want vs behaviour you don't want… [PJL] This is correct. The first thing that strikes me is that this virtualhost is only for port 80. Port 443 (https) connections aren't going to hit this vhost at all, I don't think. Where do port 443 connections go? [PJL] Yes, you’re right, I didn’t include the SSL VirtualHost, which is pretty much identical, but with SSL certificates and configured and the RewriteConds commented out: <IfModule mod_ssl.c> <VirtualHost *:443> DocumentRoot /var/www/savouredescapes ServerName www.savouredescapes.com ServerAlias savouredescapes.com origin-www.savouredescapes.com www-test.savouredescapes.com <Directory /var/www/savouredescapes/> AllowOverride All </Directory> ErrorDocument 403 /error/noindex.html ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined RewriteEngine on # Some rewrite rules in this file were disabled on your HTTPS site, # because they have the potential to create redirection loops. # RewriteCond %{SERVER_NAME} =savouredescapes.com [OR] # RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR] # RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR] # RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com # RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI} [END,NE,R=permanent] Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/savouredescapes.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/savouredescapes.com/privkey.pem </VirtualHost> </IfModule> Note: Let’s Encrypt sets up the redirect rules for the HTTP virtual host (I edit the RewriteRule to go to the specific www URI I want, rather than using the generic ${SERVER_NAME} URI Let’s Encrypt adds by default), and comments them out in the HTTPS virtual host, to avoid potential redirect loops, as per the comment. I think I could re-enable these rules without creating those loops, but as you point out below, it doesn’t seem that Apache’s doing the redirects anyway, so maybe this config is all just pointless and should be removed. The other thing I notice is that when I do: $ curl -s -v https://origin-www.wofeckcsclub.co.uk > /dev/null I see: […] < HTTP/1.1 301 Moved Permanently < Date: Sat, 09 Jul 2022 11:46:41 GMT < Server: Apache/2.4.29 (Ubuntu) < X-Redirect-By: WordPress < Location: https://www.wofeckcsclub.co.uk/ Whereas with $ curl -s -v https://origin-www.savouredescapes.com/ > /dev/null […] < HTTP/1.1 200 OK < Date: Sat, 09 Jul 2022 11:49:12 GMT < Server: Apache/2.4.29 (Ubuntu) < Link: <https://www.savouredescapes.com/wp-json/>; rel="https://api.w.org/" < Link: <https://wp.me/7loaj>; rel=shortlink < Vary: Accept-Encoding < Transfer-Encoding: chunked < Content-Type: text/html; charset=UTF-8 etc. it serves a web page, no redirect by Wordpress. [PJL] Yes, I think I had noticed this too during the past couple of weeks, just forgot to mention that in my email. This is probably why I was thinking that WordPress is doing some/all of the directs too. So I think maybe there is some setting different in Wordpress between your two example sites. [PJL] Yeah, this is pretty much what I expected, and would definitely appreciate any help that people can offer on this. I know that WordPress can redirect in a multitude of ways, including: * .htaccess file config * Plugins * wp-config.php config and I’m sure there are plenty of others. The .htaccess files are the same across all my WordPress sites, and one site had the wp-config.php configuration, but continues to redirect correctly even after removing it! Maybe I should just install a plugin and be done with it. Note that even your working example doesn't redirect by your Apache config, it redirects by Wordpress. Also I am guessing there is actually more to your config otherwise what is the point of all the additional names? I assume you're recognising Cloudfront by some means and not redirecting them back on themselves infinitely and by the same token your "test" URIs presumably don't redirect (intentionally) for you when you are testing them. [PJL] Yes, it’s a lot of hostnames. When I was hosting the websites directly off the VPS it was much simpler: domain.name was an A record and AAAA record pointing to the VPS, and www.domain.name was a CNAME pointing to domain.name. But when you introduce a CDN, you need to address the origin somehow – and not by a common name like www.domain.name, hence the introduction of origin-www.domain.name. The www-test.domain.name was a new one that I introduced recently during testing, as a name I could quickly switch between pointing at the VPS or the CDN to test if everything was working, without impacting actual visitors to the website. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting