vexim - new instance, advice

[Matt Darcy]

I've got to migrate off a legacy mail host, the host is old, the OS is old.

I'm going to do a new mail host - my initial plan was to use the "newer" versions of vexim and build a new vexim host on a new host and just migrate the users across as it's only small.

the post 2.2 release appears a long way off so I'm left with three realistic options

1.) build a new vexim host on a modern OS/platform and use the 2.2.1 release (currently testing this option) - problems with this for me are risk of support/stability of the newer components, eg: PHP 5, Mysql 5.6, Apache 2.4 etc.

2.) use the pre-release mater branch. This is a similar problem to option one, while I've seen some of the commits have helped make it a bit more future proof, there is still the risk of compatibility with the later product versions, there is also the risk of it being unstable, although from what I've seen, it's actually better than the official 2.2 releases.

3.) migrate away from vexim to something like postfix and postfixadmin - this is not something I'd planned on but is something I probably need to consider seriously due to the present options.

- -there is of course the option of waiting for a post 2.2 release, but there is no plan for this, no time line and no real list of things it will include, so it doesn't seem realistic, but I welcome more knowledge on this as an option.


what's the opinions on my options, am I missing something in these options, am I adding risks that aren't really there ?

feedback appreciated.

Matt

[udera....@gmail.com]

 I would start over with the current master branch of vexim because version 2.2.1 is just too old and has many bugs. To create the database, I would strongly recommend to use the mysql.sql template. If you have old data, you can probably import them. Mostly there are new fields and indexes, so it should work quite well. Except the clear-text password is gone.

There will be some changes until the vexim2.3-release. Only those to the docs/configure (->exim4.conf) and variables.php have to be implemented manually. All php-files can just be overwritten with the final version.

If you still have question regarding the conversion of passwords to suitable hashing-schemes, don't hesitate to ask.

udera

[Matt Darcy]

Has the code been updated in 2.3-prerelease to be happier with later versions of php ?

[Rimas Kudelis]

Hi again,

2016-07-21 16:11, Matt Darcy wrote:
> Has the code been updated in 2.3-prerelease to be happier with later
> versions of php ?

do you have any particular bit of "unhappiness" in mind? I think Vexim
should play nicely with all current PHP versions, even PHP7 (although I
haven't tried that). If it does not, bugs should be filed and fixed.
It's not like we maintain special VMs with old versions of PHP just to
suit Vexim.

Rimas

[Matt Darcy]

the versions from master seems to complain an awful lot less with php 5.4 than the 2.2 release did, so I just wondered if the patches/updates that had been put in place had been put in to make it more compatible with later PHP releases.

[Rimas Kudelis]

2016-07-23 23:45, Matt Darcy wrote:
> the versions from master seems to complain an awful lot less with php
> 5.4 than the 2.2 release did, so I just wondered if the
> patches/updates that had been put in place had been put in to make it
> more compatible with later PHP releases.

Yeah, we're trying not to use unitialized variables anymore. :)

If you look at your 2.2 php log closely, you'll see that there weren't
actually that many different (unique) entries in it. It's just that many
errors/notices were being triggered really often.

After 2.2 I migrated Vexim from Pear-DB to PDO. That's about the biggest
change you could mark as "PHP version compatibility", although I'd say
its effect is probably making some older PHP versions unsupported, not
adding extra support for newer ones.

Rimas