How to install a fresh VirtualMin server on Rocky/Alma Linux 8 right now?

I suppose I’m missing something here, and need to ask for help.

I read the forum for some hours now today, and “just” want to install a new VirtualMin server for production use. I’d like to use some RHEL8-style OS as a base, so I tried AlmaLinux and RockyLinux 8 countless times today.

No matter what, I just cannot get any installer to finish correctly.

Seems the current “suggested” way would be to use a pre-release VM7 install script, and change the VM version to 6 in there.

So I tried with all I could find, the latest tests were done with the install script 7.0.0.-RC13.
I changed “vm_version=7” to “vm_version=6”.
I also tried a VM 7 install (although I wouldn’t want to use this for production today).

I either run into the problem that the installer cannot download the VM 6 package with this error:

Username/Password Authentication Failed.
Downloading Virtualmin 6 release package: [2022-09-01 15:30:10 UTC] [ERROR] Failed with error: 6

Or the installer is almost finishing, but then erroring out during the post-install phase:

[14/16] Configuring Usermin                   Error: Failed to open PID file
Failed to open PID file
Cleaning up

[WARNING] The following errors occurred during installation:

Postinstall configuration returned an error.

Unfortunately I lost track on which error occured when during all the tests.
The first error (Authentication Failed) is occuring on a Fresh Rocky 8.6 image right now.

So, the question is:
Where am I doing things wrong?
What would be the current suggested/supported way to get a production quality VirtualMin 6 system installed on a RHEL 8-based OS?

I can provide more logs etc. if needed. I think I just may miss some forum thread/docs page with “current” instructions?

(By the qay, I do have at least 2 other machines with Alma 8.6 and a working VM install in production, I just cannot reproduce / do a successful install on a fresh machine right now.)


1 Like

Hi Joe,
wanted to send a quick reply yesterday, but did wait to double check again on my side.
The linked forum thread was the main forum thread I took my information from.

I did two more tries today, both on a plain and updated Rocky Linux 8.6 machine.
They are the same results I had yesterday. Yesterday I tested with Rocky 8.6 and Alma 8.6.

I set a FQDN and did a dnf -y upgrade.
uname -a is giving Linux <REDACTED HOSTNAME> 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2 16:19:42 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux.

/etc/redhat-release contains Rocky Linux release 8.6 (Green Obsidian).

I took the script from the link in the first post in the thread you linked (i.e. from To double check, this is labeled as 7.0.0-RC13 in the script, and its’ md5 sum is c04fab27794c60d26cc3a38d631f9a8e.

I did one install with the unchanged script, i.e. installing VirtualMin 7.

This failed with the following output (complete logfile is attached):

??? Phase 1 of 3: Setup
Installing core plugins for package manager                             [  ?  ]
Downloading Virtualmin 7 release package                                [  ?  ]
Installing Virtualmin 7 release package                                 [  ?  ]

??? Phase 2 of 3: Installation
Installing EPEL release package                                         [  ?  ]
Enabling PowerTools package repository                                  [  ?  ]
Cleaning up software repo metadata                                      [  ?  ]
Checking and installing system packages updates                         [  ?  ]
Installing dependencies and system packages                             [  ?  ]
Installing Virtualmin 7 and all related packages                        [  ?  ]
Installing Virtualmin 7 and all related packages updates                [  ?  ]

??? Phase 3 of 3: Configuration
[1/20] Configuring AWStats                                              [  ?  ]
[2/20] Configuring Apache                                               [  ?  ]
[3/20] Configuring Bind                                                 [  ?  ]
[4/20] Configuring ClamAV                                               [  ?  ]
[5/20] Configuring Dovecot                                              [  ?  ]
[6/20] Configuring Firewalld                                            [  ?  ]
[7/20] Configuring MySQL                                                [  ?  ]
[8/20] Configuring Postfix                                              [  ?  ]
[9/20] Configuring ProFTPd                                              [  ?  ]
[10/20] Configuring Procmail                                            [  ?  ]
[11/20] Configuring Quotas                                              [  ?  ]
[12/20] Configuring SASL                                                [  ?  ]
[13/20] Configuring Shells                                              [  ?  ]
[14/20] Configuring SpamAssassin                                        [  ?  ]
[15/20] Configuring Status                                              [  ?  ]
[16/20] Configuring Upgrade                                             [  ?  ]
[17/20] Configuring Usermin                                             ???????Error: Failed to open PID file
Failed to open PID file
??? Cleaning up

[WARNING] The following errors occurred during installation:

  ? Postinstall configuration returned an error.

Webmin/Usermin was not running after that, ports 10000/20000 were closed.

I recreated a fresh Rocky 8.6 machine, and tried to install VirtualMin 6 (by changing the line vm_version=7 to vm_version=6 in the script).

This failed with the following output (complete logfile is attached):

??? Phase 1 of 3: Setup
Installing core plugins for package manager                             [  ?  ]
Downloading Virtualmin 6 release package                                [ERROR] Failed with error: 6
[  ?  ]

[ERROR] Something went wrong. Exiting.
[ERROR] The last few log entries were:
[2022-09-02 07:17:44 UTC] [DEBUG] Configuring package manager for Rocky 8.6 ..
[2022-09-02 07:17:44 UTC] [DEBUG] Disabling SELinux during installation ..
[2022-09-02 07:17:44 UTC] [DEBUG]  setenforce 0 succeeded
Spin pid is: 7704
Last metadata expiration check: 0:01:49 ago on Fri 02 Sep 2022 07:15:56 AM UTC.
Package dnf-plugins-core-4.0.21-11.el8.noarch is already installed.
Dependencies resolved.
Nothing to do.
Installing core plugins for package manager: Success.
Spin pid is: 7754
Username/Password Authentication Failed.
Downloading Virtualmin 6 release package: [2022-09-02 07:17:46 UTC] [ERROR] Failed with error: 6
[2022-09-02 07:17:46 UTC] [ERROR] Something went wrong. Exiting.
[2022-09-02 07:17:46 UTC] [ERROR] The last few log entries were:

virtualmin-install_vm6.log (68.3 KB)
virtualmin-install_vm7.log (127.0 KB)

You should not do that. That literally cannot work (the repos have been reorganized, the old install script simply doesn’t know where anything is for Virtualmin 7), do not waste your time doing this over and over. The new version of the script is the only way to install on Rocky or Alma 8 or 9.

We’ll be wrapping up Virtualmin 7 this weekend, including updates or Webmin and Usermin, and we’ll be doing another round of testing. I don’t know why it’s failing…it worked the last time I tried it, and while I have rolled an update of virtualmin-config since then, I don’t think Usermin plugin changed at all, so I don’t know why it would begin failing now.

It will definitely work sometime this weekend once I’ve had time to test it/iterate on it.

1 Like

When trying to install VM 6 I did of course use the new script and - as written above - changed one line from vm_version=7 to vm_version=6. This was what I read in some forum thread here as the way to get a current (stable) VM6 installed to Alma/Rocky 8?

I’m happy to do more testing if this is of any help.


That thread is quite old and has been superceded by the beta installer. The old installer is not expected to work on Alma or Rocky. I don’t know what else to say about it.

Since you made it to the configure step (with the VM7 beta install script), you can probably just do the following to complete the install (maybe restart usermin, making sure it actually stops and restarts before hand, since it seems to be having trouble restarting the service, which is an area of bugginess on Rocky and Alma 8):

virtualmin config-system --bundle LAMP

Assuming, of course, you’re using the default install (not LEMP or minimal).

And, if that doesn’t work, you can manually run just the remaining handful of steps in the LAMP bundle (whichever ones did not complete): Virtualmin-Config/ at 9c28adfe700e164bdd5c0e06fcbc2e311cea51cc · virtualmin/Virtualmin-Config · GitHub


virtualmin config-system --include Usermin

And, if Usermin keeps failing just skip it, and manually make the changes usually perfomed by that plugin (see the source code in the same github repo linked above). If it’s really urgent you get this working, as it seems to be, that is probably the fastest way to get there. I can’t do anything else with it until this weekend.

1 Like

Looking forward to the new updates Joe

First off, I’m grateful for your time taken to respond here.

Regarding the VM6 installation: I was under the impression, that VM 6 CAN be installed on Alma/Rocky 8 successfully. And as the old installer script won’t run on Alma/Rocky 8, I though the way I read somewhere was correct.
I.e. use the new beta installer, and change vm_version to 6 there in order to do a VM 6 install.

Let’s just put this aside for now.

It’s not terribly urgent to get this system up and running. As it sound like VM 7 is really near release now, I can wait for that. I just was being curious. If the situation would be like that for longer, I would find it problematic to not being able to do a new install on a supported Grade A OS (which both of them are listed as on

When trying to start webmin / usermin manually, those also fail.
The reason is somehwat dubious:
The log messages show this:

Sep 02 09:33:10 <REDACTED>[21720]: Failed to open SSL cert /etc/webmin/miniserv.pem
Sep 02 09:33:10 <REDACTED>[21720]: Failed to create default SSL context at /usr/libexec/webmin/ line 284.

Although the file is there and ownership / access rights look good to me:

[root@web webmin]# ll /etc/webmin/miniserv.pem
-rw-------. 1 root bin 974 Sep  2 09:21 /etc/webmin/miniserv.pem

Also, the content is looking sensible to me (don’t bother me about the private key being posted, the server will be reinstalled in a few minutes anyway :wink: ):

[root@web webmin]# cat miniserv.pem

So, if I can contribute anything to diagnosing this - I’m happy to help!

Otherwise I’ll just wait over the weekend and give it a fresh spin on Monday.


@Joe: If needed / helpful, I can give access to this very machine, too…

Any news on this?

I was able to more or less create a working server:

  • Installation still does fail at the post-config stage (tested every day this week)
  • Problem is that Webmin/Usermin don’t start because of problems with the SSL cert (see output in a post above).
  • I disabled SSL for Webmin/Usermin in the respective miniserv.conf files, then was able to start the services.
  • Completed the missing post-install config steps:
virtualmin config-system --include Usermin
virtualmin config-system --include Virtualmin
virtualmin config-system --include ClamAV
virtualmin config-system --include SpamAssassin
virtualmin config-system --include Fail2banFirewalld

The last one still fails:

virtualmin config-system --include Etckeeper

It’s just giving this error message:

Can't locate Virtualmin/Config/Plugin/ in @INC (you may need to install the Virtualmin::Config::Plugin::Etckeeper module) (@INC contains: /usr/libexec/webmin /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /usr/share/perl5/vendor_perl/Module/ line 77.
Can't locate Virtualmin/Config/Plugin/Etckeeper in @INC (@INC contains: /usr/libexec/webmin /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /usr/share/perl5/vendor_perl/Module/ line 77.

I then re-created LE certificates for Webmin/Usermin and actived SSL for them again.

On a first glance things seem to work alright, but no thorough testing has been done. Obviously I will feel more confident when I will reinstall the server with a working setup script from scratch.


VM7 is OK to install now, why do you persist in wanting VM6 in the script, it doesn’t work. The script is Beta not the actual VM. Its been tested to install on Rocky and Alma with minor bugs in post install, after logging into https://url:10000 I mean. Read the forum about it.

Perhaps I haven’t been clear enough in the last post:
I DO NOT try to install VM6 anymore, just VM7. With the problems described above.
This should be easy to reproduce: Install Rocky Linux 8.6, set hostname, run the beta installer linked above.


I just fired up a new Rocky 8 machine on Vultr and ran the installed script

The ran the post install script, no issue, I didn’t install the ssl during the post.

then ran letsencrpyt

All running no issues, so I’m not sure why your having any issue with Rocky,.


Well, I don’t know, too.

That’s why I posted here and also offered access to the machine.

It always barks at the certificates for Webinar/Usermin, with no chance of user error here as far as I can see.

So there has to be something different between our two systems (which in my case for the last few tries just was a Hetzner cloud VM).

But let’s ignore that, it will probably solve itself? :roll_eyes:


OK, whatever changed, today i can successfully install VirtualMin 7 on a Hetzner cloud VM running Rocky 8.6 using the same beta installer.

@Joe can you confirm that something has been changed concerning the Webmin/Usermin certs?

(Just being curious…)


I’ve changed nothing. We haven’t rolled a new Webmin/Usermin version yet, which is, I assume, where this problem would reside. I can’t explain your difference in results.

1 Like

Strange, but we’ll leave it there. Did two more test installs today that also worked flawless (Rocky and Alma 8.6).
Thanks for your time,

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