Installing Virtualmin on a server that is not 'freshly installed OS'?

OS type and version Ubuntu 22.04 x64
Virtualmin version n/a

I’ve been running Webmin and Usermin for a number of years now, and have been managing my virtual hosts manually. I was thinking about setting up Virtualmin, but the very start of the automated install shell script states:

“This script must be run on a freshly installed supported OS.”

Can I safely ignore this warning an proceed?
I will make a snapshot/backup beforehand either way, but figured that I would ask here before going going full ‘cowboy’.


Define “safe”? It probably won’t cause catastrophic damage to your existing server, but you probably won’t find it easy to get everything working together and get Virtualmin working as documented without notable effort (and, we are hesitant to try to embark on that kind of project here in the forums because it spirals quickly out of control pretty often and users end up doing really wild stuff in a panic).

I personally wouldn’t do it that way. I would start with a new server, install Virtualmin, and then migrate my sites over, in a leisurely fashion, with no risk of outages or downtime.

well dang, I guess I asked this very question about 5 years ago already…
so the question changes slightly, to: has anything changed in 5 years?

We are more hesitant to help with such a project today than five years ago, because we have five more years experience knowing it’s going to get messy.

If you’re an expert, with both Linux and how Virtualmin does things, you can make it work. If you’re not, you’re probably going to struggle.

Thanks for the reply. That’s basically what was recommended 5 years ago. I’m hesitant to do the clean install because I don’t have much documentation on my configuration. I guess a backup of my /etc, /var/www, and /home directories plus a thorough inspection of their contents would reveal the path forward for the rebuild, but I’d rather not…

I would hesitate to call myself an expert with Linux (definitely advanced) , and I’m basically a beginner when it comes to Virtualmin. I am quite familiar with Webmin/Usermin since I’ve been using them for many years.

I would assume that the issues with shoehorning Virtualmin into an existing server would mainly hinge upon the virtualhost configuration and things around that (like certificates), but then again since I"m basically a beginner with Virtualmin I could be way off here.

Let me step back a minute here.

So I’ve got a few domains on this VPS. One of them is has self-hosted (postfix/dovecot) email. Small volume personal/vanity accounts for myself. I’ve configured and protected it as best as I can and while it wasn’t “fun” it wasn’t a nightmare either and I’d like to run email on one of the other domains.

A cursory search of the 'net got me asking myself: “maybe I should install Virtualmin

If I’ve gone this far without Virtualmin would you say that I should probably just continue to go without?

one general thing to keep in mind – the Virtualmin framework isolates each virtual server/website under /public_html/ under a distinct Linux user under /home/ – /var/www is not used by Virtualmin at all. When I first saw this years ago it took me awhile to fully understand it :slight_smile:

That’s one of the places your configuration could be different from what Virtualmin sets up, and an area where you may be missing a bunch of Virtualmin features after importing them into Virtualmin on an existing system.

But, also email is a big area with possibility of wild divergence and where Virtualmin installation could either break your existing configuration or simply not work or both. (And, now that I’m thinking about how different your mail configuration might be, I am inclined to discourage you from trying to install on a production system with even more gusto. At least installing with the install script, since it pulls in a bunch of dependencies that might conflict with the software you’re actually using and thus force the software you’re actually using to be removed.

The way Virtualmin does things may be completely foreign to your system, or look very similar. I can’t guess how you think about problems like virtual hosting. Did you put each site in its own home dir and give it its own user for security? Virtualmin does. Did you pick Postfix and Dovecot for your mail stack? Procmail for delivery agent, or something else? All of these differences can be worked out (and Virtualmin supports a bunch of other configurations and services…this is just the default stack we install).

I’ve made my recommendation: Install Virtualmin on a fresh system and migrate your sites at your leisure and with zero risk.

I can’t imagine managing a full-featured web hosting system, with mail, databases, apps, etc. without Virtualmin. I mean, I can do it, of course, and I have done it, it’s just a lot of wasted hours that could be automated away.

But, if the choice is between “keep doing what you’re doing” and “possibly do a bunch of destructive actions to your existing system”, then just keep on keeping on.

You can see what the Virtualmin install script does, if you want to run through a checklist of what software will be installed (and what that means for what you already have installed and depend on). Check the deps in GitHub - virtualmin/virtualmin-yum-groups: Group definition files for yum/dnf used by virtualmin-install on CentOS/RHEL/Fedora or GitHub - virtualmin/virtualmin-lamp-stack-ubu: Ubuntu metapackage that depends on the LAMP stack for Virtualmin

The middle ground would be just to install the wbm-virtual-server or webmin-virtual-server module, just so you get the core Virtualmin functionality in Webmin without installing any of our dependencies or any of our post-install configuration. That’s entirely safe, but only gets you a small portion of the Virtualmin experience (but the most important part of it for a lot of users…the virtual host and user and database management, though you probably have to do some configuring to make it all actually work).

Honestly, I think you’re trying really hard to make a lot of extra work for yourself, and I can’t condone that sort of thing. I think you’d save time and heartache by starting with a fresh OS, and importing your websites at your leisure.

I suspect a lot of the stuff you found difficult or fiddly to get working probably won’t be with Virtualmin, assuming it’s a full Virtualmin system installed on a fresh supported OS.architecture.

1 Like

I had installed Virtualmin on a fresh server but had to uninstall and reinstall for some reason. I used the command ~# sh --uninstall and ran the install script but it gave me errors saying the OS is not fresh and had few dependencies running already. It even threw a warning about postfix which was installed by Virtualmin. So long story short, I followed some forums that suggested I do the following

 find / -name "webmin"
  find . -type f -exec grep "virtualmin" '{}' \; -print
  sudo find / -name virtualmin
  sudo rm -rf /etc/webmin
  sudo find / -name virtualmin -exec rm -rf {} \;
  cd /etc/webmin
  sudo apt-get remove virtualmin-base
  sudo apt-get autoremove && sudo apt-get autoclean
  sudo find / -name virtualmin
  apt remove postfix
  apt autoremove
  chmod 755 /usr/bin/dpkg
  apt-get install --reinstall dpkg
  sudo rm /etc/systemd/system/proftpd.service
  rm -r /usr/sbin/virtualmin
  apt-get install proftpd-core
  apt-get install --reinstall dpkg
  apt-get remove dpkg-dev
  apt-get clean
  apt-get update && apt-get upgrade
  apt-get install -f

You may have DPKG errors if you tried uninstalling and reinstalling more than once, in my case, this fixed the DPKG problem

sudo mv /var/lib/dpkg/info /var/lib/dpkg/info_silent
sudo mkdir /var/lib/dpkg/info
sudo apt-get update
sudo apt-get -f install
sudo mv /var/lib/dpkg/info/* /var/lib/dpkg/info_silent
sudo rm -rf /var/lib/dpkg/info
sudo mv /var/lib/dpkg/info_silent /var/lib/dpkg/info

Ensure you uninstall your manually configured Apache, MySql, Php and try running Virtualmin automated install.

That’s a terrifying idea!

OP has said it’s a production system! That would absolutely destroy it.

OP, absolutely do not destroy your production system.

Thanks for the advice Joe, I am going to just ‘keep on keeping on’

Ah! Mine was a fresh new server, I assumed it was the case. My apologies!

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