Subdomain 301 to main domain, no alias given or .htaccess active (force redirect, possible bug)

P

patrickkasie

Verified User
Joined
Sep 21, 2021
Messages
183
Location
Een echte Hollander
The title explains it all.

The situation is: there's an alias b2b.domain.nl connected to domain.nl. Due to the way the website has been programmed, when the website notices the user is on b2b.domain.nl, it will present different content than when you'd be on domain.nl, despite accessing the same files.

Now here's the issue. When entering b2b.domain.nl into the webbrowser, you should see the same website as domain.nl, albeit with various additions for the b2b backbone. But the website just redirects you to domain.nl. No questions asked. Here's what me and my team tried doing to remedy it.
We have a live server and a test server.

Systems: AlmaLinux 8.5
CMS: Opencart V3.0.2.0
CLI PHP: 7.4.
Php version for domain: 7.2 PHP-FPM.
Apache/2.4.54

1. Place the reseller package on the testserver. Doesn't work, still 301 from b2b.domain.nl to domain.nl.
2. Took last night's backup and put it on the testserver. Doesn't work.
3. Took the backup from the 1st of october. Works.
4. Took last night's backup and tried fixing it on the testserver. Steps taken: ./set_permissions.sh all, followed by a chown -R user:user * inside the folder /home/user/domains/domain.nl. I'm 1 folder above the public_html. This actually does work.
5. Performs the same steps on live server. Steps taken: ./set_permissions.sh all, followed by a chown -R user:user * inside the folder /home/user/domains/domain.nl. I'm 1 folder above the public_html. This does NOT work. Tried emptying OpenCart cache, deleted its cache files, refresh modifications+extensions in admin dashboard. Still 301.
6. Reset last night's backup on testserver and performs ./build all to see if that would fix it on the testserver. It does not. So I will not do this step on the live server.
7. Reset last night's backup on testserver. Removed all .htaccess files in the public_html folder. Go to b2b.domain.nl. Still 301 to domain.nl. No 404 or 403 or 500.
8. Edited Custom HTTPD to: |?DOCROOT=/home/user/domains/domain.nl/public_html/something-that-should-crash| . Still 301 to domain.nl, followed by Forbidden 403 You don't have permission to access this resource.

I have absolutely no idea why the test server wants to fix itself and the live server does not. There's seemingly no difference. Why is this 301 so incredibly hard to take out, even with all of the steps above? And why does a seemingly irrelevant step still work on the test server, but not on the live server?
 
I don't know if you have nGinx or just apache or what customisations you made, but for sure somewhere it must cause this forbidden (301) error.
This can also be some .htaccess not in the public_html but in the subdomain itself.
Or some general customisation somewhere (maybe in apache) or something like that?

So you must look in that situation somewhere. Maybe check the logs, possibly it's saying what is causing the issue.

patrickkasie said:
The situation is: there's an alias b2b.domain.nl connected to domain.nl.
Click to expand...
What do you mean here by "connected" and in which way?
 
possible "Domain Pointer", you forgot to tick checkbox "Use as an Alias" ?
 
jamgames2 said:
possible "Domain Pointer", you forgot to tick checkbox "Use as an Alias" ?
Click to expand...
It's written down as Alias, not Domain Pointer. It also wouldn't explain why an older backup would work. Or why changing permissions have any effect in the testenvironment but not in the live environment.
 
patrickkasie said:
A 301 is a site redirection.
Click to expand...
Oeps sorry indeed. But still, I think it's some customisation somewhere, maybe a custom httpd configuration. That might explain why an older backup (if that was working) does not help.

As for permissions... normally that should be good automatically? I don't know if you're working with mod_php and mod_ruid2 (which will be removed) or php-fpm or lsphp or fastcgi or what choices are there at the time.
Normally with php-fpm there should not be an issue with permissions. Which also makes me thinking there is some customisation somewhere.
 
Richard G said:
maybe a custom httpd configuration. That might explain why an older backup (if that was working) does not help
Click to expand...
There's 3 situations:
-Backup 1st of october
-Backup last night (31st of october)
-Live

The backup on the 1st of october works. The backup on 31st of october does NOT. Fixing it using all the above steps works in the backup on the 31st, but NOT on live. It reluctantly keeps redirecting the b2b.domain.nl to domain.nl, even if I artificially edit the custom HTTPD configuration to trip into an intentional 403 error. That's what is making no sense to me.

The Custom HTTPD is not edited on any hosting account, except for the backup 31st because I want to force it into an error without redirecting. But it redirects you to domain.nl anyway, completely disregarding the inoperative .htaccess files or custom HTTPD
 

Attachments

  • mRemoteNG_tNuzituiue.png
    mRemoteNG_tNuzituiue.png
    11.5 KB · Views: 66
It becomes quite urgent as my client's customers cannot place orders as it is. We cannot move the live environment as it is to a test server. That's just not done. A 9th step being executed right now is changing the PHP CLI versions, even though I don't have high hopes it'll work. Anyone else who has any idea? @fln @smtalk
 
When we moved our backups around, we've found out that the location /home/user does not save the full backup, to our dismay, just the website itself.

This means we've lost access to the proper data of the 1st of october, but it's still forcing the redirect. We do not know where a forced redirect could be. What's the locations to all of the following for us to check out?

​
Domains Directory
​
E-Mail Accounts
​
Subdomain Lists
​
E-Mail Data
​
Ftp Accounts
​
E-Mail Settings
​
Ftp Settings
​
Vacation Messages
​
Database Settings
​
Autoresponders
​
Database Data
​
Mailing Lists
​
Deleted Trash Data
​
Forwarders

We've executed the following commands to find out where a potential redirect could be hidden inside:
cd /
find . -name "*domain*" ! -path "./home/*" -exec grep -rIil "301\|redirect\|b2b.domain.nl" {} \;
We've opened all files, we couldn't find anything besides the ./usr/local/directadmin/data/users/user/httpd.conf . In a last ditch effort, we've tried editing that file and commenting the b2b.domain.nl appearances. We've then restarted the named service, but to no avail.
./build rewrite_confs overwrote the edit we've made in the httpd.conf afterwards.
Where can we look for another potential redirect?
 
Update: it works now. It might be a bug in DirectAdmin.

What has happened is I've adjusted the option to "Force Redirect" on the domain from "No redirection" to "www.domain.nl" on the domain settings. What followed was all traffic got redirected from b2b.domain.nl to www.domain.nl. Upon further testing, this also happened on "completelyrandomdomain.nl" when creating the alias "completelyrandomdomain.vps123.nl". It went from "completelyrandomdomain.vps123.nl" to "www.completelyrandomdomain.nl". However, the reason we never thought of this was because this specific setting, Force www.domain.nl, has never been an issue on other VPS servers. But it is a problem on specifically the testserver AND live server, but not on completely different VPS-es.

TL;DR: force www. redirection forces the browser to go to www.domain.nl, regardless of what aliases do on these 2 servers.
 
patrickkasie said:
It might be a bug in DirectAdmin.
Click to expand...
I think it might be working as designed. Normally I would say then everything would be redirected to the same just with www included in front of it.

In your case this happens:
patrickkasie said:
When entering b2b.domain.nl into the webbrowser, you should see the same website as domain.nl, albeit with various additions for the b2b backbone. But the website just redirects you to domain.nl.
Click to expand...
If b2b was just a subdomain (which is normal situation) one would expect the behaviour that b2b.domain.nl would be redirected to www.b2b.domain.nl if all goes well.
Think of the fact that if you create a subdomain, normally 2 records are created, sub.domain.com and www.sub.domain.com so this www.sub.domain.com is already reserverd for the subdomain.

But you used a pointer as alias.
Pointers are send from the original domain including www. A subdomain is no pointer. Unless maybe if you create the subdomain as a domain. So probably that's the reason the system has to make a choice what to do with the force redirect as it's forced.
Since normally it forces to the subdomain, but now the subdomain does not exists (because it's a pointer) the redirection goes to the main domain.
At least this sounds logical to me.

So without the force to redirect somewhere, then the system can work like you want it to work.
Again, that's my 2 cents on this, I could be wrong, but since I know of the www record automatically created for subdomains, this might intervene with the force redirect.
 
Oke I had a look, and in fact it happens a bit different as described, and that is indeed an odd situation.

This is what is happening.

On one server with forced www redirection active, it works like this:
Source Domainhttp://www.example.otherdomain18.nl --> www.example.nl
When I visit example.otherdomain18.nl then I'm redirected to www.example.nl as should be.

On another server, exactly setup the same, just using another domain, this happens:

Source Domain http://www.example2.somedomain20.nl --> www.example2.nl

Now in this case, when I visit example2.somedomain20.nl I'm redirected to www.example2.somedomain20.nl instead of to www.example2.nl which is wrong.
I should be redirected to www.example2.com in fact.

Only difference on both servers is that on server 2 also ipv6 is in use as far as I could see quickly.
 
Last edited:
Richard G said:
Oke I had a look, and in fact it happens a bit different as described, and that is indeed an odd situation.

This is what is happening.

On one server with forced www redirection active, it works like this:
Source Domainhttp://www.example.otherdomain18.nl --> www.example.nl
When I visit example.otherdomain18.nl then I'm redirected to www.example.nl as should be.

On another server, exactly setup the same, just using another domain, this happens:

Source Domain http://www.example2.somedomain20.nl --> www.example2.nl

Now in this case, when I visit example2.somedomain20.nl I'm redirected to somedomain20.nl instead of to example2.nl which is wrong.
I should be redirected to www.example2.com in fact.

Only difference on both servers is that on server 2 also ipv6 is in use as far as I could see quickly.
Click to expand...
I've taken a better look at your reply, and I should add it's not you being redirected from example2.somedomain20.nl to somedomain20.nl, but to www.example2.somedomain20.nl
 
patrickkasie said:
it's not you being redirected from example2.somedomain20.nl to somedomain20.nl, but to www.example2.somedomain20.nl
Click to expand...
Ah oke so the redirect is to the same subdomain with www in front, but still not to the correct domain, should be to www.example2.nl still.

The given redirect isn't executed anyway, which is the most important, since that does work on the other server you use it on this way.
Thanks for correcting this.

I have editted my post and fixed it accordingly.
Hope DA can find the cause for this odd error.
 
You must log in or register to reply here.
Back
Top