Update Debian 11->12 then 12->13

Virtualmin
1

I plan to upgrade from Debian 11 to 12 (and then to 13 once the upgrade has been successfully completed and is stable) over the coming month.
It’s a Virtualmin distribution that I’ve been updating since version 8 or 9 without any problems.

I’m a good student and follow the official guidelines: Chapitre 4. Mises à niveau depuis Debian 11 (Bullseye) by taking every possible precaution and being careful about the changes I make when updating the configuration files (I check the diffs, take notes and then make adjustments if necessary).

As I said, I’ve never had any problems, but I still have some reservations about the source of the Virtualmin repository.

I currently have:
deb [signed-by=/usr/share/keyrings/debian-virtualmin-7.gpg] https://software.virtualmin.com/vm/7/gpl/apt virtualmin main

No changes for Debian 12 and 13? Incidentally, I’m planning to switch to the deb822 format:

Types: deb
URIs: https://software.virtualmin.com/vm/7/gpl/apt
Suites: virtualmin
Components: main
Signed-By: /usr/share/keyrings/debian-virtualmin-7.gpg

Am I right?

Is there anything in particular I should be aware of between these two version updates when using Virtualmin?

Thank you in advance.

SYSTEM INFORMATION
OS type and version Debian 11
Webmin version 2.651
Virtualmin version 8.1.0 GPL
Webserver version 2.4.67
2

Well, yes and no.

New installs get a different repo. And Debian 13 support in our installer didn’t arrive until Virtualmin 8 (you have the Virtualmin 7 repos, which doesn’t impact which version of software you get, including Virtualmin virtual-server module 8.x, it just indicates which installer you used).

But, a system upgraded in place generally doesn’t need to change the Virtualmin repo paths and generally shouldn’t without additional testing.

All that said, are you sure you want to do an in-place upgrade across multiple versions? You’re going to have some breakage somewhere with all the changes that necessarily come from that.

If you’re on a VM, I generally recommend you fire up a new VM, install Virtualmin using the current installer, and restore your Virtualmin backups from the old system. That allows you migrate one domain at a time (or one or two for testing and then a batch of the rest), and to test thoroughly before you flip the switch from the old production server (you can do a last rsync to catch up on email and databases, if the testing period is long enough to where you can’t just stop your services that produce more data on the old system.

We have a migration guide. How to Migrate to a New Server | Virtualmin — Open Source Web Hosting Control Panel

The risk of issues is somewhat lower and the necessary downtime is definitely lower than performing an in-place upgrade. Virtualmin doesn’t care (much) about what version of the OS you’re running. But, changing your whole OS in-place is a big change with a lot of moving pieces. It almost always gets weird. Almost always easily fixable, but still weird and still needing fixing.

3

Thank you for your reply.

No, unfortunately I’m not on a VM, but on a dedicated server.
And I haven’t planned to get a second server (unless I mess it up badly) to carry out the migration (which will take even longer if I have to reinstall everything, reconfigure the IP addresses, and so on).

So far, the only ‘hiccup’ I’ve come across is having to uninstall and then reinstall MariaDB to update it, because the full-upgrade command didn’t work, but honestly, it was really quick – just a few Apache settings to add.

So, if I’ve understood correctly regarding Virtualmin repositories, the only difference between the old ones I have and the new ones in v8 is in the installer, and since I’ve already got my system installed, it won’t make any difference, will it?

And just out of curiosity, what are the new repositories?

4

Be careful and verify your Dovecot configuration on a test server before upgrading.
11 → 12 is fine, but in 13 there is a major version upgrade of Dovecot that messes things up badly, like Dovecot has always managed to screw up in one way or the other.

5

You don’t need to know the specifics, there’s a virtualmin command to switch (at least, I think it switches):

But, as I said, you generally should not switch, especially not as part of a major OS upgrade.

There are major changes in the Virtualmin 8 repos. A move to a modularized Webmin package, which has thrown a lot of people for a loop who switched without understanding the change. When it’s time for the Virtualmin 7 repos to be deprecated we’ll provide documentation and a tool for making the switch painlessly. All the same Virtualmin package versions are in both repos, you are not missing anything by using the Virtualmin 7 repos. An upgraded system does not get the new installer defaults, so changing repos does literally nothing except make you work more.

6

Thank you very much for the heads-up; I’ve just had a look through various threads and documentation and I’ve noticed quite a few changes:

ssl

File : /etc/dovecot/dovecot.conf

V2.3 :
local_name domain.com {
	ssl_cert = </home/domaincom/ssl.combined
	ssl_key = </home/domaincom/ssl.key
	ssl_ca = </home/domaincom/ssl.ca
}
V2.4 :
local_name domain.com {
	ssl_server_cert_file = /home/domaincom/ssl.combined
	ssl_server_key_file = /home/domaincom/ssl.key
	ssl_server_ca_file = /home/domaincom/ssl.ca
}
  • ssl_cert become ssl_server_cert_file
  • ssl_key become ssl_server_key_file
  • ssl_ca become ssl_server_ca_file
  • removal of < from the URI

passdb/userdb

File : /etc/dovecot/conf.d/auth-system.conf.ext

V2.3 :
passdb {
	driver = pam
}
userdb {
	driver = passwd
}
V2.4 :
passdb pam {
}
userdb passwd {
}

In 2.4, passdb/userdb the block name replaces driver =, and an unnamed block (passdb { }) results in a fatal error: is missing section name.

mail_location

File : /etc/dovecot/conf.d/10-mail.conf

V2.3 :
mail_location = maildir:~/Maildir
V2.4 :
mail_driver = maildir
mail_path = ~/Maildir

mail_location has been removed. It needs to be split up:

plugin {}

Files :

  • /etc/dovecot/conf.d/10-logging.conf
  • /etc/dovecot/conf.d/90-acl.conf
  • /etc/dovecot/conf.d/90-plugin.conf
  • /etc/dovecot/conf.d/90-quota.conf
V2.3 :
plugin { }
V2.4 :

In version 2.4, the plugin { } section no longer exists at all (all plugin settings become global). Even if left empty, this block may cause a syntax error — it should simply be removed.

Configuration header

File : /etc/dovecot/dovecot.conf

V2.3 :
V2.4 :
dovecot_config_version = 2.4.1
dovecot_storage_version = 2.4.0

Put it at the top of the file; otherwise, it seems to crash.

ssl_dh

File : /etc/dovecot/conf.d/10-ssl.conf

V2.3 :
ssl_dh = </usr/share/dovecot/dh.pem
V2.4 :
ssl_server_dh_file = /usr/share/dovecot/dh.pem
  • ssl_dh become ssl_server_dh_file
  • removal of the < from the URI

What’s more, their configuration update tool is rubbish and doesn’t work: Config upgrader

7

Just for the sake of science, I tried setup-repos --branch stable.

He sent me the following repo: deb [signed-by=/usr/share/keyrings/debian-virtualmin-developers.gpg] https://download.virtualmin.com virtualmin main and deleted the Virtualmin 7 key.

The upgrade isn’t working because the Virtualmin packages appear to be compressed using zstd, which was introduced in apt 1.21.18, available from Debian 12 onwards…

Anyway, I’ve switched back to the old repositories, re-downloaded the Virtualmin 7 key, and everything’s back to normal :slight_smile:

PS: Shouldn’t setup-repos (re)install the repository compatible with the system version (even though I know my OS will soon be considered obsolete)?

8

Don’t say I didn’t warn you. :wink:

9

Of course, but I wanted to find out exactly what would cause the problem!

I wouldn’t try this on Debian 12 (which, in any case, will only be a transitional version), but what problems might I encounter if I tried it again on Debian 13?

10

I’m sorry, but you’re wasting your time.

Take this advice: never distro-upgrade systems that are many years or even decades apart.

And, it’s almost never necessary. Just spin up a new Debian 13 and migrate the domains there. If you need hand-holding through the upgrade, that’s a clear sign you’ll end up spending a lot more time and effort on the distro upgrade.

For example, I could do it without asking questions, but I still wouldn’t. The only distro upgrades I think are worth doing are bleeding-edge or rolling ones, like Fedora or Kali.

11
  1. If I like wasting my time, that’s my problem, isn’t it? I also reckon that figuring things out for myself and experimenting is far more rewarding than running a script that does everything for me (yes, I’ve got the time).
  2. I’ve been updating Debian for three major releases now without any major issues.
  3. If it were a default installation, yes, a fresh install would undoubtedly be quicker, but my server isn’t managed solely by Virtualmin; there are lots of custom configurations, home-made scripts, modules and a few servers not managed by Virtualmin…

So, if I do a fresh install of Debian 13, importing the VHs will happen automatically, but restoring all my customisations is a completely different matter; I don’t know how the configuration import tool works; I imagine (and hope) that it has mechanisms to update certain settings automatically (such as the dovcot settings mentioned above), but for everything else – the custom configurations and so on – it’s all done manually, and that sort of thing is a real pain to tidy up in the new configuration files.
So, I prefer to carry out an update, keep the old config files and update them by following the documentation, whilst keeping an eye on the logs; I find there’s less risk of error and it’s quicker.

But let me make it clear: it’s a question of infrastructure and personal preference.

12

Don’t get them wrong or better to say misunderstand them. What they say regarding a waste of time and it’s not the recommended way is true … in general.
That being said, it’s also true that every scenario is different. The final decision is up to you and it was not the goal to prevent or stop you from doing it your way, it’s just a friendly advice from a longer period of working on this matter.
While yes, I would also not recommend upgrading directly … I do understand that you do it your way. I like experimenting and gaining experience from that too. It’s just not the “usual” way.
If you got the time to do it that way and you are aware of the issues which might arise, why not give it a try?