@CTS, thank you for your perspective. Just to clarify, I am testing both the current version for Debian 12 — even if not ready for Debian 13 — and the upcoming Virtualmin 8. My feedback specifically concern certain Dovecot directives and their expected locations. I also asked whether my post should be redirected to GitHub, so I’m confident my intent is clear. Continuing this back-and-forth is unlikely to be constructive, as the points I’ve made are clear—perhaps just misunderstood.
@ADDISON74
Yes I think you’re intent is not clear.
Testing a release that Cleary states that it is not for intended OS target and there being a almost ready to release version for said new Target OS is a waste of energy and this whole thread is corrupt because you’re intent is still not understood.
I wish we could all help with you’re original post but it is just pointless now.
If you find something in the not yet released Virtualmin 8 that does not run correctly please report to staff but testing on Virtualmin 7.x for Debian 13 is beating a dead horse now.
Have a blessed day
For it to be actionable, you have to be testing some reasonable combination of things (i.e. not Virtualmin 7 on an unsupported distro), and something specific (i.e. if you’re talking about Debian 12 and Virtualmin 7, or Debian 13 and the dev version of the Virtualmin 8 installer, those are two totally different things…different branches in git, different software repos, different packages). It isn’t clear what installer you used where you’ve having to do all these changes…if you used the Virtualmin 7 installer, everything you’ve mentioned is expected to fail. If you used the Virtualmin 8 dev installer, almost everything you’ve mentioned is expected to work and reports to the contrary are useful.
But, I can’t keep up with a bunch of different things intermingled in one topic.
Webmin should already understand include files in the Dovecot configuration, but we’ll need to make sure we’re modifying the right things in Virtualmin-Config, and I’m trying to carve out some time for testing this weekend. Normally, when there’s a conf.d where we can override things, we’ll add something like 90-virtualmin.conf to place our configuration in, but Dovecot hasn’t always had that (but it has had it for much longer than 2.4 and we’ve supported config files in that layout for some time), and we’ve never converted to doing it that way in the Virtualmin installer for this particular service. Probably worth doing, though. We like to keep config in places where people can understand what we do and what their OS did (both so we don’t catch the blame for dumb things Ubuntu does, and so people can easily compare their system to a known-good Virtualmin system and know/understand what specific changes we make during install).
@CTS: I’d like to clarify my intent from an engineering perspective and respond to both points raised here.
The initial testing on Debian 13 with Virtualmin 7 was not meant as an attempt to make an unsupported stack work in production, nor as a bug report for 7.x. It was deliberately used as a way to explore the failure surface and better understand what expectations are reasonable for Virtualmin 8, especially given prior statements that many of these issues had already been analyzed and addressed. From that standpoint, starting with a known-broken combination can still provide useful context when evaluating whether the next major version actually closes those gaps.
I also want to note that, in my opinion, Virtualmin has faced and resolved far more severe issues in the past than what is being discussed in this thread. The points raised here are relatively minor by comparison and primarily relate to configuration hygiene and upgrade safety, not fundamental functionality.
@Joe: Thank you for the detailed explanation and for taking the time to look into this more thoroughly. I appreciate you considering additional testing and the idea of placing Virtualmin-managed settings into a dedicated file (for example, a 90-virtualmin.conf under conf.d). That separation is exactly what I was aiming to highlight: clearly delineating OS defaults from Virtualmin-managed configuration makes systems easier to reason about and significantly reduces the risk of accidental overwrites during upgrades.
I fully agree that actionable reports should be based on reasonable and supported combinations. Once I complete testing with Debian 13 and the Virtualmin 8 development installer, I’ll report any unexpected behavior in that context specifically.
Thanks again for the time and effort put into reviewing this — it’s appreciated.