- Use python UUID to convert binary objectGUID to string. It doesn't look like value of uniqueid returned by from cache is used anywhere (needs to double check), so only forward conversion is needed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 3 2019
Apr 2 2019
Apr 1 2019
- Use python UUID to convert binary objectGUID to string. It doesn't look like value of uniqueid returned by from cache is used anywhere (needs to double check), so only forward conversion is needed.
- Also do not strip anything from bytestring attributes (objectGUID) because after stripping conversion to UUID string is not possible.
Mar 22 2019
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
It doesn't seem like there's any actual errors in reality.
Mar 19 2019
- Use python UUID to convert binary objectGUID to string. This way dont need to chage cache db format. It doesn't look like value of uniqueid returned by from cache is used anywhere (needs to double check), so only forward conversion is needed.
Mar 5 2019
Jan 30 2019
Fixed in ff9be33f7795.
Dec 10 2018
This should be documented here, shouldn't it?
https://docs.kolab.org/upgrade-guide/kolab-16.html
Nov 27 2018
Aug 1 2018
oh, I was to overhasty. The patch still works, it was my mistake. This should be altered in the function "find_resource":
is there anyghing new about that?
I just tried to apply the patch to an actual kolab 16 with
Jul 27 2018
Jul 3 2018
In T2289#37694, @vanmeeuwen wrote:The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.
Jun 26 2018
Renaming the mailbox works as intended -- if the result attribute value changes, then so must the mailbox name. This is an effect of the username canonification processes applied in webmail+friends and Cyrus IMAP itself (using ptloader).
Jun 17 2018
Jun 3 2018
See above for a patch that implements option 2.
Jun 2 2018
The above patch was the simple part; now we need a script that gets called when the package is upgraded and drops the respective tables. I assume it's okay to drop the tables whenever the PyKolab package gets an update - please veto if you disagree.
May 31 2018
Okay, so we have to modify the database schema. In https://kolab.org/hub/topic/260/google-mails-rejected/4 it is suggested that the statistic table should also be altered, which looks plausible to me.
Raising priority because this bug causes data loss: emails are getting rejected.
May 2 2018
Mar 12 2018
Jan 24 2018
In T2729#49743, @timeberhardt wrote:That's my dirty hack (utf-8 hardcoded):
...
Jan 11 2018
That's my dirty hack (utf-8 hardcoded):
Jan 9 2018
In T2729#48073, @timeberhardt wrote:I can reproduce this bug with a fresh Kolab install on top of Ubuntu 16.04. I could not create new users after I added a user with an umlaut in his name.
The Bug is caused because in pykolab.utils the locale_name configured for the user (in my case de_DE) is fed to the python method locale.normalize which then returns de_DE.ISO8859-1. But the input string isn't latin but utf-8, so iconv can't convert the whole string and replaces the umlaut with a questionmark. As soon as I hardcoded utf-8 into the iconv call, everything was working again (of course that's not a solution).
Dec 19 2017
refering to all occurances of user_mailbox_rename in https://git.kolab.org/diffusion/P/browse/master/pykolab/auth/ldap/__init__.py
Dec 7 2017
I can reproduce this bug with a fresh Kolab install on top of Ubuntu 16.04. I could not create new users after I added a user with an umlaut in his name.
Nov 17 2017
Nov 2 2017
For others who might run into the same issue, the above sql does not work. after fixing the syntax because md had interpreted the backticks, it left me unable to send or receive mail. I had to delete the table and let pykolab recreate it.
My kolab install is rejecting emails from Amazon because of this bug. The logs when such an email arrive show:
Sep 27 2017
Sep 21 2017
If there is a patch for Winterfell could you please port this also to Kolab16?
I have a current Kolab16 installation in a Centos7 lxc container on an Ubuntu 16.04 host.
kolab lm is not working and there are no folders created for new users.
Jul 22 2017
Jul 21 2017
A low hanging fruit. Patch in my comment above.
In T1543#38255, @machniak wrote:@vanmeeuwen Does https://git.kolab.org/rP0e8a8276f60b4cf99ef37d9e3b413153d80bcd98 fix this or we plan another solution?
Jul 20 2017
@vanmeeuwen Does https://git.kolab.org/rP0e8a8276f60b4cf99ef37d9e3b413153d80bcd98 fix this or we plan another solution?
I have changed the acls for anyone to lrs and that did the trick - don't see errors anymore. Wallace messages were dispatched.
ps. there's possible performance optimization in find_user_folders: don't use imap.list_folders('*'), instead depend on imap.get_metadata('*'), which we do anyway. But of course we should ask for the metadata we need, not all of them.
Now I see where's the problem:
- @vanmeeuwen, a side of the main reason of the issue (see below). There must be some bug somewhere because imap SELECT on a folder that has 'lr' for anyone should not fail.
- If you consider this code
# exclude shared and other user's namespace if ns_other is not None and folder.startswith(ns_other) and '_delegated_mailboxes' in user_rec: # allow shared folders from delegators if len([_mailbox for _mailbox in user_rec['_delegated_mailboxes'] if folder.startswith(ns_other + _mailbox + '/')]) = continue # TODO: list shared folders the user has write privileges ? if ns_shared is not None and len([_ns for _ns in ns_shared if folder.startswith(_ns)]) > 0: continue
You will see that if user_rec['_delegated_mailboxes'] is not set (which is the case here) no other user folders will be excluded. So, my proposed fix is:
--- a/wallace/module_invitationpolicy.py +++ b/wallace/module_invitationpolicy.py @@ -796,7 +796,9 @@ def list_user_folders(user_rec, type):
No, user smith@domain.tld doesn't have any delegates in LDAP.
Or to be more precise (according to the traceback). It does not even tries to write to the folder, but just tries to select it (and then search for an object). I'm not sure why select fails while the folder is 'lr'.
Is there delegation setup between these users? For me it looks like there is, but delagtor's calendar folder is non writable and the code does not check that trying to write to it.
Jul 3 2017
The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.
Jun 30 2017
@vanmeeuwen, what's your take on this?
Any thoughts/plans about fixing this issue? Users hit this issue very often, because currently kolab auto-updates only the *first* recipient calendar..
Jun 29 2017
That looks like simple mistake in the code. Fixed in rRPKc2e8cc16abf3.
I was investigating a similar case - create event in Gmail and invite 2 attendees - one for user with Outlook and one for user in Roundcube. Both accept the invitation, but user who accepted it in Roundcube is not marked with a check box in Gmail.
it turns out, that Roundcube sends possibly wrong DTSTAMP in meeting acceptance iTip. Comparing responses I noticed that original invitation from Gmail has
METHOD:REQUEST DTSTAMP:20170627T054332Z CREATED:20170627T054331Z LAST-MODIFIED:20170627T054331Z
Acceptance iTip coming from Outlook has:
METHOD:REPLY CREATED:20170627T054452Z DTSTAMP:20170627T054452Z LAST-MODIFIED:20170627T054452Z
But Roundcube sends iTip with:
METHOD:REPLY DTSTAMP:20170627T054331Z CREATED:20170627T054331Z LAST-MODIFIED:20170627T054331Z
It is one second behind from DTSTAMP value in invitation. If I send exactly the same response as Roundcube did, but modify DTSTAMP to be at least the same value as it was in invitation, then Gmail records the status of the attendee.
RFC5545 says that:
In the case of an iCalendar object that specifies a "METHOD" property, this property differs from the "CREATED" and "LAST- MODIFIED" properties. These two properties are used to specify when the particular calendar data in the calendar store was created and last modified. This is different than when the iCalendar object representation of the calendar service information was created or last modified.
I'm not sure I fully understand what they want to say here, but to me it looks like:
- DTSTAMP in REPLY should be later than it was in REQUEST
- DSTAMP should be different from CREATED and LAST-MODIFIED
Jun 22 2017
Not exactly the same error, but we have already T2163.
Jun 21 2017
- So, the iTips differ not much. I don't think CLASS:PUBLIC is relevant.
- I think it's possible. When the event time changes client could request "re-sheduling". You'd need to see what's in G's iTip in step 4.
In T2504#37355, @machniak wrote:We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.
Back to your questions:
- No idea. Check Itip payload.
Event which doesn't make GMail Calendar record attendee status as accepted
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN CALSCALE:GREGORIAN METHOD:REPLY BEGIN:VEVENT UID:i698fn56cjct6tvjt3sfa2m6j0@google.com DTSTAMP:20170621T091446Z CREATED:20170621T091446Z LAST-MODIFIED:20170621T091446Z DTSTART:20170622T040000Z DTEND:20170622T050000Z SUMMARY:KS Demo =C4=97 DESCRIPTION:View your event at https://www.google.com/calendar/event?action SEQUENCE:0 TRANSP:OPAQUE STATUS:CONFIRMED ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA= NT;CUT YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com END:VEVENT END:VCALENDAR
Event which makes GMail record attendee status
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN CALSCALE:GREGORIAN METHOD:REPLY BEGIN:VEVENT UID:i698fn56cjct6tvjt3sfa2m6j0@google.com DTSTAMP:20170621T091716Z CREATED:20170621T091446Z LAST-MODIFIED:20170621T091716Z DTSTART:20170622T040000Z DTEND:20170622T060000Z SUMMARY:KS Demo =C4=97 DESCRIPTION:View your event at https://www.google.com/calendar/event?action SEQUENCE:0 TRANSP:OPAQUE STATUS:CONFIRMED CLASS:PUBLIC ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA= NT;CUT YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com END:VEVENT END:VCALENDAR
We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.
May 7 2017
I am getting this issue on vanilla Kolab 16 installation but after dropping the policy_result table it gets recreated.
Apr 5 2017
Re-opening, as this issue is not fixed in git.
Mar 15 2017
So the actual issue seems to be if there are multiple recipients in the calendar invitation email then wallaced only creates the placeholder calendar event for the *first* recipient only.
Yes, i'm pretty certain this is the actual issue i've been seeing.
Sounds like a bug. So, this is the explanation of the initial issue, yes?
Mar 14 2017
Another test was now done by sending a calendar invitation from Exchange 2010 to Kolab 16.1.
Oh, it seems --debug=8 syntax doesn't seem to work. This works instead:
Mar 13 2017
This seems to be related to what email platform the sender is using. I tested the same procedure using google gmail.com as a sender, and kolab seems to work properly in that case, and updates the not-yet-accepted calendar invitation just like it should.
Yeah, with *_SAVE_AND_FORWARD it should probably update existing unresponded invitation event.
Mar 6 2017
Indeed according to RFC3696 and https://www.rfc-editor.org/errata_search.php?eid=1690 the address length limit is 254 characters.
Feb 24 2017
Just updated to Kolab 16.0.1 Release 12.1.el7.kolab_wf that this is still an issue when running in an LXC host!
Jan 17 2017
Jan 10 2017
I was able ro reproduce the error:
- I received a meeting invite.
- I accepted the invite
- I clicked Update in my calendar.
- The webinterface showed saving for about 3 minutes
4.1 Mail and calendar was locked during this time
- After recovery 3 minutes mail was working and the calendar was updated
Jan 6 2017
Jan 5 2017
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.