It seems that the version number for packaging needs to be increased at some slope rider point now.

Current git version gives the full error:

I guess the version number for packaging needs to be bumped somewhere now.

docs.kolab.org was built from this repository: https://git.kolab.org/diffusion/D/ (which should be the same as the github one, but if in question git.kolab.org is the up-to-date version).

There where many documents

• Howtos
• Admin and Developer Guids
• Kolab Architecture

Fixed in master of kolab-webadmin and kolab-net-ldap3.

I'm not sure about this since we have Knowledge Base. https://kb.kolab.org/2023/03/install-kolab-16-on-alma-linux-9/

I would just remove the _debug() call.

So the 389-ds packages are a mess in Ubuntu. The tools and scripts needed to update the on disk formats are not built and when I enable them they are broken. I am not sure if the upstream source is broken or it comes from the patches applied by Debian or Ubuntu. The only thing that I found worked was moving the contents of /var/lib/dirsrv and /etc/dirsrv to a backup, then upgrade from 18.04 to 20.04 and return the contents before rebooting. There were several other hiccups in the process as kolab packaging for Ubuntu newer than 18.04 is broken and missing packages, see: https://git.kolab.org/T8416

On our server ipv6 was disabled in the kernel. Enabling ipv6 did resolve the crash of guam

I also see crashes of guam on AlmaLinux release 9.5 (Teal Serval)
I tested with I guam-0.9.13-3.61.el9.kolab_16.x86_64

Patch merged.

This patch fixes the login for me - thanks a lot.

Maybe something like this would help:

diff --git a/lib/Auth/LDAP.php b/lib/Auth/LDAP.php
index f5e33b2..2db826e 100644
--- a/lib/Auth/LDAP.php
+++ b/lib/Auth/LDAP.php
@@ -122,6 +122,12 @@ class LDAP extends Net_LDAP3 {
         $this->config_set("root_dn", $root_dn);
     }

php-net-ldap3 is our main workhorse for ldap connections, php-net-ldap2 is a dependency there for a one or two features in use.

The message header is parsed!

As the fix sets encoding="utf8", does this mean all messages are utf-8 encoded here?

this link of yours https://kb.kolab.org/2023/03/install-kolab-16-on-alma-linux-9/solar smash The package is missing when doing dnf install kolab.

The package has been updated; closing this task.

Packaging fix: https://obs.kolabsys.com/request/show/3324

Proposed fix in D4959.

I've now removed the package from my system - let's see what happens.
We most likely can't "Conflict" roundcube with this package - other Debian packages might still need it.
Thanks for the vendoring hint. We might want to hint admins during upgrades that it might be possible/useful to remove old packages.

I believe we're now using composer to install dependencies into /usr/share/roundcubemail/vendor folder, so packages like this aren't needed.

The debian package seems to work when editing sieve filters.

Sorry, I didn't mean to imply otherwise on the 389ds issue, I knew it was upstream that was broken but also that it is required for Kolab and has been stopping an update to 20.04.

389ds update issue resides on Ubuntu, it is not a Kolab issue.

Please do, that might help me get the 389ds update for ubuntu functioning and get me off of 18.04 finally.

I can second that. I ran into this issue as well. The dependency is not configured therefore the package is missing when doing dnf install kolab.

Hi there,
I was just able to successfully upgrade from CentOS 7 to Almalinux 9. Everything seems to be working the in place upgrade of the 389ds and the cyrus imapd were a bit of a hassle, but after testing it several times based on backups it worked ok. I can share my list of commands.

I managed to get the package updated but I still cannot send from the webmail interface, I see the same errors in roundcube/errors.log (with a new line number)

[15-Jul-2024 14:24:45 -0400]: <ka2vqi5j> PHP Error: STARTTLS failed (POST /webmail/hF3kdGo6e2kLGlvH/?_task=mail&_unlock=loading1721067885788&_framed=1&_action=send)
[15-Jul-2024 14:24:45 -0400]: <ka2vqi5j> PHP Error: Invalid response code received from server (POST /webmail/hF3kdGo6e2kLGlvH/?_task=mail&_unlock=loading1721067885788&_framed=1&_action=send)
[15-Jul-2024 14:24:45 -0400]: <ka2vqi5j> SMTP Error: Authentication failure: STARTTLS failed (Code: ) in /usr/share/roundcubemail/program/lib/Roundcube/rcube.php on line 1815 (POST /webmail/hF3kdGo6e2kLGlvH/?_task=mail&_unlock=loading1721067885788&_framed=1&_action=send)

I don't think this should be closed, the roundcube-1.5.7.4-1 package which contains the fix is not installable on Ubuntu 18.04 (it conflicts with roundcube-plugins-kolab) so this is an open issue for me.

Thanks. Fixed.

Update request: https://obs.kolabsys.com/request/show/3299

Short term, we should update the php-http-request2 package. 2.6.0 supports PHP >= 5.6 still, so there's no issue with that.

Thanks - I've added it to my "must fix list" when upgrading...

it was a smarty version issue.
bookworm comes with smarty4.

Can you explain "Smarty issue fixed by hand" in detail? What's the issue and how did you fix it?

Fixed in master

Maybe something like this:

--- a/cyruslib.py
+++ b/cyruslib.py
@@ -885,6 +885,7 @@ class CYRUS:
             annotation = annotation.strip()
             tokens = tokenize(annotation)
             folder = tokens[0]
+            mailbox = ensure_binary(mailbox)

This file opening problem again caused wallace to crash on my server, resulting in the failure to deliver emails to the end recipient.
Searching though the wallace directory I found the following instances

Same file opening problem exists in /usr/lib/python3.9/site-packages/wallace/module_invitationpolicy.py - line 270 :-

Duplicate of T8337: [pykolab][wallace][Debian 12] UnicodeDecodeError: 'utf-8' codec can't decode byte 0xdf in position 3620: invalid continuation byte.

Fixed in https://git.kolab.org/rRPKed50d5fc5855dae0c32c1109fbabb0554310f05e.

Looks like something to fix in https://git.kolab.org/source/pykolab/browse/master/pykolab/setup/setup_mysql.py$184

Fixed in 79bd5932b24b.

I would agree, probably not the right patch (Just provided it as it's what we do to make it work, just carrying the patch internally)

should be fixed in 1.5.6.7

The error was fixed in https://git.kolab.org/rRPK84c232f6dc4c603949199c46865d2cf6cd1bfd34, I'm not aware of the packaging state.

Also applies to EL9.
One solution appears to be to change the declaration of $ready , in class/kolab_ldap (files /usr/share/roundcubemail/plugins/libkolab/lib/kolab_ldap.php and /usr/share/roundcubemail/public_html/assets/plugins/libkolab/lib/kolab_ldap.php) from private to public.
There is also another problem, the directory /usr/share/roundcubemail/program/resources containing the "Ooops ..." error message that, presumably, should be displayed on crashes is missing.

It's because of default php versions on Debian:
Debian 10 - php 7.3
Debian 11 - php 7.4
Debian 12 - php 8.2

I'm still on Debian 10 - a new test-install on Debian 12 throws errors when logging in to kolab-webadmin. Didn't investigate further...

Patch merged.

Thanks for this happy news :-)

This has now been merged into Kolab:16, though the package is still building, but should become available shortly.

Thx for the News!

Problem is with loading order of php modules. On Ubuntu the fix for me was:

mv /etc/php7.4/cli/conf.d/30-kolabformat.ini /etc/php7.4/cli/conf.d/32-kolabformat.ini
mv /etc/php7.4/apache2/conf.d/30-kolabformat.ini /etc/php7.4/apache2/conf.d/32-kolabformat.ini

We're working on a fix for packaging.