TO BE CLOSED I turned back to where i used to be, and “upgraded” to Ubuntu 14.04(I used to have 12.04 before the crash). Zarafa 7.1.11-46050 is still working fine, now the mails get delivered in and out, Fetchmail can again deliver to my local users and that is it.
I know that latest in 04/2019 I will have to take care to upgrade to something higher than Ub14.04, but then other parameters in my life may change aswell ;-)
Thanks to the community for your support anyway, even if I cannot call Kopano a “success story” for me. Bye, Heinrich <br>BTW, I tried Kollab Server, which didn’t work for me either …
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.
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 are other odd things with the foo2 user’s store too.
I created a Contacts folder with the recreate system folder python script and the folder is listed in webapp but isn’t listed using the listfolders.php in z-push.
php /usr/share/z-push/backend/kopano/listfolders.php -l foo2
Available folders in store ‘foo2’:
@sreek which versions of Kopano and Univention are you using now and have been using before?
I’ve read reports about Kopano not starting after reboot after upgrading to UCS 4.2 from some users on the Univention forum, but one the hand I was never able to reproduce with the information provided.
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.
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.
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.
Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.