The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 5 2017
Jul 3 2017
Jun 30 2017
@vanmeeuwen, what's your take on this?
Hmm, the user who has been reporting this issue uses some mobile email client in addition to the kolab roundcubemail, so it *might* be related to mobile client, but I'm not sure really..
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
Still can't find the way to reproduce the issue. Another source informed us that it had the same issue and there was CalDAV client involved. I reviewed the code and I don't see what actions could lead to such invalid timezone entries. Here's a patch that we could use, but I think the issue is in another place:
--- a/plugins/calendar/calendar.php +++ b/plugins/calendar/calendar.php @@ -1974,6 +1974,8 @@ class calendar extends rcube_plugin */ private function write_preprocess(&$event, $action) { + $event['start'] = preg_replace('/\s*\(.*\)/', '', $event['start']); + $event['end'] = preg_replace('/\s*\(.*\)/', '', $event['end']); // convert dates into DateTime objects in user's current timezone $event['start'] = new DateTime($event['start'], $this->timezone); $event['end'] = new DateTime($event['end'], $this->timezone);
Jun 7 2017
Search for files with content "FLE Daylight Time" in /var/spool/imap/domain/ and provide a sample file.
Any tips how to best debug this issue?
Jun 6 2017
I've replaced the https_check() function with
As far as I can trace the calls back... our old friend api_url() is used to create the base URL and the scheme depends only on rcube_utils::https_check() and nothing else.
If the scheme "http" is used this can only mean, that rcube_utils::https_check() returned false - please correct me, if I'm wrong. Perhaps we should have a look at it next.
I've changed the file_api_url setting to some nonsense for testing purposes... Of course, it does not work, but the changed URL is passed along.
I've created a new text file and tried to open it. Same issue :-(
In this case it is Roundcube connecting to Chwala directly. It looks like the config has been ignored. I have no idea how's that possible. Maybe there's something in between that caches the request and returns old response? Check with a different file.
Is there anything I can do to help you to diagnose it?
I've set in kolab_files.inc.php
But it should work if you set file_api_url to a full url with https:// prefix? Do you set options in /etc/roundcubemail/config.inc.php? I'm unable to reproduce.
Yes, I've set use_https to true and applied the mentioned fixes. I'm sorry, but the issue persists :-/
And that is with use_https=true? BTW, there's another fix: rC0349c2d84661.
Now the error is away. Thank you!
Ok, try this change: rCd0539d6f029d.
I don't see how $_SERVER['SERVER_PORT'] == 80 would make it appended to the url. The if statement requires it to be different than $port and than 80. Maybe we should use intval($_SERVER['SERVER_PORT']).
I've written out $_SERVER['SERVER_PORT'] ... it's port 80. I assume that rcube_utils::https_check() returns true, so $schema is "https", this leads to $port = 443 and to a true, when evaluating the new if-block. So the port is appended to the hostname.
I've done just copy & paste. The code of the resulting function is ...
Maybe you just applied the patch incorrectly. Note the dot character in this line:
$url .= ':' . $_SERVER['SERVER_PORT'];
Forget my last comment. There's no such thing like $_SERVER['HTTP_PORT'].
Hmm... I'm just thinking. Maybe in your env you don't have $_SERVER['SERVER_PORT'] set either. Then try replacing this with $_SERVER['HTTP_PORT'].
What if you replace $_SERVER['SERVER_NAME'] with $_SERVER['HTTP_HOST']?
Thank you for the fix, but it doesn't seem to work :-/
Hope rCd886aeac2aec fixes that.
Jun 5 2017
Setting use_https to true does has not the desired effect. The created URL now contains the scheme "https", but it still uses port 80. Other parts of the application now complain about errors like this one:
May 31 2017
That's the problem. The error in question hasn't happened to me, so i don't know the exact steps to reproduce. What I've heard is that "it just happens automatically". When the recipient gets the calendar invitation email, the placeholder event is automatically created in the calendar (per kolab policy settings), and when the recipient user tries to accept/reject the invitation from the kolab roundcube webmail *calendar* application he gets the Internal Server Error and the PHP Fatal Error and the stack trace I posted can be found from the logs.
Fixed. You now would need to set use_https to true or file_api_uri to full chwala api path.
May 30 2017
The fix is in roundcubemail-plugins-kolab repo.
Fixed in rRPKce9ac27d783d.
Looks like rC21f6abd52a929 broke compatibility with Roundcube 1.2. Looks like we have now 3 options:
- Revert the change and wait with Roundcube 1.3 support until it's in Kolab, then apply it again
- Copy blank.tiff to blank.tif in roundcubemail package
- Use chwala URL to access these files.
May 29 2017
But this object has valid dates. So, how do I reproduce the issue?
I hope I didn't screw up the xml while removing private info.. but here goes:
http://pasik.reaktio.net/kolab-webmail-calendar-internal-server-error.xml
May 24 2017
I can't reproduce the issue by importing the .ics file. Could you provide the object in xml format (i.e. the message from imap folder)?
May 23 2017
Sorry took a while, but now it happened again..:
May 22 2017
May 21 2017
Net_Sieve taken over. So, we can keep using pear/Net_Sieve. Note that for PHP7 support version 1.4.0 is required.
https://github.com/pear/Net_Sieve/pull/5 for reference. However, I'll try to take over the package and backport our fixes to it anyway.
The original Net_Sieve author abandoned the package and didn't want to fix it. That's why we forked. As for the pdo, openssl, session, json, pcre, these are php extensions, I didn't check package names for them.
Roundcube 1.2:
- don't require pear's MDB2, Mail_mimeDecode, nor DB,
- don't require php-mcrypt,
May 16 2017
An update (-kolab6) should be available for both libkolabxml and libkolab (or php-kolabformat and php-kolab respectively).
May 15 2017
May 11 2017
Fixed.
Fixed.
May 10 2017
On PHP7 (Ubuntu Xenial) we see:
[10-May-2017 12:57:43 Europe/Berlin] PHP Deprecated: Methods with the same name as their class will not be construc tors in a future version of PHP; Net_Sieve has a deprecated constructor in /usr/share/php/Net/Sieve.php on line 93 [10-May-2017 12:57:43 Europe/Berlin] PHP Warning: array_merge(): Argument #1 is not an array in /usr/share/php/Net/ Sieve.php on line 312
these are fixed in the Roundcube's fork of Net_Sieve. We should provide that in packaging.
apt-get install kolab works with Winterfell repository. I think it is misleading to have instructions for Kolab 16 at https://docs.kolab.org/installation-guide/index.html. So, we should fix the packages or remove that part of documentation.
Sorry, I was too fast. It installed only postfix and stopped. It also fails on kolab-webadmin.
The following packages have unmet dependencies: kolab-webadmin : Depends: libapache2-mod-php5 which is a virtual package and is not provided by any available package.
May 7 2017
I am getting this issue on vanilla Kolab 16 installation but after dropping the policy_result table it gets recreated.
Apr 11 2017
Apr 7 2017
Apr 1 2017
The best would be to see the whole message. You can remove private data.
Which parts of the XML are important? I can try to find it..
Mar 30 2017
Is there a chance we can see the original event data in XML form or as iCal export? Anyway, I suppose a needed fix here will be to remove the timezone string in brackets before passing it to the DateTime constructor.
Mar 18 2017
Just in case, more rpm versions:
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.
Feb 24 2017
Done in 99cd2b17522.
Actually the change need to be backported from master to roundcubemail-plugins-kolab-3.2 branch.
Feb 21 2017
To reproduce the issue just try to rename a file over WebDAV.
Feb 6 2017
So same issue, with slightly different results: multiple commands sent together, which is allowed by the IMAP spec indeed, and then the client ends up waiting for responses that do not come as expected. Thanks for the report.
Feb 5 2017
I've encountered another bug with guam. This time It's "eM Client" for Windows. I've activated the client debug log (in eM Client) and after sending a XLIST and SELECT command in TLS/SSL mode (it looks like the client sends 2 commands at once) the connections gets into some kind of stale mode. It's no longer working. Hard to tell without decrypting network traffic.
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