Trouble with dovecot in newer ( grade B suppoted ) OS releases

Virtualmin
1
SYSTEM INFORMATION
OS type and version Fedoa 43
Webmin version 2.610
Virtualmin version 7.50.2 GPL
Webserver version Not relevant
Related packages Dovecot CE

Heads-up (not a support request)

I’m running Virtualmin servers across mixed environments (Fedora, Alma; mostly GPL, some PRO). I usually fix my own issues, and minor bugs often get resolved after reports here or on GitHub.

Recently, I’ve noticed more Linux distributions upgrading to Dovecot 2.4, which breaks existing configs since the format is incompatible with 2.3.x. On my Grade B supported GPL systems, configs fail completely, and I’ve been fixing them manually. These installs are mostly for convenience, and in many cases Dovecot isn’t even in use so i have not given it too much attention to begin with.

Key breaking changes in Dovecot 2.4

  • Configs now require a defined version for the config and storage setup
  • SSL/certificate definitions have changed
  • %d variable is no longer valid
  • Auth configuration format is different
  • Mailbox format/setup has changed
  • Not just a simple change of config keywords

Why it matters

There’s no auto-migration between 2.3 and 2.4. Once 2.4 hits Grade A OS repos, many users will likely face broken mail setups as they upgrade their packages and blame Virtualmin. It may be worth reviewing compatibility now, since Virtualmin already manages daemon behavior via profiles / server templates i think it should not be too hard to rewrite a new config that fits the intended server behavior / templated layout based on it.

I haven’t yet tested how Let’s Encrypt auto-renew interacts with 2.4, or how other virtualmin domain changes may affect dovecot, but on GPL installs after the rpm upgrade, configs break fully.

Some pages that i used in figuring out how to get my dovecot instances back up and running and proof that this is a major issue incoming in many Linux flavors. I have no affiliation in any way with any of the links, just found them to be good information.

Summary

This is just a **heads-up for @Jamie and @Joe **: Dovecot 2.4 introduces major config changes that could cause widespread issues once adopted in supported OS repos. Better to prepare now than deal with a flood of support requests later when 2.4 hits those repo’s.

– Steven

2 Likes
2

We know about it. We expect it to work with clean installs using the development version 8.0.0 of the installation script. Does it work for you then?

To be clear, manual upgrades or clean installations with the current Version 7.5.3 Virtualmin install script won’t work with Dovecot 2.4 out-of-the-box because only Versions 8.0.0 and up support it.

3

A post was split to a new topic: Dovecot status shows not running on the dashboard in Debian 12

4

Are there any plans for Virtualmin to provide a migration path for Dovecot? I know neither Dovecot nor the OS offers an automated upgrade path between versions, so expecting Virtualmin to create one seems unfair. However, since Virtualmin already stores each domain’s configuration and sets up the /home/ environment during install, it seems technically possible for it to regenerate compatible configs for Dovecot 2.4.

I assume Virtualmin won’t expect existing installations to rebuild entire servers just to keep Dovecot working. With Virtualmin 8.x.x supporting Dovecot 2.4 at least out-of-the-box during install, I’m hoping Jamie might introduce some form of migration assistance, as he has done with other complex transitions i have seen him do in the past. ( been using virtualmin since early 2008 )

If such a migration path is planned, I’m happy to help test it. For now, I’m manually adjusting configs after upgrades until Virtualmin supports 2.4 on my affected hosts. I’m sure I’m missing some details though, since the affected servers don’t host active mailboxes, and the ones that do are on Pro licenses and more stable OS’es that haven’t reached 2.4 yet.

I do have some Fedora 43 GPL servers with a few archive mailboxes where Dovecot broke after the upgrade. I’ve kept them in this state specifically for testing, whether through “official manual instructions” or an automated Virtualmin migration path if ever provided.

If testing could be useful for validation, I’m ready to help and can recover the servers when needed if something breaks.

Steven

5

In addition,

I missed the note about the development version that could be tested,

Where can i find this version specifically? I have looked at Documentation | Virtualmin — Open Source Web Hosting Control Panel though could not find any reference to them there,

I have looked at https://software.virtualmin.com using the dropdown menu for the unstable versions I could see some newer files, though its unclear if this is the intended code to test and how to use it making sure the host switches to the dev version, as there where also vm 7.5xx release files there.

And then there is no clear info on what the actual dev state would be ( is there some changelog linked to the version somewhere? so i at least know what the state should be?

Steven

6

You can try the Virtualmin 8 stable repo (still in testing mode) and install it like this:

sudo sh -c "$(curl -fsSL https://download.virtualmin.com/install-script)" -- --bundle LAMP
7

Was about to give this a try though it seems the .dev domain for virtualmin is down:

https://rc.software.virtualmin.dev/ → unresponsive
https://software.virtualmin.dev/ → unresponsive

seems like there is an issue with the “origin.download.virtualmin.dev” host.

Steven

edit
seems https://rc.download.virtualmin.dev works, not sure if it is just an issue with the dropdown menu as seen on https://software.virtualmin.com, habbits over the years make me go to this url directly, seems that is part of the reason the links above are not working.

8

Some findings after the install:

  • During the install, the installer correctly identifies there is no ipv6 public on the server.
[17/19] Configuring Usermin                                                  ✔ 
[18/19] Configuring Virtualmin                                              ███[28/Dec/2025:02:13:59 +0100] Failed to work out externally visible IPv6 address
 ✔ 
[19/19] Configuring Webmin                                                   ✔ 
▣▣▣ Cleaning up

the message for this finding pops behind the “spinner” and throws of the locatin for the spinner in the terminal, nothing bad, just cosmetics.

  • The installer deploys and auto activates the firewall zone “public” resulting in the user losing their connection allowed in their own setup firewall zone (in my case the default “FedoraServer”, resulting in the loss of access to cockpit) was simple to fix by adding the default entries from the FedoraServer zone into the Public zone and reloading.

  • After a clean install, Dovecot was broken and fails to start: “doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: auth_allow_cleartext=yes has no effect with ssl=required” it was simple to fix, before completing the setup of virtualmin → “Webmin-> servers → dovecot imap/pop3 → ssl configuration” change “Disallow plaintext authentication in non-SSL mode” from yes to default or no. save, dovecot now starts as expected.

  • There seems to be some issue with the order of deploying the lookup-domain.service. Directly after install:

2:10 AM Failed to start lookup-domain.service - Daemon for quickly looking up Virtualmin servers from procmail.
2:10 AM lookup-domain.service: Failed with result 'exit-code'.
2:10 AM lookup-domain.service: Control process exited, code=exited, status=203/EXEC
2:10 AM lookup-domain.service: Failed at step EXEC spawning /usr/sbin/virtualmin: No such file or directory 
2:10 AM lookup-domain.service: Unable to locate executable '/usr/sbin/virtualmin': No such file or directory
2:10 AM Starting lookup-domain.service - Daemon for quickly looking up Virtualmin servers from procmail...

After reloading the unit files, the daemon was able to start without problems. Likely a simple reboot would have also solved this one. however after completing the virtualmin configuration steps the service was marked as failed again:

2:50 AM lookup-domain.service: Consumed 914ms CPU time, 86.7M memory peak.
2:50 AM Stopped lookup-domain.service - Daemon for quickly looking up Virtualmin servers from procmail.
2:50 AM lookup-domain.service: Failed with result 'exit-code'.
2:50 AM lookup-domain.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
2:50 AM test: extra argument ‘&&’
2:50 AM Stopping lookup-domain.service - Daemon for quickly looking up Virtualmin servers from procmail...

After another unit file reload and the service seems to start again just fine. However i think i have disabled this service during the install, so it is likely it should not even be running, though there still seems to be an issue in the unit file itself given the test argument error.

beyond the above, so far everything works as expected, added my external dns servers, restored a backup ( only database failed to restore due to a ~ 1Gb restore as to be expected using defaults for mariadb )

If I find more things that cause issues I’ll update, so far the vm 8 version seems to do things nicely on my fc43 machine, and yes i am aware it’s not meant for production, just love living on the edge sometimes, there is backups and recovery paths for the data, worst case i will have another go at the install once vm 8 hits release, as it is using the rc to test seems the best way to learn and figure out what’s good and bad.

Steven

9

What installer did you use?

10

Thanks, I will fix that up.

11

from history:
wget https://rc.download.virtualmin.dev/virtualmin-install-8.0.1.sh
then chmod +x and ran the installer as ./virtualmin-install-8.0.1.sh --unstable

from the installer log file, nothing interesting is mentioned at all the relevant section

...//
[2025/12/28 02:13:49] [INFO] - Configuring Usermin
[2025/12/28 02:13:50] [INFO] - Succeeded
[2025/12/28 02:13:50] [INFO] - Configuring Virtualmin
[2025/12/28 02:15:54] [INFO] - Succeeded
[2025/12/28 02:15:54] [INFO] - Configuring Webmin
[2025/12/28 02:16:04] [INFO] - Code: 0 Result:
[2025/12/28 02:16:04] [INFO] - Succeeded
//...

Steven

12

Sorry, what are you saying—did something not work?

13

I meant that
“in the section of the install log” where “the ip detection from the background process “escaped” to the foreground miss-aligning the spinner” the install.log, “did not mention anything special in relation to that happening.”.

Sorry English is not my primary language and writing in it is not always as unambiguous as i would like. though in short, the install.log did not report any additional info as to why the spinner was pushed aside.

Steven

14

The IP detection warning is harmless and will be fixed in the next Virtualmin release.

And thank you for reporting it!

15

just to be sure they get patched too, what about the other three non cosmetic issues? ( dovecot’s bad default, firewalld setup not honoring existing rules in the active zone when the zone is changed by the installer, and the syntax issue in the email-lookup unit file? ) should I report them elsewhere or are those also known or passed on / fixed?

Steven

16

Those come from upstream, right? Are you saying the distro you’re using has bad defaults? We don’t do that, and I’m not convinced we should micromanage it. Do you?

Ideally, there shouldn’t be any pre-installed software on the system, as we can’t handle every possible manual configuration. We can only know the system’s defaults and rely on that when making automated configurations. If you want something manual, it’s better to do it after Virtualmin is installed using our install script.

I’m not sure about that. Do you have steps to reproduce it? Or better yet, open a separate ticket to discuss just this issue. It’s not good to discuss multiple problems in one ticket.

17

Alright, we’ll respect that in the next release! Thanks! It’s not a problem and actually should be done because Rocky/Alma and Fedora have different default FirewallD zones.

18

Agreed, i will run a few test installs and figure out where the problem originates and report them upstream or back here if it is virtualmin deploy related.

port 9090 → cockpit service → firewalld zone FedoraServer is default present in a fedora server install clean from the press. nothing modified or manually configured. I realize it’s a grade B OS, so i did not expect a fix, just feedback as “something to be aware of”, however as you mention, this is future behavior on more then just the Fedora OS.

yes, cause, report and fix as suggested in new topic

Steven

19

We will respect that. We won’t touch any existing ports. We’ll just add ours, like 10000.

Thanks!

20

tried some things, reported a new bug in topic here This one can be closed as resolved splitting to new topics for each relevant part.

Thanks @Ilia for holding out the topic and helping me get the relevant parts going.

Steven

1 Like