Discussion:
Status of GUAM and TLS>1.1 ?
Matthias Busch
2018-08-10 15:57:33 UTC
Permalink
Good day,

I've seen that the big guam bug (client buffers/split command) was fixed
some time ago and I could unfreeze the 0.8.3 version.

Unfortunately, GUAM still seems unable to do TLS1.2 - which means, I'm
still stuck on Thunderbird 45.8 - or need to set
security.tls.version.max = 2

At least it does start with TLS1.2 in the config.
With TLS1.3 in the config, it doesnt. Although I am not 100% certain
that my assumption how to try was correct.


So, if anyone knows, is there working TLS1.2 out there?
Is 1.3 on the horizon?

I can post my guam config if 1.2 should work with thunderbird. Maybe I
have a problem in the config.
I also can post logs.
(Please note that it may take some time to post though)

Thanks in advance
Catwiesel

PS: Thanks for the hard work on guam, Jeroen and Christoph!
Vuorikoski, Jupiter
2018-08-10 17:42:40 UTC
Permalink
_______________________________________________
users mailing list
***@lists.kolab.org
https://lists.kolab.org/mailman/listinfo/users
Christoph Erhardt
2018-08-15 12:39:49 UTC
Permalink
Hi Matthias,

this might be a limitation of the Erlang SSL library shipped with your
distribution. If I remember correctly, I had a similar problem with Guam on
Debian Jessie that went away after I upgraded to Stretch.

Cheers,
Christoph
Post by Matthias Busch
Good day,
I've seen that the big guam bug (client buffers/split command) was fixed
some time ago and I could unfreeze the 0.8.3 version.
Unfortunately, GUAM still seems unable to do TLS1.2 - which means, I'm
still stuck on Thunderbird 45.8 - or need to set
security.tls.version.max = 2
At least it does start with TLS1.2 in the config.
With TLS1.3 in the config, it doesnt. Although I am not 100% certain
that my assumption how to try was correct.
So, if anyone knows, is there working TLS1.2 out there?
Is 1.3 on the horizon?
I can post my guam config if 1.2 should work with thunderbird. Maybe I
have a problem in the config.
I also can post logs.
(Please note that it may take some time to post though)
Thanks in advance
Catwiesel
PS: Thanks for the hard work on guam, Jeroen and Christoph!
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users
Matthias Busch
2018-09-04 10:26:12 UTC
Permalink
this is quite valuable information. many thanks.

how stable is kolab 16 on stretch?
do I just change debian apt/sources to stretch and run dist-upgrade?

I just saw, documentation now has debian9 too...

What process do you recommend to upgrade from kolab 16 on deb8 to deb9?

change only debian or only kolab or both apt sources?
run apt-get upgrade or dist-upgrade between what changes?

(usually, I change all apt sources, run upgrade, then dist-upgrade)
Christoph Erhardt
2018-09-04 10:49:23 UTC
Permalink
Hi Matthias,

in my experience, Kolab 16 is just as stable on Debian Stretch as it is on
Jessie.

To upgrade, you typically change all APT sources, then run "apt dist-upgrade".
Some manual intervention may be required afterwards: for instance, you may
have to make sure that all PHP 5 packages are upgraded to their PHP 7
counterparts. That involves a bit of fumbling, but no rocket science. Should
any questions arise in the process, feel free to ask them here or on IRC.

For obvious reasons, I recommend creating a full backup before the upgrade.

Best regards,
Christoph
Post by Matthias Busch
this is quite valuable information. many thanks.
how stable is kolab 16 on stretch?
do I just change debian apt/sources to stretch and run dist-upgrade?
I just saw, documentation now has debian9 too...
What process do you recommend to upgrade from kolab 16 on deb8 to deb9?
change only debian or only kolab or both apt sources?
run apt-get upgrade or dist-upgrade between what changes?
(usually, I change all apt sources, run upgrade, then dist-upgrade)
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users
Matthias Busch
2018-09-04 12:14:21 UTC
Permalink
Post by Christoph Erhardt
For obvious reasons, I recommend creating a full backup before the upgrade.
never! waste of time and space!
kidding. of course, having a full backup before attempting an update goes without saying.


I will attempt the update when I have a bit more time to deal with problems that may arise due to updating.
we'll see about any neccesary manual intervention. I am indeed worried that it may cause me headaches...

again, thanks for your help!
Matthias Busch
2018-09-05 09:22:39 UTC
Permalink
reading this I got a massive flashback to my switch from debian7 to debian8

where I decided to do a fresh install and migration of data.

If Christoph can just dist-upgrade and it works, and you get a kolab
suicide, there must be a difference in method?
maybe if you only use dist-upgrade without upgrade?

I dont think removing kolab is a sensible step, even if one might
believe that it will be reinstalled later...
it is possible, but man, do I not want to even try that...
Post by Christoph Erhardt
Post by Christoph Erhardt
Hi Matthias,
in my experience, Kolab 16 is just as stable on Debian Stretch as it
is on
Post by Christoph Erhardt
Jessie.
To upgrade, you typically change all APT sources, then run "apt
dist-upgrade". Some manual intervention may be required afterwards: for
instance, you may have to make sure that all PHP 5 packages are
upgraded to
Post by Christoph Erhardt
their PHP 7 counterparts. That involves a bit of fumbling, but no rocket
science. Should any questions arise in the process, feel free to ask
them
Post by Christoph Erhardt
here or on IRC.
I will gladly take this opportunity to ask here: I changed my APT
sources (both for debian and for kolab) to stretch / Debian 9.0, took
the usual precautions and started the upgrade. After the minimal
upgrade with apt-get upgrade two times which went fine and upgraded a
lot of packages, I get
lists... Done Building dependency tree Reading state information...
Done Calculating upgrade... The following packages were automatically
installed and are no longer required: 389-admin 389-admin-console
389-console 389-ds 389-ds-base 389-ds-base-libs ...
sa-compile sane-utils smarty3 socat spamassassin spamc update-inetd
wallace zendframework Use 'apt-get autoremove' to remove them. Done
The following packages will be REMOVED: chwala erlang-webtool irony
kolab kolab-webclient libcwidget3 libnss3-1d libpcrecpp0 libperl5.20
libproxy1 libpython3.4-minimal libpython3.4-stdlib libreadline6-dev
libsigc++-2.0-0c2a libwxbase3.0-0 libwxgtk3.0-0 mysql-client-5.5
mysql-server-5.5 mysql-server-core-5.5 perl-modules php-sabre-dav-2.1
python3.4 python3.4-minimal The following NEW packages will be
installed: ca-certificates-java default-java-plugin default-jre
default-jre-headless
...
r-cran-survival r-recommended re2c reportbug 129 upgraded, 94 newly
installed, 23 to remove and 0 not upgraded. Need to get 237 MB/240 MB
of archives. After this operation, 633 MB of additional disk space
will be used. Do you want to continue? [Y/n]
I am not sure I want to remove kolab, kolab-webclient, chwala and
irony in the process, if they get removed it must be for some
dependency problem, so I am not sure I will be able to reinstall them
afterwards. Any thoughts on this?
Johannes
Post by Christoph Erhardt
For obvious reasons, I recommend creating a full backup before the
upgrade.
Post by Christoph Erhardt
Best regards,
Christoph
Post by Matthias Busch
this is quite valuable information. many thanks.
how stable is kolab 16 on stretch?
do I just change debian apt/sources to stretch and run dist-upgrade?
I just saw, documentation now has debian9 too...
What process do you recommend to upgrade from kolab 16 on deb8 to
deb9?
Post by Christoph Erhardt
Post by Matthias Busch
change only debian or only kolab or both apt sources?
run apt-get upgrade or dist-upgrade between what changes?
(usually, I change all apt sources, run upgrade, then dist-upgrade)
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users
Christoph Erhardt
2018-09-05 10:16:02 UTC
Permalink
Hi Johannes,

yep, that's the "bit of fumbling" I was referring to. ;-)

APT wants to remove iRony because not all of its dependencies can be satisfied
automatically due to the migration from PHP 5 to 7. The best way I found to
resolve this is to let APT temporarily have its way, then fix the dependencies
afterwards. As the packages are only removed, not purged, you won't lose any
data.

What I did on my box was the following series of steps:

1. Double check that all important data is backed up and can be restored.
2. Do the dist-upgrade and allow it to remove iRony for now.
3. Reboot.
4. Replace all installed php5-* packages with their php-* counterparts.
5. Install the Kolab meta-package again.
6. Make sure that the Kolab PHP modules are activated.

Best regards,
Christoph
I will gladly take this opportunity to ask here: I changed my APT sources
(both for debian and for kolab) to stretch / Debian 9.0, took the usual
precautions and started the upgrade. After the minimal upgrade with apt-get
upgrade two times which went fine and upgraded a lot of packages, I get
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically installed
389-admin 389-admin-console 389-console 389-ds 389-ds-base 389-ds-base-libs
...
sa-compile sane-utils smarty3 socat spamassassin spamc update-inetd wallace
zendframework
Use 'apt-get autoremove' to remove them.
Done
chwala erlang-webtool irony kolab kolab-webclient libcwidget3 libnss3-1d
libpcrecpp0 libperl5.20 libproxy1 libpython3.4-minimal libpython3.4-stdlib
libreadline6-dev
libsigc++-2.0-0c2a libwxbase3.0-0 libwxgtk3.0-0 mysql-client-5.5 mysql-
server-5.5 mysql-server-core-5.5 perl-modules php-sabre-dav-2.1 python3.4
python3.4-minimal
ca-certificates-java default-java-plugin default-jre default-jre-headless
...
r-cran-survival r-recommended re2c reportbug
129 upgraded, 94 newly installed, 23 to remove and 0 not upgraded.
Need to get 237 MB/240 MB of archives.
After this operation, 633 MB of additional disk space will be used.
Do you want to continue? [Y/n]
I am not sure I want to remove kolab, kolab-webclient, chwala and irony in
the process, if they get removed it must be for some dependency problem, so
I am not sure I will be able to reinstall them afterwards. Any thoughts on
this?
Johannes
Johannes Ranke
2018-09-05 10:39:01 UTC
Permalink
Hi Christoph,

thanks for your reply - my diagnosis of the problem gave a different reason
for the problems, see the other mail...

Thanks for the heads-up anyways! Without your success report I would have put
this off even longer. Now, after the successful upgrade, I feel I am much more
ready for the future!

Cheers,

Johannes
Post by Christoph Erhardt
Hi Johannes,
yep, that's the "bit of fumbling" I was referring to. ;-)
APT wants to remove iRony because not all of its dependencies can be
satisfied automatically due to the migration from PHP 5 to 7. The best way
I found to resolve this is to let APT temporarily have its way, then fix
the dependencies afterwards. As the packages are only removed, not purged,
you won't lose any data.
1. Double check that all important data is backed up and can be restored.
2. Do the dist-upgrade and allow it to remove iRony for now.
3. Reboot.
4. Replace all installed php5-* packages with their php-* counterparts.
5. Install the Kolab meta-package again.
6. Make sure that the Kolab PHP modules are activated.
Best regards,
Christoph
I will gladly take this opportunity to ask here: I changed my APT sources
(both for debian and for kolab) to stretch / Debian 9.0, took the usual
precautions and started the upgrade. After the minimal upgrade with apt-get
upgrade two times which went fine and upgraded a lot of packages, I get
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically installed
389-admin 389-admin-console 389-console 389-ds 389-ds-base
389-ds-base-libs
...
sa-compile sane-utils smarty3 socat spamassassin spamc update-inetd wallace
zendframework
Use 'apt-get autoremove' to remove them.
Done
chwala erlang-webtool irony kolab kolab-webclient libcwidget3 libnss3-1d
libpcrecpp0 libperl5.20 libproxy1 libpython3.4-minimal libpython3.4-stdlib
libreadline6-dev
libsigc++-2.0-0c2a libwxbase3.0-0 libwxgtk3.0-0 mysql-client-5.5 mysql-
server-5.5 mysql-server-core-5.5 perl-modules php-sabre-dav-2.1 python3.4
python3.4-minimal
ca-certificates-java default-java-plugin default-jre default-jre-headless
...
r-cran-survival r-recommended re2c reportbug
129 upgraded, 94 newly installed, 23 to remove and 0 not upgraded.
Need to get 237 MB/240 MB of archives.
After this operation, 633 MB of additional disk space will be used.
Do you want to continue? [Y/n]
I am not sure I want to remove kolab, kolab-webclient, chwala and irony in
the process, if they get removed it must be for some dependency problem, so
I am not sure I will be able to reinstall them afterwards. Any thoughts on
this?
Johannes
--
PD Dr. Johannes Ranke
Grenzach-Wyhlen
Johannes Ranke
2018-09-05 10:36:40 UTC
Permalink
Dear all,

I found a solution without having to temporarily remove kolab:

I had a look at what aptitude dist-upgrade proposed, and then did

apt-install default-mysql-client default-mysql-server

which was a step in the right direction. Now aptitude dist-upgrade proposed to
remove cyrus-imapd. This made me wonder how this could be, so I checked

***@kolab:~# apt-cache policy cyrus-imapd
cyrus-imapd:
Installed: 2.5.11.41-0~kolab2
Candidate: 2.5.11.41-0~kolab2
Version table:
2.5.11.41-0~kolab2 501
501 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./
Packages
*** 2.5.11.41-0~kolab2 100
100 /var/lib/dpkg/status
2.5.10-3 500
500 http://mirror.hetzner.de/debian/packages stretch/main amd64
Packages
500 http://http.debian.net/debian stretch/main amd64 Packages

which made me suspect that two different versions of this package exist that
have the exact same version string, and in fact there are some subtle
differences e.g. in the Depends (look for libpci3 for example).

***@kolab:~# apt-cache show cyrus-imapd
Package: cyrus-imapd
Version: 2.5.11.41-0~kolab2
Architecture: amd64
Maintainer: Jeroen van Meeuwen (Kolab Systems) <***@kolabsys.com>
Installed-Size: 4591
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>> 1.9.0),
netbase (>= 4.07), gawk, libc6 (>= 2.14), libcomerr2 (>= 1.01), libdb5.3,
libjansson4 (>= 2.
0.1), libldap-2.4-2 (>= 2.4.7), libpci3 (>= 1:3.5.2-1), libpcre3, libsasl2-2,
libsensors4 (>= 1:3.0.0), libsnmp30 (>= 5.7.3+dfsg-1.7~dfsg), libssl1.1 (>=
1.1.0), libwrap
0 (>= 7.6-4~), libzephyr4, perl (>= 5.24.1-3+deb9u4), perlapi-5.24.1
Suggests: sasl2-bin, apt-listchanges (>= 2.35)

...

standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36

Package: cyrus-imapd
Status: install ok installed
Priority: extra
Section: mail
Installed-Size: 4371
Maintainer: Jeroen van Meeuwen (Kolab Systems) <***@kolabsys.com>
Architecture: amd64
Version: 2.5.11.41-0~kolab2
Replaces: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common, cyrus22-imapd,
cyrus23-common, cyrus23
-imapd, cyrus24-common, cyrus24-imapd
Provides: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common, cyrus23-common,
cyrus24-common, imap-s
erver, pop3-server
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>> 1.9.0),
netbase (>= 4.07), gawk, libasn1-8-heimdal (>= 1.4.0+git20110226), libc6 (>=
2.14), libcomer
r2 (>= 1.01), libdb5.3, libgssapi3-heimdal (>= 1.4.0+git20110226), libjansson4
(>= 2.0.1), libkrb5-26-heimdal (>= 1.4.0+git20110226), libldap-2.4-2 (>=
2.4.7), libpci3 (
= 1:3.2.1-1), libpcre3 (>= 1:8.35), libroken18-heimdal (>=
1.4.0+git20110226), libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>=
5.7.2.1+dfsg-1+deb8u1+b1~dfsg), libss
l1.0.0 (>= 1.0.0), libwrap0 (>= 7.6-4~), libzephyr4, perl (>=
5.20.2-3+deb8u11), perlapi-5.20.2

...

standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Homepage: http://www.cyrusimap.org/

So I went ahead and did an apt install cyrus-imapd, which (not sure why)
updated to the newer version with the same version name. Then some more
dependency digging told me that I have to downgrade php-sabre-dav-2.1 from
version 2.1.11-1 (not sure where this came from, I think from kolabsys) to
version 2.10-1 from Debian stretch:

apt install php-sabre-dav-2.1/stretch

and voilá - the dist-upgrade succeeded without removing kolab!

Cheers,

Johannes

P.S.: I do think that this could at least partially have been avoided if the
version string in the Debian 9 repo would be always different from the version
string in the Debian 8 repo. For example, for my R backports repositories on
CRAN, I always append ~stretchcran.0 to the version string for backports to
stretch, and ~jessiecran.0 for backports to jessie. Here ~kolab2 was used for
both repositories.
Hi Matthias,
in my experience, Kolab 16 is just as stable on Debian Stretch as it is on
Jessie.
To upgrade, you typically change all APT sources, then run "apt
dist-upgrade". Some manual intervention may be required afterwards: for
instance, you may have to make sure that all PHP 5 packages are upgraded to
their PHP 7 counterparts. That involves a bit of fumbling, but no rocket
science. Should any questions arise in the process, feel free to ask them
here or on IRC.
I will gladly take this opportunity to ask here: I changed my APT sources
(both for debian and for kolab) to stretch / Debian 9.0, took the usual
precautions and started the upgrade. After the minimal upgrade with apt-get
upgrade two times which went fine and upgraded a lot of packages, I get

***@kolab:/etc/apt/apt.conf.d# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically installed and
are no longer required:
389-admin 389-admin-console 389-console 389-ds 389-ds-base 389-ds-base-libs

...

sa-compile sane-utils smarty3 socat spamassassin spamc update-inetd wallace
zendframework
Use 'apt-get autoremove' to remove them.
Done
The following packages will be REMOVED:
chwala erlang-webtool irony kolab kolab-webclient libcwidget3 libnss3-1d
libpcrecpp0 libperl5.20 libproxy1 libpython3.4-minimal libpython3.4-stdlib
libreadline6-dev
libsigc++-2.0-0c2a libwxbase3.0-0 libwxgtk3.0-0 mysql-client-5.5 mysql-
server-5.5 mysql-server-core-5.5 perl-modules php-sabre-dav-2.1 python3.4
python3.4-minimal
The following NEW packages will be installed:
ca-certificates-java default-java-plugin default-jre default-jre-headless

...

r-cran-survival r-recommended re2c reportbug
129 upgraded, 94 newly installed, 23 to remove and 0 not upgraded.
Need to get 237 MB/240 MB of archives.
After this operation, 633 MB of additional disk space will be used.
Do you want to continue? [Y/n]

I am not sure I want to remove kolab, kolab-webclient, chwala and irony in the
process, if they get removed it must be for some dependency problem, so I am
not sure I will be able to reinstall them afterwards. Any thoughts on this?

Johannes
For obvious reasons, I recommend creating a full backup before the upgrade.
Best regards,
Christoph
Post by Matthias Busch
this is quite valuable information. many thanks.
how stable is kolab 16 on stretch?
do I just change debian apt/sources to stretch and run dist-upgrade?
I just saw, documentation now has debian9 too...
What process do you recommend to upgrade from kolab 16 on deb8 to deb9?
change only debian or only kolab or both apt sources?
run apt-get upgrade or dist-upgrade between what changes?
(usually, I change all apt sources, run upgrade, then dist-upgrade)
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users
--
PD Dr. Johannes Ranke
Grenzach-Wyhlen
Christoph Erhardt
2018-09-05 11:08:22 UTC
Permalink
Hi Johannes,

glad you got it to work! Now that you mentioned it, I remember these two
additional pitfalls as well. I upgraded my system back in May and regretfully
failed to take notes. ;-)

Did the upgrade from PHP 5 to 7, including all PHP packages, work without any
manual intervention? I definitely had to hand-pick the php-* packages when I
migrated my system to Stretch.

I agree that some kind of distribution suffix would be helpful in the case of
the cyrus-imapd package. Unfortunately, I believe it's not trivial to do that
because all .deb packages are built from the exact same sources:
https://obs.kolabsys.com/package/show/Kolab:16/cyrus-imapd

That said, allow me to argue that upgrading the underlying distro is neither
officially documented nor officially supported - it's a best-effort thing. We
try our best not to actively break things, but the faint-hearted are probably
better off with the "back up -> install cleanly -> restore" routine. :-)

Best regards,
Christoph
Post by Johannes Ranke
Dear all,
I had a look at what aptitude dist-upgrade proposed, and then did
apt-install default-mysql-client default-mysql-server
which was a step in the right direction. Now aptitude dist-upgrade proposed
to remove cyrus-imapd. This made me wonder how this could be, so I checked
Installed: 2.5.11.41-0~kolab2
Candidate: 2.5.11.41-0~kolab2
2.5.11.41-0~kolab2 501
501 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./
Packages
*** 2.5.11.41-0~kolab2 100
100 /var/lib/dpkg/status
2.5.10-3 500
500 http://mirror.hetzner.de/debian/packages stretch/main amd64
Packages
500 http://http.debian.net/debian stretch/main amd64 Packages
which made me suspect that two different versions of this package exist that
have the exact same version string, and in fact there are some subtle
differences e.g. in the Depends (look for libpci3 for example).
Package: cyrus-imapd
Version: 2.5.11.41-0~kolab2
Architecture: amd64
Installed-Size: 4591
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>> 1.9.0),
netbase (>= 4.07), gawk, libc6 (>= 2.14), libcomerr2 (>= 1.01), libdb5.3,
libjansson4 (>= 2.
0.1), libldap-2.4-2 (>= 2.4.7), libpci3 (>= 1:3.5.2-1), libpcre3,
libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>= 5.7.3+dfsg-1.7~dfsg),
libssl1.1 (>= 1.1.0), libwrap
0 (>= 7.6-4~), libzephyr4, perl (>= 5.24.1-3+deb9u4), perlapi-5.24.1
Suggests: sasl2-bin, apt-listchanges (>= 2.35)
...
standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Package: cyrus-imapd
Status: install ok installed
Priority: extra
Section: mail
Installed-Size: 4371
Architecture: amd64
Version: 2.5.11.41-0~kolab2
Replaces: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common, cyrus22-imapd,
cyrus23-common, cyrus23
-imapd, cyrus24-common, cyrus24-imapd
Provides: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common, cyrus23-common,
cyrus24-common, imap-s
erver, pop3-server
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>> 1.9.0),
netbase (>= 4.07), gawk, libasn1-8-heimdal (>= 1.4.0+git20110226), libc6
(>= 2.14), libcomer
r2 (>= 1.01), libdb5.3, libgssapi3-heimdal (>= 1.4.0+git20110226),
libjansson4 (>= 2.0.1), libkrb5-26-heimdal (>= 1.4.0+git20110226),
libldap-2.4-2 (>= 2.4.7), libpci3 (
= 1:3.2.1-1), libpcre3 (>= 1:8.35), libroken18-heimdal (>=
1.4.0+git20110226), libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>=
5.7.2.1+dfsg-1+deb8u1+b1~dfsg), libss
l1.0.0 (>= 1.0.0), libwrap0 (>= 7.6-4~), libzephyr4, perl (>=
5.20.2-3+deb8u11), perlapi-5.20.2
...
standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Homepage: http://www.cyrusimap.org/
So I went ahead and did an apt install cyrus-imapd, which (not sure why)
updated to the newer version with the same version name. Then some more
dependency digging told me that I have to downgrade php-sabre-dav-2.1 from
version 2.1.11-1 (not sure where this came from, I think from kolabsys) to
apt install php-sabre-dav-2.1/stretch
and voilá - the dist-upgrade succeeded without removing kolab!
Cheers,
Johannes
P.S.: I do think that this could at least partially have been avoided if the
version string in the Debian 9 repo would be always different from the
version string in the Debian 8 repo. For example, for my R backports
repositories on CRAN, I always append ~stretchcran.0 to the version string
for backports to stretch, and ~jessiecran.0 for backports to jessie. Here
~kolab2 was used for both repositories.
Johannes Ranke
2018-09-13 10:48:50 UTC
Permalink
Hi Christoph,
Post by Christoph Erhardt
Hi Johannes,
glad you got it to work! Now that you mentioned it, I remember these two
additional pitfalls as well. I upgraded my system back in May and
regretfully failed to take notes. ;-)
Did the upgrade from PHP 5 to 7, including all PHP packages, work without
any manual intervention? I definitely had to hand-pick the php-* packages
when I migrated my system to Stretch.
well, I just hadn't noticed that iRony wasn't working... I did have to replace
the packages listed by dpkg --get-selections | grep php5 by their php7
counterparts, and install the php7 apache module. In the process, my apache
php module got disabled, so I had to a2enmod php7.0 and now the kolab modules
are loaded when apache2 starts. For reference, the error message I got in /
var/log/iRony/errors was

[13-Sep-2018 11:50:03 Europe/Berlin] PHP Fatal error: Call to undefined
function dl() in /usr/share/php/kolabformat.php on line 22

which was triggered because the php kolab modules were not loaded.

Also, /usr/lib/php5/sessionclean had spammed my ***@kolab-box mail account
whith error messages about '/usr/lib/php5/20131226/kolabformat.so' and others
which could not be loaded.

I think everything works now...

Cheers,

Johannes
Post by Christoph Erhardt
I agree that some kind of distribution suffix would be helpful in the case
of the cyrus-imapd package. Unfortunately, I believe it's not trivial to do
https://obs.kolabsys.com/package/show/Kolab:16/cyrus-imapd
That said, allow me to argue that upgrading the underlying distro is neither
officially documented nor officially supported - it's a best-effort thing.
We try our best not to actively break things, but the faint-hearted are
probably better off with the "back up -> install cleanly -> restore"
routine. :-)
Best regards,
Christoph
Post by Johannes Ranke
Dear all,
I had a look at what aptitude dist-upgrade proposed, and then did
apt-install default-mysql-client default-mysql-server
which was a step in the right direction. Now aptitude dist-upgrade proposed
to remove cyrus-imapd. This made me wonder how this could be, so I checked
Installed: 2.5.11.41-0~kolab2
Candidate: 2.5.11.41-0~kolab2
2.5.11.41-0~kolab2 501
501 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./
Packages
*** 2.5.11.41-0~kolab2 100
100 /var/lib/dpkg/status
2.5.10-3 500
500 http://mirror.hetzner.de/debian/packages stretch/main amd64
Packages
500 http://http.debian.net/debian stretch/main amd64 Packages
which made me suspect that two different versions of this package exist
that have the exact same version string, and in fact there are some
subtle differences e.g. in the Depends (look for libpci3 for example).
Package: cyrus-imapd
Version: 2.5.11.41-0~kolab2
Architecture: amd64
Installed-Size: 4591
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>>
1.9.0), netbase (>= 4.07), gawk, libc6 (>= 2.14), libcomerr2 (>= 1.01),
libdb5.3, libjansson4 (>= 2.
0.1), libldap-2.4-2 (>= 2.4.7), libpci3 (>= 1:3.5.2-1), libpcre3,
libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>= 5.7.3+dfsg-1.7~dfsg),
libssl1.1 (>= 1.1.0), libwrap
0 (>= 7.6-4~), libzephyr4, perl (>= 5.24.1-3+deb9u4), perlapi-5.24.1
Suggests: sasl2-bin, apt-listchanges (>= 2.35)
...
standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Package: cyrus-imapd
Status: install ok installed
Priority: extra
Section: mail
Installed-Size: 4371
Architecture: amd64
Version: 2.5.11.41-0~kolab2
Replaces: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common,
cyrus22-imapd,
cyrus23-common, cyrus23
-imapd, cyrus24-common, cyrus24-imapd
Provides: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common,
cyrus23-common, cyrus24-common, imap-s
erver, pop3-server
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>>
1.9.0), netbase (>= 4.07), gawk, libasn1-8-heimdal (>=
1.4.0+git20110226), libc6 (>= 2.14), libcomer
r2 (>= 1.01), libdb5.3, libgssapi3-heimdal (>= 1.4.0+git20110226),
libjansson4 (>= 2.0.1), libkrb5-26-heimdal (>= 1.4.0+git20110226),
libldap-2.4-2 (>= 2.4.7), libpci3 (
= 1:3.2.1-1), libpcre3 (>= 1:8.35), libroken18-heimdal (>=
1.4.0+git20110226), libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>=
5.7.2.1+dfsg-1+deb8u1+b1~dfsg), libss
l1.0.0 (>= 1.0.0), libwrap0 (>= 7.6-4~), libzephyr4, perl (>=
5.20.2-3+deb8u11), perlapi-5.20.2
...
standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Homepage: http://www.cyrusimap.org/
So I went ahead and did an apt install cyrus-imapd, which (not sure why)
updated to the newer version with the same version name. Then some more
dependency digging told me that I have to downgrade php-sabre-dav-2.1 from
version 2.1.11-1 (not sure where this came from, I think from kolabsys) to
apt install php-sabre-dav-2.1/stretch
and voilá - the dist-upgrade succeeded without removing kolab!
Cheers,
Johannes
P.S.: I do think that this could at least partially have been avoided if
the version string in the Debian 9 repo would be always different from
the version string in the Debian 8 repo. For example, for my R backports
repositories on CRAN, I always append ~stretchcran.0 to the version
string for backports to stretch, and ~jessiecran.0 for backports to
jessie. Here ~kolab2 was used for both repositories.
--
PD Dr. Johannes Ranke
Grenzach-Wyhlen
Johannes Ranke
2018-09-13 16:18:26 UTC
Permalink
Also, /usr/lib/php5/sessionclean had spammed my ***@kolab-box mail account
whith error messages about '/usr/lib/php5/20131226/kolabformat.so' and others
which could not be loaded.

I had to move /etc/php5/apache2/php.ini out of the way in order to stop the
spam from /usr/lib/sessionclean.

Cheers, Johannes



I think everything works now...

Cheers,

Johannes
Post by Christoph Erhardt
I agree that some kind of distribution suffix would be helpful in the case
of the cyrus-imapd package. Unfortunately, I believe it's not trivial to do
https://obs.kolabsys.com/package/show/Kolab:16/cyrus-imapd
That said, allow me to argue that upgrading the underlying distro is neither
officially documented nor officially supported - it's a best-effort thing.
We try our best not to actively break things, but the faint-hearted are
probably better off with the "back up -> install cleanly -> restore"
routine. :-)
Best regards,
Christoph
Post by Johannes Ranke
Dear all,
I had a look at what aptitude dist-upgrade proposed, and then did
apt-install default-mysql-client default-mysql-server
which was a step in the right direction. Now aptitude dist-upgrade proposed
to remove cyrus-imapd. This made me wonder how this could be, so I checked
Installed: 2.5.11.41-0~kolab2
Candidate: 2.5.11.41-0~kolab2
2.5.11.41-0~kolab2 501
501 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./
Packages
*** 2.5.11.41-0~kolab2 100
100 /var/lib/dpkg/status
2.5.10-3 500
500 http://mirror.hetzner.de/debian/packages stretch/main amd64
Packages
500 http://http.debian.net/debian stretch/main amd64 Packages
which made me suspect that two different versions of this package exist
that have the exact same version string, and in fact there are some
subtle differences e.g. in the Depends (look for libpci3 for example).
Package: cyrus-imapd
Version: 2.5.11.41-0~kolab2
Architecture: amd64
Installed-Size: 4591
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>>
1.9.0), netbase (>= 4.07), gawk, libc6 (>= 2.14), libcomerr2 (>= 1.01),
libdb5.3, libjansson4 (>= 2.
0.1), libldap-2.4-2 (>= 2.4.7), libpci3 (>= 1:3.5.2-1), libpcre3,
libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>= 5.7.3+dfsg-1.7~dfsg),
libssl1.1 (>= 1.1.0), libwrap
0 (>= 7.6-4~), libzephyr4, perl (>= 5.24.1-3+deb9u4), perlapi-5.24.1
Suggests: sasl2-bin, apt-listchanges (>= 2.35)
...
standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Package: cyrus-imapd
Status: install ok installed
Priority: extra
Section: mail
Installed-Size: 4371
Architecture: amd64
Version: 2.5.11.41-0~kolab2
Replaces: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common,
cyrus22-imapd,
cyrus23-common, cyrus23
-imapd, cyrus24-common, cyrus24-imapd
Provides: cyrus-common-2.2, cyrus-common-2.3, cyrus-common-2.4, cyrus-
imapd-2.2, cyrus-imapd-2.3, cyrus-imapd-2.4, cyrus22-common,
cyrus23-common, cyrus24-common, imap-s
erver, pop3-server
Depends: postfix | mail-transport-agent, adduser (>= 3.34), dpkg (>>
1.9.0), netbase (>= 4.07), gawk, libasn1-8-heimdal (>=
1.4.0+git20110226), libc6 (>= 2.14), libcomer
r2 (>= 1.01), libdb5.3, libgssapi3-heimdal (>= 1.4.0+git20110226),
libjansson4 (>= 2.0.1), libkrb5-26-heimdal (>= 1.4.0+git20110226),
libldap-2.4-2 (>= 2.4.7), libpci3 (
= 1:3.2.1-1), libpcre3 (>= 1:8.35), libroken18-heimdal (>=
1.4.0+git20110226), libsasl2-2, libsensors4 (>= 1:3.0.0), libsnmp30 (>=
5.7.2.1+dfsg-1+deb8u1+b1~dfsg), libss
l1.0.0 (>= 1.0.0), libwrap0 (>= 7.6-4~), libzephyr4, perl (>=
5.20.2-3+deb8u11), perlapi-5.20.2
...
standard mail spool. It stores mail in a separate directory in its
own MH-like format.
Description-md5: 784eb5fed1d37ab067b173ecc415ee36
Homepage: http://www.cyrusimap.org/
So I went ahead and did an apt install cyrus-imapd, which (not sure why)
updated to the newer version with the same version name. Then some more
dependency digging told me that I have to downgrade php-sabre-dav-2.1 from
version 2.1.11-1 (not sure where this came from, I think from kolabsys) to
apt install php-sabre-dav-2.1/stretch
and voilá - the dist-upgrade succeeded without removing kolab!
Cheers,
Johannes
P.S.: I do think that this could at least partially have been avoided if
the version string in the Debian 9 repo would be always different from
the version string in the Debian 8 repo. For example, for my R backports
repositories on CRAN, I always append ~stretchcran.0 to the version
string for backports to stretch, and ~jessiecran.0 for backports to
jessie. Here ~kolab2 was used for both repositories.
--
PD Dr. Johannes Ranke
Grenzach-Wyhlen
Loading...