Hello @RemoStrotkamp,

i’ve found something thats related (maybe).

run “locale -a |grep “de_DE”” on your system. my installed language is “de_DE.utf8” - not “de_DE.UTF-8”.

Maybe this is just a naming problem.

i remember the same issue in ZCP 7.2.4 - after upgrade all new inboxes where “Inbox” instead of “Posteingang” - Changed the value to “de_DE.UTF-8” (because it was written in the guide) - But it didnt work. - After using the system-named locale “de_DE.utf8” everything works.

Coffee_is_life

Hi @Steampower ,

you can find some more detailed information about HA for Kopano at https://documentation.kopano.io/kopanocore_administrator_manual/high_availability.html

a mariaDB/Galera Cluster

the last time I check galera it had the “drawback” of requiring a full mirror of all databases on each node. depending on the amount of kopano servers and galera instances this can mean quite a lot of overhead. Depending on what else you are running on galera you may want to establish a dedicated sql server for kopano, since i/o is crucial for performance.

But is it possible to run several Kopano Core servers connecting to these shared resources (and maybe run a load balancer between the servers and the clients)?

yes, and through the possibility to define listening sockets and configuration locations you are even able to run multiple kopano-server processes on the same node (this is what we utilise in the described pacemaker scenario in the manual).

The one thing to keep in mind though, is that each users has an assigned “homeserver”, meaning you cannot balance users between backend servers, but you can use standard loadbalancing mechanisms to distribute user access between your frontend (webapp and z-push) nodes.

If you have any further question let me know and I can establish contact to our professional services department, which is also able to prepare a concept tailored to your environment.

There was a problem with the UCS 4.2 postfix integration. It should be fixed once the UCS server is updated to at least errata 49

@leroyk2 said in Backup could not serialize attachment:

I am storing the attachments in the database instead of the filesystem. Could that be a problem?

That may or not may be.

The ticket in question (and probably what @sebschremser is referring to) is by the way https://jira.kopano.io/browse/KC-575. But this is mainly to remove the ugly traceback and print an actual error message instead. This is fixed for the upcoming 8.4 release and not 8.3.1.

Up until this point we are unable to reproduce the “no access” error internally and don’t know why it occurs and therefore are unable to fix (especially since kopano-backup is running as an admin which should always have access). So if you come across a way to force this error I am all ears.

HI All,

Please be also aware that installation on Fedora 25 do not work in the moment, only Centos 7 i have tried.

with best regards
HK

issue should be resolved with >=8.4.0~813

Hi, thanks for all your feedback. I did not yet have the time to verify the fix myself, but its good to hear that the issue has been resolved for you.

OK i missed to renew my free / home Zarafa subscription and i need to wait for the support
contacting me.

@darootler said in Incident: inline.txt attached in mails:

The ticket https://jira.kopano.io/browse/KC-624 linked from @jengelh is just misleading and not fixing the issue described above.

that’s what I was saying all along. it does describe something different, than in your first post.

I am investing much time to do the “testing part” for you, seems like you do not have any testers for the daily builds, and all i earn is “get a subscription”. What i do is just work for you!

The master branch is indeed only fully tested and qa’ed once it has been branched off for a release until that point it will only receive punctual tests (apart from a battery of automated tests).

But in open source its the mutual agreement that for the software/code that you receive you contribute back, either by giving feedback in case you encountered an error or pushing back code for such errors and new features.

All this never happened during the times the product was called zarafa…

Mostly since you now work on the master branch instead fenced off releases and we have been busy over the last few releases in refactoring the majority of the code.

@fbartels Quick update - the perms fix has resolved this issue.

Thanks again.

Replying to myself. When running kopano-server as user “root” then PAM authentication works as expected. Is this a bug or a configuration error?

after update to kopano core-8.4.0-792_149.1-Debian_8.0-amd64, send mails to local and external users from webapp, but the log “<= bdb_substring_candidates: (mail) not indexed” persists.

@robing Thanks again for the script :thumbsup:

I would appreciate if you could provide more information on why the caldav client was able to bypass the protected system folder’s permissions before I escalate the bug/issue with Fantastical’s dev team.

Best
Wiz

as long as the database revision stays the same a rollback is always possible and quite painless.

Personally I would also always remove the failed upgrade from the versions table, but if the downgrade is only for a quick test starting kopano-server with the --ignore-database-version-conflict is of course also possible.

Thanks for all your reports. I have now created https://jira.kopano.io/browse/KC-709 to officially investigate this error.

I’ve set the rule now via the users webapp - so dont rush it :)

feel free to text me if you need a test-subject :)

//EDIT: btw in https://stash.kopano.io/projects/KSC/repos/core-tools/browse the delete-items section has “localize-folders.py” instead of “delete-items.py”
and the “create rule with multiple conditions”-example should switch with “create rule with one condition”-example :)

Coffee_is_life

@ck0ne, pls post your …/z-push/backend/kopano/config.php

there should be something like

define('MAPI_SERVER', 'default:');

you use local socket or tcp connection?

Coffee_is_life

@riomeister said in kopano-gateway 8.4 / Apple Mail:

yesterday we had problems with the version 8,4,0,596. The content of e-mails was no longer displayed in the web app. We went back to version 8,4,0,522. The problems with the Apple Mail were and are already present here.

sounds a bit like https://forum.kopano.io/topic/296/bugreport-kc-8-4-0-667_139-error-while-accessing-html-mail-items-in-webapp, I was not able to reproduce this with the latest master build though.

@riomeister said in kopano-gateway 8.4 / Apple Mail:

Where can we send the eml?

if you have a subscription please send the example to our support. if you down own a subscription please send it to feedback at kopano dot io and make a reference to this thread.

Hi @robertwbrandt,

@robertwbrandt said in Kopano-backup errors:

First: I found that a worker_processes of 1 in the backup.cfg file took a ridiculous amount of time to complete. and 20 maxed out the box and made it un-usable. I finally settled on 10 which puts a heavy load on the server, but in the middle of the night, I don’t care.

yes, it was the same with the old zarafa-backup. it uses one thread by default. the amount of threads you can use depends on your hardware, amount of users and configuration of server.cfg, so its hard to give a general recommendation.

@robertwbrandt said in Kopano-backup errors:

Second: I find that after I start the backup, even after the process appears to end, there at 10 additional kopano-backup threads running in the background - always.

please contact our support for this, since you have a subscription

@robertwbrandt said in Kopano-backup errors:

Third: I see these errors constantly in the backup.log file??

please contact our support for this, since you have a subscription

@robertwbrandt said in Kopano-backup errors:

Fourth: I’ve found that the kopano-backup executable doesn’t seem to work like the MAN page says it should. For instance:

the path is needed when items should be restored from an existing set only. please have a look at the examples at the end of the man page, to see if this clears things up for you.

@Joost said in [Bugreport] Periodical SIGSEGV in php-fpm while using webapp with KC 8.4.0~596 (utf-16.so):

Please upgrade your systems to this version (it’s just been published to the community) and let us know if the problem has been resolved.

Hi Joost,
thanks - build 8.4.0-644 fixes above issues on CentOS 6.9.

I ran into one problem while applying the update (yum update *.rpm):

php-xapian-1.2.21-5.1.x86_64.rpm postulates dependencies on php5 although it should depend on php56 (for the RHEL6 packages).
rpm -U php-xapian-1.2.21-5.1.x86_64.rpm --nodeps was a workaround, but I think this package still needs fine-tuning.

++umgfoin.