@ebroch
The service has not been available for a long time.
You are in the wrong area ;)
I think they were hacked ;)

https://forum.kopano.io/category/25/synchronising-mobile-devices-via-z-push

If your database is only used on this host, you may also use:

skip-external-locking skip-name-resolve

57 connections is not a whole lot, I would not limit that anyway - the default is 150.
“query_cache_size” and “query_cache_limit” with InnoDB are a difficult topic - it is usually better to set “0”.

You may also use multiple buffer pools for better concurrency with:

innodb_buffer_pool_instances

I usually match my number of cpu cores with the number of buffer pools and io-threads.
The overall buffer pool size is calculated “innodb_buffer_pool_instances” * “innodb_buffer_pool_size”.

Why are you increasing “innodb_lock_wait_timeout” ?

More is not always better…

@boospy
It seams you did not change all references from “repo.z-hub.io” to “download.kopano.io”.

@fbartels But the wiki is at z-hub.io, right? This post links to the wiki using z-hub.io: https://forum.kopano.io/topic/3615/z-push-2-6-2-final-release

@junglemarc like I have written before I would suggest you to use Kopano One. You can find instructions for Kopano One and Ubuntu 20.04 at https://kb.kopano.io/display/WIKI/Kopano+One+on+Ubuntu+20.04+-+quick+installation+instructions.

The repo configuration that you can download in the portal is for the individual products, but for new installation we recommend to use Kopano One. If you still want to use the individual repositories you can still configure them manually. Instructions for that can be found at https://kb.kopano.io/display/WIKI/Configure+repositories and https://documentation.kopano.io/kopanocore_administrator_manual/installing.html#installing-kopano-core-through-the-kopano-package-repositories

Nevertheless I notified our internal it that this wizard seems to miss the ability to select Ubuntu 20.04.

@fbartels you are correct.

I did a reboot on the server, and it did wonders.

kopano-search, kopano-server processes not as cpu hungry anymore.

The search function has been good past week.

Case closed :P

Marc

@meyca said in Stable version is at 8 - why have nightlies version 11?:

And when will the current release fix for a memory exhaustion issue forwarded to the community and the other versions?

Changes are done first in the master branch (the one branch where you can downloads nightly binary builds of) and are from there backported/cherry-picked to the relevant release branches (8.x, 9.x, …).

The specific change was first introduced in the master branch in https://stash.kopano.io/projects/KC/repos/kopanocore/commits/512457466b87039c6a8d25887fdaca6173619546 and then picked into the 8.7 release branch for the 8.7.20 release as https://stash.kopano.io/projects/KC/repos/kopanocore/commits/2ddd63cd55e236f382124ee2b6d7f41b12986848.

I have been successfully using the release on openSUSE Leap 15.2 for quite some time now. It is very close to the latest version (10.0.5) and has been VERY stable. Leap is being maintained on a “release” basis, as opposed to Tumbleweed which updates daily. If you’re really looking for something for your SMB, I highly recommend Kopano on the Leap platform. Very easy to manage, too, IMHO.

I’d be happy to have a single user. However I’d also think a baseline + per-user cost could make sense as requirements are different … guess some may have their whole family on Kopano, for me its just me.

sorry for the late reply, now my problem is solved now, I also search this on the Internet and on Youtube as well, and I found this post, this is really helping me a lot, thanks again my problem is solved now

@burgessja yes, that is pretty much the expected way unless there would be official builds from us. The good thing about go is that you could compile it on a different system (or in a container) and just copy the resulting binary to your target system.

@worms By looking around, kopano-cli is actually a python file… just had to install an older version of kopano-core somewhere to get the file on my current install…
For now it works… until the next update where Kopano dev will remove the ability to loggin as a user with the python lib :)
I hope this will not happens… otherwise, see you next year for probably my last good bye :’(

@bhuisman openSUSE’s build service is usually really good at having the latest (within reason) versions of packages but with kopano it seems very hit and miss. I’ve been using kopano/zarafa for many years now and for a lot of that time I’ve needed to use the nightlies from kopano/zarafa but for almost the same amount of time the versions built and distributed via openSUSE have been pretty recent so I’ve used their repository.

I’d much rather just subscribe to a repository and allow updates to just be available each time I update my server rather than have to keep downloading nightlies and installing them by hand, hence my preference for using the openSUSE packages. I guess it’s reached the point where I need to go back to the nightlies direct from kopano.

Thanks for you comments.

Ian

@fbartels
Thanks for confirming. I guess I’m at where I’m at.

I may look into the nightlies if they are reasonably stable.

I can’t end up in the situation where I have an unstable mail system, as our personal email is used for all sorts of communication from my son’s school, bills, etc.

If 8.7 seems to work well, I may just run it with no internet access except postfix/mta which gets updated by Ubuntu & require my family to vpn in to use webapp & imaps. Everything else is listening on sockets/localhost at the moment.

@hinz_linux

Can you try to run https://stash.kopano.io/projects/KSC/repos/core-tools/browse/ipf-imap-to-note

Thank you @AnotherAndy and @mcostan for your answers :)

i did notice Kopano doesnt host its own product. i think this is a shame :)

As a result, i have now setup a kopano server with AD myself :) took me a night but its working :)

@ishouldhavebeenaqatester
I think I have this solved!

After reading more on postfix, the logs were showing local delivery, so I changed

virtual_transport = lmtp:127.0.0.1:2003

to

mailbox_transport = lmtp:127.0.0.1:2003

So you my ask next: Why not use:

mailbox_transport = lmtp:unix:/var/spool/kopano/dagent.sock

?

Note: I also had to change /etc/kopano/dagent.cfg to also run on 127.0.0.1:2003

When postfix runs chrooted, it won’t have access to the socket that runs non-chrooted, so 127.0.0.1:2003 is a safer bet.

I hope this can help someone.

Hi @mcdaniels,

did you manage to do your update?

Disclaimer: I cannot recommend to use the nightly builds for a production deployment as they are not covered by our support.