Yeah, 8GB is plenty (unless something weird is going on), so not surprising it’s not memory. I guess it could still be memory if this is an OpenVZ or Virtuozzo container, as memory is a total mess there. So, we’re still stumped about what it is.
Is this a VM at a hosting provider, or a physical machine you’ve installed the OS on yourself?
Its a VM at Hetzner.
CX32 - 4 Cores, 8GB RAM, 80GB, 20TB Traffic
I just ran setup agian… there is one line at the setup
Phase 2 of 4: Setup
Installing core plugins for package manager 
Downloading Virtualmin 7 release package
Fehler: Das Paket ist nicht installiert
Installing Virtualmin 7 release package
2024-12-16 10:10:39 URL:https://software.virtualmin.com/vm/7/rpm/virtualmin-gpl-release.noarch.rpm [15879/15879] -> "virtualmin-gpl-release.noarch.rpm" [1]
[2024-12-16 10:10:39 CET] [INFO] Downloading Virtualmin 7 release package: [2024-12-16 10:10:39 CET] [INFO] Success.
[2024-12-16 10:10:41 CET] [INFO] Spin pid is: 1649
Warnung: virtualmin-gpl-release.noarch.rpm: Header V4 RSA/SHA256 Signature, Schlüssel-ID b9a0b8b7: NOKEY
Fehler: Transaktion-Sperre auf /var/lib/rpm/.rpm.lock kann nicht erstellt werden (Die Ressource ist zur Zeit nicht verfügbar)
Fehler: /etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin-7: Import des Schlüssels 1 fehlgeschlagen.
[2024-12-16 10:10:41 CET] [INFO] Installing Virtualmin 7 release package: [2024-12-16 10:10:41 CET] [INFO] Success.But that seems to be OK, Virtualmin gets installed…
Sometime it may also simply be the OS ISO which is badly configured. Did you try an other OS available (Debian might be a good start) ? Or maybe a Rocky linux but with an ISO from an other source ?
I also tried other ISO. Not on the Server @Hetzner, but VM here @home.
Same “error”.
Debian would have been my 1st choice for a server, but there I run into issues with missing logs due to systemd witch are needed by CSF (The firewall and logfile scanner I want to use).
This wording is a tad confusing. Which Debian? I had to update from 10 to 11. If CSF needs the OLD style logs, then you can add rsyslog. Otherwise, I’d think systemd would be consistent across all platforms.
If CSF isn’t updated to systemd yet, that would be surprising.
All distros have mostly moved to logging most services to the journal. And, things can be configured to log to a text log instead. (Off-topic for this thread, but it’s certainly a soluble problem. And I can’t imagine CSF can’t work directly with the journal instead of text logs?)
I’ll try to do a test install on the latest Rocky, but I’ll be surprised if it’s broken there…all of my servers (for Virtualmin and person) are running Rocky, it’s my first test platform for everything. But, I guess Alma might be worth a shot, in the sense that it’s very similar to Rocky, but from a different source and if something got weird in Rocky it probably didn’t get weird in the same way in Alma (though we’ve had people installing it on both distros during this conversation, without hitting this issue, so we seem to be dealing with something specific, I just can’t figure out what).
CSF has some caveats for Debian. Only supports 11 and ‘may’ require some custom regex.
Can not wait to hear back from a new installation by a pro 
Don’t forget to test the virus filtering - that was was triggered me looking into it at first at all - I used the eicar test from don’t panic…
But if you like I got a hugh collection of real malware somewhere laying around 
By the way, this is what I used for the Post-Installation Wizard
Run email domain lookup server?
Yes, faster mail processing with more RAM used (≈70M)
Enable virus scanning with ClamAV?
Yes, uses up to 2G of RAM
Run SpamAssassin server filter?
Yes, faster mail processing with more RAM used (≈30M) and no per-domain settings
Run MariaDB database server?
Yes
MariaDB Passwort
****************
Master administrator's email address
arpo@hostname.domain.tld
Password storage mode
Store plain-text passwords
MariaDB configuration size
Keep MariaDB system defaults
Location for SSL certificates
In each domain's home directory Well, I can not help, sorry. But would it be possible to know if you get the same problem with virtualmin 7.2 and not 7.3 (To try to narrow it down; just in case it would be a bug with the last version).
I don’t know how to install an older version.
None of that matters, as the problem in the original report was about procmail-wrapper which is setup before the postinstallation wizard runs. It’s part of the Configure stage of the install process.
I just did a test install on Rocky 9 on a VM at Vultr (I can’t test on Hetzner as they rejected my card as a payment method last time I tried to sign up, so I don’t have an account there) and everything got setup correctly, so the issue remains a mystery. I can’t reproduce it, so I’m more confident of something unique to your system, but I still don’t any good guesses about what.
But, I don’t see how it’s possible that you have this behavior both on a VM at Hetzner and on your own server. That doesn’t make sense, it would have to show up for others, if you’re seeing it in two completely different systems that are freshly installed Rocky 9. I will note that Hetzner has come up in the past as being a provider with customized/broken OS images, though the issue was different from this one (and, I don’t remember details).
Wait, there is an aesthetic bug in the SpamAssassin module. It should not display the warning about Procmail if Virtualmin is managing email. I thought that was fixed a million years ago.
@Jamie is it a regression that this warning still shows up in the SpamAssassin module, or am I just imagining that it was hidden in the past when Virtualmin was configured?
“Warning! SpamAssassin does not appear to be set up in the system’s Procmail configuration file /etc/procmailrc, so any configuration done using this module will have no effect unless users have it set up individually.”
@SkaFan You can/should ignore that message entirely. It is nonsense in a Virtualmin system, and has no bearing on anything. It means nothing. (It appears even when Postfix is correctly configured to send mail through procmail-wrapper/procmail and spam/AV scanning will be handled appropriately as configured in Virtualmin. The bug is that the warning shows up, it doesn’t indicate any problems.)
@Joe, good morning…
“You can/should ignore that message entirely.” well not really!
Mails containing a virus dont get scanned nor put into the virus folder.
If I scan the homes folder with clamscan manually the virus get detected.
Also while installing the system the ISO got CRC checked. I was not using a Hetzner pre-installed system.
Cloud you test mails with a virus? Did they get scanned and put into the virus folder?
I am talking about the message you mentioned in the SpamAssassin module in Webmin. I am not talking about virus scanning. That that message appears when you browse to the SpamAssassin module is a bug (because Virtualmin is handling the procmail rules and doing trying to do anything that interferes with that, like adding a generic catchall rule that directs mail through SpamAssassin, would break Virtualmin’s rules), and should be ignored.
OK, Server → Spamassassin’s procmailec complain is a bug - ignore it.
What about the virus not get detect? That is somehow procmail too, right?
I just spun up a clean Rocky 9 instance (x86_64) on Linode and performed a fresh Virtualmin GPL install. I don’t see the issue you’re reporting.
Is this a clean and minimal Rocky 9 server instance with nothing pre-configured? Also, keep in mind that spam and virus scanning requires a significant amount of RAM—probably at least 8 GB.
You shouldn’t need to do this—it happens automatically when a new domain with mail and spam/virus features is first created.
Again, there’s no reason you should need to do that, unless you’re trying to install it on yet unsupported ARM system.
Try Rocky 9 on Linode. Which provider are you currently using?
Im using a VM at Hetzner.
But… It’s getting worster and worster.
Right now there is a fresh installation running.
But Virtualmin does not create a Let’s Entrypt SSL Cert.
I was looking into it… restored a backup without Virtualmin installed.
Checked hostname and hostname -f. It was hostname and hostname.domain.tld as it should be - Both where OK.
While Virutalmin was installing I keep checking on an other SSH session and suddenly hostname changed to hostname.domain.tld again! No wonder Virtualmin cloud not create a valid cert. I Guess it wanted to create a cert for hostname.domain.tld.domain.tld.
WTF is going on with Hetzner?
Kind of, yes, but not in the way that the SpamAssassin module is complaining about. But, the problem with your system is still something I can’t figure out.
Earlier you said you needed to compile procmail-wrapper yourself, which I don’t understand, as I see in the install log that the procmail-wrapper package was installed. So why were you compiling it? Was the binary not actually present?
And, it seemed like this was not present in your Postfix main.cf?
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
If that’s not present we continue to believe your installation was incomplete in a way I don’t understand. I see it on my test install.
The only issue I see, so far, on my test install is that SpamAssassin module is issuing a bogus warning about procmail.
That’s a different issue, and is unsurprising. It won’t even try if the hostname doesn’t resolve correctly back to the system. If you want to follow up on that issue, create a new topic.
People have reported issues in the past. I don’t recall specifics. But, I wouldn’t consider the failure to automatically get a Let’s Encrypt certificate a fatal issue. That happens probably most of the time, and for many years we didn’t even try, because so many things that are outside the control of Virtualmin or the installer can go wrong