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: packages of the software I'm using.

• My choice of distro (gentoo) makes it fairly simple to build binary

• 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