@Atomius it will use additional disk space, how much depends mainly on the type of email you receive (many attachments, higher disk usage).

I would say identify such a newly received email and then grep in the directory to find the corresponding eml, e.g. by grapping the subject.
Delete the others to avoid wasting too much space.

@kmeyer said in changing folder names to other languages - error on global "kopano" - python script:

Hi bo,
yes I had modified ist during our conversation. Now it works! Great!
Thanks!

Great! You’re welcome.

Bo

@Gerald said in IMAP issue on Thunderbird with core-8.3.0~788_104.1:

I’ve just installed the new build and my quick initial tests seem to confirm that tonights build has indeed fixed the IMAP problem.
Let’s hope it stays this way.

Glad to hear that!

Bo

Great you got it working. The wierd %s@%s logic is to take out the domains not the users.

Bo

Fixed with Commit 74a6353f7e3 (issue KC-558 ) core-8.4.0~22_11.1.

btw of course happy to login remotely to debug the issue further if needed. if that is possible, please contact me/felix privately.

@Atomius hiya,

I have a feeling that there is a bug in python-kopano, when used against “old” versions of ZCP, which we could probably solve by logging in remotely. would that perhaps be an option…?

thanks!!
mark.

@fbartels
Felix, thanks, I will update via RHEL6-rpm, tomorrow.

As far as I can see:
The PR_TRANSPORT_MESSAGE_HEADERS(_W) -problem is not part of recent merges.

This seems to be a Python 2.6 compatibility issue, too, with the negative effect, that using the PYKO example-scripts might kill your data if header-filtering fails.

bg umgfoin.

Hello Sven,

The php7-mapi package is only build for distributions offering official php7 packages. But no one will stop you from compiling it yourself, if you want to use it.

I found the problem. I had configured run_as_user und run_as_group to kopano. I change it to blank and now it works.

@fbartels

in which case it is fine as it is. Yum localinstall works for RHEL.

@fbartels
Thank you
I solved the topic unsing univention.
Kind regards
Hans

For the record, I have implemented the HAProxy solution and it is working beautifully.

@scottalanmiller said

That’s very true, hopefully in a situation like this you would not have DCs going up and down with any regularity. If you do, that would create a lot of other problems and would explain why the DCs aren’t working as it is. DNS Round Robining is, in theory, how DCs are supposed to work by default, actually. It just has automated harvesting.

Which actually means that a load balancer like HAProxy would not actually do anything, as there is already load balancing in place that is not working properly.

A few years ago, we moved from a Linux based environment (Novell eDirectory) to Microsoft. And during this time we have seems some issues with Microsoft DCs.
First problem is a memory leak (small but noticeable).
Second, Microsoft Servers need a TON more resources!
Third, when the DCs are about to fail, they do so in weird ways. They still respond to network services and all of our SNMP and server monitoring tools can’t detect any problems, but DNS, LDAP and other requests start failing here and there!

HAProxy is intelligent enough to detect this and stop sending requests to that server for a period of time!

@scottalanmiller said in Kopano Core Install Fails on CentOS 7 Due to Missing Package:

Don’t worry about trying to find a fix for this. […]

I’m sorry you feel that way. I just reviewed the parts in question and due to changes in package names (we moved libical and libvmime to more explicitly named packages to avoid package conflicts) the recommendation for package installation was indeed not correct anymore. I have just now pushed an update to the documentation.

Some of the things you wrote I do not want to stay the way so allow me one more reply (no attempt to change your mind, just want to correct some things).

Kopano is not for production use and even talking about installation requires monetary payment.

While the “brand name” Kopano is quite new, Zarafa is already a quite mature product (in other threads you also referred to the product already being ten years old). Talking about installation does not require monetary support, but we of course also have to focus on where to earn money to pay developers and qa & support staff. This on the one hand means that we focus our attention one those distributions that we know have a certain market share and receive updates (or patches as you have called them before) for a longer time. This also means that distributions that only have a short livespan, such as Fedora, OpenSuse or non-LTS releases of Ubuntu are not our primary choice, but provided as-is for community members to play with it.

pretending that there is a community for the open source

just as stated before, the name Kopano is still quite new, and therefore you won’t find too many posts in this forum. The majority of interaction can be found in the “old” Zarafa forums at https://forums.zarafa.com/. We just did not want to migrate all the data. We also see quite a big community around us. Over the years we have developed quite a big partner network, Z-Push (which was initiated by Zarafa) is used in a lot of different software projects and during the last fosdem we also received a lot of positive feedback.

Please don’t regard this as an attack, but I also think that you aggressive bumping did not help with the situation. Over at the mangolassi forum you wrote somewhere, that you were now already the second most active poster here. (too lazy to search for that post right now). You came, flodded the forum with posts, and some users felt they needed to act on it.

@fbartels said in Kopano Core Missing Directory on Ubuntu 16.04:

@scottalanmiller that remark is obsolete. I have just now removed it from the manual. You can keep the default value for the plugin_path.

@fbartels said in Kopano Core Missing Directory on Ubuntu 16.04:

@scottalanmiller that remark is obsolete. I have just now removed it from the manual. You can keep the default value for the plugin_path.

Ah, thanks. I know that he got it working eventually, but was confused by that.