Hi Forum,

I find the Problem.
php 56 was installed to /opt/rh/rh-php56/ and the command line php programm was stored in

/opt/rh/rh-php56/root/usr/bin/php

php was not found on this Maschine on the command line, so I make a symbolic link:

ln -s /opt/rh/rh-php56/root/usr/bin/php /usr/bin/php

now hex2bin was found on the command line and everything is fine.

@eric said in Access and manage Kopano contacts from other clients (e.g. Thunderbird):

in combination with sabre-zarafa

Instead of sabre-zarafa you could also give kdav a try. It’s a new implementation of caldav and cardav: https://forum.kopano.io/topic/1341/request-for-feedback-new-caldav-and-carddav-implementation-for-kopano

Hi @ralphy,

from the version given above it sounds like you have a Kopano subscription and therefore access to our support. I would recommend to open up a support case with them, since this is a community forum and will probably not provide the level of service you need to resolve the issues on your installation.

Even better,

https://packages.debian.org/search?keywords=kopano
so dont worry the Debian devs will keep this going.

Commits have been made (pkg versions 8.6.7.9 and 8.6.81.266) to cease relying on en_US being present.

I find this Problem.

There is a wrong path in /etc/opt/rh/rh-php56/php.d/mapi.ini

; Enable MAPI extension module extension=mapi.so ; Adding path with php mapi classes to include dir include_path="${include_path}:/usr/share/kopano/php

must

; Enable MAPI extension module extension=mapi.so ; Adding path with php mapi classes to include dir include_path="${include_path}:/usr/share/kopano/php/

@joost

Hi can i also search on sender? Instead of subject?

Try this subject https://forum.kopano.io/topic/1704/kopano-search-issue
It seems to have solved the issue.

Hej decibel83.

Kopano isn’t Courier and the gateways may run different.
First of all…it should work.

Please post your system-environment…versions a.s.o. Did you tested WebApp or DeskApp for your clients? This is, maybe, the better way to manage many clients

Hej.

You say “old Debian machine” …which version of Debian is it you run Zarafa?

Hello.

Sorry for the delay…
The Resolution about kopano-cli was a Servername configured in server.cfg with German-Umlauts äöü a.s.o.

# Name for identifying the server in a multi-server environment # server_name = Ätschibätsch ###does not work

But only kopano-cli bring up this error. I havn’t tested this with newer versions.

@jmx said in Internal mail to 'everyone' is undelivered:

So i’ve got the feeling the everyone@domain.tld is not used for the ‘Everyone’-group by default any more?!

Ah, now we’re getting somewhere. The problem here is that these internal groups cannot be resolved from the outside and therefore have no email address. But this has been like this for as long as I can remember.

My guess would be that you had a custom group on your old system which has the everyone@domain.tld address and that resolved to all your users.

To resolve this, it seems to be safe to go through the following procedure.

** THIS PROCEDURE IS FOR INSTALLATIONS WITH THE ATTACHMENTS HELD IN THE DATABASE ***

You have two possibilities:
A) leave the MAPI object believe they have an attachement, but when you try to open such, you will get an error message
B) entirely discard the reference to such attachments.

To fix the above error message, method A is sufficient

I would recommend version A, because in this case you get a feedback from Kopano that the attachement is broken. This seems to be better than not knowing at all there used to be an attachment. Additionally, method B is probably incomplete.

PROCEED AT YOUR OWN RISK. I’M NOT A KOPANO SUPPORTER, OR RELATED TO KOPANO OTHER THAN I’M A USER. I CAN NOT BE HELD LIABLE FOR ANY DATA LOSS IF YOU FOLLOW MY INSTRUCTIONS*

MAKE A BACKUP OF YOUR PRODUCTION DATABASE AND FEED IT INTO A TEST SYSTEM. TRY THE PROCEDURE ON THE TEST SYSTEM BEFORE FIXING YOUR PRODUCTION*

do the basic cleanup of the attachments by running /usr/share/doc/kopano/perl -w db-remove-orphaned-attachments /etc/kopano/server.cfg Stop kopano server if you choose method A, delete all records from singleinstances that do not have any records in lob: delete from singleinstances where instanceid not in (select instanceid from lob); if you choose method B, delete the records in hierarchy that claim to have an attachement, but the attachment is not in the database: delete from hierarchy where type=7 and id not in (select hierarchyid from singleinstances); restart kopano-server

NOTICE: following method B probably leaves other stubs in the databse. It seems to work, but is far from doing a surgery on your data. It’s more like the sledgehammer.

@rjvbaal said in Upgrade from core-8.6.80.1248 > core-8.6.81.171 gives reply issues with mime coding in to header:]

It only appears with external mail before the update.

I’ll check this out.

i think the core don’t use these packages anymore?

Correct, they should get removed when running autoremove:

~#: apt-get autoremove

… and requested the supportes to close it unprocessed. I found out what’s wrong, and the solution is at https://forum.kopano.io/topic/1697/database-corruption

All I can say is, you are right, and then (!!curses at the old config directives!!)