migration from 2.0.16

lists lists at lazygranch.com
Thu Dec 17 17:14:42 EET 2020


I have found opensuse to be very stable and the upgrades to be drama free IF (big if) you stick to the distribution repositories. For a server, sticking to the disty repos is very likely. It is desktop users (me) that load a lot of software from other repos that occasionally muck things up.

I run centos 7 on my servers and opensuse on the desktop. They are very similar. I always have trouble when I have to use Debian, which these days is only on a R Pi. Opensuse can use three different package managers, one of which being yum. 






  Original Message  


From: barbara at rfx.it
Sent: December 17, 2020 6:57 AM
To: dovecot at dovecot.org
Subject: RE: migration from 2.0.16


On Thu, 17 Dec 2020, Marc Roos wrote:

> I would not choose centos 8 it has EOL < than centos7. IBM is pulling
> the plug on the centos distribution, and makes it more or less a beta
> for the rhel. Thus centos7 and then you have a few years to decide what
> to choose. Enough to go to full containerized eg. ;)

We own the servers and use CT (LXC).
The IBM move is clear, but going to C7 today seems to me not a good
choice.
It is in its descending stage and in a couple of years packages are going
to became very outdated.
If RH8 remain "open source" I suppose the community or some interested
medium level company that use CentOS for their business can became a new
CentOS and switch to a different named distro is supposed to be only a
question of replace repositories.
That seems to me a smoother path (IMHO).
Debian 10 is EOL on 2022
Ubuntu LTS seems a solution, but I hadn't ever used it (I may be wrong,
but in the past Canonical don't inspire me to much trust).

Other options (not too "exotic")?


> You do not need to rsync, dovecot can sync messages. I am just in the
> process of migrating a server from a different network to a different
> mailbox format.
>
> My approach was to create an 'archive' namespace on shared slower but
> distributed storage so I do not have to move to much data.

I am studying the situation, but there are many variables and the old age
of the source server probably meke it more complex.
And I am not a dovecot expert ...

Thanks, B.


More information about the dovecot mailing list