Wrong site being served by apache

SYSTEM INFORMATION
OS type and version Ubuntu 22.04
Webmin version Latest
Virtualmin version Latest
Related packages SUGGESTED

I just setup a new site on my server (and deleted it and re set it up) and each time i try to view it i get a different site on my server. This has been an ongoing issue and I would like to know what the permanent fix is.

This always happens, i ask for help then figure it out.

Seems that the new version of virtuialmin does not copy the config from sites-available to sites-enabled it just creates a symlink. This does not seem to work properly.

I removed the symlink and copied the config and it works properly.

Perhaps the issue is that all of the other sites conf files are copied not symlinked. it may work if they are ALL symlinked but i am not sure and cant test on this production machine.

See this: Website Troubleshooting – Virtualmin

This is definitely not the problem. Making a symlink is the only right way to do this. That’s how the OS-provided tools do it.

well changing from a symlink to an actual file resolves the issue.

You always seem to be quite negative and confrontational Joe. We pay for pro so we have access to Premium Ticket Support. Your assistance is never “premium” thats for sure.

you should pay for a pro-fessional webmaster too… you obviously don’t know sh*t about apache.

apache uses symlinks. there’s official apache-provided tool called a2ensite which does exactly that. (=symlink to sites-available/site.)
something else is wrong, but not providing details (files/logs/etc), isn’t gonna get you anywhere closer to debugging your issue…

2c.

a2ensite is provided by Debian (and, thus, Ubuntu), not Apache, but still, this is a practice we got from upstream. It’s not our invention.

1 Like

I’m sorry, I wasn’t intending to be confrontational, just trying to rule out things that can’t be the cause of the issue.

I still don’t really have any ideas about what you’re seeing; symlinks is how this is normally done on Ubuntu, so I’m not sure what is going wrong in your case. We’d need more info. Errors from the error log might help clear it up.

you’re right, i got confused because debian/ubuntu ship it along with apache2 package.

This thread has cemented our dedication to our new project. We will be dumping virtualmin and moving to an actual containerization solutions. Webmin is a fine tool but the virtualmin team is not one we wish to continue working with.

I had the experience you described yesterday with a second Virtualmin-based server that I’m building. I migrated a Virtual Server containing four domains (call them domain1.com … domain4.com) and four small web servers to the new Virtualmin-based server, which is running Ubuntu 18.04.6.

All other aspects of the migration were resolved and worked correctly. But when I tried to look at domain1.com or one of the other domains with a web browser, I was shown the home page of a website that previously existed on this second server.

I compared the Apache .conf file for properly-functioning web server with one of the newly-migrated .conf file (i.e. domain1.com.conf, domain2.com.conf, etc.) that exists in the /etc/apache2/sites-available directory.

What I found was the VirtualHost directives in the newly-migrated .conf files only referenced the iPv4 address, but the properly-functioning web server referenced both the the iPv4 and the iPv6 addresses.

When I added the iPv6 to the newly-migrated .conf files, saved them, and restarted Apache, the five web servers all started working correctly and resolving to the correct domain names.

I hope this explanation makes sense, and it helps someone avoid a bunch of manual file comparison that I ended up having to do.

1 Like

There’s a doc that covers this problem, though I don’t think it explicitly calls out IPv6 as a possible culprit.

If you just google “virtualmin wrong site shows up” you should get that link (hopefully). Er, I just checked, and Google pushes it to the fourth result and shows the ancient archived doc version (argh, frustrating, I guess I need to figure out how to tell Google some other page is correct, somehow), but DuckDuckGo gets it right and it is the first result.

Edit: And, of course, searching the forum will also turn up a bunch of discussion. It’s a common problem, and not one we can easily prevent (though we’ve tried…if you go back far enough, you’ll find a lot more gnashing of teeth about it because we relied on different default behavior when creating domains…detecting any * as an invitation to always use *, which makes more of a mess than the opposite, which is what we do now). When you have multiple IPs, and you have virtual servers using different indicators of IP:port combinations, you get Apache’s wildly unintuitive selection code at work…and it doesn’t behave in the way anybody would ever expect, I think.

2 Likes

I agree.

I just wanted to help out with one possible use case, because I had just experienced it, and because it might help another server administrator.

1 Like

Yeah, I think it’s worth updating our docs to also cover the IPv6 case. It’s the same problem, it just looks a little different…it may not jump out at someone if they don’t see the exact situation described in the doc.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.