Oh, wait, nevermind, I do see code for it: https://github.com/virtualmin/virtualmin-gpl/blob/f72c28dfdbd8927d8e2330101a49add11a22bf57/virtual-server-lib.pl#L260
I have no idea what’s happening.
Yep. That explains everything. So, I guess the problem is downgrading to GPL didn’t actually work. I don’t know why that would happen.
OK, so I did the downgrade process again.
[root@vulture ~]# virtualmin downgrade-licence --downgrade
Downgrade Virtualmin Pro system to GPL.
virtualmin downgrade-licence --perform
[root@vulture ~]# virtualmin downgrade-licence --perform
Downgrading Virtualmin license ...
... done
Your system has been successfully downgraded to Virtualmin GPL! Thank you for giving Virtualmin Pro a try.
[root@vulture ~]#
So, something might be broken in 7.7 maybe?
I wonder if the downgrade is the problem. It’s a script, probably untested on FreeBSD.
It may expect to find the license info in /etc/virtualmin-license, but that may not be what’s being checked by Virtualmin itself. I don’t even know. Something is obviously amiss, but I’m stumped about what.
Fair about it being untested on FreeBSD. Believe it or not, that exists in the expected place.
[root@vulture /usr/local/etc/webmin]# cat /etc/virtualmin-license
SerialNumber=GPL
LicenseKey=GPL
[root@vulture /usr/local/etc/webmin]#
And a snippet of the relevant portion of my Dashboard.
Delete the /usr/local/etc/webmin/virtual-server/pro directory and everything in it if it exists, and then use the Webmin Configuration->Webmin Modules page to install the latest wbm version of the virtual-server module from https://software.virtualmin.com/vm/6/gpl/wbm/virtual-server-7.9.0.gpl-1.wbm.gz
The downgrade probably isn’t dealing correctly with a wbm installation.
You may also find everything is easier using a well-supported Linux distro. It just gets so much more testing (hundreds, maybe thousands, of times more users), it’s much more likely to Just Work.
Success! /usr/local/etc/webmin/virtual-server/pro didn’t exist. I went through the manual upgrade process you suggested and the Dashboard is reporting 7.9.0, and I see the green nag box to try pro again. Lesson learned the first time, I’ll ignore that box now.
Yes, it isn’t supported yet. For the time being, I’ve added a clear error message to handle it clearly:
@Joe, if we support FreeBSD is it going to be .wbm.gz installs or something else?
Also, have we abandoned wbm/updates.txt upgrades support? Should we fix it?
As an aside, I would be willing to test Webmin/Virtualmin/Usermin via a FreeBSD VM.
If FreeBSD has a reasonable package manager now, we will provide proper packages. I’ve been told FreeBSD now has a reasonable package manager, but I’ll refrain from belief until I’ve actually worked with it. It didn’t have reasonable package management when I last supported FreeBSD.
I’m not doing anything with FreeBSD unless and until funding is confirmed (for anyone who isn’t Ilia: we’re in discussion with someone who has offered funding that’s maybe sufficient to make supporting FreeBSD worthwhile); it’s a lot of work to support it properly, and I don’t want to half-ass support for anything. So, I’m not going to spend any time trying to figure out what to do with it, yet, and you probably shouldn’t either…we’re not short of stuff needing done.
I don’t know about wbm/updates.txt. I thought it was updating. I guess it broke again during one of my script updates. We have too many danged supported systems, it’s impossible for such a small team to keep it all working.
1 Like
FreeBSD has 2 basic methods of pkg installation
-
PORTS: Source compilation, think Gentoo Linux, but PORTS is where portage came from. Fairely advanced pkg control, and regular PORTS tree maintenance can ensure things are kept up to date.
-
PKG: Binary pkg management (the method I’ve been using for this box in particular).
-
Regular audits by the FreeBSD community ensure that pkgs submitted to the PORTS tree or via binary distribution are kept in line and meet the expectations of the FreeBSD standards for not tainting the system.
-
The upside to using pkg is speed. Compiling via the PORTS tree is time-consuming, resource-consuming, and on a live system, can be detrimental to production system resources. Years ago, I learned that you can have a backup “offline” system that manages your PORTS tree, compilation happens on that system and the build pkgs are made available via a binary build process (same as pkg cmd). So you could install updated pkgs from the PORTS tree as binary pkgs the same as the pkg command (then it was called pkg_install) on a live system via an NFS share.
-
There is a third option, you can of course manage the build and installation of any package via source yourself. In certain circumstances, this is the only option, especially if what you are trying to do is obscure and/or you need specific controls in place.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.