I opened a duplicate bifrost for this at https://bifrost.kolabsystems.com/T21031 .
One of the cases should end up in a commit and a new pykolab version, I think.

Proposed fix:

-- a/pykolab/auth/ldap/__init__.py
+++ b/pykolab/auth/ldap/__init__.py
@@ -1683,6 +1683,8 @@ class LDAP(pykolab.base.Base):
                     entry[mailserver_attribute]
                 )

I was able ro reproduce the error:

1. I received a meeting invite.
2. I accepted the invite
3. I clicked Update in my calendar.
4. The webinterface showed saving for about 3 minutes

4.1 Mail and calendar was locked during this time

5. After recovery 3 minutes mail was working and the calendar was updated

Moved with investigation even further, leaving /usr/lib/python2.7/site-packages/cyruslib.py modified, I also modified:

• wallace/modules.py commenting lines 135-136, to make sure smtp.set_debuglevel(True) is not set. in debug level 9
• pykolab/auth/ldap/__init__.py commenting lines 427-428, to make sure trace_level = 1 is not set in debug level 9
• pykolab/imap/cyrus.py commenting lines 90-92, to make sure self.VERBOSE = True and self.m.debug = 5 is not set in debug level 9

Now I can get wallace working correctly even in debug level 9.

Comments in T2166: wallace fails to read resource calendar might be related.

Comments in T2166: wallace fails to read resource calendar might be related.

I was able to bypass the issue in debug mode 8, by setting self.LOGFD = open('/var/log/kolab/cyruslib.log', 'a') around line 319 in cyruslib/py library. Now wallace successfully parse the message and resource calendar and accepts the invitation.
The same trick gives different results in debug level 9:

2017-01-05 16:23:43,776 pykolab.wallace ERROR Module resources.heartbeat() failed with error: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/wallace/__init__.py", line 89, in modules_heartbeat
    modules.heartbeat(module, lastrun)
  File "/usr/lib/python2.7/site-packages/wallace/modules.py", line 128, in heartbeat
    return modules[name]['heartbeat'](*args, **kw)
  File "/usr/lib/python2.7/site-packages/wallace/module_resources.py", line 442, in heartbeat
    imap.connect()
  File "/usr/lib/python2.7/site-packages/pykolab/imap/__init__.py", line 170, in connect
    self._imap[hostname].login(admin_login, admin_password)
  File "/usr/lib/python2.7/site-packages/pykolab/imap/cyrus.py", line 142, in login
    cyruslib.CYRUS.login(self, *args, **kw)
  File "/usr/lib/python2.7/site-packages/cyruslib.py", line 419, in login
    self.__doexception("LOGIN", error)
  File "/usr/lib/python2.7/site-packages/cyruslib.py", line 359, in __doexception
    self.__doraise( function.upper(), msg )
  File "/usr/lib/python2.7/site-packages/cyruslib.py", line 368, in __doraise
    raise CYRUSError( idError[0], mode, msg )
CYRUSError: (10, 'LOGIN', '[Errno 9] Bad file descriptor')

and

2017-01-05 16:25:10,389 pykolab.imap DEBUG [13257]: Logging on to Cyrus IMAP server localhost
2017-01-05 16:25:10,422 pykolab.wallace ERROR Unknown error occurred; CYRUSError(10, 'LOGIN', '[Errno 32] Broken pipe')
2017-01-05 16:25:10,423 pykolab.wallace ERROR Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/wallace/modules.py", line 118, in execute
    return modules[name]['function'](*args, **kw)
  File "/usr/lib/python2.7/site-packages/wallace/module_invitationpolicy.py", line 363, in execute
    imap.connect()
  File "/usr/lib/python2.7/site-packages/pykolab/imap/__init__.py", line 170, in connect
    self._imap[hostname].login(admin_login, admin_password)
  File "/usr/lib/python2.7/site-packages/pykolab/imap/cyrus.py", line 142, in login
    cyruslib.CYRUS.login(self, *args, **kw)
  File "/usr/lib/python2.7/site-packages/cyruslib.py", line 419, in login
    self.__doexception("LOGIN", error)
  File "/usr/lib/python2.7/site-packages/cyruslib.py", line 359, in __doexception
    self.__doraise( function.upper(), msg )
  File "/usr/lib/python2.7/site-packages/cyruslib.py", line 368, in __doraise
    raise CYRUSError( idError[0], mode, msg )
CYRUSError: (10, 'LOGIN', '[Errno 32] Broken pipe')

and

2017-01-05 16:25:00,082 pykolab.auth ERROR LDAP server unavailable: SERVER_DOWN({'desc': "Can't contact LDAP server"},)
2017-01-05 16:25:00,084 pykolab.auth ERROR Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 3065, in _search
    secondary_domains
  File "<string>", line 10, in <module>
  File "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 2963, in _regular_search
    (_result_type, _result) = self.ldap.result(_search, False, 0)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458, in result
    resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462, in result2
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469, in result3
    resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Although there is still a progress, because looks like the invitation is parsed, just these tracebacks are thrown later.

Looks like none of libkolabxml and plugins: libkolab and calendar support BYSETPOS. As a quick fix we should probably allow two simple and most common cases of "first weekday" and "last weekday" by converting them to correct BYDAY property.

This is RFC 3744 which has to be implemented. We have a ticket for this (T756), but that one is about WebDAV. Let's keep a separate ticket for CalDAV.

Are there any other related patches? I searched and was unable to locate similar issues.

I'm not able to reproduce the issue anymore.

This is a duplicate of T1847.

I can confirm this. There are at least two issues here:

1. allday flag for exceptions is forced to be the same as main event. This can be fixed with this:

-- a/plugins/libkolab/lib/kolab_format_event.php
+++ b/plugins/libkolab/lib/kolab_format_event.php
@@ -291,7 +291,9 @@ class kolab_format_event extends kolab_format_xcal
         }

Roundcube core and kolab_addressbook plugin does not support photo URLs. It is not clear to me if it is at all possible to store URL and mediatype in Kolab XML format (probably only URL without type is supported).

I just did an update on some old Kolab:Winterfell installation:

33 | update                   | 2016-12-29 09:31 | E, I, O, U     |  481 EE
32 | update                   | 2016-08-31 12:05 | E, I, U        |  194 EE

I see no issues. Anyway this looks more like a mysql issue.

This was fixed in 66310b2fc46138.

clamav-update package is required dependency of kolab-16.0.1-3 according to https://obs.kolabsys.com/package/rdiff/Kolab:16/kolab?linkrev=base&rev=9 So, this probably is fixed already. @vanmeeuwen ?

The same as in syncroton (T1751) it is caused by authentication cache.

I'm afraid Chwala does not log successful logins either. Failed logins log comes from kolab_auth plugin.

It is because syncroton uses authentication cache. So, when the username is in the cache kolab_auth plugin (which logs userlogins errors) is bypassed. We need some additional code in kolab_sync::authenticate(), probably should depend on Roundcube's log_logins setting.

Transferred to https://bifrost.kolabsystems.com/T9049 on Oct 27 2016.

@vanmeeuwen, So we have a case with no delegation, but with a shared folder where user (with write rights) deletes an event. Considering my comment here https://git.kolab.org/T1357#27566 and the next one, what would you propose? Note that we first have to solve this independently from what wallace does, i.e. define what iTip messages are sent and when, should we use SENT-BY field, etc. Then how wallace would handle that is another story.

Anything interesting in mariadb logs?

I upgraded all kolab packages from current on 10/18 to what was current on 12/15 for CentOS 7

Roundcube works, everything works, mail, calendaring, address book, etc.... I can even browse files in the roundcube files. I can't view or edit files. The Chwala errors posted are from when I try to view/edit.
What should I try out in SQL?

Any news for this issue?

Did you try to use mysql from command line? Does Roundcube work? What exactly did you upgrade?

(Actually, setting this to open until the upstream code gets fixed; may be a good idea) Resolved elsewhere, still a problem upstream.

..... AND I have no good way to provide code... so Github it is!

With {tls, no} guam will not initiate the STARTTLS to the backend server and present the non-starttls response. With { tls, starttls } guam will already initialize a STARTTLS Session to the backend resulting in the security problem descriped above and guam allows unencrypted login, Even the LOGIN is stripped from the CAPABILITY afail

In T2082#31878, @dhoffend wrote:

Test @ 143

# nc localhost 143
* OK [CAPABILITIES IMAP4rev1 LITERAL+ ID ENABLE STARTTLS LOGINDISABLED] kolab Cyrus IMAP 2.5.10-49-g2e214b4-Debian-2.5.10.49-0~kolab1 server ready

Yes. I've already played around with this setup. Here're the results. The only thing that's strange are the capabilities after STARTTLS but before! AUTH

In T2082#31869, @dhoffend wrote:

A possible workaround (especially for Kolab:16) would be to update the default configurations of Cyrus and Guam.

Cyrus should listen on 1143 (non-ssl) and 9993 (ssl) while guam forwards 143 to 1143 and 993 to 9993 (2 different upstream servers and 2 listeners). This way guam isn't exposing and you wouldn't have to deal with it. But in the long term it would be great of guam could take over this work so you wouldn't need cyrus to listen on 2 different ports and running 2 different sets of worker/threads.

A possible workaround (especially for Kolab:16) would be to update the default configurations of Cyrus and Guam.

The fact is that the clients may respond to the availability of authentication capabilities before TLS is started (notably URLAUTH, SASL-IR, while AUTH= parameters are already stripped):

Still considering what to be done with this.

out of file handles.

Known issue.

Connecting with cli imap client "mutt" you can see this behavior because it always presents the full folder list (in the left folder view (patched) version as well when you want to switch the folders.

I could narrow it a bit down towards multiline input (IMO). The single commands are processed and filtered correctly. In the moment you or the client issues multiple IMAP commands at once guam isn't able to intercept and split it correctly.

Promoted to Bifrost#T18595.

This ticket has evolved in to T224, and T2055 and T2058 since. Your current entitlements also alleviate git.kolab.org from the support issues you may find yourself suffering from.

My personal workaround was to comment out 989-994 so that the rest of my contacts and properties actually sync.