I have been running a mailserver with virtualmin GPL for years and was always very happy. Untili now I used to be able to fix smaller issues by myself (e.g. wrong theme). The server runs postfix/dovecot/roundcube and I used virtualmin to administrate the virtual servers for my customers.
But now I am completely stuck: I needed to upgrade the server from Ubuntu 12.04 for security reasons. The first upgrade (12 → 14) did not complete successfully. The upgrade from 14 to 16 worked after removing some broken packages.
So it might be that there are some broken dependencies but I got everything I need up and running but virtualmin does not run anymore.
After the upgrade the directory virtual-server disappeared from /usr/share/webmin. I could copy the folder from another server but I am not sure if it is the same version as before. When trying to call the virtualmin module the following error is reported:
ERROR — PERL EXECUTION FAILED
Undefined subroutine &virtual_server::wizard_redirect called at /usr/share/webmin/virtual-server/index.cgi line 8.
Since I am not a PERL expert I do not know how to fix this. Is there a way to repair a broken virtualmin installation?
This request for help should have been posted in another section of the forum, it is not an issue in Virtualmin.
You didn’t provide any details how you did the upgrade as steps. You most likely did not edit the other files in /etc/apt to change the repositories, other than Ubuntu. This is a common mistake. In addition, the README file which inform about the differences between versions must be taken in consideration in order to make further changes.
Personally, I would have made a complete backup of the system and taken it to a test environment, a VM image from which to start testing the system upgrade. Then I did the upgrade step by step as shown in many tutorials. If the jump is more than one version, I would recommend installing the final operating system to avoid any further problems. If you have the configurations saved from Webmin/Virtualmin, it won’t take much to have a properly configured server with minimal efforts.
Hi,
thanks for the reply. First of all: In which section should I post this.
Second: The upgrade was done with do-release-upgrade. I’d like to make a dry run on a separate system, but this is not a VM. So it was simply not possible. Also lack of time was an issue.
Anyway, if I am not able to fix it my self I will have to administrate everything without the help of virtualmin. BTW: Of course moving everything to a new and clean server would have been an option, but since there are tons of data which cannot be transferred easily I had not too much choice. I was thinking of something wrong with path configurations, environment variables or missing entries somewhere. Thank you anyway.
That’s almost always a problem. We don’t recommend performing distro-upgrades. Many things can go broken (and usually go broken). Even though it is possible to fix popped up issues, but I’d say it would take much more time then simply spinning up a new Ubuntu 22.04 or Debian 12 and migrating websites.
That said, I don’t see how the issue you reported can be a Virtualmin problem.
I solved the problem by re-installing virtualmin from the gpl repo for ubuntu-xenial after adding the repo to sources.list. I got everything running again:
host:
hostname: gandalf.lustige-informatik.at
module root: /usr/share/webmin/virtual-server
os: Ubuntu Linux 16.04.7
root: /usr/share/webmin
theme version: 21.05
virtualmin version: 7.2.gpl-1
webmin version: 2.102
Most important all data from my previous virtual servers is accessible. Finally I’d like to say that I never thought it was actually a virtualmin problem. Just missed the right place, sorry for that. I was just hoping that you can point me in the right direction. Thanks.
That’s not really true. I’ve had mostly good luck with them. But, going from 12.04 to 20.04 (which is how far you have to go to get to a maintained Ubuntu version) is almost certainly a bridge too far. I do recommend a fresh install and migration for something that dramatic.
Going from a good, up to date, 16.04 to 20.04 is fine, though. But 12.04 is going to have a very, very, old Virtualmin repo and configuration. So…that’s messy.
Joe, I had not really a choice other than risking a quick and - yes! - dirty solution. I always refrained from updating the server because I was quite aware that running an upgrade with virtualmin in place might break up things. It was not so easy to find reliable information how to upgrade virtualmin anyway. I also did not intend to go as far as to 20.04 because I have done this before and starting with 12.04 - especially when something goes wrong - is as you said far away. Unfortunately the server in question is a (physical) production mailserver and before moving everything to a new system (probably running 20.04) I have had to bring this machine in a working state - which is the case now. Actually the information that Ilia gave me was exactly the one I was looking for. But I did not dare to run virtualmin-install.sh again without exactly knowing the necessary switches. I found a post that said very clearly that running the install script again will mess up everything - and probably destroy the former virtual server settings. Anyway - you guys brought me to think in the right direction and maybe someone else finds this useful.
And of course I am perfectly aware of the fact that 16.04 is outdated but since I use manually setup configurations which are not out of the box I am sure that they stop working when I continue to upgrade to 18.04 or beyond. This server runs for more than 15 years! Going to 20.04 can only be done by setting up a new system and migrating everything which takes time - which I got now.
Yeah, I know, that used to be true. The current version of the install script has a --setup flag that just configures repos.
But, I think it was a mistake to put that functionality into the install script after we’d spent years telling people to never run it on a production server. It’s mixed messages. We probably should have just made a separate script for the repos, though it’d be something else to maintain.
Edit: Ilia just reminded me there is also the virtualmin setup-repos command, if you’re reasonably up to date with the Virtualmin package, and that doesn’t need the install script at all. I’ll try to remember to recommend that, instead, in the future.
@cbalogh You can run AWS instances and pay by the minute. So spinning up a new temp server to migrate to while you prep the new system isn’t that painful. It is also a good test to see how well you old data gets imported into the newer setup.