Uograde Zentyal 1.4 to release 2.2

[ian]

Hello,

Is there an option to upgrade V1.4 to V2.2.

If not how is it possible to export the users and computer accounts from 1.4 and import them to the new release 2.2.


It is not so easy and takes a lot of work to upgrade an oparational 1.4 system with more than 100 users and +/- 50 computer in a domain.

Best regards,
Ian

[J. A. Calvo]

The only path for upgrading to 2.2 is through 2.0, so maybe you can try to upgrade your 1.4 to 2.0 first, and after having a working 2.0 installation you'll be able to use the migration tool for 2.2.

[Sam Graf]

Ian is specifically interested in knowing how to follow this advice, I think:

An upgrade from 1.4 (hardy based) to 2.2 (lucid based) is not trivial and probably the best is to reinstall. To migrate users and machines on Samba just dump your LDAP database and reimport it back into the new 2.2 install. We have made this to many customers and works fine.

Hopefully someone in the community can offer some specific guidance.

[robb]

Agree with Sam. Upgrade paths are a must when it comes to professional use of Zentyal. Especially upgradepaths between major releases.
I can imagine that a simple 'sudo do-release-upgrade' will break zentyal. But there should be an alternative so a system upgrade to the next LTS version can be done.
Next year another major release is coming up and I sincerely hope a decent upgrade path to Precise Pangolin will be offered.

For now, people are still struggling with the upgrade to lucid/zentyal 2.x and personaly I think it is not acceptable that, after more than 1 year, there is still no step by step guide to upgrade from ebox 1.4 to zentyal 2.x

[christian]

Robb,

I do share.
Upgrade path can have different form: running script (like from 2.0 to 2.2) is one way to upgrade. Applying this to 1.4 to 2.0 jump is not realistic but minimal expectation is to have some clear process ensuring that nothing will be lost while following migration steps (could be, e.g. data backup, + system upgrade + new Zentyal install + data restore) and I believe this is the way most of us have upgraded. But this clear process and documentation is missing as far as I know.
LDAP backup is not enough (and even this deserves some documentation, most Zentyal users not understanding what this means and how to achieve it).
What's about Postgres DB, mail, web sites?
i.e., anything that will be lost because of new Zentyal installation must be saved and restored and this must be documented.

[robb]

Hi Christian,

That's exactly what I mean. There must be a solid way on how to implement _all_ your settings AND data (office, db's, mail etc...) on the new release.
As far as I can see there are a few options. Based on using the same hardware, based on using new hardware or a last option is to use a virtualized environment.

It would be a nice gesture if a few active forum members, with some help of a Zentyal dev brainstorm on how to accomplish a fail/fool proof procedure on migrating from eBox1.4 to Zentyal 2.x (Can the 'x' be a 2 or will that be a step to far and do we need to go from 1.4 via 2.0 to 2.2?)

[christian]

It would be a nice gesture if a few active forum members, with some help of a Zentyal dev brainstorm on how to accomplish a fail/fool proof procedure on migrating from eBox1.4 to Zentyal 2.x (Can the 'x' be a 2 or will that be a step to far and do we need to go from 1.4 via 2.0 to 2.2?)

For sure  but this is quite time consuming 
And it would be even nicer if THIS, among other "reliability related stuff" was the top priority above add of new features, components, whistles and bells 

The point is that, at least to me, is also a matter of design: one need some tool to identity was is already configured (which modules are actives, which ones are installed...) ans what has been configured or customized. Migration tool or script will never cover everything but there is a very minimum not yet reached.
Furthermore, I would also vote for a disaster recovery mode in case migration fails: how do you ensure you do not lose everything if your migration script fails, for whatever reason.

[robb]

Furthermore, I would also vote for a disaster recovery mode in case migration fails: how do you ensure you do not lose everything if your migration script fails, for whatever reason.
Modify message

This last point I cover by using a decent raid adapter with hotswap backplane. I bring down the server, break the raid1 config and reboot with failed disk0. If something turns out bad during migration, I revert to the original state by bringing down the server, take out the messed up migrationdisk1, put back disk0 and boot again with failed disk1. This is similar to making a snapshot of a virtual server.

[christian]

Sure this works. And if migration is successful, you connect second disk again (assuming you have everything on one single (mirrored) disk and synchronize?
This is also already very advanced and not fitting 100% with Zentyal philosophy targeting SMBs.

Either everything is installed on one single disk or you have to proceed with clever custom installation, using multiple RAID for system, data...

Do not misunderstand my point. I'm sure what you do works. I did migrate/reinstall multiple times without loosing data (except first time when I reinstalled mail at the very beginning and loose all mailboxes  ) but what I want to highlight here is that migration till now is not "end-user" oriented.

[jsalamero]

The number of users still running 1.4 is marginal so I'm not sure about making such big effort for a small number of users. LDAP (users, groups, passwd, domain computers, mail accounts, etc) can be easily migrated using ldapsearch, dumping into a ldif file users and groups OU and restoring it back with ldapadd. That will cover most of the cases and the most valuable information: the LDAP tree. Data can be migrated using standard backup tools (cp, rsync, etc).

Upgrade paths are not trivial tasks (see that migration tool from 2.0 to 2.2 is still in beta), but Zentyal team is committed to make best effort possible to provide migration paths.

[robb]

I agree that upgradepaths are no trivial tasks, but for a professional environment software upgrardes ARE trivial expectations and must be met. I know the Zentyal devs do a great job, and I only hope enough time is available and planned to make upgradespaths available.
If community help (like beta testing) is needed, maybe a specific call from the devs towards the community can be made.

[jsalamero]

Remember that you don't need to upgrade a server on production since support for that version is still available. Professional environments don't upgrade until: a new version of the software is required because a new feature is required or software version reaches end of support life.

[robb]

Ok, then lets assume we have a server with a 5 year support timeframe and a 2 year major release update timeframe (where did I see this before.. )
Now I am at the end of a 5 year support timeframe.... What's next? I still will need to do the migration to the newest version. Since you have to update over 2 major releases, problems will be even bigger then for a single major release update.
I rather update with each major release then wait for the 5 years of support end making it necessary to have a decent and fail/fool proof upgrade procedure.

[J. A. Calvo]

Next year another major release is coming up and I sincerely hope a decent upgrade path to Precise Pangolin will be offered.

Yes, you can be sure we'll do our best to allow a smooth upgrade from Lucid with Zentyal 2.2 to Precise with Zentyal 3.0

[christian]

I've no doubt whole Zentyal team is working in best effort mode  and I also understand that migration script for such open perimeter where everyone can customize a lot is really tricky.
This said, I do not fully share jsalamero's statement describing migration as ldap on one hand and data on the other hand.
Because of all different modules Zentyal offers, deploying again some pretty large environments can be very painful: once you have retrieved all users account, restored mailboxes and data, you still have to reconfigure manually DHCP, DNS, Firewall rules, think about secondary Zentyal servers (what's about slave ldap in the meantime?).
What is underlying is the lack of backup strategy that could be used to save Zentyal related data to be restored in case of new installation. I've to admit that this puzzles me a bit 

Everything done vie "upgrade" should maintain existing repositories assuming this is strategy implemented by Zentyal. So far, all previous upgrades before 2.0 to 2.2 have been done through complete re-installation, if I'm not wrong.

My point here is to highlight that such strategy will be very challenging because of the increasing amount of new features and product plus extended LTS support that may slow done system upgrades, resulting in bigger steps...