Just a heads up that I’ll be performing a server migration of Virtualmin.com and software.virtualmin.com this afternoon or tonight. Downtime is expected to be minimal, just a few minutes to an hour or two. In particularly software.virtualmin.com downtime should be unnoticeable, since it won’t matter much if it’s not immediately in sync.
But, expectations don’t always match reality, so downtime may run longer, or there may be some bumps in the process (we’re also changing our architecture a bit to enable better future scaling; as you may have noticed we’ve had some growing pains with the current servers, as our user base has grown dramatically). So, if you have anything important to file tickets about, do it now.
Also, our mail will be moving, as well, which means our MTA will be down for a few minutes, while the final rsync runs.
I’ll also be rolling out Virtualmin 3.88 today, but, again, software.virtualmin.com shouldn’t have any problems, since it’ll be running on both the new and old IP addresses through the process.
If all goes well, you won’t notice any difference…the site will just be faster, and the 500 errors that folks have been seeing intermittently for the past few months will hopefully be gone.
No. The virtual-server module has no relation to that issue…it is a virtualmin-base issue.
And, unfortunately, there’s nothing to be done about that issue on currently effected systems (as “fixing” it would cause huge swaths of packages to be automatically removed for everyone; there is simply no safe way to resolve it for those systems; you can work around it, and I’ve covered how in the upgrade notes here in the forums for Debian, but it can’t be fixed in existing Ubuntu 10.04 systems). The latest Debian release has had this issue resolved (though I think in many ways the new way is less elegant and potentially more error prone, it is more flexible), and the next LTS release of Ubuntu will also get the altered install.sh and virtualmin-base.
Luckily, only a handful of users are effected by it. I’ll also note that it is of questionable benefit…forking on Linux is extremely fast and efficient and there is very little shared state between Apache processes that normal library caching doesn’t accommodate, so moving to a threaded Apache isn’t particularly helpful in most environments. On systems that have heavier processes, and clunkier fork semantics, like Windows, it’s important to use alternatives to prefork, but on Linux, that’s not the case.
If so, it did not really help I’m afraid. I’ve just checked back - after a few weeks of pause and waiting for server to become stable - to forums and issue tracker, and I’m still seeing very long page loading delays and “500 Internal server errors” when retrieving the “Your recent posts” page.
It got derailed by some last-minute database and firewall issues. It has now taken place. DNS is propagating as we speak.
I’m sure I’ll be tweaking things and fixing minor issues for the next day or two, but we’re now on the new servers, and it should be dramatically faster and more reliable.
