Looking for help installing Virtualmin on FreeBSD 13.1

Help! (Home for newbies)
1

Hello! I’m looking to set up Virtualmin on a home NAS, which is running TrueNAS and uses FreeBSD Jails. I did download the script using wget, and it promptly fails with “Perl could not be installed. Cannot continue.”

I did a search on the forums for FreeBSD, but most of the posts are 5+ years old, and the most recent one from this year simply noted “Its not Grade A OS, it would be a tricky setup to get it to work I would think.”

Do we have confirmation if Virtualmin can be installed on FreeBSD, either GPL or Pro edition?

I could potentially run a Linux VM on my FreeBSD server, but that seems a bit overkill if it’s able to be run more efficiently.

Thank you!

2

The automated install script does not support FreeBSD. The supported operating systems are documented.

The install script ought to also print out the list of supported distributions before anything, but I see some changes led to that not happening anymore. We’ll fix that.

But, you are on your own installing Virtualmin on FreeBSD. Webmin and the Virtualmin module may still be available in ports. I’m not sure, I haven’t heard from the person who was maintaining it in several years. We just don’t hear from FreeBSD users much (self-reinforcing loop). Installing Webmin and Virtualmin is only a small fraction of what the install script does, but it’s better than nothing, I guess.

You’d then need to configure all the various services you’ll be using. Basically a manual installation, which I pretty strongly discourage unless you’re extremely comfortable with your OS and all of the services you’ll be managing (Apache, Postfix, BIND, etc.

In short: There is no mystery. Our automated installer absolutely does not work on FreeBSD and absolutely could not work on FreeBSD (it needs packages in a repository, and there is no FreeBSD package repository), and it needs some way of setting up all dependencies (a metapackage on Debian/Ubuntu, a yum group on RHEL/Alma/Rocky), and it needs virtualmin-config to support your OS, and while it can work on most deb and rpm based Linux distros, it definitely can’t work on a BSD. So…you’d have to do a manual install, and it will be an absolute PITA.

3

@Joe - thank you. That’s the definitive answer I needed to see, and while it means I can’t use FreeBSD, it’s a clear answer.

That being said, I can run a VM on my setup, so I can use a Linux distro. Is there a preferred Linux distro for web hosting / Virtualmin? It’s been a few years since I’ve played with Linux (I used to run Gentoo), so I am behind on current distributions.

Thank you again!

4

He just told you what they were. Any of them will do nicely.

1 Like
5

I think the RedHat variants, ie. Rocky/Alma are preferred by the team over the Debian, even if just by a little bit. I couldn’t go that route because the script to get from Cent to Rocky failed for me and the place I have server space at was limited in what I could initially load.

6

I guess someone is using Virtualmin on FreeBSD, still: Php-cgi -v zombie process resulting from collectinfo.pl

That’s definitely not a recommendation, it just tells me that it’s probably still working fine on FreeBSD (the issue being discussed is minor, and I’m sure correctable).

7

FreeBSD installation from port and pkg are updated near current at all times, and install just fine.

The usermin and virtualmin packages work great too.

I’ve never had any insurmountable trouble installing or configuring webmin on FreeBSD.

1 Like
8

@ID10T - thank you, that was the nuance I was looking for - preferred, over supported / grade A.

@JeremyHorland - is there documentation or an (unofficial) install script for configuring everything on FreeBSD? I’m still getting used to FreeBSD and completely new to Virtualmin, the Linux install script is very appealing because it helps with a lot of the packages, configuration, etc. so you don’t need it by hand. Joe’s response above is leading me to lean more towards Linux over FreeBSD for ease of support, unless I am missing something.

Again, thank you. Part of the reason I am asking so many direct questions is to make sure it’s well documented for the next FreeBSD user that comes along.

9

The FreeBSD way of installing software is using either pkg or port.

Pkg consists of pre-compiled binaries from a central repository of assumed “safe” code, while Ports are source code FreeBSD downloads and compiles for you.

Both distribution (distro) methods check for GPG signatures, and install prerequisites. I’d recommend installing Perl for yourself first, as this requires a slight nuance.

If you already have a Perl you like installed, go ahead and install the Webmin/Usermin/Virtualmin combo using either of the methods below:

Run the below commands either using sudo, or the more “BSD” method of using su to root.

Pkg:
pkg install sysutils/webmin
pkg install sysutils/usermin
pkg install sysutils/virtualmin

Port:
cd /usr/ports/sysutils/webmin/ && make install clean
cd /usr/ports/sysutils/usermin/ && make install clean
cd /usr/ports/sysutils/virtualmin/ && make install clean

No need to document this, it’s already well documented at FreshPorts, and the Perl install via rmake.conf is also widely documented, search google for this too.

First, check the “current” supported versions of perl: https://www.freshports.org/search.php?query=perl5

Usually, it’s best to go with the highest supported number.

Installing PERL requires changing an environment variable in your /etc/make.conf

Please add the “perlX=X.xx” variable to your DEFAULT_VERSIONS if it exists, and add the DEFAULT_VERSIONS flag if it does not.

In my case, I wanted to use Perl 5.36, which is current as of the time of this post. MY DEFAULT_VERSIONS line looks like this:

DEFAULT_VERSIONS+=perl5=5.36 python=3.11 python3=3.11 php=php8.2 ruby=3.2

This tells make that it needs to add symlinks to standard system locations after installation.

Then, once that’s done, you can install perl from the “meta-port” and it will install all the files, and symlinks into the correct places using:

pkg:
pkg install lang/perl5.36

port:
cd /usr/ports/lang/perl5.36/ && make install clean

Once you’re all installed, go ahead and check the default locations of servers & config files for the modules you intend to use. Most non-core services will need to be configured to the “userland” directories /usr/local/ and the subsequent directories therein.

The above is pretty much standard for installing anything on FreeBSD, and would appear as straight-forward advice to most FreeBSD regulars.

That being said, please remit all configuration changes – Joe might be moved to add a default FreeBSD flag that tells Webmin & the family where the standard “user land” locations are for the necessary applications that are usually not installed by OS in BSD’s.

Webmin has been in continual use on our FreeBSD machines for over 20 years, and I’d recommend it highly.

PS – if you have an old Perl, you can find and delete it using pkg, even if it was installed by a port, all software registers through the pkg manager.

If it’s your first time using ports, you’ll need to install and configure a few things, BSD will walk you through it.

Never ignore the output of a make – it has most of the hints you need to solve problems.

PSS - the “FreeBSD” way of saying all of the above would normally be to direct you to the pages where this information is found on FreeBSD source sites – however since this is Virtualmin site, we’ll do this the Virtualmin way and actually document in-thread.

10

I hate to keep editing – this is our maintainer at FreeBSD – the most recent update was mid-February.

olgeni@freebsd.org

11

I think you should stick to a supported OS, in that case. If you need a production quality deployment, and you don’t have weeks to tinker with it and learn your way around all the services being managed, the only reasonable way is to use a supported OS and the automated installer.

If you’re doing it for fun and learning, then do whatever seems most fun. But, be aware that using FreeBSD (in general) is a lot more hands-on than the usual Linux experience, and without the automated installer for Virtualmin, you’re going to be doing a lot of work before anything at all works reasonably (like days, weeks, months, depending on your level of experience).

1 Like
12

Perfect, and good advice. I have the Rocky VM up and running, and the script ran smoothly. I may tinker with a FreeBSD jail down the line, but for now, this does exactly what I needed. Thank you for the advice and insight!

1 Like
13

It is one thing to maintain the packages but quite another to maintain the install script. I don’t know if the maintainer is doing a blind port of packages which is only a piece of the puzzle.

14

They are just maintaining packages (which is great, too! I’m happy they’re still doing it!). There is no automated install/configure process for FreeBSD.

15

I guessed as much but it isn’t my place to speak for ‘the team’.

Does that script remain fairly constant?

16

It is not really a script.

Our install process starts with a script, but the script just detects the OS, sets up the OS repositories and installs the dependencies…all the work is handled by the yum groups or metapackages (for dependency installation) and virtualmin-config for configuration.

There is no reasonable equivalent to yum groups or metapackages on FreeBSD, AFAIK (though there has been a new pkg system introduced since I last tried to support installation on FreeBSD, which may provide something similar), and virtualmin-config would need some minor tweaks to work on FreeBSD. But, I would almost certainly reject any patches to make FreeBSD supported in our installer, even if it cost me no time or effort to include it.

The reason I stopped supporting FreeBSD (aside from the extreme lack of paying customers using FreeBSD) was because I couldn’t make it nice. Package management was an awful experience for a variety of reasons (no way to offer a third party package repo, for instance, which is absolutely necessary for us to sell Virtualmin Pro), ports are unpredictable in that it’s easy for changes to one package to break other packages. The straw that broke the camels back was finding that upgrading a system to current libraries from the OS repos broke Postfix, requiring a rebuild from ports (i.e. I had installed everything from binary packages, when possible, but then a later upgrade broke the OS-provided binary packages because Postfix didn’t get updated when libraries it depended on did). That happened enough times and with enough really important packages that I just couldn’t deal with the kind of support load FreeBSD generated when we made it easy. Every FreeBSD user/developer I talked to insisted that this never happens and that ports is infallible and superior to all other package managers, but, I could reliably reproduce all sorts of ugly problems, so…I found the responses unhelpful.

When FreeBSD is hard, we almost never hear from FreeBSD users because they know a lot about their systems. Most serious FreeBSD users are very good system administrators and they know how to use FreeBSD better than I do, so as long as it’s hard, we’re happy that there is a path for FreeBSD users to use Virtualmin. But, if I were to automate it, people who should not be using FreeBSD would begin using FreeBSD with Virtualmin, and we’d go bankrupt or insane trying to support them.

In short: Porting the current install process to FreeBSD is probably an endeavor I would not participate in nor would I encourage it. But, it wouldn’t be a huge ordeal for someone that knows FreeBSD well. And, it may even be that it doesn’t suck anymore. FreeBSD raised the default limit on secondary groups to something reasonable several years ago (historically we had to build a damned custom kernel to work well on FreeBSD!), we no longer use suexec (which required rebuilding Apache), so it’s probably that you can get everything in binary packages now. Probably most of the pain is historic. I still don’t trust packages on FreeBSD, as I’m not convinced FreeBSD developers know what “package manager” means, in terms of handling dependencies and updates, etc. (They probably do by now. Even Microsoft has figured out how to build package manager as of a year or so ago. I think Apple still has no reasonable package manager, though, so I guess it’s possible for smart people to still not understand their utility.)

1 Like
17

Selecting a Unix or Unix-like OS based upon the availability of an official Virtualmin installation script is like the tail of a dog wagging the dog. Since 2016 we have been running FreeBSD systems with Webmin installed, and later also the Virtualmin module installed in Webmin. Our primary reason for selecting FreeBSD was that it is the principal primogenitor of macOS, which most of our systems run. We also have a couple of systems running Ubuntu Linux. Over the years since 2016 our preference has only grown stronger for true Unix systems like macOS and FreeBSD over Linux systems for many reasons that are beyond the scope of this reply.

As Joe noted: “Our install process starts with a script, but the script just detects the OS, sets up the OS repositories and installs the dependencies…all the work is handled by the yum groups or metapackages (for dependency installation) and virtualmin-config for configuration.” This installation is easily reproduced using the FreeBSD package management system as Jeremy Horland explained. However, there are disadvantages to using the packages. The main disadvantage is that the packaged versions occasionally lag behind the latest versions. Webmin will offer to self-update by clicking a button that appears on the Dashboard when an update is available. Unfortunately, deciding not to wait for updated packages and running the self-update causes the automatic FreeBSD security system to detect this as extensive corruption. The quite long security reports automatically sent by FreeBSD to the Superuser via email listing all the apparently missing and corrupt files quickly become tedious. There is a way to mitigate this, but the mitigation must be repeated after each self-update.

Six commands run from the Unix command prompt with Superuser privileges can install Webmin on FreeBSD. Here are examples:

% sudo cd /usr/local/lib

% sudo wget --show-progress --no-host-directories --directory-prefix=/usr/local/lib http://software.virtualmin.com/gpl/wbm/webmin-current.tar.gz

% sudo tar --extract --file webmin-current.tar.gz

% sudo rm webmin-current.tar.gz

% sudo pkg install p5-Authen-PAM p5-IO-Tty p5-Net-SSLeay python3.9 perl5

% sudo /usr/local/lib/webmin-2.021/setup.sh

The second to last command line installs the dependencies listed on the FreshPorts page referenced above by Jeremy Horland. The path to the setup shell script file in the last command line includes the name of the directory created by extracting the current version of Webmin. The setup shell script supports FreeBSD, which is really what counts. After Webmin is Installed, modules such as Virtualmin can be installed in Webmin.

I should note that FreeBSD 13.2 is now the current release version. Yesterday I upgraded a system running FreeBSD 13.1 to FreeBSD 13.2. All ran smoothly. Only a few minor edits of /etc/ssh/sshd_config were needed to reconcile some earlier edits I had made with the new defaults.

18

@MSSEsq - thank you, this was IMMENSELY helpful. Two of the version numbers were off in your examples, but I was able to correct them (“python3.9” replaced with “python3” and Webmin is version 1.941 when installed).

It was easy to set up, and I’ll begin playing with the rest soon - thank you for this, and I may be back in touch if I need more guidance under FreeBSD.

I wanted to take a moment to express gratitude for everyone that was helpful despite FreeBSD being a “Grade B” OS - hopefully, this generated enough interest that we can get people involved and bring it up to Grade A.

19

With @JeremyHorland and @MSSEsq 's posts, I’ve done some playing, and here’s what I have found so far - Michael’s process includes the script to configure everything, but uses older (not current) packages - Apache 2.2 instead of 2.4, and Webmin 1.941 instead of 2.021. I was able to get Webmin up and running, but had challenges getting Apache configured and installing additional modules from within the GUI.

With Jeremy’s process, the latest versions are installed, but there’s no script to configure everything, and for someone just getting started, this means configuring Apache 2.4, PHP, mySQL, etc. by hand, which is daunting.

I think the key here is that the install script needs to be ported for BSD - the packages are one thing, but the script is what makes everything work smoothly. Unfortunately, I don’t have the skills to do it myself.

20

See above: Looking for help installing Virtualmin on FreeBSD 13.1 - #16 by Joe

The install script does almost nothing. The interesting work is in the packages, the yum groups or metapackages, and in virtualmin-config.

Porting the install script to FreeBSD would not do anything useful without software repositories, and some mechanism for handling the dependencies.

Also, I do not recommend source-installed anything. If there is an actively maintained package or port of any software you’re using, you should use that. The fact that anyone using FreeBSD considers a source install superior to packages or ports suggests to me that package management continues to suck on FreeBSD. I’d been told that the new pkg system was good. I haven’t tried it, so I don’t know. But, I don’t know how anyone can manage many servers without good package management.