VM 7 RC9 Install on Rocky Appears to be Successful

OS type and version Rocky Linux 8.6
Webmin version 1.994
Virtualmin version 7.1 Pro
Related packages Just a default install so far

I gave up trying to fix AlmaLinux and decided to give Rocky a try instead. The system is up and running, apparently with only minor glitches. I’m going to use this as a test bed for a while before migrating any sites to it.

The following is for debugging / informational purposes. I encountered the following glitches:

Glitch 1: ClamAV issue

Warning!  A problem occurred testing the ClamAV server scanner :

ERROR: Could not connect to clamd on LocalSocket /run/clamd.scan/clamd.sock: No such file or directory

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.000 sec (0 m 0 s)
Start Date: 2022:06:13 15:09:42
End Date:   2022:06:13 15:09:42

This is probably a result of the ClamAV maintainers diddling with stuff, based on previous experience. They don’t seem to like leaving stuff alone.

Glitch 2: Errant repo URL Prevented Upgrading to Pro

Errors during downloading metadata for repository 'virtualmin-noarch':
  - Status code: 404 for https://[redacted]@software.virtualmin.com/vm/7/rpm/noarch/repodata/repomd.xml (IP:
Error: Failed to download metadata for repo 'virtualmin-noarch': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

This was solved by editing the repo URL in




Ran the upgrade again, and it worked.

Glitch 3: Dovecot Issue that Resolved Itself

Dovecot failed to start, and when started manually, was not detected by the Servers status panel. However, it seems to have resolved itself after a reboot.

Glitch 4: Let’s Encrypt Certificate for Hostname

I forgot to copy this one, but basically it refused to issue a cert because an IPv6 address was found, but the virtual server for the hostname didn’t have IPv6 enabled.

I decided to skip the validation for this one, which worked.

The reason I did it that way was because the IPv6 address didn’t match what I believe to be the assigned one; and the staff at Turnkey Internet really bent over backwards for me for several hours this morning solving another problem related to a bad OS template. I’ll leave the IPv6 address for another day.

All in all, unlike yesterday’s adventure with AlmaLinux, the installation on Rocky was pretty much trouble-free, at least for someone with a vague familiarity with Linux. It may have knocked a newbie for a loop, though. But newbies shouldn’t be playing with betas anyway.

I used a spare domain that I wouldn’t mind using as a permanent domain for the hostname for this one; so although it’s a test bed for now, it may graduate to a production server at some point.


This one feels annoyingly bug-like. I’ll ask @Jamie if it makes sense for this to happen. I think the check is trying to solve a common problem, but I think maybe it’s going about it in the wrong direction (like, if the domain doesn’t have IPv6 setup, why make that the user’s problem? It’s a common scenario).

Setting up CSF Firewall was painless. I imported the settings from an existing server, so I just had to make a few tweaks and upload the reporter script that sends the miscreant reports to AbuseIPDB and to my own blocklist site.


That does sound like a bug. What was the exact error message?

I just repeated the Let’s Encrypt request to find the exact wording, Jamie. This was for the virtual server on the hostname.

Validating configuration for server2.[redacted].com ..
.. errors were found, which will prevent Let's Encrypt from issuing a certificate :

Apache website : An IPv6 DNS record server2.[redacted].com with address [IPv6 address] exists, but this virtual server does not have IPv6 enabled

The IPv6 address isn’t the one the DC provided me with. But it may have been changed as part of some work they did for me this morning, or it may be assigned dynamically. I just skipped the validation for now.


Oh, that means it’s a legit error. I’m surprised you could get a cert if an AAAA record for IPv6 existed but no domain was configured.

Yeah, an invalid IPv6 address for the hostname you’re trying to request will often cause Let’s Encrypt to fail because it will try IPv6 first.

There is no AAAA record, and the IPv6 in the error record isn’t the one originally assigned by the DC. That’s why I wanted to hold off on adding one. The Let’s Encrypt script is getting it from somewhere, but it’s not in the zone file.

It could have to do with the fact that Rocky was manually reinstalled from ISO because of a template error on the automated OS reinstall for Rocky. Apparently I’m the first one who ever used that particular function, so they only discovered the error when I submitted a ticket. (It would work fine for an original installation, but not a reinstall.)

So my guess is that the IPv6 got changed when they reinstalled Rocky. I’m going to look into it today. But there’s no quad A record in DNS as of now.


Apparently the IPv6 is dynamic, but reserved to the interface. So what shows up in ifconfig is valid.


@Jamie, I think perhaps we should disable IPv6 for all new installs? By setting ip6enabled to 0:

If one wants explicitly setup IPv6 they will do it and they will know what’s going on.

Richard, also I have specifically was running super extensive tests yesterday with two Rocky instances. One was GPL with Nginx and the other was Pro with Apache. I haven’t encountered nor repo issues or ClamAV issues. Although, I was trying the very latest virtualmin-install.sh script from master and all recent applied patches.

AlmaLinux issues are all sorted out to.

@Joe, can we push new updates to the repos so the tests would be more relevant?

@Jamie, I will wrap up systemd issues today so we can make a new release for Webmin and Usermin.

1 Like

Richard, also I have specifically was running super extensive tests yesterday with two Rocky instances. One was GPL with Nginx and the other was Pro with Apache. I haven’t encountered nor repo issues or ClamAV issues. Although, I was trying the very latest virtualmin-install.sh script from master and all recent applied patches.

AlmaLinux issues are all sorted out to.

That’s good to know.

For me, my preference for AlmaLinux was pretty weak and based solely on the fact that I fear that community support (as in $$$ support) for Rocky will eventually drop off, as it did for CentOS, which is why CentOS became a Red Hat property.

I figured that AlmaLinux would have more support from Igor because he needs it for Cloud Linux (and now from Benny, because of her position at cPanel, which is actually a turn-off for me).

But I have Rocky installed now; and assuming this new server continues to work well, it will become a production server at some point. I’ll just keep sending Rocky Linux money and hope others do as well.

Right now the only site this new server is hosting is a honeypot for hackers, and it’s already caught a few. It gives me the giggles.


1 Like

Roundcube and phpMyAdmin both installed cheerfully using the Script Installer and work properly.


No, that’s also not a great solution. IPv6 is becoming more common, and should be more common, and Virtualmin was among the earliest control panels to have good support for IPv6 (though it gets so little testing, I think there are still bugs).

IPv6 should be easy and mostly automatic. The problem in this case is not something we can solve…and shouldn’t solve by making it harder for someone to get up and running with IPv6.

1 Like

The error in this case had nothing to do with Virtualmin anyway. It was a legit error message. Apparently there was a problem with the routing after the OS reinstall.

The hosting company also identified another problem with the subnet, which they’re fixing as we speak. That’s actually one of the things I like about them: When there’s a problem, they own up to it and fix it rather than blaming it on someone else. They have that in common with Virtualmin staff.


1 Like

The email filtering doesn’t seem to work in Usermin and is absent in Roundcube.

Does the Usermin filtering use Procmail, dovecot-pigeonhole, or something else? (I know that Roundcube filtering uses Pigeonhole, which is not installed.)



Upgrade PHP to 8.1 (remi-safe) was painless.

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