[Kolab-devel] Upgradepath towards 3.1

[de Raad, Hans]

LS,

with the compelling features of Kolab 3.1 in reach, i'm very interested
in both a timeline as well as an upgrade path. Would it be possible to
provide such information?

I'd like to inquire about the following:

- what is the current release planning for Kolab 3.1

- would it be possible to upgrade partially (ie, implement the SabreDav
components and filesharing)?

- will there be an upgrade-kolab script provided (in spirit of the very
usefull setup-kolab)?

These answers would enable me to setup more testing sites at real-life
customer installs, since it seems that the Kolab package itself is
pretty much unchanged, as well as its primary dependencies.

Looking forward to the new release!

Best regards,

Hans de Raad

A happy Kolab 3.0 user
--
DevHdR
onderdeel van HaLeNaS v.o.f.

Van Sevenbergestraat 49
2274 PK Voorburg

KvK: 53493753

Tel: [phone]

www.hcderaad.nl

[Jeroen van Meeuwen (Kolab Systems)]

Post by de Raad, Hans
LS,
with the compelling features of Kolab 3.1 in reach, i'm very interested
in both a timeline as well as an upgrade path. Would it be possible to
provide such information?
- what is the current release planning for Kolab 3.1
- would it be possible to upgrade partially (ie, implement the SabreDav
components and filesharing)?
- will there be an upgrade-kolab script provided (in spirit of the very
usefull setup-kolab)?
These answers would enable me to setup more testing sites at real-life
customer installs, since it seems that the Kolab package itself is
pretty much unchanged, as well as its primary dependencies.
Looking forward to the new release!

Hi Hans,

the kolab package itself is largely unchanged because it is only used as
a meta-package to pull in various dependencies - we've only introduced
two new ones for Kolab 3.1, being chwala and iRony.

chwala and iRony (with WebDAV) both depend on a more recent version of
libkolabxml, and libkolab than ships with Kolab 3.0, but not for the
obvious reason (files) - a very mysterious chain of dependencies makes
chwala and iRony depend on the latest roundcubemail, and the latest
roundcubemail-plugins-kolab, versions of which cannot just be mixed and
mangled (probably the cost of moving forward as fast).

That said, IMAP is still IMAP (replace /etc/imapd.annotations.conf with
the new version for CardDAV / CalDAV compatibility),
iRony/chwala/roundcube/syncroton from Kolab 3.1 can run on a different
server (than MTA/LDAP, components that might have updates but do not
require updates, and there's no further schema changes) and as such one
could "stage" an upgrade...

That said, the upgrade path is far from described in detail. I'm working
on both the actual documentation as well as the upgrade path /
changelog[1].

This, and [2], might help you see why I can't really say all that much
about a timeline.

Kind regards,

Jeroen van Meeuwen

[1]
http://hosted.kolabsys.com/~vanmeeuwen/build/html/administrator-guide/upgrading-from-kolab-3.0.html
[2]
http://kolab.org/blog/vanmeeuwen/2013/09/09/why-kolab-3.1-still-alpha

[de Raad, Hans]

Hi Jeroen,

thanks for responding so thouroughly (and apparently i've missed a blog
post, congratulations on your mykolab.com succes btw!), so basically
what you would advise (if i distill this correctly from your message)
would be to follow one of the following 2 strategies:

1. Setup a different server for the webbased components of Kolab and
have them configured to hook into the (unchanged apart from the new
annotations) Cyrus/389/postfix server.

2. Upgrade everything (yum upgrade ?) to the develpackages (fingers
crossed) and perform the following steps:

2.1 Run setup-kolab imap to implement the new annotations

2.2 Remove/change underscores from the names from START, SERVICES and
EVENTS section of cyrus.conf

2.3 Delete all files named *.squat from the IMAP spools

2.4 Check for/or add the setting: postuser : shared to /etc/imapd.conf

Is that a correct interpretation of the documentation?

Would there perhaps also be an option 3? Using kolab migrate tools for
this excersize to a new clean installation?

Thanks for your input!

Best regards,

Hans de Raad
--
DevHdR

onderdeel van HaLeNaS v.o.f.

Van Sevenbergestraat 49

2274 PK Voorburg

KvK: 53493753

Tel: [phone]

www.hcderaad.nl

[Jeroen van Meeuwen (Kolab Systems)]

Post by de Raad, Hans
2. Upgrade everything (yum upgrade ?) to the develpackages (fingers
2.1 Run setup-kolab imap to implement the new annotations
2.2 Remove/change underscores from the names from START, SERVICES and
EVENTS section of cyrus.conf
2.3 Delete all files named *.squat from the IMAP spools
2.4 Check for/or add the setting: postuser : shared to /etc/imapd.conf

Running `setup-kolab imap` will actually take care of 2.2 and 2.4
itself.

Post by de Raad, Hans
Is that a correct interpretation of the documentation?

Noted that one could run `setup-kolab mta` to update the postfix
configuration to the latest and greatest as well - assuming you didn't
make any manual configuration changes to /etc/postfix/ldap/*.cf files,
this should be fine.

One could also run `setup-kolab roundcube` for its configuration to be
updated, but one will;

- One will need to know the MySQL root password and MySQL roundcube
password, and specify those exactly as they are,
- Get an error on the attempt to create the database,
- Get an error during the attempt(s) to create the tables in the
database,

and one might want to double-check whether any of the MySQL schema
upgrade files still need to be applied separately (list them with rpm
-ql roundcubemail roundcubemail-plugins-kolab | grep sql)

Post by de Raad, Hans
Would there perhaps also be an option 3? Using kolab migrate tools for
this excersize to a new clean installation?

No data migration is needed for an upgrade of Kolab 3.0 to Kolab 3.1. We
intend to stick to a mantra of minor version number bumps only requiring
(perhaps) configuration changes and updates, and bump the major version
number component for LDAP schema upgrades, format converstions, and
such.

Kind regards,

Jeroen van Meeuwen

[de Raad, Hans]

Hi Jeroen,

thanks again for the clarifications, might i try a quick summary?
This to try and find the cleanest possible upgrade path.

1. Upgrade all packages to the devel version
2. Run setup-kolab imap
2.1 Remove squatter:
http://hosted.kolabsys.com/~vanmeeuwen/build/html/administrator-guide/upgrading-from-kolab-3.0.html#the-use-of-squatter
3. Run setup-kolab mta
4. Run setup-kolab roundcube
4.1 Dont be scared of errors about already existing databases
(improvement might be possible here?)
4.2 Manually check schema updates (improvement might be possible here?)
rpm -ql roundcubemail roundcubemail-plugins-kolab | grep sql

And by now one would run 3.1?

If this is the case, i'd like to offer to create an update script
performing these steps.

All the best!

Hans de Raad

---

DevHdR
onderdeel van HaLeNaS v.o.f.

Van Sevenbergestraat 49
2274 PK Voorburg

KvK: 53493753

Tel: [phone]

www.hcderaad.nl

[Jeroen van Meeuwen (Kolab Systems)]

Post by de Raad, Hans
Hi Jeroen,
thanks again for the clarifications, might i try a quick summary?
This to try and find the cleanest possible upgrade path.
1. Upgrade all packages to the devel version
2. Run setup-kolab imap
http://hosted.kolabsys.com/~vanmeeuwen/build/html/administrator-guide/upgrading-from-kolab-3.0.html#the-use-of-squatter
3. Run setup-kolab mta
4. Run setup-kolab roundcube
4.1 Dont be scared of errors about already existing databases
(improvement might be possible here?)
4.2 Manually check schema updates (improvement might be possible here?)
rpm -ql roundcubemail roundcubemail-plugins-kolab | grep sql
And by now one would run 3.1?
If this is the case, i'd like to offer to create an update script
performing these steps.

That would be great, I would appreciate notes and feedback on what else
may need to happen for an upgrade process.

That said, if we start to iterate over the things we might look at
doing;

- check and optionally prepare various aspects of the system, and
- setup components (all of them or part of them), and
- update / upgrade components,

we might want to start looking at how useful the current setup-kolab.py
is exactly. Additionally I can add to this list;

- a functioning '--yes' that just walks through the preparations and
setup with default values,
- a functioning '--demo' that seeds some sample data in to the
environment,
- a variety of options along the lines of: --with-ldap=openldap,
--with-imap=dovecot, --with-sql=postgres.

So perhaps it is time to design all of that properly.

Kind regards,

Jeroen van Meeuwen