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 <users@mailman.bitfolk.com>
Date: Saturday, 9 July 2022 at 12:56
To: users@mailman.bitfolk.com <users@mailman.bitfolk.com>
Cc: Andy Smith <andy@bitfolk.com>
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:
> Now to the problem
>
> 6. https://origin-www.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk --> website loads

> 6. https://origin-www.savouredescapes.com --> website loads [not correct]

Just reducing this to an example of behaviour you want vs behaviour
you don't want…

[PJL] This is correct.

> All the VirtualHosts are configured the same, and look like this:
>
> <VirtualHost *:80>
>         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
> 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]
> </VirtualHost>

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:

DocumentRoot /var/www/savouredescapes

ServerName www.savouredescapes.com

ServerAlias savouredescapes.com origin-www.savouredescapes.com www-test.savouredescapes.com

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:

    > GET / HTTP/1.1
    > Host: origin-www.wofeckcsclub.co.uk
    > User-Agent: curl/7.64.0
    > Accept: */*
    >

[…]

    < 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

    > GET / HTTP/1.1
    > Host: origin-www.savouredescapes.com
    > User-Agent: curl/7.64.0
    > Accept: */*
    >

[…]

    < 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