I got Virtualmin working on ARM64 (Ampere)

Virtualmin
1

I attempted getting Virtualmin working on ARM64 and it went really well. I know it’s not officially supported, but here are my experiences…

Why ARM64?

ARM64 is going to be a game changer for hosting if you look at the current pricing. The comparison I’m making is a 2 vCPU, 4GB compute resource with 60 GB of disk space at Digital Ocean for $24 per month versus a 2 vCPU, 4GB compute resource with 40 GB of disk space from Hetzner in Germany is around $4.12 (€3.78) per month.

image

image

Why Virtualmin?

Virtualmin is an amazing open source solution that is incredibly powerful and near-par with the very expensive cPanel. If we can get this working before cPanel fixes their proprietary libraries we can gain massive market share.

Why not Virtualmin?

Officially Virtualmin doesn’t support ARM64 architecture. FYI I’m not writing this post to get the Virtualmin team to suddenly open up ARM64 support as I’m sure they have more than enough work on their plate. But I do think we can open the door as the community and see how far we can go to get it working in the meanwhile.

What I have tested so far and what works

  • Installation worked perfectly first time, including quotas
  • It was a LAMP installation
  • Let’s Encrypt SSL works
  • IPv4 and IPv6
  • WordPress script deployment
  • Email (see notes)
  • IMAP SSL, SMTP SSL (465)
  • SpamAssassin & ClamAV
  • Greylisting
  • Usermin & Roundcube
  • Bind DNS integration (master / slave)
  • DKIM inbound verification
  • Mail Client Auto Configuration
  • Performance is snappy

For the majority of my workloads just having a working web server, SSL, spam protected email and BIND DNS integration for master / slave is more than enough.

Email Notes

The procmail-wrapper needed to be recompiled for ARM64 before SpamAssassin would work. Luckily it’s super simple to do yourself as the procmail-wrapper is just there to check some parameters and permissions.

If you don’t fix it, you’ll get this error when receiving email at the server:

Jul 3 19:57:45 arm64 postfix/local[92596]: A1A6467492: to=<"eugene@arm64.vander.host"@arm64.vander.host>, orig_to=<eugene@arm64.vander.host>, relay=local, delay=0.04, delays=0.02/0.01/0/0.02, dsn=5.3.0, status=bounced (Command died with status 126: "/usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME". Command output: sh: 1: /usr/bin/procmail-wrapper: Exec format error )

The fix is:

cd /root
wget https://github.com/virtualmin/virtualmin-gpl/blob/master/procmail-wrapper.c
gcc procmail-wrapper.c -o procmail-wrapper
mv /usr/bin/procmail-wrapper /usr/bin/procmail-wrapper.backup
cp procmail-wrapper /usr/bin/procmail-wrapper
chmod 4755 /usr/bin/procmail-wrapper

If you don’t do the 4755 you’ll get weird Procmail errors and SpamAssassin won’t work.

Anyhow there is still some work left to do for this experiment.

I still need to get DMARC and DKIM outbound working. The only reason why I haven’t gotten there is when you sign up at Hetzner Cloud, even if you have an existing paid for service, there is a hold on your account for SMTP port 25 outbound till the first new invoice is paid.

I want to test NGinx as well.

Also I haven’t been able to properly benchmark it against a Digital Ocean server, but I should get around to doing that in the next week. What I do know is ARM64 takes less power and is more efficient cooling wise so if you’re that way inclined you’re doing the environment a favour :wink: Smile Gretha.

I’m super stoked about the possibilities for us and for Virtualmin in the future! The beauty of Virtualmin is because it’s stock and non-proprietary, and even though the ARM64 platform isn’t supported, so far everything important I value has just worked.

5 Likes
2

There will be problems when Virtualmin packages need to be updated.

The way packaging works in Virtualmin is not clear

The impression I get is that Virtualmin packages are installed from source on a new install but are updated from precompiled binaries for x86 architecture only (64 and 32 bit), not aarch64 (ARM64).

Virtualmin does want to support anything other than x86 (64 bit only for RHEL based distros). It is a lot of work.

Webmin, that Virtualmin builds on, is different. It will work with aarch64 and a lot more.

I am sure Virtualmin would be amenable to being sponsored to supporting aarch64 (ARM64). Maybe we would could organise something. Such as if a fund reaches a certain agreed value, then Virtualmin would be willing to go ahead. However there is a lot of ongoing work.

Also I think Debian based distros have very good support for ARM64. RHEL based distros perhaps not so. So perhaps sponsoring Virtualmin for aarch64 (ARM64) for Debian based distros should be considered.

3

No there won’t. All Virtualmin packages, except for procmail-wrapper are not architecture dependent.

The way packages in Virtualmin works is extremely clear and has been consistent throughout the life of the project, and the source for everything we use for packaging is in our repos. There is no way to call our packaging practices mysterious.

We use the native package manager on your OS, either dpkg+apt or rpm+dnf. We build our modules with the makemoduledeb.pl or makemodulerpm.pl scripts found in the Webmin github repo. Our other tools, like virtualmin-config include their packaging information and scripts in the repo itself.

That’s true. We like money. It allows us to devote more time to Virtualmin, rather than other non-Virtualmin work (all of us have to have other sources of income).

1 Like
4

An issue here is Virtualmin packaging.

I think it is fair to state Virtualmin packaging is unclear. Maybe you can clarify, instead of getting annoyed.

There is so much that is unclear in Virtualmin. It is not funny.

I installed Virtualmin on aarch64 a few months ago. Installation worked great.

When VIRTUALMIN packages needed to be updated I got failure. The architecture is not supported.

So, what else I am expected to conclude, other than VIRTUALMIN packages install from source but VIRTUALMIN packages update from non source architecure dependenant packaging that usually (but not necessarily) contain binary code?

What if we could choose to update from an experimental repository that has all Virtualmin Debian packages relabelled as '‘noarch’?

It looks like Virtualmin is nearly 100% there to using aarch64.

Why not let us focus on this?

Please accept that Virtualmin has a lot of issues with regard to clarity and just let us move on.

5

That doesn’t make sense. I’d need to see the exact errors, but the repos contain mostly noarch/all packages (rpm or deb respectively), which should work anywhere. I have only tried it on RPM-based systems, but I wouldn’t expect it to fail on a deb-based system, but maybe there’s something wrong with our repo config that causes problems.

To be clear, the only package we provide where architecture matters is procmail-wrapper. I don’t think we have any other binary packages in our repos.

That’s not a reasonable conclusion, we have never installed from raw source on our currently supported platforms. The Virtualmin install script sets up your OS package manager with our repos, and with our signing key for verifying our packages, and then installs everything from packages. Updates are handled the same way. Nothing comes from raw sources in a default Virtualmin installation (except the install script itself, which is a POSIX shell script…something has to bootstrap the OS-detection and package repo setup).

6

The first paragraph of the download page says this:

“Usually, getting started with Virtualmin can be done with a few simple steps, using our automated install script. The install script will setup your package manager, usually apt-get or yum, and then download our packages as well as all of the necessary dependencies for running Virtualmin.”

7

Sorry, that was unnecessarily harsh on my part. I’m just so upset to be accused of installing software from source on over one hundred thousand production servers. That’s a tremendous insult. :man_shrugging:

8

My original reply has been updated.

We need clarity, not annoyance.

9

As stated in amended reply

What if we could choose to update from an experimental repository that has all Virtualmin Debian packages relabelled as '‘noarch’?

It looks like Virtualmin is nearly 100% there to using aarch64.

Why not let us focus on this?

10

The apt repos are labeled as all,i386,amd64, which my understanding would lead to it working fine for ARM, for the all packages.

As I said, I’d need to see a specific error. As far as I know it’s already right.

11

OK. I will spin up an aarach64 with Virtualmin, like @vander.host. That way both of us can report on our experiences and confirm issues. I will chose Debian. I don’t know what distro @vander.host is using.

We cannot reports errors until a Virtualmin package update is available and fails.

12

You can fake it by force installing an older package from the repo. We keep two old versions around in RPM repos, and I think Debian/Ubuntu repos never get pruned automatically because I’ve never come up with a safe way to do it, so there will be a lot of old packages in the apt repos. (apt-cache madison <packagename> will show available versions, and apt install <packagename>=<version> will install a specific version).

13

@johnhe

I don’t know what distro @vander.host is using

I used stock Ubuntu 22.04 as supplied by Hetzner.

@Joe

That’s true. We like money. It allows us to devote more time to Virtualmin, rather than other non-Virtualmin work (all of us have to have other sources of income).

I would be interesting to see what budget will be required. For now I’m very happy to sponsor a free ARM64 package at Hetzner for one year. Please DM then we can get that going.

This is an interesting debate, but I highly recommend go and see the magic of Virtualmin on ARM64 and spin up a VM.

14

I have an ARM64 aarch64 instance running with Debian 11 and Virtualmin 7. There were no problems with the install.

I found a few Virtualmin 7 packages, using apt-cache pkgnames | grep virtualmin and apt-cache madison, that had multiple Virtualmin 7 packages, such as virtualmin-config and virtualmin-lemp-stack-minimal.

Downgrading down and back up again, for example using apt install virtualmin-lemp-stack-minimal=7.024-1, did not cause an issue.

I need to find a virtualmin package to downgrade to with architectural dependencies, if that was the cause of the upgrade issue with the previous install. Since Virtualmin 7 is new, there may not be any.

As of right now, I am left with a puzzle why I could do a previous install of Virtualmin on aarch64 and why Virtualmin recommended upgrades failed. The previous distribution tried was Rocky, not Debian and was probably Virtualmin 6. My recollection is that there was an architecture mismatch.

I will leave the instance running. Or maybe snapshot it, delete it and resurrect it now and then as upgrades become available.

If a Virtualmin install works but package upgrades do not work then this points to an issue that should be easily fixed.

15

My install methodology was super simple:

  1. Spin up ARM64 VM with Ubuntu 22.04
  2. Following instructions here, so:

wget https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh
sudo sh virtualmin-install.sh

Everything worked on installation. No errors at all…

Normally when I install on Ubuntu 22.04 I still have to do kernel sources for quotas to work but in this case not (perhaps something to do with Hetzner).

Then I went to Scheduled Package Updates, turned it on, and saw how everything updated nicely. I’m referring to apt packages.

Virtualmin is mostly Perl scripts so technically should be OS and platform agnostic.

16

Can’t this be fixed on a Hetzner VPS with line below?

sudo apt install linux-image-extra-virtual

Reference How To Set Filesystem Quotas on Ubuntu 20.04 | DigitalOcean

Webmin is platform agnostic.

However Joe continually complains that it is not worth it financially to Virtualmin to support other platforms than x86.

Hopefully Virtualimin will take you up on your generous offer of sponsorship for ARM64 for one year and give you acknowledgment.

17

Those are expected not to work. The only package that won’t work on ARM that we provide, that I am aware of, is procmail-wrapper, and it definitely won’t work. It won’t install at all (and shouldn’t install at all).

I can’t think of any reason that would be the case. The known issue is that procmail-wrapper is not available for ARM in our repos, and we have done no install testing on ARM, and I haven’t had the time to devote to setting up repos and doing the testing. I won’t call it supported as long as the mail stack doesn’t work at all on ARM (and the mail stack does not currently work at all on ARM).

18

I am going to propose a working theory of why the install worked previously but upgrades did not. I would need to examine the Virtualmin install script in detail to see if this theory hold merit.

  1. Virtualmin uses its own install system that, in order to attempt an install on different architectures, chooses a default architecture if there is no match.
  2. Upgrades are performed by the native package system, which will naturally refuse to accept another architecture instead of its own architecture
  3. However, dependencies which are architectural don’t necessarily contain binaries, just scripts and layout that is dependent on the distribution rather than the architecture.

If the above is correct then Virtualmin needs to do very little work for aarch64 compatibility.

19

Why would you think that?

20

With facts as presented, it is a useful working theory worthy of investigation until dismissed, proven or amended.

Installation with virtualmin-install.sh script, which is an installer (or install system), works but upgrades with native packagers do not work when there was an architectural dependency to the upgrade.

It is reasonable to assume the install script chose a default architecture to install, if it cannot find a matching architecture. Otherwise how can Virtualmin even complete an install on an unsupported architecture? It does not make sense otherwise.

The facts, as presented, occurred with a previous Virtualmin install on aarch64 a few months ago.

Hence my previous suggestion of an experimental repository where architecture specific Virtualmin Debian packages are relabelled for ‘noarch’ (using label ‘all’).