Thanks for the quick reply @fbartels !
Today I put some time into finding out, what exactly happens before the error occurs:
we are using the LDAP-module as single user plugin. What I originally thougt to be distribution group errors actually are group errors, the icon looks alike, but they are in the global address book, not my individual one. Also I can not edit or change them directly, as they are managed by LDAP.
So when I create a new ldap group with only my own email address inside and try to send a mail there, the server.log shows those lines:

Mon Aug 26 15:35:14 2019: [error ] Command "/etc/kopano/userscripts/creategroup" exited with non-zero status 127 Mon Aug 26 15:35:16 2019: [error ] LDAP search error: Can't contact LDAP server. Will unbind, reconnect and retry. Mon Aug 26 15:35:18 2019: [warning] K-1515: Object not found unknown user "testgroup@server.com": testgroup@server.com not found in LDAP Mon Aug 26 15:35:49 2019: [error ] LDAP search error: Can't contact LDAP server. Will unbind, reconnect and retry.

The first line is clear - there simply is no userscripts/creategroup.
The following lines look like there were connection problems - that I could not yet verify - and kopano be looking for the testgroup as a user first, not as a group.

In disregard of the log lines, the test email was delivered.

@ckruijntjens The official recommendation is of course to use our supported packages.

@ckruijntjens RTT is the total time it takes for the Kopano Server to answer a client request. This includes everything, such as database queries, retrieving attachments, authentication (e.g. with LDAP) or network latency. Without diving deeper into your environment it is impossible to say what you need to do to lower and stabilize your RTT.

This type of work is generally dealt with by our professional services team - I recommend that you get in touch with support and/or sales to set up a project if you’re interested.

Thank you for your reply

Hi @crankshaft,

@crankshaft said in ubuntu 18.04 apt install kopano-core:

but is this “demo” version time limited or crippled in any way, does it require a subscription to run it ?
Sorry, but this does not appear to be made clear in the pages / documentation that I have seen :-)

Our software is completely open source and does not require a subscription or license key to run or the enable certain features (apart from e.g. support and our package repositories). This is also the reason why you cannot find documentations about limitations in the demo, there aren’t any ;-)

And for your other statements:

@crankshaft said in ubuntu 18.04 apt install kopano-core:

do I need to purchases a subscription […] I am only a small user of 4 and don’t require paid support ?!

@crankshaft said in ubuntu 18.04 apt install kopano-core:

are rather reluctant to have to purchase a subscription / license a second time since we are very small users (4 users) and don’t really need all of the latest bells & whistles, just mailboxes & public folders.

Please also have in mind that someone needs to finance further development and running, maintaining and responding in such places as a forum. Just because you once purchased a product does not mean that you can automatically expect to benefit from all further maintenance and development eternally. If you take a look at the website you will also find that its quite reasonable priced.

I’d argue you spent only a fraction of the money that goes into powering your kopano server for the actual subscription.

Look at the dagent log and see what it says about dagent.sock.

Hi @fbartels,

i tried 8.7.82.12 and 8.7.82.53. Then i downgraded to 8.7.3.0-lp150.91.7 which is latest in opensuse repo.

Sorry, just don’t have the time to play around with. Problem with hanging backup (https://forum.kopano.io/topic/2566/kopano-backup-hangs) is also resolved after downgrade.

There are no problems to be expected when skipping minor releases.

Hi,

We’re observing exactly the same symptom as yours : when syncing emails from a groupwise server to Kopano via ‘kopano-migration-imap’, we noticed that the “Received” date had a two hour shift.

I wonder if it could be related to commit 764b2072a79be5a31006aa55652a1892f371ab9c (gateway: refactor StringToFileTime to use strptime and validate timestamp).

I finally found a (dirty) workaround by patching kopano-migration-imap to append a converted date in UTC :

my $h1_date_patched = POSIX::strftime('%d-%b-%Y %T +0000', gmtime(str2time(substr $h1_date, 1, -1)));

In your example, the APPEND command is patched like this :

9 APPEND "INBOX" "24-May-2019 13:44:22 +0000" {533+}

And the received date in Kopano is displaying correctly…

Regards,
Nicolas

@ckruijntjens Ahh… i know that fealing, happend to me also., as long as it running fine now… :-) Good to hear you could fix it.

Ok, I think that is my problem.
I only change mariadb Server and use supported kopano centos6 rpm‘s.
So I must accept this warning.

THX

Hello,

unfortunately it does not solve the problem that 2 users with the same user name can not exist in 2 different companies, because the user name must always be unique.

thx

I had the same problem on CentOS 7.

I think I solved this easily by:

adding the amavis user to the group kopano.
Since amavis/sa-learn is now able to read the files in /var/lib/kopano/spamd/spam, it is no longer necessary to do a chow or chmod in kopano-spamd. So I commented these two lines (106,107) out in /usr/lib/python2.7/site-packages/kopano_spamd/init.py, like this:
#os.chown(emlfilename, uid, gid)
#os.chmod(emlfilename, 0o660)
By increasing the loglevel to Info in /etc/kopano/spamd.cfg I could verify that the results are now as expected in the systemlog:

aug 02 07:33:33 server03.xxxxx.local kopano-spamd[17541]: 2019-08-02 07:33:33,488 - spamd - INFO - Learning message as SPAM, entryid: 0000000000D9DA0165C843EBB498FB6BD1E7C5820100000005000000519FE396E2274687B6E78B016896BC6000000000

I’m not sure though if sa-learn is automatically triggered within kopano-spamd on CentOS.

Paul

addition to your defense, i should ask for the folders (createuser.d;createcompany.d etc.) aswell, not just the scripts
:)

but its solved so well - mistakes were made :)
drink more coffee ;)

I’ve upgraded the held packages and everything is back to normal.

Wow LOL lesson learned! hehe thank you!

Go Kopano!

Thank you for the reply when i changed the ldap configuration to /usr/share/kopano/ldap.active-directory.cfg
as you described i noticed that the problem i previously had was gone. I then did a diff between the two files and noticed that
i changed “ldap_dynamicgroup_search_filter” that was why it could not find the group.

root@kobra:/etc/kopano# diff ldap.active-directory.cfg /usr/share/kopano/ldap.active-directory.cfg 45c45 < ldap_user_search_filter = --- > ldap_user_search_filter = (objectCategory=Person) 327c327 < ldap_dynamicgroup_search_filter = kopanoAccount --- > ldap_dynamicgroup_search_filter =

Thank a lot for the help.