I have more server’s with Debian 10, but one with Cloudmin 9.7 Pro and one with Virtualmin 7.7 Pro. I need upgrade all our systems to Debian 11.
For Cloudmin installation I have record
deb http://name:password@cloudmin.virtualmin.com/debian binary/ in sources.list .
For Virtualmin installation I have record’s
deb https://software.virtualmin.com/vm/6/apt virtualmin-buster main
deb https://software.virtualmin.com/vm/6/apt virtualmin-universal main
in sources.list.d/virtualmin.conf.
If I change debian repository to bullseye and I want to use a combination apt update && apt upgrade && apt dist-upgrade, how do i need to change resources for Cloudmin and Virtualmin?
Rony
The Cloudmin server should probably stay on Debian 10 until we have better tested it on newer distro versions.
For Virtualmin, you can upgrade, but you don’t need to (and can’t) change the virtualmin-buster repo to virtualmin-bullseye because there is no such repo. Virtualmin 7 was the first installer version to support Debian 11, and we refactored the repositories so we no longer maintain separate binary repos for every Debian/Ubuntu version. The one binary package in the Debian binary repo works fine on any supported version, so you do not need to change repos.
At some point you may want/need to migrate to a newer Virtualmin repo, but the /vm/6 repo is maintained and has all current packages and will continue to do so for some time. There are differences in the metapackages in the /vm/7 repos, which are probably safe to switch to, but I wouldn’t recommend doing it casually.
Oh, and, I don’t have a firm date for Cloudmin, but I do hope to have the new repos and new installer released soon (as in not more than a month or two out).
1 Like
Oh, wait, Debian 11 is old enough to probably be fine with Cloudmin. I think our only known issues are in stuff from 2022-ish. So, it’s probably fine to upgrade the Cloudmin system to 11, too. No repo changes needed.
Yes, Debian 11 is Bullseye and it’s stable. Version 11.0 stable from august 2021. 11.6 is out from december 2022, but it’s still a Debian 11 Bullseye 
. However, we have been using Debian 10 Buster (aka old-stable) so far. But we already need to upgrade for other reasons, and we don’t want to have two versions of Debian on our systems unless absolutely necessary.
THX for reply. Saturday morning will find out what the truth is
If it helps anyone:
the upgrade according to the above went without any big problems. The only problem was proftpd, where we see from bullseye does not support the IdentLookups configuration option, so proftpd remained unconfigured. The fix is trivial. Reboot Cloudmin and Virtualmin completely in progress with a new kernel on an encrypted file system. They both ran.
To start, webmin detected a distribution upgrade, so I offered to change the presentation from Debian 10 to 11. After acceptance, he changed it. So everything is great.
The another problem occurred with the Virtualmin installation. Apt offered me autoremove for bind, mariadb, postfix and many other packages that Virtualmin depends on. So the dependency chain was broken somewhere. How to fix it? With Apt reinstall Virtualmin? Or? It would be convenient to treat this with some Post-Invoke script. It could happen that someone will use the offered autoremove.
And another thing: somewhere in Cloudmin, the binding to the IP address of the xen guest guest with Virtualmin installation went wrong. Status of this host in Cloudmin is “Ping failed (Last changed at 29.04.2023 01:42)”. Detailed status error ssh: Could not resolve hostname 62.168.116.188/29: Name or service not known. I suspect that this host is presented with an IP address with postfix netmask format, i.e. XXX.XXX.XXX.XXX/YY. Other xen guests are presented only with IP in the classic format without the netmask postfix, i.e. XXX.XXX.XXX.XXX.
However, both pings and ssh logins to these machines from the Internet and between them work. What should I do about it? The network is configured correctly on both machines. This is how I can’t manage a Virtualmin machine from Cloudmin. I’m guessing it’s some glitch in Cloudmin, but I have no idea what to look for. After the dist-upgrade, I first restarted the Virtualmin host, and it worked perfectly. Virtualmin was on Debian 11 and Cloudmin was on Debian 11, but the kernel was from Debian 10, i.e. before restarting. After restarting the machine with Cloudmin this error appeared.
But otherwise: after our never ending problems with the previous webhosting panel we used, this was great. A nice job is done on this software(cloudmin and virtualmin).
1 Like
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.