Kopano Core 8.2.0 final is now available
As the name implies Kopano Core sits at the heart of every Kopano environment and is therefore a key figure in our promise to deliver stability and extendability of Kopano’s proven communication platform. In version 8.2 we introduce improvements on SSL hostname verification, LDAP configuration organisation, migration tools and many more enhancements. Please read this release announcement carefully, since it contains important information for upgrading to this latest major version.
“Kopano Search has been updated to allow recursive searches in shared stores. This requires a small update of the search data, which can be performed by executing kopano-search-upgrade-findroots.py.”
# kopano-search-upgrade-findroots.py from: can't read /var/mail/MAPI.Util /usr/sbin/kopano-search-upgrade-findroots.py: line 3: import: command not found /usr/sbin/kopano-search-upgrade-findroots.py: line 12: $' \n\nas of Kopano-Core 8.2, PR_STORE_SUPPORT_MASK has STORE_SEARCH_OK enabled\nfor every store. this means that this script needs to run at upgrade time,\nto create the findroots and ACLS so that cross-store searches will actually \nwork.\n\n': command not found /usr/sbin/kopano-search-upgrade-findroots.py: line 14: FINDROOT_RIGHTS: command not found /usr/sbin/kopano-search-upgrade-findroots.py: line 16: syntax error near unexpected token `(' /usr/sbin/kopano-search-upgrade-findroots.py: line 16: `def main():'
Hi @Gerald ,
thanks for bringing this to my attention. The current version of the script is missing the she-bang and therefore has to be executed like
I have created https://jira.kopano.io/browse/KC-553 to fix this for the next iteration of the packages.
Hi, when can we expect the Update to be available in Univention UCS App portal to Update our UCS installations ?
the update to enable 8.2 compatibility in Univention has been uploaded last week and is currently awaiting approval. The update does bring the ability to easier update the Kopano Core packages through our official repositories, but no actual packages. Once this has proven itself the same mechanism will be rolled out for the other Kopano Univention apps .
Great sounds great to have the ability to use the Kopano repos in future !!!
thanks & rg
We upgraded this morning to 8.2.0 - final and noticed a warning we have never seen before in server.log
Mon Feb 20 08:03:55 2017: [warning] Object not found unknown user "Everyone": Everyone
The upgrade itself went without a hitch and we also executed python /usr/sbin/kopano-search-upgrade-findroots.py … so no issues there.
Also, can you look into the possibility of including an archive of the source at the time of release (for both stable and pre-final/beta releases) in the supported download area as we are compiling our own mapi version against remi’s php56 on Centos 7?
Finally, we like to know why Kopano’s mapi.so version is way smaller in size than the version we compile - ours is 1.7MB and Kopano’s is ~ 400KB… We used the instructions at https://documentation.kopano.io/kopanocore_administrator_manual/installing.html?highlight=compile as reference. Again, this is on the latest Centos 7 release with only remi’s php56 and MariaDB 10.1 installed - what’s your secret sauce?
As reference, we use:
./configure --enable-epoll \ --enable-unicode \ --disable-static \ --with-userscript-prefix=/etc/kopano/userscripts \ --with-quotatemplate-prefix=/etc/kopano/quotamail \ --enable-release
We previously used --enable-swig, --disable-testtools, --enable-python, --enable-tcmalloc in addition to the above, however, the configuration script gave a warning that these options were no longer recognized so we dropped them.
Hello again @fbartels
Another issue with this release:
Wed Feb 22 05:06:49 2017: [notice ] Startup succeeded on pid 9608 Wed Feb 22 05:06:49 2017: [crit ] ---------------------------------------------------------------------- Wed Feb 22 05:06:49 2017: [crit ] Fatal error detected. Please report all following information. Wed Feb 22 05:06:49 2017: [crit ] Application Server version: 8,2,0,523 Wed Feb 22 05:06:49 2017: [crit ] OS: Linux, release: 3.10.0-514.6.1.el7.x86_64, version: #1 SMP Wed Jan 18 13:06:36 UTC 2017, hardware: x86_64 Wed Feb 22 05:06:49 2017: [crit ] Thread name: z-s: 127.0.0.1 Wed Feb 22 05:06:49 2017: [crit ] Peak RSS: 26568 Wed Feb 22 05:06:49 2017: [crit ] Pid 9608 caught SIGSEGV (11), traceback: Wed Feb 22 05:06:49 2017: [crit ] Backtrace: Wed Feb 22 05:06:49 2017: [crit ] #0. /lib64/libkcutil.so.0(+0x2d8c0) [0x7fdca74a48c0] Wed Feb 22 05:06:49 2017: [crit ] #1. /lib64/libkcutil.so.0(+0x23c88) [0x7fdca749ac88] Wed Feb 22 05:06:49 2017: [crit ] #2. /lib64/libkcutil.so.0(generic_sigsegv_handler+0x1d6) [0x7fdca749aff6] Wed Feb 22 05:06:49 2017: [crit ] #3. /lib64/libpthread.so.0(+0xf370) [0x7fdca3b8a370] Wed Feb 22 05:06:49 2017: [crit ] Signal errno: Success, signal code: 1 Wed Feb 22 05:06:49 2017: [crit ] Sender pid: 0, sender uid: 0, si_status: 0 Wed Feb 22 05:06:49 2017: [crit ] User time: -131939379829056, system time: -131906613379592, signal value: 0 Wed Feb 22 05:06:49 2017: [crit ] Faulting address: (nil), affected fd: 0 Wed Feb 22 05:06:49 2017: [crit ] When reporting this traceback, please include Linux distribution name (and version), system architecture and Kopano version. Wed Feb 22 05:06:49 2017: [warning] Killing self with signal had no effect; doing regular exit without coredump. Wed Feb 22 05:09:15 2017: [ notice] Starting server version 8,2,0,523, pid 10817 Wed Feb 22 05:09:15 2017: [notice ] Listening for TCP connections on port 236 Wed Feb 22 05:09:15 2017: [notice ] Listening for priority pipe connections on /var/run/kopano/prio.sock Wed Feb 22 05:09:15 2017: [notice ] Listening for pipe connections on /var/run/kopano/server.sock Wed Feb 22 05:09:15 2017: [notice ] Connection to database 'kopano' succeeded Wed Feb 22 05:09:15 2017: [notice ] Loading searchfolders Wed Feb 22 05:09:15 2017: [notice ] Startup succeeded on pid 10817
Starting kopano-server is touch and go (not consistent) as it crashes requiring another start to actually startup.
Fyi, my upgrade went well, just “yum upgrade”, very slick, BRAVO!
When will this be available as it now some weeks later ?
@externa1 we have a bit of a disagreement on how the repository integration for Univention should be achieved. Hopefully we have new idea until the end of the week (as Univention is also quite busy with their upcoming release).
any news on this? I try to avoid answers from the support alla “please update to latest release” and I can’t do this :(
@Atomius sadly Univention is still busy with their upcoming release. If you’re feeling adventurous, then you can activate their test appcenter with the following command:
ucr set appcenter/index/verify=no update/secure_apt=no repository/app_center/server='appcenter-test.software-univention.de'
This will then give you Z-Push 2.3.5 and the Kopano App with Reposupport for 8.2.x.
EDIT: or less invasive. Just add the following line to
/etc/apt/sources.list, then do an apt-get update && apt-get upgrade.
deb http://repo.z-hub.io/kopano4ucs/Univention_4.0/ /
Afterwards you can follow https://wiki.z-hub.io/display/K4U/Updating+Kopano+packages+directly+from+the+Kopano+download+server
It’s working with ucr set. Now I’m a real Betatester instead of half one ;)
Is that similar to 8.2?
@Atomius thats just the version of the “app”, after you have enabled the repository like explained on the wiki page, there should be a package update which brings you to 8.2.1 (you can see the actual version in the WebApp settings).
Everything went fine. System now runs 4.1-4 errata360 (after disabling fetchmail repo)
Thank you for your support ;)
@Atomius please keep your posts in English.
I also got the news a few hours ago, that the update is now officially available.
sorry for that, it’s a bit confusing as the support team answered in German :D changed that.
No problem, I think this situation would repeat often, as the development is faster than the audition ;)
@fbartels since the changelog mentions the “Extended and enforced SSL hostname verification” with additional configuration needs I’d like to know if UCS is also affected.
Since the UCS Apache proxies the connections, correct?