[Dovecot] Dovecot Dsync

[Ed W]

On 27/08/2013 09:54, Ben wrote:
> On 23/08/2013 13:08, Ed W wrote:
>> Hi
>>
>>> I'm on an Ubuntu LTS release so the dovecot came from their release.
>>> I'd prefer to stay that way unless I really have to...
>>
>> Everyone is entitled to their own opinions, but "IMHO" this kind of
>> attitude is a huge detriment to most software projects.  I see very
>> little reason to take such policies personally...
>>
>> 1) I use virtualisation (especially lightweight virtualisation such as
>> vservers) so that each service is in its own container. Now if I have no
>> interest in some container and want to let it rot (ie as per LTS), then
>> I can just do so.
>> 2) I use a fast moving rolling distro (gentoo in my case, Arch is
>> probably a good choice also) so that I have the option to stay up to
>> date when I want to
>>
>> The end result is you can be as up to date as you want, or let things
>> rot, as you please.
>>
>> Unfortunately if you want to use a very old bit of software, then you
>> also get to keep all it's bugs... Sorry.
>>
>> Good luck!  Hope this inspires you to try a different route!
>>
>> Ed W
>
> Whilst to some degree I appreciate where you're coming from and agree 
> with you to a certain extent, I would caution that following the 
> bleeding edge, always running the latest versions is not without risk 
> or bugs either !

OK, but virtualisation also helps you mitigate this:
- I setup my "containers" so that I have at least two mount points, one 
for the operating system and any data broken out into it's own mount.
- This makes it quite simple to duplicate the container and spin up a 
test version pointing if required at the live data
- Now you can run a test upgrade on the test container. If it works 
either swap them around or upgrade the original

Additionally:
- My choice of distro (gentoo) makes it fairly simple to build binary 
packages of the software I'm using.
- I then use these binary packages on all my containers, additionally 
with guided profiles which control which packages and which options we 
deploy.
- It's fairly simple to roll back most packages to the previous binary 
version if a problem is detected (logging of package changes is built-in)

So it's quite low risk to use such a rolling distro in general. Note, I 
can't speak for other distros, but gentoo "stable" is fairly 
conservative and shouldn't be a problem for an experienced admin to keep 
up to date.  It has the option to unmask "bleeding edge" packages where 
necessary and this can be useful to hit specific version numbers of 
software.  It's also pretty trivial to keep a private repo of customised 
packages (ebuilds) with either personal patches or to pin certain 
versions of software.  (So for example if you run, say, Dovecot with a 
few custom patches, then it's fairly trivial to drop these patches in a 
directory and now you can use the package manager to follow stable 
builds, but your custom patches will be rolled in for you with each 
update - can be very handy for some requirements)

I don't have the same experience with RPM/DEB so I can't say that all 
the same is easy to do, but the key thing is the use of 
containers/virtualisation to assist with testing and upgrades.  Even 
worst case you have to do a whole OS upgrade, at least if you can do 
that in a test container while the live remains running, is a big advantage

Good luck

Ed W