I am a seeing the same thing on Debian. It crashes roughly once a month, also without anything in the log.

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

You asked for hints!
The crash should not happen, but there are still to much variables included.
I just analyzed, the information I had.

Yes, the user hr1@os-s.de does not exist in the LDAP. It is not a vaild usser. Therefore no authentication is possible. But this should not be a cause for saslauthd to fail and terminate, am I correct?
The kolab-saslauthd terminates. I reconfigured systemd to automatically restart the daemon because otherwise the login would fail for valid users as well.

as long as I could see, it is still a Domain address issue!

Actually the logs continue. Apparently my copy buffer did not copy the complete log. I guess the failed login of hr1 is the last thing of the old process. Then the saslauthd is restarted reading its configuration files:

perhaps Domain based issue?
see end of your logs.

Any further ideas how to debug this? What error causes INVALIDARGUMENT? Or is this a sign for an uncaught error?

Closing as duplicate of T8337.

Ok. I have increased the debug output to 9. Unfortunately nothing is logged. kolab-saslauthd failed at 08:03:39 and is automatically restarted.

I have increased the debug output to 5 so far. Currently it only logs failed authentications. I will increase it to 9 now. I was a bit hesitant because of the log size.

Thanks a lot. Saslauthd fails every 3-14 days. Once I have more data, I will add it to the ticket.

Yes, this seems to fix the issue. When will this be included in the packages?

the debug option is " -d " with an integer up to 9

seems the same problem as T8337.
I have posted a workaround to the parser UTF8 error.

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 - 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?

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...

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.

The broken install dependency kolab-webclient -> roundcubemail-plugins-kolab should be fixed by https://obs.kolabsys.com/request/show/3262, which is currently under review.

Superseded by https://obs.kolabsys.com/request/show/3262, which includes an additional fix for the upgrade path by adding a conflict with roundcubemail-plugins-kolab.

Seems to be fixed by D3692 and rPbd3a9e74745461089d7afc4e51a39c21958907bf.

Judging by the last comment, it looks like this has been fixed. Closing as Resolved; please reopen if I'm mistaken.

Fix proposed in https://obs.kolabsys.com/request/show/3261. @machniak, @mollekopf, could you please take a look and push it through to Kolab:16 if it's okay?

Any further Developments here?

Very old.

Packaged and released in 1.5.4.11

Latest roundcubemail package on Ubuntu 18.04 is 1.5.4.7-1~kolab1_all.deb, which as far as I can see has Net_SMTP in version 1.10.1 built-in. So, all should be ok, but I don't have Ubuntu system to verify on.

@mollekopf, imap.user_mailbox_create() returns False on error.

Duplicate of T6688.

I think it is better to pass the invitation to Inbox for manual processing.

imap.user_mailbox_create() always returns a string, so this should be fine. Is there a command-line way to reproduce this issue?

Fixed in roundcubemail-selfcontained

D3692 and D3710 should fix this
I ran into same error, when testing for Python 3

According to the log, the script tries to create a user named '@'. That's, well, weird. Unfortunately, I'm not sufficiently familiar with the pykolab codebase to make a qualified guess where this username may have originated from.

Hello sicherha,

Hello sicherha,

Umm, yeah, the docs are somewhat outdated because the build pipeline appears to be broken (T6055)...

Is there a release date for Kolab for Debian Buster?
https://docs.kolab.org/installation-guide/index.html does not mention anything.

Looking at the email source the for the invitation there's this part (IDs changed, so it's not proper link to test with):

I see Debian 10 has been added in OBS, is anyone working on adding CentOS 8?

I didn't know that wallace created generate calender placeholder. Do they have an update for this? Hoping that they fix it as soon as possible.

Any thoughts about how to fix this issue?

Yes I agree a 1000% (three zeros!)
I taught about it a while ago, but was very busy,

Hello gpunk,

Changing to hight, since it is a non working advertised feature -- hence a blocking problem .

Patch seems to work. I haven't seen this issue after applying the patch. Thanks a lot!

I've updated my kolab installation from Debian 9 to 10. All in all nothing major. Highlights:

If you feel courageous enough, I would say it's ready for field testing. Should you encounter any remaining rough edges, please report them so they can be ironed out.

I've seen in OBS that we now build packages for Debian 10.
What's your opinion: Is it probably ready to upgrade my instance?
The only package failing to build is chwala - where I could possiby use the old package...

@machniak Thanks a lot! I'll try the patch. This .ics arrived from Microsoft Exchange Server 2010 (based on the PRODID field in .ics).

Fixed.

Further investigation shows that actually Kolab format has CutypeRoom and CutypeUnknown defined. So, we can add these to the map, but still we should probably silently ignore unsupported values.

According to RFC5545 ROOM, UNKNOWN, X-* are valid values. Those aren't supported by Kolab, but we definitely should not throw exceptions on these. I wouldn't touch the map variable. Probably better to handle these in set_cutype().

I believe this was already fixed back in June with https://obs.kolabsys.com/package/rdiff/Kolab:Winterfell/kolab?linkrev=base&rev=37.

I'm working on providing Debian 10 packages for Kolab 16.

According to https://obs.kolabsys.com/project/show/Kolab:Winterfell
RHEL_8 and Debian_10.0 have been added to Winterfell.
So my most pressing wishes have been granted :-)

Fixed in 3841f63fbd42 [roundcubemail master] and eee719e6d2f87 [roundcubemail-plugins-kolab master].

This issue is a bug in Roundcube sql cache, so is reproducible with $config['imap_cache'] = 'db' and of course only when using MySQL engine. No issue if it's set to memcache, redis or disabled.