Why is that, doc say to use
sudo sh -c "$(curl -fsSL https://download.virtualmin.com/virtualmin-install)" -- --bundle LAMP
Right, pro. From memory I just add the licience into GPL and it worked, I canāt remember running a command
I had an existing licence so it seemed like the best option as you donāt have to upgrade from within the virtualmin, it starts life as a pro virtualmin install
I dug into this and found the real culprit. To be clear, repo setup is a very complex flow with thousands of small ordered steps, and I made one ordering mistake in the EL migration pathāwe removed the old release/repo file before checking whether the old repo had been present. Because of that, the migration logic never ran on EL systems.
Besides, the migration script did not correctly handle release-number changes within the same package version, for example Webmin 2.641-1 vs 2.641-3. That would have caused problems too, because package managers treat those as different package releases even though the upstream Webmin version is the same.
Debian and Ubuntu were not affected in the same way because their migration path still detected the old repo correctly and ran the migration as expected.
I understand the concern, but Iām sure it would be far more complicated to support both paths.
A repo change happens either way because moving from GPL to Pro is also a repo change. I understand and agree itās not exactly the same as moving from Virtualmin 7 repos to Virtualmin 8 repos within the same product line, but we still need to place the system on the correct Pro repo. This is especially important for clean Virtualmin 8 GPL installs upgraded to Pro, as they must get the new Virtualmin Pro repo, not the old one.
So, if we try to support both, we have to distinguish between clean GPL-to-Pro upgrades, older Virtualmin 7 repo installs, already-migrated systems, stable/pre-release/unstable branches, and GPL vs Pro repo layouts. That would highly likely create more issues than it solves.
The migration logic is designed to handle repo switch cleanly, and now it does on both EL systems and Debian/Ubuntu. Factually, the main practical difference between the old and new repos is that Webmin changed from a full package to a core package with separate module packages. If the migration runs correctly, as it does now, it reinstalls Webmin from the new repo and restores the Webmin modules the user was already using.
Later this autumn, weāll still need to ask a much larger group of users to upgrade their repos. Theyāll start seeing a message during config check starting September 30 asking them to do so. If we didnāt already have this process in place, the same type of bug could have affected a much larger group of users. Now the repo upgrade path should be smooth, and users shouldnāt have to worry anymore about missing modules they were previously using.
In the past, the repo upgrade logic was mostly hard-coded around the Virtualmin package itself, which made these kinds of issues much harder to fix cleanly. Now the repo setup logic is decoupled, so we can fix repo setup or repo migration bugs in no time.
And, as you very well know, Joe, the repo setup script is extremely complex. And, this is why itās now the single source of truth for how GPL and Pro repos are configured across stable, pre-release, and unstable branches across different systems.
In this case, as I explained above, the EL issue came down to one ordering mistake in a process with thousands of small steps, as we removed the old repo file before checking whether the old repo was present. Thatās fixed now, so no worries here.
I added a direct link from the Virtualmin Documentation page in the FAQ section to explain the change. Itās now much easier to find.
Yet, after all Iām thinking we should add back a few modules to Webmin core package that many users asked about, like webmin-custom and webmin-postgresql at least. Iāll test how it behaves during upgrades and whether package managers can handle the change correctly.
Again, thanks to everyone for bringing this up and helping to sort out a tricky but important issue. I really appreciate it!
And sorry for any frustration caused by the few missing Webmin modules after upgrade.
ok is there any way to restore back to the virtualmin 7 repros and get apt to reinstall everything back to how it was ? I guess not. This looks like an ill conceived āimprovementā that has come home to roost, to the point being that ācleverā is not always the best way forward
I use Debian/Ubuntu whichever, maybe you need to look at that also, perhaps you missed a step or 2 there also
This was something Jamie, Joe, and I agreed on. It wasnāt a solo decision, and it was done to make an improvement.
Why would you want to restore the Virtualmin 7 repos? What exactly is missing?
What did I miss? Is something not working for you?
Iāll see what else we can do to make it truly resilient. We should upgrade the Webmin and Virtualmin packages before running the repo switch and the final upgrade to Pro. The patch is here:
Iāve run more tests and added one final patch to make it run more smoothly and removed webmin from the process, since all we need is the latest Virtualmin GPL package for everything to work properly.
I consider this issue fully resolved.
Donāt forget this was a pro install rather than an upgrade from gpl to pro, does this fix also work in that instance ?
If the upgrade happened to go through without triggering the migration logic, you would need to install the missing modules manually, such as with apt install webmin-custom.
Can you tell me what is missing for you?
at a quick look
- webmin-firewall
- webmin-firewall6
- webmin-custom
- webmin-rubygems
- PPTP VPN Server (not reinstalled this one yet so I donāt know the module nme)
- There may others but Iām in the process of trying to remember what was installed
what it also did was to re enable firewalld and move the module from unused to current, Iāve not used firewalld in about 3 years, so was this the package manager re enabling firewalld or something to do with the upgrade (?) to the webmin 8 repro ?
All of these can be manually installed in a few seconds using a package manager.
Thatās unlikely, because for that to happen, something would need to install the firewall-cmd package. And, the Webmin Firewalld module is present in both the full and core packages, so no change here in this regard.
not everyone is conversant with using the package manager, so as I think I have said before maybe a module to manage modules or a revamp of webmin->webmin configuration->webmin modules to show non 3rd party modules that can be installed , so in effect moves the unused modules list out of the main gui to this location thus if a module is clicked on (from that list) webmin will install it no need to use the package manager and also adding the underlying software that the module supports
Yes, I agreed with that. Here I was just trying to help solve the original problem.
Could you open a new ticket with a feature request to add a Webmin Module Manager in the UI and have it replace the traditional one when the Webmin core package is installed?